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

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel