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

On Sep 30, 2005, at 3:03 AM, Keir Fraser wrote:

On 30 Sep 2005, at 01:54, Andrei Petrov wrote:

How about writing a script that converts the Xen public headers into a
set that, when compiled on 32-bit ppc, match the 64-bit ppc layout?
That might be saner than trying to manually finesse our headers around
the ppc abi so that building in 32-bit or 64-bit environment both
happen to give same binary layout.

If this type of ABI compatibility is needed, interface data structures should be declared platform-independantly, i.e using 'sized' types (yeah, field alignment should be taken care of too).

Absolutely agree.

That'll guarantee 32/64 bit independance and that's good thing to have. Once defined it can be managed in controlled way. There could be penalty involved for using larger data types than neccessary, but that can be resolved having 32-bit(or 64-bit, depending whichever is attractive as basic)
hypercall subset.

When we previously had this, by defining packed structs, there were plenty of screams that it wasn't ANSI compliant, and that performance sucks on some architectures. At the time there seemed no good reason for cross-ABI compatibility (we don't plan to stuff these structs into network packets, for example).

The complaints I remember were specifically about using GCC's __attribute__((packed)) extension. Properly laying out the structures and/or using explicit padding is a different solution.

Example:
typedef struct {
    /* IN variables. */
    domid_t       domain;
    unsigned long max_pfns;
    void         *buffer;
    /* OUT variables. */
    unsigned long num_pfns;
} dom0_getmemlist_t;

This could be fixed by laying it out like this:
typedef struct {
    /* IN variables. */
    u64 max_pfns;
    u64 buffer;
    domid_t       domain;
    char _pad[6];
    /* OUT variables. */
    u64 num_pfns;
} dom0_getmemlist_t;

Or easier, losing the IN/OUT sections:
typedef struct {
    u64 max_pfns; /* in */
    u64 buffer; /* in */
    u64 num_pfns; /* out */
    domid_t domain; /* in */
} dom0_getmemlist_t;

And yes, pointers will need to be "fixed" into u64s.

As for performance, it does take an extra memory reference on x86 when assigning from a 32-bit value into a 64-bit field, but I would expect that cost to be insignificant compared to the cost of a hypercall. Maybe doing 64-bit math on x86 would be significantly slower, but that's not what we're talking about...

--
Hollis Blanchard
IBM Linux Technology Center


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