[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] uint64_aligned_t not compatible across gcc versions
>> 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |