Re: [PATCH RFC v2 6/6] KVM: introduce a new API for getting dirty bitmaps

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 04/23/2010 03:46 PM, Arnd Bergmann wrote:
On Friday 23 April 2010, Avi Kivity wrote:
On 04/23/2010 03:27 PM, Arnd Bergmann wrote:
Using a 64-bit integer avoids the problem (though perhaps not sufficient
for s390, Arnd?)

When there is only a __u64 for the address, it will work on s390 as well,
gcc is smart enough to clear the upper bit on a cast from long to pointer.

Ah, much more convenient than compat_ioctl.  I assume it part of the
ABI, not a gccism?
I don't think it's part of the ABI, but it's required to guarantee
that code like this works:

int compare_pointer(void *a, void *b)
{
	unsigned long ai = (unsigned long)a, bi = (unsigned long)b;

	return ai == bi; /* true if a and b point to the same object */
}

We certainly rely on this already.

Ah so the 31st bit is optional as far as userspace is concerned? What does it mean? (just curious)

What happens on the opposite conversion?  is it restored?

What about

int compare_pointer(void *a, void *b)
{
	unsigned long ai = (unsigned long)a;
	void *aia = (void *)ai;

	return a == b; /* true if a and b point to the same object */
}


Does gcc mask the big in pointer comparisons as well?

--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux