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
