Re: [Xen-devel] uint64_aligned_t not compatible across gcc versions

["Jan Beulich" <jbeulich@xxxxxxxxxx>]

>> Further looking into how it is being used and therefore into the uses of
>> XEN_GUEST_HANDLE_64 I am not really clear about the intentions of that
>> macro and its companions: Reserving a 64-bit slot for a pointer would seem
>> nice for doing the compatibility layer, but turns out useless if the 32-bit
>> native implementation doesn't check the upper half of passed in values, as
>> that implies that the 64-bit compatibility layer must not assume these upper
>> bits are all zero or else it wouldn't be binary compatible.
>
>Yes, the aim is to avoid the need for a 32-on-64 shim for the domctl and
>sysctl hypercalls. I guess we'll end up with a semi-automated scheme for the
>other hypercalls anyway, but since we don't guarantee compatibility on those
>interfaces we may as well make our lives as easy as possible.
>
>Guest handle fields are *only* written by the set_xen_guest_handle() macro
>in the tools -- you'll see that I modified that macro to zap the high bits

This doesn't seem to be that way: I didn't do an exhaustive search, but at
least struct sched_poll has a handle member and is being intended to be
called from the kernel. I'm also thinking that rather than inventing yet
another abstraction, re-using the handle stuff for the few remaining
pointers in the public headers would be more appropriate (which is what
I'm actively doing at this moment).

>if the field is 8 bytes. This should be sufficient?

No, I wouldn't want to trust the user mode tools in the hypervisor. Hence I
see a need for checking the high bits in 32-bit native or not reading them in
64-bits compat mode.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel