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