| Message ID | 4f085bcbf5b6f1bc42824bfb08724e8a9bbd4918.1743005389.git.oleksii.kurochko@gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [v1] xen/config.h: Move BITS_PER_* definitions from asm/config.h to xen/config.h | expand |
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. ARM is the odd-one-out having a non-64bit arch use a 64bit XEN_ULONG. ~Andrew
On 26.03.2025 18:47, Oleksii Kurochko wrote: > --- 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__ Just one remark here: Imo this needs to come with a comment, as alignment and size aren't necessarily tied together. It's merely that we assume that sizeof(void *) == __alignof(void *). Jan
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. Jan
On 3/27/25 1:44 AM, 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. Do you mean this patch:https://lore.kernel.org/xen-devel/20250320153241.43809-3-andrew.cooper3@citrix.com/? I haven't checked clang but if to look at gcc then these builtin macros was introduced in 024a85aeb6a("c-cppbuiltin.c (builtin_define_type_sizeof): New function.") and it seems like even older then gcc5 contains this patch: $ git tag --contains 024a85aeb6a912811d917f737eaad39140c2fb0c ... releases/gcc-4.3.0 ... Am I missing something? > > 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. Thanks. I'll update that and send the new patch version. ~ Oleksii
On 3/27/25 9:18 AM, Jan Beulich wrote: > On 26.03.2025 18:47, Oleksii Kurochko wrote: >> --- 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__ > Just one remark here: Imo this needs to come with a comment, as alignment and > size aren't necessarily tied together. It's merely that we assume that > sizeof(void *) == __alignof(void *). I will added the following comment then: /* it is assumed that sizeof(void *) == __alignof(void *) */ ~ Oleksii
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
On 27.03.2025 13:50, Oleksii Kurochko wrote: > > On 3/27/25 1:44 AM, 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. > > Do you mean this patch:https://lore.kernel.org/xen-devel/20250320153241.43809-3-andrew.cooper3@citrix.com/? > > I haven't checked clang but if to look at gcc then these builtin macros was introduced in > 024a85aeb6a("c-cppbuiltin.c (builtin_define_type_sizeof): New function.") and it seems like even older then gcc5 > contains this patch: > $ git tag --contains 024a85aeb6a912811d917f737eaad39140c2fb0c > ... > releases/gcc-4.3.0 > ... > > Am I missing something? The check yet to be adjusted is looking for 4.1, so 4.3 would already be "too new". Jan
On 27.03.2025 13:53, Andrew Cooper wrote: > 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. Yes indeed. > All of this needs purging from the API/ABIs before RISC-V/PPC inherit > the mistakes that are holding x86 and ARM back. I'm curious to learn how you envision to support a 32-bit guest on RV128, for example. You dislike the compat layer, and you also dislike xen_ulong_t (I agree its name is potentially misleading). So you must be thinking of something entirely new to express in particular interfacing structures. Jan
On 27.03.2025 13:51, Oleksii Kurochko wrote: > > On 3/27/25 9:18 AM, Jan Beulich wrote: >> On 26.03.2025 18:47, Oleksii Kurochko wrote: >>> --- 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__ >> Just one remark here: Imo this needs to come with a comment, as alignment and >> size aren't necessarily tied together. It's merely that we assume that >> sizeof(void *) == __alignof(void *). > > I will added the following comment then: > /* it is assumed that sizeof(void *) == __alignof(void *) */ Ftaod - starting with a capital letter, to be in line with ./CODING_STYLE. Jan
On 3/27/25 2:16 PM, Jan Beulich wrote: > On 27.03.2025 13:50, Oleksii Kurochko wrote: >> On 3/27/25 1:44 AM, 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. >> Do you mean this patch:https://lore.kernel.org/xen-devel/20250320153241.43809-3-andrew.cooper3@citrix.com/? >> >> I haven't checked clang but if to look at gcc then these builtin macros was introduced in >> 024a85aeb6a("c-cppbuiltin.c (builtin_define_type_sizeof): New function.") and it seems like even older then gcc5 >> contains this patch: >> $ git tag --contains 024a85aeb6a912811d917f737eaad39140c2fb0c >> ... >> releases/gcc-4.3.0 >> ... >> >> Am I missing something? > The check yet to be adjusted is looking for 4.1, so 4.3 would already be "too new". I guess you mean this one check: check-$(gcc) = $(call cc-ver-check,CC,0x040100,"Xen requires at least gcc-4.1") Could I ask then why in the link above it is checked different version? -#if !defined(__GNUC__) || (__GNUC__ < 4) -#error Sorry, your compiler is too old/not recognized. -#elif CONFIG_CC_IS_GCC -# if defined(CONFIG_ARM_32) && CONFIG_GCC_VERSION < 40900 -# error Sorry, your version of GCC is too old - please use 4.9 or newer. -# elif defined(CONFIG_ARM_64) && CONFIG_GCC_VERSION < 50100 -/* - * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63293 - * https://lore.kernel.org/r/20210107111841.GN1551@shell.armlinux.org.uk - */ -# error Sorry, your version of GCC is too old - please use 5.1 or newer. -# endif ~ Oleksii
On 27.03.2025 17:12, Oleksii Kurochko wrote: > > On 3/27/25 2:16 PM, Jan Beulich wrote: >> On 27.03.2025 13:50, Oleksii Kurochko wrote: >>> On 3/27/25 1:44 AM, 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. >>> Do you mean this patch:https://lore.kernel.org/xen-devel/20250320153241.43809-3-andrew.cooper3@citrix.com/? >>> >>> I haven't checked clang but if to look at gcc then these builtin macros was introduced in >>> 024a85aeb6a("c-cppbuiltin.c (builtin_define_type_sizeof): New function.") and it seems like even older then gcc5 >>> contains this patch: >>> $ git tag --contains 024a85aeb6a912811d917f737eaad39140c2fb0c >>> ... >>> releases/gcc-4.3.0 >>> ... >>> >>> Am I missing something? >> The check yet to be adjusted is looking for 4.1, so 4.3 would already be "too new". > > I guess you mean this one check: > check-$(gcc) = $(call cc-ver-check,CC,0x040100,"Xen requires at least gcc-4.1") > > Could I ask then why in the link above it is checked different version? Because we're only in the process of switching to a higher baseline. Some parts still need bringing back in sync. Which is also why Andrew said what he said. Jan
diff --git a/xen/arch/arm/include/asm/bitops.h b/xen/arch/arm/include/asm/bitops.h index f163d9bb45..60686a3a55 100644 --- a/xen/arch/arm/include/asm/bitops.h +++ b/xen/arch/arm/include/asm/bitops.h @@ -22,8 +22,6 @@ #define __set_bit(n,p) set_bit(n,p) #define __clear_bit(n,p) clear_bit(n,p) -#define BITS_PER_BYTE 8 - #define ADDR (*(volatile int *) addr) #define CONST_ADDR (*(const volatile int *) addr) @@ -75,7 +73,7 @@ bool clear_mask16_timeout(uint16_t mask, volatile void *p, #define arch_ffs(x) ((x) ? 1 + __builtin_ctz(x) : 0) #define arch_ffsl(x) ((x) ? 1 + __builtin_ctzl(x) : 0) -#define arch_fls(x) ((x) ? 32 - __builtin_clz(x) : 0) +#define arch_fls(x) ((x) ? BITS_PER_INT - __builtin_clz(x) : 0) #define arch_flsl(x) ((x) ? BITS_PER_LONG - __builtin_clzl(x) : 0) #endif /* _ARM_BITOPS_H */ diff --git a/xen/arch/arm/include/asm/config.h b/xen/arch/arm/include/asm/config.h index 0a51142efd..5a02db6937 100644 --- a/xen/arch/arm/include/asm/config.h +++ b/xen/arch/arm/include/asm/config.h @@ -8,19 +8,11 @@ #define __ARM_CONFIG_H__ #if defined(CONFIG_ARM_64) -# define LONG_BYTEORDER 3 # define ELFSIZE 64 #else -# define LONG_BYTEORDER 2 # define ELFSIZE 32 #endif -#define BYTES_PER_LONG (1 << LONG_BYTEORDER) -#define BITS_PER_LONG (BYTES_PER_LONG << 3) -#define POINTER_ALIGN BYTES_PER_LONG - -#define BITS_PER_LLONG 64 - /* xen_ulong_t is always 64 bits */ #define BITS_PER_XEN_ULONG 64 diff --git a/xen/arch/ppc/include/asm/bitops.h b/xen/arch/ppc/include/asm/bitops.h index c942e9432e..e72942cca0 100644 --- a/xen/arch/ppc/include/asm/bitops.h +++ b/xen/arch/ppc/include/asm/bitops.h @@ -15,8 +15,6 @@ #define __set_bit(n, p) set_bit(n, p) #define __clear_bit(n, p) clear_bit(n, p) -#define BITS_PER_BYTE 8 - /* PPC bit number conversion */ #define PPC_BITLSHIFT(be) (BITS_PER_LONG - 1 - (be)) #define PPC_BIT(bit) (1UL << PPC_BITLSHIFT(bit)) @@ -121,7 +119,7 @@ static inline int test_and_set_bit(unsigned int nr, volatile void *addr) #define arch_ffs(x) ((x) ? 1 + __builtin_ctz(x) : 0) #define arch_ffsl(x) ((x) ? 1 + __builtin_ctzl(x) : 0) -#define arch_fls(x) ((x) ? 32 - __builtin_clz(x) : 0) +#define arch_fls(x) ((x) ? BITS_PER_INT - __builtin_clz(x) : 0) #define arch_flsl(x) ((x) ? BITS_PER_LONG - __builtin_clzl(x) : 0) #define arch_hweightl(x) __builtin_popcountl(x) diff --git a/xen/arch/ppc/include/asm/config.h b/xen/arch/ppc/include/asm/config.h index 148fb3074d..8e32edd5a5 100644 --- a/xen/arch/ppc/include/asm/config.h +++ b/xen/arch/ppc/include/asm/config.h @@ -6,19 +6,12 @@ #include <xen/page-size.h> #if defined(CONFIG_PPC64) -#define LONG_BYTEORDER 3 #define ELFSIZE 64 #define MAX_VIRT_CPUS 1024u #else #error "Unsupported PowerPC variant" #endif -#define BYTES_PER_LONG (1 << LONG_BYTEORDER) -#define BITS_PER_LONG (BYTES_PER_LONG << 3) -#define POINTER_ALIGN BYTES_PER_LONG - -#define BITS_PER_LLONG 64 - /* xen_ulong_t is always 64 bits */ #define BITS_PER_XEN_ULONG 64 diff --git a/xen/arch/riscv/include/asm/config.h b/xen/arch/riscv/include/asm/config.h index 7141bd9e46..314c97c20a 100644 --- a/xen/arch/riscv/include/asm/config.h +++ b/xen/arch/riscv/include/asm/config.h @@ -119,25 +119,12 @@ #define HYPERVISOR_VIRT_START XEN_VIRT_START #if defined(CONFIG_RISCV_64) -# define INT_BYTEORDER 2 -# define LONG_BYTEORDER 3 # define ELFSIZE 64 # define MAX_VIRT_CPUS 128u #else # error "Unsupported RISCV variant" #endif -#define BYTES_PER_INT (1 << INT_BYTEORDER) -#define BITS_PER_INT (BYTES_PER_INT << 3) - -#define BYTES_PER_LONG (1 << LONG_BYTEORDER) -#define BITS_PER_LONG (BYTES_PER_LONG << 3) -#define POINTER_ALIGN BYTES_PER_LONG - -#define BITS_PER_LLONG 64 - -#define BITS_PER_BYTE 8 - /* xen_ulong_t is always 64 bits */ #define BITS_PER_XEN_ULONG 64 diff --git a/xen/arch/x86/include/asm/config.h b/xen/arch/x86/include/asm/config.h index 19746f956e..f0123a7de9 100644 --- a/xen/arch/x86/include/asm/config.h +++ b/xen/arch/x86/include/asm/config.h @@ -7,16 +7,8 @@ #ifndef __X86_CONFIG_H__ #define __X86_CONFIG_H__ -#define LONG_BYTEORDER 3 #define CONFIG_PAGING_LEVELS 4 -#define BYTES_PER_LONG (1 << LONG_BYTEORDER) -#define BITS_PER_LONG (BYTES_PER_LONG << 3) -#define BITS_PER_BYTE 8 -#define POINTER_ALIGN BYTES_PER_LONG - -#define BITS_PER_LLONG 64 - #define BITS_PER_XEN_ULONG BITS_PER_LONG #define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS 1 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__ + #endif /* __XEN_CONFIG_H__ */
BITS_PER_* values can be defined in a common way using compiler-provided macros. Thus, these definitions are moved to xen/config.h to reduce duplication across architectures. Additionally, *_BYTEORDER macros are removed, as BITS_PER_* values now come directly from the compiler environment. The arch_fls() implementation for Arm and PPC is updated to use BITS_PER_INT instead of a hardcoded value of 32. Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> --- Potentially, BITS_PER_XEN_ULONG could also be moved to xen/config.h, as it is 64 for all architectures except x86. A possible approach: #ifndef BITS_PER_XEN_ULONG #define BITS_PER_XEN_ULONG 64 #endif CI's tests result: https://gitlab.com/xen-project/people/olkur/xen/-/pipelines/1736620512 --- xen/arch/arm/include/asm/bitops.h | 4 +--- xen/arch/arm/include/asm/config.h | 8 -------- xen/arch/ppc/include/asm/bitops.h | 4 +--- xen/arch/ppc/include/asm/config.h | 7 ------- xen/arch/riscv/include/asm/config.h | 13 ------------- xen/arch/x86/include/asm/config.h | 8 -------- xen/include/xen/config.h | 9 +++++++++ 7 files changed, 11 insertions(+), 42 deletions(-)