Re: xen bits broke x32 build

[David Woodhouse]

On Mon, 2023-04-03 at 08:46 +0200, Philippe Mathieu-Daudé wrote:
> > > Well. Maybe xen support should be disabled entirely on x32.
> > > Or maybe x32 should be declared as unsupported entirely.
> > > I dunno.
> > 
> > We rely heavily on the struct layouts being precisely the same,
> > since these are ABI for the Xen guests. Wherever there was some
> > 32/64 compatibility issue — and often where there wasn't — that's
> > why I littered it with those build assertions.
> > 
> > But while there are enough in there to sanity check the i386 vs.
> > x86_64 ABI differences, I wouldn't swear that I've put in enough
> > checks for x32. So "it builds without hitting an assertion" does
> > not necessarily mean it'll be *correct*. Let's disable it on x32.
> 
> Does "(unsigned) long" type mix well with "ABI"?

No, but this is Xen. The i386 and x86_64 ABIs are different.

My favourite Xen ABI for this is the vcpu_runstate_info:

struct vcpu_runstate_info {
    int state;
    uint64_t state_entry_time;
    uint64_t time[4];
};

That's different between i386 and x86_64 not because of any of the
sizes, but because of the *alignment* differences. Giving us four bytes
of padding between 'state' and 'state_entry_time' in the x86_64 (and
x32) version, and this for i386 compatibility mode:

struct compat_vcpu_runstate_info {
    int state;
    uint64_t state_entry_time;
    uint64_t time[4];
} __attribute__((packed));

I suspect that an x32 build could probably get away with supporting a
32-bit guest, but 64-bit guest support would be entirely hosed. And
it's the *compat* structures I've put the sanity checks on, not the
native ones.

smime.p7s
Description: S/MIME cryptographic signature