Re: [PATCH v2 2/2] x86/ucode: Add Kconfig option to remove microcode loading

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 12/01/2026 7:12 pm, Alejandro Vallejo wrote:
> Hi,
>
> On Mon Jan 12, 2026 at 7:47 PM CET, Alejandro Vallejo wrote:
>> On Mon Jan 12, 2026 at 6:15 PM CET, Andrew Cooper wrote:
>>> On 12/01/2026 3:02 pm, Alejandro Vallejo wrote:
>>>>  automation/gitlab-ci/build.yaml    |  2 +-
>>>>  docs/misc/efi.pandoc               |  2 ++
>>>>  docs/misc/xen-command-line.pandoc  |  4 ++--
>>>>  xen/arch/x86/Kconfig               | 14 +++++++++++++-
>>>>  xen/arch/x86/cpu/microcode/amd.c   | 22 +++++++++++++---------
>>>>  xen/arch/x86/cpu/microcode/core.c  | 25 ++++++++++++++++++-------
>>>>  xen/arch/x86/cpu/microcode/intel.c | 16 +++++++++-------
>>>>  xen/arch/x86/efi/efi-boot.h        |  3 ++-
>>>>  xen/arch/x86/platform_hypercall.c  |  2 ++
>>>>  xen/common/Makefile                |  3 ++-
>>>>  10 files changed, 64 insertions(+), 29 deletions(-)
>>> Much nicer in terms of (non) invasiveness.
> An interesting fact came to my attention. If you set a function pointer as
> IS_ENABLED(x) ? foo : NULL, rather than ifdeffing out the compiler doesn't 
> even
> need __maybe_unused to eliminate the statics.

Oh, yes.  I'd forgotten that trick when I suggested __maybe_unused.  Sorry.

>
> I'm adjusting as needed and creating something so that...
>
>   custom_param_if("ucode", parse_ucode, IS_ENABLED(CONFIG_MICROCODE_LOADING));
>
> ... does the right thing. I'm sure it'll have uses outside this (minor) patch 
> to
> remove a number of cmdline handlers when the feature they control isn't 
> active.

This I'm rather less sure about.  The lockdown patches are also
competing for a 3rd parameter in the param() APIs.

Again, I think microcode is a weird (i.e. rare) subsystem where we're
only compiling out part of it.  Personally I'd leave it as you had in
this patch.  It was minimally invasive.

~Andrew