WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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


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