Re: [Xen-devel] 32/64-bit hypercall interface - padding

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 4 Oct 2005, at 23:04, Hollis Blanchard wrote:

> #define PAD_POINTER(type, name) \
>     union { \
>         char _pad[sizeof(u64) - sizeof(void*)]; \
>         type *ptr; \
>     } name;
> typedef struct {
>     ...
>     PAD_POINTER(vcpu_guest_context_t, ctxt);
> } dom0_setdomaininfo_t;
>
> That looks nice, but it may confuse tools like cscope. Of course, so 
> would the
> original XENIF_PTR macro idea. So I think I like the first better.
All approaches other than XENIF_PTR are broken in that they do not 
initialise the high-order bytes of the u64 field to zero. A 32-bit 
toolset will set only the low 4 bytes, leaving 64-bit hypervisor to 
read garbage for the high-order bytes.
Here is how I would define these macros for ppc:
define XENIF_PTR(type, name) union { u64 u; type t; };
define xenif_pack_ptr(field, var) <do type check>; field.u = (unsigned 
long)var
define xenif_unpack_ptr(var, field) <do type check>; var = (void 
*)(unsigned long)field.u
Where <do type check> does the type-check trick demonstrated by our 
min/max macros in include/xen/kernel.h. Something like:
    const typeof(var) _x = 0;
    const typeof(field.t) _y = 0;
    (void)(&_x == &_y);

Note how the correctly-typed field of the union is used only for 
compile-time checking. Run-time data transfer is done entirely via the 
u64 field. The compile-time type check has no run-time overhead.
For x86, those macros are all defined as the obvious 'no-ops'.

 -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel