This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] uint64_aligned_t not compatible across gcc versions
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Mon, 28 Aug 2006 16:32:23 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 28 Aug 2006 08:32:18 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C118C3FE.EA6%Keir.Fraser@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <44F31DE2.76E4.0078.0@xxxxxxxxxx> <C118C3FE.EA6%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>> 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.


Xen-devel mailing list