On 27/03/2025 8:21 am, Jan Beulich wrote: > On 27.03.2025 01:44, Andrew Cooper wrote: >> On 26/03/2025 5:47 pm, Oleksii Kurochko wrote: >>> diff --git a/xen/include/xen/config.h b/xen/include/xen/config.h >>> index d888b2314d..dbbf2fce62 100644 >>> --- a/xen/include/xen/config.h >>> +++ b/xen/include/xen/config.h >>> @@ -98,4 +98,13 @@ >>> #define ZERO_BLOCK_PTR ((void *)-1L) >>> #endif >>> >>> +#define BYTES_PER_LONG __SIZEOF_LONG__ >>> + >>> +#define BITS_PER_BYTE __CHAR_BIT__ >>> +#define BITS_PER_INT (__SIZEOF_INT__ << 3) >>> +#define BITS_PER_LONG (BYTES_PER_LONG << 3) >>> +#define BITS_PER_LLONG (__SIZEOF_LONG_LONG__ << 3) >>> + >>> +#define POINTER_ALIGN __SIZEOF_POINTER__ >> See how much nicer this is. This patch possibly wants to wait until >> I've fixed the compiler checks to update to the new baseline, or we can >> just say that staging is staging and corner case error messages are fine. >> >> One thing, you have to replace the "<< 3" as you're hard-coding 8 here >> and ignoring __CHAR_BIT__. >> >> I'd suggest keeping the BITS_PER_BYTE on the LHS, e.g: >> >> #define BITS_PER_INT (BITS_PER_BYTE * __SIZEOF_INT__) >> >> which tabulates better. >> >> I suggest keeping BITS_PER_XEN_ULONG to be arch-local. > I agree here despite ... > >> ARM is the >> odd-one-out having a non-64bit arch use a 64bit XEN_ULONG. > ... not agreeing here: x86 is the odd-one-out; I sincerely hope any new ports > to 32-bit architectures / flavors will avoid compat layer translation by > making > this type a proper 64-bit one. Architectures truly being 32-bit only, with no > expectation of a 64-bit flavor ever appearing, would be different.
I have some very firm opinions about this. It is an error that the type xen_ulong exists, anywhere. The fact it wasn't named guest_ulong shows a profound misunderstanding of its purpose and usage in the API/ABI. Similarly, BITS_PER_XEN_ULONG is buggily named, and should be BITS_PER_GUEST_ULONG, as demonstrated by it's singular use in Xen (calculating BITS_PER_EVTCHN_WORD(d)). ARM declaring that arm32 uses 64-bit xen_ulongs was cutting a corner that's going to bite twice as hard when 128bit comes along, and RISCV-128 is in progress already. All of this needs purging from the API/ABIs before RISC-V/PPC inherit the mistakes that are holding x86 and ARM back. ~Andrew
