Re: [PATCH v2] x86: guard synthetic feature and bug enumerators

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 07/01/2026 2:11 pm, Jan Beulich wrote:
> While adding new enumerators one may overlook the (rare) need to bump
> X86_NR_{SYNTH,BUG}. Guard against that happening by adding respective
> checking. The use of BUILD_BUG_ON_ZERO(), however, entails a number of
> other changes, as the expansion may not appear in the assembly produced.
> Furthermore inputs to file-scope asm() are only supported in gcc15 (or
> newer).
>
> No difference in generated code (debug info, however, grows quite a bit).
>
> An implication from the changes is that users of the alternatives patching
> macros may not use unnamed asm() input operands anymore, as the "injected"
> new operands would break numbering expectations.
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> ---
> v2: Fix shim build. Use named label operand in pdx.h.

I'm pretty sure that will be rejected by Eclair as a Rule R20.12
violation (using a parameter as a regular value, and stringised), and is
a blocking rule.

But more generally...  I see why you want a guard rail here, I can't
help feeling that the cure is worse than the poison.

Updating every alternative is very invasive, and this in particular

> --- a/xen/arch/x86/include/asm/spec_ctrl.h
> +++ b/xen/arch/x86/include/asm/spec_ctrl.h
> @@ -73,7 +73,7 @@ static always_inline void spec_ctrl_new_
>  
>      /* (ab)use alternative_input() to specify clobbers. */
>      alternative_input("", "DO_OVERWRITE_RSB xu=%=", X86_BUG_IBPB_NO_RET,
> -                      : "rax", "rcx");
> +                      "i" (0) : "rax", "rcx");
>  }
>  

without even an explanation of why, is an immediate red flag.


Could we not split X86_SYNTH()/BUG() to take a leaf/bit pair, similar to
how we express regular features as a*32+b?

That would at least make it more obvious than currently when a new leaf
is needed, and contained it to a single header.

~Andrew