Rather than spelling out their amounts (requiring updates when multiples
of 32 are crossed), introduce a sentinel each and calculate the two
numbers from those.

No difference in generated code, albeit debug info size grows quite a bit.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
This is an alternative to "x86: guard synthetic feature and bug
enumerators", bulding upon the expectation that when adding to the end of
either list people will notice the sentinel and not forget to update it.

--- a/xen/arch/x86/include/asm/cpufeatures.h
+++ b/xen/arch/x86/include/asm/cpufeatures.h
@@ -7,7 +7,6 @@
 #define FSCAPINTS FEATURESET_NR_ENTRIES
 
 /* Synthetic words follow the featureset words. */
-#define X86_NR_SYNTH 2
 #define X86_SYNTH(x) (FSCAPINTS * 32 + (x))
 
 /* Synthetic features */
@@ -44,9 +43,11 @@ XEN_CPUFEATURE(IBPB_ENTRY_HVM,    X86_SY
 XEN_CPUFEATURE(USE_VMCALL,        X86_SYNTH(30)) /* Use VMCALL instead of VMMCALL */
 XEN_CPUFEATURE(PDX_COMPRESSION,   X86_SYNTH(31)) /* PDX compression */
 XEN_CPUFEATURE(XEN_REP_MOVSB,     X86_SYNTH(32)) /* REP MOVSB used for memcpy() */
+XEN_CPUFEATURE(nr,                X86_SYNTH(33)) /* Number of synthetic features */
+
+#define X86_NR_SYNTH DIV_ROUND_UP(X86_FEATURE_nr - FSCAPINTS * 32, 32)
 
 /* Bug words follow the synthetic words. */
-#define X86_NR_BUG 1
 #define X86_BUG(x) ((FSCAPINTS + X86_NR_SYNTH) * 32 + (x))
 
 #define X86_BUG_FPU_PTRS          X86_BUG( 0) /* (F)X{SAVE,RSTOR} doesn't save/restore FOP/FIP/FDP. */
@@ -64,5 +65,10 @@ XEN_CPUFEATURE(XEN_REP_MOVSB,     X86_SY
 #define X86_SPEC_BHB_LOOPS        X86_BUG(20) /* Use clear_bhb_loops for BHI mitigation.*/
 #define X86_SPEC_BHB_LOOPS_LONG   X86_BUG(21) /* Upgrade clear_bhb_loops to the "long" sequence. */
 
+#define X86_BUG_nr                X86_BUG(22) /* Number of bug identifiers */
+
+#define X86_NR_BUG DIV_ROUND_UP(X86_BUG_nr - (FSCAPINTS + X86_NR_SYNTH) * 32, \
+                                32)
+
 /* Total number of capability words, inc synth and bug words. */
 #define NCAPINTS (FSCAPINTS + X86_NR_SYNTH + X86_NR_BUG) /* N 32-bit words worth of info */

On 19/01/2026 3:30 pm, Jan Beulich wrote:
> Rather than spelling out their amounts (requiring updates when multiples
> of 32 are crossed), introduce a sentinel each and calculate the two
> numbers from those.
>
> No difference in generated code, albeit debug info size grows quite a bit.

Presumably because of the substantial increase in preprocessed output?

>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> This is an alternative to "x86: guard synthetic feature and bug
> enumerators", bulding upon the expectation that when adding to the end of
> either list people will notice the sentinel and not forget to update it.

The extra preprocessing overhead is not ideal, but it's certainly
preferable to the first version.

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

On 02.02.2026 16:56, Andrew Cooper wrote:
> On 19/01/2026 3:30 pm, Jan Beulich wrote:
>> Rather than spelling out their amounts (requiring updates when multiples
>> of 32 are crossed), introduce a sentinel each and calculate the two
>> numbers from those.
>>
>> No difference in generated code, albeit debug info size grows quite a bit.
> 
> Presumably because of the substantial increase in preprocessed output?

I wouldn't expect that to matter. My suspicion was that de-duplication might
not work very well there. But I didn't go check, as debug info size really
isn't a primary concern to me.

>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> ---
>> This is an alternative to "x86: guard synthetic feature and bug
>> enumerators", bulding upon the expectation that when adding to the end of
>> either list people will notice the sentinel and not forget to update it.
> 
> The extra preprocessing overhead is not ideal, but it's certainly
> preferable to the first version.
> 
> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

Thanks.

Jan