[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.