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

[Hollis Blanchard <hollisb@xxxxxxxxxx>]

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