| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] uint64_aligned_t not compatible across gcc versions
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
|
|
|
| |
|
Home