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: Jan Beulich <jbeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] uint64_aligned_t not compatible across gcc versions
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Mon, 28 Aug 2006 16:35:38 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 28 Aug 2006 08:44:58 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <44F328A7.76E4.0078.0@xxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcbKt5x+2vGUxzaqEduFWwANk04WTA==
Thread-topic: [Xen-devel] uint64_aligned_t not compatible across gcc versions
User-agent: Microsoft-Entourage/
On 28/8/06 4:32 pm, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

>> 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.

The kernel also uses set_xen_guest_handle in all cases. This is checked by
the compiler because guest handles are structural types and so cannot be
directly written with a scalar value.

> 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).

This isn't a new abstraction. All the old accessor functions work as they
always did on the Xen and guest sides of the interface. It's just a change
of size and alignment -- an implementation detail from most p.o.v.

Changing the non-handles to be handles is debatable. Those pointers are in
interfaces that need backward API and ABI compatibility. I guess it depends
how much effort it saves in trying to deal with them specially in a script.

>> 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.

Well, it's not really an issue of trust imo. In this respect they can only
hurt themselves by passing a 'dirty' 64-bit field that fails validation
checks on 64-bit Xen. And it's unlikely there'll be a programmer error here
because it would be difficult to initialise a guest-handle field without
using the correct macro.

OTOH, extra checking rarely hurts and would be easy to add.

 -- Keir

Xen-devel mailing list