[PATCH v4 0/4] Add Kconfig option to remove microcode loading support

[PATCH v4 0/4] Add Kconfig option to remove microcode loading support

[Alejandro Vallejo]

Hi,

v1: https://lore.kernel.org/xen-devel/20251112162219.226075-1-alejandro.garciavallejo@amd.com/
v2: https://lore.kernel.org/xen-devel/20260112150259.74535-1-alejandro.garciavallejo@amd.com/
v3: https://lore.kernel.org/xen-devel/20260113122109.62399-1-alejandro.garciavallejo@amd.com/
pipeline (red, but see below):
    https://gitlab.com/xen-project/people/agvallejo/xen/-/pipelines/2272127547

Pipeline failures are on ARM builds, so clearly unrelated to this. Also has
an eclair run on allcode that shows no new failures in earlycpio.c.

The only dependency here is patch 2 going in before patch 3. Everything else
can be freely rearranged.

Cheers,
Alejandro

Alejandro Vallejo (5):
  x86/ucode: Add Kconfig option to remove microcode loading
  xen: Allow lib-y targets to also be .init.o
  earlycpio: lib-ify earlycpio.c
  docs/misra: Remove earlycpio.c from the Eclair exclusion list.
  automation: Disable ucode loading on AMD's analysis run

 automation/gitlab-ci/analyze.yaml      |  1 +
 docs/admin-guide/microcode-loading.rst |  2 ++
 docs/misc/efi.pandoc                   |  2 ++
 docs/misc/xen-command-line.pandoc      |  7 ++++---
 docs/misra/exclude-list.json           |  4 ----
 xen/Rules.mk                           | 10 +++++-----
 xen/arch/x86/Kconfig                   | 14 ++++++++++++++
 xen/arch/x86/cpu/microcode/amd.c       | 16 +++++++++-------
 xen/arch/x86/cpu/microcode/core.c      | 15 ++++++++++++---
 xen/arch/x86/cpu/microcode/intel.c     | 11 +++++++----
 xen/arch/x86/cpu/microcode/private.h   |  3 +++
 xen/arch/x86/efi/efi-boot.h            |  3 ++-
 xen/arch/x86/platform_hypercall.c      | 10 ++++++++--
 xen/common/Makefile                    |  2 +-
 xen/lib/Makefile                       |  1 +
 xen/{common => lib}/earlycpio.c        |  0
 16 files changed, 71 insertions(+), 30 deletions(-)
 rename xen/{common => lib}/earlycpio.c (100%)


base-commit: 7b3e1b4e848d34c9a5b6634009959a7b9dd42104
-- 
2.43.0

[PATCH v4 1/5] x86/ucode: Add Kconfig option to remove microcode loading

[Alejandro Vallejo]

Amend docs to reflect ucode= command/stanza depend on MICROCODE_LOADING
being set.

The new MICROCODE_OP() is a conditional setter for the microcode_ops
struct. By using IS_ENABLED() there rather than ifdef we allow DCE to
remove all statics no longer used when microcode loading is disabled
without tagging them with __maybe_unused.

Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
v4:
  * Minor spell fix in commit message ("rather")
  * efi.pandoc: terminate sentence with "enabled".
  * xen-command-line: State applicability as first line.
  * reorder cpu hooks.
  * MICROCODE_OP() comment
  * MICROCODE_OP() moved next to microcode_ops
  * Re-arranged platform_ops to turn them into smaller hunks.
---
 docs/admin-guide/microcode-loading.rst |  2 ++
 docs/misc/efi.pandoc                   |  2 ++
 docs/misc/xen-command-line.pandoc      |  7 ++++---
 xen/arch/x86/Kconfig                   | 14 ++++++++++++++
 xen/arch/x86/cpu/microcode/amd.c       | 16 +++++++++-------
 xen/arch/x86/cpu/microcode/core.c      | 15 ++++++++++++---
 xen/arch/x86/cpu/microcode/intel.c     | 11 +++++++----
 xen/arch/x86/cpu/microcode/private.h   |  3 +++
 xen/arch/x86/efi/efi-boot.h            |  3 ++-
 xen/arch/x86/platform_hypercall.c      | 10 ++++++++--
 10 files changed, 63 insertions(+), 20 deletions(-)

diff --git a/docs/admin-guide/microcode-loading.rst b/docs/admin-guide/microcode-loading.rst
index a07e25802f..148bc8559b 100644
--- a/docs/admin-guide/microcode-loading.rst
+++ b/docs/admin-guide/microcode-loading.rst
@@ -23,6 +23,8 @@ TSX errata which necessitated disabling the feature entirely), or the addition
 of brand new features (e.g. the Spectre v2 controls to work around speculative
 execution vulnerabilities).
 
+Microcode loading support in Xen is controlled by the
+``CONFIG_MICROCODE_LOADING`` Kconfig option.
 
 Boot time microcode loading
 ---------------------------
diff --git a/docs/misc/efi.pandoc b/docs/misc/efi.pandoc
index 11c1ac3346..8198a7f063 100644
--- a/docs/misc/efi.pandoc
+++ b/docs/misc/efi.pandoc
@@ -104,6 +104,8 @@ Specifies an XSM module to load.
 
 Specifies a CPU microcode blob to load. (x86 only)
 
+Only available when Xen is compiled with CONFIG_MICROCODE_LOADING enabled.
+
 ###`dtb=<filename>`
 
 Specifies a device tree file to load.  The platform firmware may provide a
diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index 15f7a315a4..0eca489b7d 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -2751,9 +2751,10 @@ performance.
     Applicability: x86
     Default: `scan` is selectable via Kconfig, `nmi,digest-check`
 
-Controls for CPU microcode loading. For early loading, this parameter can
-specify how and where to find the microcode update blob. For late loading,
-this parameter specifies if the update happens within a NMI handler.
+Controls for CPU microcode loading, available when `CONFIG_MICROCODE_LOADING` is
+enabled. For early loading, this parameter can specify how and where to find the
+microcode update blob. For late loading, this parameter specifies if the update
+happens within a NMI handler.
 
 'integer' specifies the CPU microcode update blob module index. When positive,
 this specifies the n-th module (in the GrUB entry, zero based) to be used
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index d5705e4bff..61f58aa829 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -331,8 +331,22 @@ config REQUIRE_NX
 	  was unavailable. However, if enabled, Xen will no longer boot on
 	  any CPU which is lacking NX support.
 
+config MICROCODE_LOADING
+	bool "Microcode loading"
+	default y
+	help
+	  Microcode updates for CPUs fix errata and provide new functionality for
+	  software to work around bugs, such as the speculative execution
+	  vulnerabilities. It is common for OSes to carry updated microcode as
+	  software tends to get updated more frequently than firmware.
+
+	  For embedded environments where a full firmware/software stack is being
+	  provided, it might not be necessary for Xen to need to load microcode
+	  itself.
+
 config MICROCODE_SCAN_DEFAULT
 	bool "Scan for microcode by default"
+	depends on MICROCODE_LOADING
 	help
 	  During boot, Xen can scan the multiboot images for a CPIO archive
 	  containing CPU microcode to be loaded, which is Linux's mechanism for
diff --git a/xen/arch/x86/cpu/microcode/amd.c b/xen/arch/x86/cpu/microcode/amd.c
index 71b041c84b..c1ab6deb4d 100644
--- a/xen/arch/x86/cpu/microcode/amd.c
+++ b/xen/arch/x86/cpu/microcode/amd.c
@@ -561,11 +561,11 @@ static const char __initconst amd_cpio_path[] =
     "kernel/x86/microcode/AuthenticAMD.bin";
 
 static const struct microcode_ops __initconst_cf_clobber amd_ucode_ops = {
-    .cpu_request_microcode            = cpu_request_microcode,
     .collect_cpu_info                 = collect_cpu_info,
-    .apply_microcode                  = apply_microcode,
-    .compare                          = amd_compare,
-    .cpio_path                        = amd_cpio_path,
+    .cpu_request_microcode            = MICROCODE_OP(cpu_request_microcode),
+    .apply_microcode                  = MICROCODE_OP(apply_microcode),
+    .compare                          = MICROCODE_OP(amd_compare),
+    .cpio_path                        = MICROCODE_OP(amd_cpio_path),
 };
 
 void __init ucode_probe_amd(struct microcode_ops *ops)
@@ -574,7 +574,8 @@ void __init ucode_probe_amd(struct microcode_ops *ops)
      * The Entrysign vulnerability (SB-7033, CVE-2024-36347) affects Zen1-5
      * CPUs.  Taint Xen if digest checking is turned off.
      */
-    if ( boot_cpu_data.family >= 0x17 && boot_cpu_data.family <= 0x1a &&
+    if ( IS_ENABLED(CONFIG_MICROCODE_LOADING) &&
+         boot_cpu_data.family >= 0x17 && boot_cpu_data.family <= 0x1a &&
          !opt_digest_check )
     {
         printk(XENLOG_WARNING
@@ -614,8 +615,9 @@ void __init amd_check_entrysign(void)
     unsigned int curr_rev;
     uint8_t fixed_rev;
 
-    if ( boot_cpu_data.vendor != X86_VENDOR_AMD ||
-         boot_cpu_data.family < 0x17 ||
+    if ( !IS_ENABLED(CONFIG_MICROCODE_LOADING)  ||
+         boot_cpu_data.vendor != X86_VENDOR_AMD ||
+         boot_cpu_data.family < 0x17            ||
          boot_cpu_data.family > 0x1a )
         return;
 
diff --git a/xen/arch/x86/cpu/microcode/core.c b/xen/arch/x86/cpu/microcode/core.c
index dabdb95b4c..efaf808f1a 100644
--- a/xen/arch/x86/cpu/microcode/core.c
+++ b/xen/arch/x86/cpu/microcode/core.c
@@ -58,7 +58,7 @@
  */
 #define MICROCODE_UPDATE_TIMEOUT_US 1000000
 
-static bool __initdata ucode_mod_forced;
+static bool __initdata __maybe_unused ucode_mod_forced;
 static unsigned int nr_cores;
 
 /*
@@ -104,6 +104,7 @@ static int __initdata opt_mod_idx;
 static bool __initdata opt_scan = IS_ENABLED(CONFIG_MICROCODE_SCAN_DEFAULT);
 bool __ro_after_init opt_digest_check = true;
 
+#ifdef CONFIG_MICROCODE_LOADING
 /*
  * Used by the EFI path only, when xen.cfg identifies an explicit microcode
  * file.  Overrides ucode=<int>|scan on the regular command line.
@@ -162,6 +163,7 @@ static int __init cf_check parse_ucode(const char *s)
     return rc;
 }
 custom_param("ucode", parse_ucode);
+#endif /* CONFIG_MICROCODE_LOADING */
 
 static struct microcode_ops __ro_after_init ucode_ops;
 
@@ -469,7 +471,7 @@ struct ucode_buf {
     char buffer[];
 };
 
-static long cf_check ucode_update_hcall_cont(void *data)
+static long cf_check __maybe_unused ucode_update_hcall_cont(void *data)
 {
     struct microcode_patch *patch = NULL;
     int ret, result;
@@ -613,6 +615,7 @@ static long cf_check ucode_update_hcall_cont(void *data)
     return ret;
 }
 
+#ifdef CONFIG_MICROCODE_LOADING
 int ucode_update_hcall(XEN_GUEST_HANDLE(const_void) buf,
                        unsigned long len, unsigned int flags)
 {
@@ -645,6 +648,7 @@ int ucode_update_hcall(XEN_GUEST_HANDLE(const_void) buf,
      */
     return continue_hypercall_on_cpu(0, ucode_update_hcall_cont, buffer);
 }
+#endif /* CONFIG_MICROCODE_LOADING */
 
 /* Load a cached update to current cpu */
 int microcode_update_one(void)
@@ -658,7 +662,7 @@ int microcode_update_one(void)
     if ( ucode_ops.collect_cpu_info )
         alternative_vcall(ucode_ops.collect_cpu_info);
 
-    if ( !ucode_ops.apply_microcode )
+    if ( !IS_ENABLED(CONFIG_MICROCODE_LOADING) || !ucode_ops.apply_microcode )
         return -EOPNOTSUPP;
 
     spin_lock(&microcode_mutex);
@@ -678,6 +682,7 @@ int microcode_update_one(void)
  */
 static int __initdata early_mod_idx = -1;
 
+#ifdef CONFIG_MICROCODE_LOADING
 static int __init cf_check microcode_init_cache(void)
 {
     struct boot_info *bi = &xen_boot_info;
@@ -734,6 +739,7 @@ static int __init cf_check microcode_init_cache(void)
     return rc;
 }
 presmp_initcall(microcode_init_cache);
+#endif /* CONFIG_MICROCODE_LOADING */
 
 /*
  * There are several tasks:
@@ -898,6 +904,9 @@ int __init early_microcode_init(struct boot_info *bi)
 
     printk(XENLOG_INFO "BSP microcode revision: 0x%08x\n", this_cpu(cpu_sig).rev);
 
+    if ( !IS_ENABLED(CONFIG_MICROCODE_LOADING) )
+        return -ENODEV;
+
     /*
      * Some hypervisors deliberately report a microcode revision of -1 to
      * mean that they will not accept microcode updates.
diff --git a/xen/arch/x86/cpu/microcode/intel.c b/xen/arch/x86/cpu/microcode/intel.c
index 281993e725..dac464961a 100644
--- a/xen/arch/x86/cpu/microcode/intel.c
+++ b/xen/arch/x86/cpu/microcode/intel.c
@@ -408,17 +408,20 @@ static const char __initconst intel_cpio_path[] =
     "kernel/x86/microcode/GenuineIntel.bin";
 
 static const struct microcode_ops __initconst_cf_clobber intel_ucode_ops = {
-    .cpu_request_microcode            = cpu_request_microcode,
     .collect_cpu_info                 = collect_cpu_info,
-    .apply_microcode                  = apply_microcode,
-    .compare                          = intel_compare,
-    .cpio_path                        = intel_cpio_path,
+    .cpu_request_microcode            = MICROCODE_OP(cpu_request_microcode),
+    .apply_microcode                  = MICROCODE_OP(apply_microcode),
+    .compare                          = MICROCODE_OP(intel_compare),
+    .cpio_path                        = MICROCODE_OP(intel_cpio_path),
 };
 
 void __init ucode_probe_intel(struct microcode_ops *ops)
 {
     *ops = intel_ucode_ops;
 
+    if ( !IS_ENABLED(CONFIG_MICROCODE_LOADING) )
+        return;
+
     if ( !can_load_microcode() )
         ops->apply_microcode = NULL;
 }
diff --git a/xen/arch/x86/cpu/microcode/private.h b/xen/arch/x86/cpu/microcode/private.h
index e6c965dc99..77ce816c1a 100644
--- a/xen/arch/x86/cpu/microcode/private.h
+++ b/xen/arch/x86/cpu/microcode/private.h
@@ -8,6 +8,9 @@
 /* Opaque.  Internals are vendor-specific. */
 struct microcode_patch;
 
+/* Aids dead-code elimination of the static hooks */
+#define MICROCODE_OP(x) (IS_ENABLED(CONFIG_MICROCODE_LOADING) ? (x) : NULL)
+
 struct microcode_ops {
     /*
      * Parse a microcode container.  Format is vendor-specific.
diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
index 0194720003..42a2c46b5e 100644
--- a/xen/arch/x86/efi/efi-boot.h
+++ b/xen/arch/x86/efi/efi-boot.h
@@ -295,7 +295,8 @@ static void __init efi_arch_cfg_file_late(const EFI_LOADED_IMAGE *image,
 {
     union string name;
 
-    if ( read_section(image, L"ucode", &ucode, NULL) )
+    if ( !IS_ENABLED(CONFIG_MICROCODE_LOADING) ||
+         read_section(image, L"ucode", &ucode, NULL) )
         return;
 
     name.s = get_value(&cfg, section, "ucode");
diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c
index f8eca48170..2ac9fc2d96 100644
--- a/xen/arch/x86/platform_hypercall.c
+++ b/xen/arch/x86/platform_hypercall.c
@@ -317,8 +317,11 @@ ret_t do_platform_op(
     {
         XEN_GUEST_HANDLE(const_void) data;
 
-        guest_from_compat_handle(data, op->u.microcode.data);
+        ret = -EOPNOTSUPP;
+        if ( !IS_ENABLED(CONFIG_MICROCODE_LOADING) )
+            break;
 
+        guest_from_compat_handle(data, op->u.microcode.data);
         ret = ucode_update_hcall(data, op->u.microcode.length, 0);
         break;
     }
@@ -327,8 +330,11 @@ ret_t do_platform_op(
     {
         XEN_GUEST_HANDLE(const_void) data;
 
-        guest_from_compat_handle(data, op->u.microcode2.data);
+        ret = -EOPNOTSUPP;
+        if ( !IS_ENABLED(CONFIG_MICROCODE_LOADING) )
+            break;
 
+        guest_from_compat_handle(data, op->u.microcode2.data);
         ret = ucode_update_hcall(data, op->u.microcode2.length,
                                  op->u.microcode2.flags);
         break;
-- 
2.43.0

Re: [PATCH v4 1/5] x86/ucode: Add Kconfig option to remove microcode loading

[Andrew Cooper]

On 20/01/2026 9:38 am, Alejandro Vallejo wrote:
> diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c
> index f8eca48170..2ac9fc2d96 100644
> --- a/xen/arch/x86/platform_hypercall.c
> +++ b/xen/arch/x86/platform_hypercall.c
> @@ -317,8 +317,11 @@ ret_t do_platform_op(
>      {
>          XEN_GUEST_HANDLE(const_void) data;
>  
> -        guest_from_compat_handle(data, op->u.microcode.data);
> +        ret = -EOPNOTSUPP;
> +        if ( !IS_ENABLED(CONFIG_MICROCODE_LOADING) )
> +            break;
>  
> +        guest_from_compat_handle(data, op->u.microcode.data);
>          ret = ucode_update_hcall(data, op->u.microcode.length, 0);
>          break;
>      }
> @@ -327,8 +330,11 @@ ret_t do_platform_op(
>      {
>          XEN_GUEST_HANDLE(const_void) data;
>  
> -        guest_from_compat_handle(data, op->u.microcode2.data);
> +        ret = -EOPNOTSUPP;
> +        if ( !IS_ENABLED(CONFIG_MICROCODE_LOADING) )
> +            break;
>  
> +        guest_from_compat_handle(data, op->u.microcode2.data);
>          ret = ucode_update_hcall(data, op->u.microcode2.length,
>                                   op->u.microcode2.flags);
>          break;

Very minor.  This diff looks like this because you've dropped the blank
line between guest_from_compat_handle() and ucode_update_hcall().  That
can also be fixed up on commit.

~Andrew

Re: [PATCH v4 1/5] x86/ucode: Add Kconfig option to remove microcode loading

[Alejandro Vallejo]

On Tue Jan 20, 2026 at 3:09 PM CET, Andrew Cooper wrote:
> On 20/01/2026 9:38 am, Alejandro Vallejo wrote:
>> diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c
>> index f8eca48170..2ac9fc2d96 100644
>> --- a/xen/arch/x86/platform_hypercall.c
>> +++ b/xen/arch/x86/platform_hypercall.c
>> @@ -317,8 +317,11 @@ ret_t do_platform_op(
>>      {
>>          XEN_GUEST_HANDLE(const_void) data;
>>  
>> -        guest_from_compat_handle(data, op->u.microcode.data);
>> +        ret = -EOPNOTSUPP;
>> +        if ( !IS_ENABLED(CONFIG_MICROCODE_LOADING) )
>> +            break;
>>  
>> +        guest_from_compat_handle(data, op->u.microcode.data);
>>          ret = ucode_update_hcall(data, op->u.microcode.length, 0);
>>          break;
>>      }
>> @@ -327,8 +330,11 @@ ret_t do_platform_op(
>>      {
>>          XEN_GUEST_HANDLE(const_void) data;
>>  
>> -        guest_from_compat_handle(data, op->u.microcode2.data);
>> +        ret = -EOPNOTSUPP;
>> +        if ( !IS_ENABLED(CONFIG_MICROCODE_LOADING) )
>> +            break;
>>  
>> +        guest_from_compat_handle(data, op->u.microcode2.data);
>>          ret = ucode_update_hcall(data, op->u.microcode2.length,
>>                                   op->u.microcode2.flags);
>>          break;
>
> Very minor.  This diff looks like this because you've dropped the blank
> line between guest_from_compat_handle() and ucode_update_hcall().  That
> can also be fixed up on commit.

sure

>
> ~Andrew

[PATCH v4 2/5] xen: Allow lib-y targets to also be .init.o

[Alejandro Vallejo]

There's some assumptions as to which targets may be init-only. But
there's little reason to preclude libraries from being init-only.

Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
---
 xen/Rules.mk | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 2b28d1ac3c..2c3f836c1b 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -130,9 +130,9 @@ endif
 
 targets += $(targets-for-builtin)
 
-$(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS-y += -DINIT_SECTIONS_ONLY
+$(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y) $(lib-y)): CFLAGS-y += -DINIT_SECTIONS_ONLY
 
-non-init-objects = $(filter-out %.init.o, $(obj-y) $(obj-bin-y) $(extra-y))
+non-init-objects = $(filter-out %.init.o, $(obj-y) $(obj-bin-y) $(extra-y) $(lib-y))
 
 ifeq ($(CONFIG_CC_IS_CLANG),y)
     cov-cflags-$(CONFIG_COVERAGE) := -fprofile-instr-generate -fcoverage-mapping
@@ -146,7 +146,7 @@ endif
 $(call cc-option-add,cov-cflags-$(CONFIG_COVERAGE),CC,-fprofile-update=atomic)
 
 # Reset cov-cflags-y in cases where an objects has another one as prerequisite
-$(nocov-y) $(filter %.init.o, $(obj-y) $(obj-bin-y) $(extra-y)): \
+$(nocov-y) $(filter %.init.o, $(obj-y) $(obj-bin-y) $(extra-y) $(lib-y)): \
     cov-cflags-y :=
 
 $(non-init-objects): _c_flags += $(cov-cflags-y)
@@ -156,7 +156,7 @@ ifeq ($(CONFIG_UBSAN),y)
 UBSAN_FLAGS := $(filter-out -fno-%,$(CFLAGS_UBSAN)) $(filter -fno-%,$(CFLAGS_UBSAN))
 
 # Reset UBSAN_FLAGS in cases where an objects has another one as prerequisite
-$(noubsan-y) $(filter %.init.o, $(obj-y) $(obj-bin-y) $(extra-y)): \
+$(noubsan-y) $(filter %.init.o, $(obj-y) $(obj-bin-y) $(extra-y) $(lib-y)): \
     UBSAN_FLAGS :=
 
 $(non-init-objects): _c_flags += $(UBSAN_FLAGS)
@@ -273,7 +273,7 @@ define cmd_obj_init_o
     $(OBJCOPY) $(foreach s,$(SPECIAL_DATA_SECTIONS),--rename-section .$(s)=.init.$(s)) $< $@
 endef
 
-$(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): $(obj)/%.init.o: $(obj)/%.o FORCE
+$(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y) $(lib-y)): $(obj)/%.init.o: $(obj)/%.o FORCE
 	$(call if_changed,obj_init_o)
 
 quiet_cmd_cpp_i_c = CPP     $@
-- 
2.43.0

Re: [PATCH v4 2/5] xen: Allow lib-y targets to also be .init.o

[Jan Beulich]

On 20.01.2026 10:38, Alejandro Vallejo wrote:
> There's some assumptions as to which targets may be init-only. But
> there's little reason to preclude libraries from being init-only.
> 
> Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>

[PATCH v4 3/5] earlycpio: lib-ify earlycpio.c

[Alejandro Vallejo]

It's only used for microcode loading on x86. By lib-ifying it we can make
it go away automatically when microcode loading becomes an optional
feature in follow-up patches.

Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
---
v4:
  * Makes the lib-y target init-only
---
 xen/common/Makefile             | 2 +-
 xen/lib/Makefile                | 1 +
 xen/{common => lib}/earlycpio.c | 0
 3 files changed, 2 insertions(+), 1 deletion(-)
 rename xen/{common => lib}/earlycpio.c (100%)

diff --git a/xen/common/Makefile b/xen/common/Makefile
index 92c97d641e..4fc0c15088 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -65,7 +65,7 @@ obj-y += wait.o
 obj-bin-y += warning.init.o
 obj-y += xmalloc_tlsf.o
 
-obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma lzo unlzo unlz4 unzstd earlycpio,$(n).init.o)
+obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma lzo unlzo unlz4 unzstd,$(n).init.o)
 
 obj-$(CONFIG_COMPAT) += $(addprefix compat/,domain.o memory.o multicall.o xlat.o)
 
diff --git a/xen/lib/Makefile b/xen/lib/Makefile
index efca830d92..3b0137902c 100644
--- a/xen/lib/Makefile
+++ b/xen/lib/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_X86) += x86/
 lib-y += bsearch.o
 lib-y += ctors.o
 lib-y += ctype.o
+lib-y += earlycpio.init.o
 lib-y += find-next-bit.o
 lib-y += generic-ffsl.o
 lib-y += generic-flsl.o
diff --git a/xen/common/earlycpio.c b/xen/lib/earlycpio.c
similarity index 100%
rename from xen/common/earlycpio.c
rename to xen/lib/earlycpio.c
-- 
2.43.0

Re: [PATCH v4 3/5] earlycpio: lib-ify earlycpio.c

[Andrew Cooper]

On 20/01/2026 9:38 am, Alejandro Vallejo wrote:
> It's only used for microcode loading on x86. By lib-ifying it we can make
> it go away automatically when microcode loading becomes an optional
> feature in follow-up patches.
>
> Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>

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

[PATCH v4 4/5] docs/misra: Remove earlycpio.c from the Eclair exclusion list.

[Alejandro Vallejo]

It's clean.

Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
---
 docs/misra/exclude-list.json | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/docs/misra/exclude-list.json b/docs/misra/exclude-list.json
index 388397dd3b..273e24db4a 100644
--- a/docs/misra/exclude-list.json
+++ b/docs/misra/exclude-list.json
@@ -121,10 +121,6 @@
             "rel_path": "common/bunzip2.c",
             "comment": "Imported from Linux, ignore for now"
         },
-        {
-            "rel_path": "common/earlycpio.c",
-            "comment": "Imported from Linux, ignore for now"
-        },
         {
             "rel_path": "common/gzip/*",
             "comment": "Imported from Linux, ignore for now"
-- 
2.43.0

Re: [PATCH v4 4/5] docs/misra: Remove earlycpio.c from the Eclair exclusion list.

[Nicola Vetrini]

On 2026-01-20 10:38, Alejandro Vallejo wrote:
> It's clean.
> 
> Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
> ---
>  docs/misra/exclude-list.json | 4 ----
>  1 file changed, 4 deletions(-)
> 

Hi. Do you have a link to a pipeline?

> diff --git a/docs/misra/exclude-list.json 
> b/docs/misra/exclude-list.json
> index 388397dd3b..273e24db4a 100644
> --- a/docs/misra/exclude-list.json
> +++ b/docs/misra/exclude-list.json
> @@ -121,10 +121,6 @@
>              "rel_path": "common/bunzip2.c",
>              "comment": "Imported from Linux, ignore for now"
>          },
> -        {
> -            "rel_path": "common/earlycpio.c",
> -            "comment": "Imported from Linux, ignore for now"
> -        },
>          {
>              "rel_path": "common/gzip/*",
>              "comment": "Imported from Linux, ignore for now"

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253

Re: [PATCH v4 4/5] docs/misra: Remove earlycpio.c from the Eclair exclusion list.

[Alejandro Vallejo]

On Tue Jan 20, 2026 at 12:21 PM CET, Nicola Vetrini wrote:
> On 2026-01-20 10:38, Alejandro Vallejo wrote:
>> It's clean.
>> 
>> Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
>> ---
>>  docs/misra/exclude-list.json | 4 ----
>>  1 file changed, 4 deletions(-)
>> 
>
> Hi. Do you have a link to a pipeline?

In the cover letter. I only run it on allcode.

Cheers,
Alejandro

>
>> diff --git a/docs/misra/exclude-list.json 
>> b/docs/misra/exclude-list.json
>> index 388397dd3b..273e24db4a 100644
>> --- a/docs/misra/exclude-list.json
>> +++ b/docs/misra/exclude-list.json
>> @@ -121,10 +121,6 @@
>>              "rel_path": "common/bunzip2.c",
>>              "comment": "Imported from Linux, ignore for now"
>>          },
>> -        {
>> -            "rel_path": "common/earlycpio.c",
>> -            "comment": "Imported from Linux, ignore for now"
>> -        },
>>          {
>>              "rel_path": "common/gzip/*",
>>              "comment": "Imported from Linux, ignore for now"

Re: [PATCH v4 4/5] docs/misra: Remove earlycpio.c from the Eclair exclusion list.

[Nicola Vetrini]

On 2026-01-20 12:27, Alejandro Vallejo wrote:
> On Tue Jan 20, 2026 at 12:21 PM CET, Nicola Vetrini wrote:
>> On 2026-01-20 10:38, Alejandro Vallejo wrote:
>>> It's clean.
>>> 
>>> Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
>>> ---
>>>  docs/misra/exclude-list.json | 4 ----
>>>  1 file changed, 4 deletions(-)
>>> 
>> 
>> Hi. Do you have a link to a pipeline?
> 
> In the cover letter. I only run it on allcode.
> 

I see. I can spot these additional violations from earlycpio.c. It does 
not result in a failure, but only because x86_64-allcode has also other 
non-clean guidelines and is thus allowed to fail. Ideally in some 
copious free time I'd send a patch to create a subset of clean 
guidelines for the *-allcode analysis that is failing, so that the 
"allow_fail: true" can be removed.

https://eclair-analysis-logs.xenproject.org/fs/space/verdesse0/XEN.ecdf/xen-project/people/agvallejo/xen/ECLAIR_normal/ucode-disable_v4/X86_64/12771570090/PROJECT.ecd;/by_main_file/xen/lib/earlycpio.c.html

> Cheers,
> Alejandro
> 
>> 
>>> diff --git a/docs/misra/exclude-list.json
>>> b/docs/misra/exclude-list.json
>>> index 388397dd3b..273e24db4a 100644
>>> --- a/docs/misra/exclude-list.json
>>> +++ b/docs/misra/exclude-list.json
>>> @@ -121,10 +121,6 @@
>>>              "rel_path": "common/bunzip2.c",
>>>              "comment": "Imported from Linux, ignore for now"
>>>          },
>>> -        {
>>> -            "rel_path": "common/earlycpio.c",
>>> -            "comment": "Imported from Linux, ignore for now"
>>> -        },
>>>          {
>>>              "rel_path": "common/gzip/*",
>>>              "comment": "Imported from Linux, ignore for now"

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253

Re: [PATCH v4 4/5] docs/misra: Remove earlycpio.c from the Eclair exclusion list.

[Alejandro Vallejo]

On Tue Jan 20, 2026 at 12:41 PM CET, Nicola Vetrini wrote:
> On 2026-01-20 12:27, Alejandro Vallejo wrote:
>> On Tue Jan 20, 2026 at 12:21 PM CET, Nicola Vetrini wrote:
>>> On 2026-01-20 10:38, Alejandro Vallejo wrote:
>>>> It's clean.
>>>> 
>>>> Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
>>>> ---
>>>>  docs/misra/exclude-list.json | 4 ----
>>>>  1 file changed, 4 deletions(-)
>>>> 
>>> 
>>> Hi. Do you have a link to a pipeline?
>> 
>> In the cover letter. I only run it on allcode.
>> 
>
> I see. I can spot these additional violations from earlycpio.c. It does 
> not result in a failure, but only because x86_64-allcode has also other 
> non-clean guidelines and is thus allowed to fail. Ideally in some 
> copious free time I'd send a patch to create a subset of clean 
> guidelines for the *-allcode analysis that is failing, so that the 
> "allow_fail: true" can be removed.
>
> https://eclair-analysis-logs.xenproject.org/fs/space/verdesse0/XEN.ecdf/xen-project/people/agvallejo/xen/ECLAIR_normal/ucode-disable_v4/X86_64/12771570090/PROJECT.ecd;/by_main_file/xen/lib/earlycpio.c.html

The web interface doesn't allow to search?! Sigh... thanks for the pointer.

I'll have a look.

Cheers,
Alejandro

Re: [PATCH v4 4/5] docs/misra: Remove earlycpio.c from the Eclair exclusion list.

[Nicola Vetrini]

[-- Attachment #1: Type: text/plain, Size: 1581 bytes --]

On 2026-01-20 12:51, Alejandro Vallejo wrote:
> On Tue Jan 20, 2026 at 12:41 PM CET, Nicola Vetrini wrote:
>> On 2026-01-20 12:27, Alejandro Vallejo wrote:
>>> On Tue Jan 20, 2026 at 12:21 PM CET, Nicola Vetrini wrote:
>>>> On 2026-01-20 10:38, Alejandro Vallejo wrote:
>>>>> It's clean.
>>>>> 
>>>>> Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
>>>>> ---
>>>>>  docs/misra/exclude-list.json | 4 ----
>>>>>  1 file changed, 4 deletions(-)
>>>>> 
>>>> 
>>>> Hi. Do you have a link to a pipeline?
>>> 
>>> In the cover letter. I only run it on allcode.
>>> 
>> 
>> I see. I can spot these additional violations from earlycpio.c. It 
>> does
>> not result in a failure, but only because x86_64-allcode has also 
>> other
>> non-clean guidelines and is thus allowed to fail. Ideally in some
>> copious free time I'd send a patch to create a subset of clean
>> guidelines for the *-allcode analysis that is failing, so that the
>> "allow_fail: true" can be removed.
>> 
>> https://eclair-analysis-logs.xenproject.org/fs/space/verdesse0/XEN.ecdf/xen-project/people/agvallejo/xen/ECLAIR_normal/ucode-disable_v4/X86_64/12771570090/PROJECT.ecd;/by_main_file/xen/lib/earlycpio.c.html
> 
> The web interface doesn't allow to search?! Sigh... thanks for the 
> pointer.
> 
> I'll have a look.
> 

It does allow searching, just not in the typical way. There is a 
technical reason for that that I won't go into.

> Cheers,
> Alejandro

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253

[-- Attachment #2: Screenshot from 2026-01-20 13-01-37.png --]
[-- Type: image/png, Size: 17587 bytes --]

Re: [PATCH v4 4/5] docs/misra: Remove earlycpio.c from the Eclair exclusion list.

[Alejandro Vallejo]

On Tue Jan 20, 2026 at 12:51 PM CET, Alejandro Vallejo wrote:
> On Tue Jan 20, 2026 at 12:41 PM CET, Nicola Vetrini wrote:
>> On 2026-01-20 12:27, Alejandro Vallejo wrote:
>>> On Tue Jan 20, 2026 at 12:21 PM CET, Nicola Vetrini wrote:
>>>> On 2026-01-20 10:38, Alejandro Vallejo wrote:
>>>>> It's clean.
>>>>> 
>>>>> Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
>>>>> ---
>>>>>  docs/misra/exclude-list.json | 4 ----
>>>>>  1 file changed, 4 deletions(-)
>>>>> 
>>>> 
>>>> Hi. Do you have a link to a pipeline?
>>> 
>>> In the cover letter. I only run it on allcode.
>>> 
>>
>> I see. I can spot these additional violations from earlycpio.c. It does 
>> not result in a failure, but only because x86_64-allcode has also other 
>> non-clean guidelines and is thus allowed to fail. Ideally in some 
>> copious free time I'd send a patch to create a subset of clean 
>> guidelines for the *-allcode analysis that is failing, so that the 
>> "allow_fail: true" can be removed.
>>
>> https://eclair-analysis-logs.xenproject.org/fs/space/verdesse0/XEN.ecdf/xen-project/people/agvallejo/xen/ECLAIR_normal/ucode-disable_v4/X86_64/12771570090/PROJECT.ecd;/by_main_file/xen/lib/earlycpio.c.html
>
> The web interface doesn't allow to search?! Sigh... thanks for the pointer.

It's your usual mess of miscasting, enum-as-int, etc.

Would you rather keep the exclusion and deal with it later or let it pile up?
I just don't have the time to go into it myself.

Cheers,
Alejandro

Re: [PATCH v4 4/5] docs/misra: Remove earlycpio.c from the Eclair exclusion list.

[Nicola Vetrini]

On 2026-01-20 13:09, Alejandro Vallejo wrote:
> On Tue Jan 20, 2026 at 12:51 PM CET, Alejandro Vallejo wrote:
>> On Tue Jan 20, 2026 at 12:41 PM CET, Nicola Vetrini wrote:
>>> On 2026-01-20 12:27, Alejandro Vallejo wrote:
>>>> On Tue Jan 20, 2026 at 12:21 PM CET, Nicola Vetrini wrote:
>>>>> On 2026-01-20 10:38, Alejandro Vallejo wrote:
>>>>>> It's clean.
>>>>>> 
>>>>>> Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
>>>>>> ---
>>>>>>  docs/misra/exclude-list.json | 4 ----
>>>>>>  1 file changed, 4 deletions(-)
>>>>>> 
>>>>> 
>>>>> Hi. Do you have a link to a pipeline?
>>>> 
>>>> In the cover letter. I only run it on allcode.
>>>> 
>>> 
>>> I see. I can spot these additional violations from earlycpio.c. It 
>>> does
>>> not result in a failure, but only because x86_64-allcode has also 
>>> other
>>> non-clean guidelines and is thus allowed to fail. Ideally in some
>>> copious free time I'd send a patch to create a subset of clean
>>> guidelines for the *-allcode analysis that is failing, so that the
>>> "allow_fail: true" can be removed.
>>> 
>>> https://eclair-analysis-logs.xenproject.org/fs/space/verdesse0/XEN.ecdf/xen-project/people/agvallejo/xen/ECLAIR_normal/ucode-disable_v4/X86_64/12771570090/PROJECT.ecd;/by_main_file/xen/lib/earlycpio.c.html
>> 
>> The web interface doesn't allow to search?! Sigh... thanks for the 
>> pointer.
> 
> It's your usual mess of miscasting, enum-as-int, etc.
> 
> Would you rather keep the exclusion and deal with it later or let it 
> pile up?
> I just don't have the time to go into it myself.
> 

Well, including more stuff in the scan doesn't hurt and it's only a 
handful of reports that could be fixed, but the maintainers will have 
the final say. This file is not really inside my area as a reviewer, but 
if it helps:

Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253

Re: [PATCH v4 4/5] docs/misra: Remove earlycpio.c from the Eclair exclusion list.

[Andrew Cooper]

On 20/01/2026 2:20 pm, Nicola Vetrini wrote:
> On 2026-01-20 13:09, Alejandro Vallejo wrote:
>> On Tue Jan 20, 2026 at 12:51 PM CET, Alejandro Vallejo wrote:
>>> On Tue Jan 20, 2026 at 12:41 PM CET, Nicola Vetrini wrote:
>>>> On 2026-01-20 12:27, Alejandro Vallejo wrote:
>>>>> On Tue Jan 20, 2026 at 12:21 PM CET, Nicola Vetrini wrote:
>>>>>> On 2026-01-20 10:38, Alejandro Vallejo wrote:
>>>>>>> It's clean.
>>>>>>>
>>>>>>> Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
>>>>>>> ---
>>>>>>>  docs/misra/exclude-list.json | 4 ----
>>>>>>>  1 file changed, 4 deletions(-)
>>>>>>>
>>>>>>
>>>>>> Hi. Do you have a link to a pipeline?
>>>>>
>>>>> In the cover letter. I only run it on allcode.
>>>>>
>>>>
>>>> I see. I can spot these additional violations from earlycpio.c. It
>>>> does
>>>> not result in a failure, but only because x86_64-allcode has also
>>>> other
>>>> non-clean guidelines and is thus allowed to fail. Ideally in some
>>>> copious free time I'd send a patch to create a subset of clean
>>>> guidelines for the *-allcode analysis that is failing, so that the
>>>> "allow_fail: true" can be removed.
>>>>
>>>> https://eclair-analysis-logs.xenproject.org/fs/space/verdesse0/XEN.ecdf/xen-project/people/agvallejo/xen/ECLAIR_normal/ucode-disable_v4/X86_64/12771570090/PROJECT.ecd;/by_main_file/xen/lib/earlycpio.c.html
>>>>
>>>
>>> The web interface doesn't allow to search?! Sigh... thanks for the
>>> pointer.
>>
>> It's your usual mess of miscasting, enum-as-int, etc.
>>
>> Would you rather keep the exclusion and deal with it later or let it
>> pile up?
>> I just don't have the time to go into it myself.
>>
>
> Well, including more stuff in the scan doesn't hurt and it's only a
> handful of reports that could be fixed, but the maintainers will have
> the final say. This file is not really inside my area as a reviewer,
> but if it helps:
>
> Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
>

I'm not seeing anything in that report that's on the clean and blocking
list.  But to double check, I've started

https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2274001675

which is this patch in isolation to see if anything shows up in the
*-amd runs.

~Andrew

Re: [PATCH v4 4/5] docs/misra: Remove earlycpio.c from the Eclair exclusion list.

[Nicola Vetrini]

On 2026-01-20 16:14, Andrew Cooper wrote:
> On 20/01/2026 2:20 pm, Nicola Vetrini wrote:
>> On 2026-01-20 13:09, Alejandro Vallejo wrote:
>>> On Tue Jan 20, 2026 at 12:51 PM CET, Alejandro Vallejo wrote:
>>>> On Tue Jan 20, 2026 at 12:41 PM CET, Nicola Vetrini wrote:
>>>>> On 2026-01-20 12:27, Alejandro Vallejo wrote:
>>>>>> On Tue Jan 20, 2026 at 12:21 PM CET, Nicola Vetrini wrote:
>>>>>>> On 2026-01-20 10:38, Alejandro Vallejo wrote:
>>>>>>>> It's clean.
>>>>>>>> 
>>>>>>>> Signed-off-by: Alejandro Vallejo 
>>>>>>>> <alejandro.garciavallejo@amd.com>
>>>>>>>> ---
>>>>>>>>  docs/misra/exclude-list.json | 4 ----
>>>>>>>>  1 file changed, 4 deletions(-)
>>>>>>>> 
>>>>>>> 
>>>>>>> Hi. Do you have a link to a pipeline?
>>>>>> 
>>>>>> In the cover letter. I only run it on allcode.
>>>>>> 
>>>>> 
>>>>> I see. I can spot these additional violations from earlycpio.c. It
>>>>> does
>>>>> not result in a failure, but only because x86_64-allcode has also
>>>>> other
>>>>> non-clean guidelines and is thus allowed to fail. Ideally in some
>>>>> copious free time I'd send a patch to create a subset of clean
>>>>> guidelines for the *-allcode analysis that is failing, so that the
>>>>> "allow_fail: true" can be removed.
>>>>> 
>>>>> https://eclair-analysis-logs.xenproject.org/fs/space/verdesse0/XEN.ecdf/xen-project/people/agvallejo/xen/ECLAIR_normal/ucode-disable_v4/X86_64/12771570090/PROJECT.ecd;/by_main_file/xen/lib/earlycpio.c.html
>>>>> 
>>>> 
>>>> The web interface doesn't allow to search?! Sigh... thanks for the
>>>> pointer.
>>> 
>>> It's your usual mess of miscasting, enum-as-int, etc.
>>> 
>>> Would you rather keep the exclusion and deal with it later or let it
>>> pile up?
>>> I just don't have the time to go into it myself.
>>> 
>> 
>> Well, including more stuff in the scan doesn't hurt and it's only a
>> handful of reports that could be fixed, but the maintainers will have
>> the final say. This file is not really inside my area as a reviewer,
>> but if it helps:
>> 
>> Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
>> 
> 
> I'm not seeing anything in that report that's on the clean and blocking
> list.  But to double check, I've started
> 
> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2274001675
> 
> which is this patch in isolation to see if anything shows up in the
> *-amd runs.
> 

https://eclair-analysis-logs.xenproject.org/fs/space/verdesse0/XEN.ecdf/xen-project/people/agvallejo/xen/ECLAIR_normal/ucode-disable_v4/X86_64/12771570090/PROJECT.ecd;/by_main_file/xen/lib/earlycpio.c.html#{"select":true,"selection":{"hiddenAreaKinds":[],"hiddenSubareaKinds":[],"show":true,"selector":{"enabled":true,"negated":false,"kind":1,"children":[{"enabled":true,"negated":false,"kind":0,"domain":"clean","inputs":[{"enabled":true,"text":"added"}]},{"enabled":true,"negated":true,"kind":0,"domain":"kind","inputs":[{"enabled":true,"text":"caution"}]}]}}}

Looks ugly, but it's a direct view into the clean:added selection: 
R10.2, R20.7, R7.1 in short.

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253

Re: [PATCH v4 4/5] docs/misra: Remove earlycpio.c from the Eclair exclusion list.

[Andrew Cooper]

On 20/01/2026 3:25 pm, Nicola Vetrini wrote:
> On 2026-01-20 16:14, Andrew Cooper wrote:
>> On 20/01/2026 2:20 pm, Nicola Vetrini wrote:
>>> On 2026-01-20 13:09, Alejandro Vallejo wrote:
>>>> On Tue Jan 20, 2026 at 12:51 PM CET, Alejandro Vallejo wrote:
>>>>> On Tue Jan 20, 2026 at 12:41 PM CET, Nicola Vetrini wrote:
>>>>>> On 2026-01-20 12:27, Alejandro Vallejo wrote:
>>>>>>> On Tue Jan 20, 2026 at 12:21 PM CET, Nicola Vetrini wrote:
>>>>>>>> On 2026-01-20 10:38, Alejandro Vallejo wrote:
>>>>>>>>> It's clean.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Alejandro Vallejo
>>>>>>>>> <alejandro.garciavallejo@amd.com>
>>>>>>>>> ---
>>>>>>>>>  docs/misra/exclude-list.json | 4 ----
>>>>>>>>>  1 file changed, 4 deletions(-)
>>>>>>>>>
>>>>>>>>
>>>>>>>> Hi. Do you have a link to a pipeline?
>>>>>>>
>>>>>>> In the cover letter. I only run it on allcode.
>>>>>>>
>>>>>>
>>>>>> I see. I can spot these additional violations from earlycpio.c. It
>>>>>> does
>>>>>> not result in a failure, but only because x86_64-allcode has also
>>>>>> other
>>>>>> non-clean guidelines and is thus allowed to fail. Ideally in some
>>>>>> copious free time I'd send a patch to create a subset of clean
>>>>>> guidelines for the *-allcode analysis that is failing, so that the
>>>>>> "allow_fail: true" can be removed.
>>>>>>
>>>>>> https://eclair-analysis-logs.xenproject.org/fs/space/verdesse0/XEN.ecdf/xen-project/people/agvallejo/xen/ECLAIR_normal/ucode-disable_v4/X86_64/12771570090/PROJECT.ecd;/by_main_file/xen/lib/earlycpio.c.html
>>>>>>
>>>>>>
>>>>>
>>>>> The web interface doesn't allow to search?! Sigh... thanks for the
>>>>> pointer.
>>>>
>>>> It's your usual mess of miscasting, enum-as-int, etc.
>>>>
>>>> Would you rather keep the exclusion and deal with it later or let it
>>>> pile up?
>>>> I just don't have the time to go into it myself.
>>>>
>>>
>>> Well, including more stuff in the scan doesn't hurt and it's only a
>>> handful of reports that could be fixed, but the maintainers will have
>>> the final say. This file is not really inside my area as a reviewer,
>>> but if it helps:
>>>
>>> Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
>>>
>>
>> I'm not seeing anything in that report that's on the clean and blocking
>> list.  But to double check, I've started
>>
>> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2274001675
>>
>>
>> which is this patch in isolation to see if anything shows up in the
>> *-amd runs.
>>
>
> https://eclair-analysis-logs.xenproject.org/fs/space/verdesse0/XEN.ecdf/xen-project/people/agvallejo/xen/ECLAIR_normal/ucode-disable_v4/X86_64/12771570090/PROJECT.ecd;/by_main_file/xen/lib/earlycpio.c.html#{"select":true,"selection":{"hiddenAreaKinds":[],"hiddenSubareaKinds":[],"show":true,"selector":{"enabled":true,"negated":false,"kind":1,"children":[{"enabled":true,"negated":false,"kind":0,"domain":"clean","inputs":[{"enabled":true,"text":"added"}]},{"enabled":true,"negated":true,"kind":0,"domain":"kind","inputs":[{"enabled":true,"text":"caution"}]}]}}}
>
>
> Looks ugly, but it's a direct view into the clean:added selection:
> R10.2, R20.7, R7.1 in short.
>

And to follow up:

https://gitlab.com/xen-project/hardware/xen-staging/-/jobs/12783298989

So, earlycpio.c is not clean to the clean-subset for the AMD target build.


In terms of ordering the series, patches 1 and 5 want to go in first, to
get ucode disabled in the AMD target build.

This patch wants merging into 3 for bisectibility reasons, but the
justification wanted is "so it's included in the *-allcode" analysis.

~Andrew

[PATCH v4 5/5] automation: Disable ucode loading on AMD's analysis run

[Alejandro Vallejo]

Explicitly set CONFIG_MICROCODE_LOADING=n

Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
---
 automation/gitlab-ci/analyze.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/automation/gitlab-ci/analyze.yaml b/automation/gitlab-ci/analyze.yaml
index a472692fcb..b3395e2da7 100644
--- a/automation/gitlab-ci/analyze.yaml
+++ b/automation/gitlab-ci/analyze.yaml
@@ -93,6 +93,7 @@ eclair-x86_64-amd:
       CONFIG_DEBUG_LOCKS=n
       CONFIG_SCRUB_DEBUG=n
       CONFIG_XMEM_POOL_POISON=n
+      CONFIG_MICROCODE_LOADING=n
   rules:
     - if: $ECLAIR_SAFETY
       when: always
-- 
2.43.0

Re: [PATCH v4 5/5] automation: Disable ucode loading on AMD's analysis run

[Alejandro Vallejo]

+Victor

On Tue Jan 20, 2026 at 10:38 AM CET, Alejandro Vallejo wrote:
> Explicitly set CONFIG_MICROCODE_LOADING=n
>
> Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
> ---
>  automation/gitlab-ci/analyze.yaml | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/automation/gitlab-ci/analyze.yaml b/automation/gitlab-ci/analyze.yaml
> index a472692fcb..b3395e2da7 100644
> --- a/automation/gitlab-ci/analyze.yaml
> +++ b/automation/gitlab-ci/analyze.yaml
> @@ -93,6 +93,7 @@ eclair-x86_64-amd:
>        CONFIG_DEBUG_LOCKS=n
>        CONFIG_SCRUB_DEBUG=n
>        CONFIG_XMEM_POOL_POISON=n
> +      CONFIG_MICROCODE_LOADING=n
>    rules:
>      - if: $ECLAIR_SAFETY
>        when: always

Re: [PATCH v4 5/5] automation: Disable ucode loading on AMD's analysis run

[Andrew Cooper]

On 20/01/2026 9:38 am, Alejandro Vallejo wrote:
> Explicitly set CONFIG_MICROCODE_LOADING=n
>
> Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>

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

I've discussed this enough with Stefano in the past to know that it's
part of ThePlan(tm).

~Andrew

Re: [PATCH v4 5/5] automation: Disable ucode loading on AMD's analysis run

[Stefano Stabellini]

On Wed, 21 Jan 2026, Andrew Cooper wrote:
> On 20/01/2026 9:38 am, Alejandro Vallejo wrote:
> > Explicitly set CONFIG_MICROCODE_LOADING=n
> >
> > Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
> 
> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
> 
> I've discussed this enough with Stefano in the past to know that it's
> part of ThePlan(tm).

Yep, thanks Andrew. Ack from me as well.

Re: [PATCH v4 0/4] Add Kconfig option to remove microcode loading support

[Jan Beulich]

On 20.01.2026 10:38, Alejandro Vallejo wrote:
> The only dependency here is patch 2 going in before patch 3. Everything else
> can be freely rearranged.

Is this correct? Didn't you say (confirming what I observed elsewhere a little
while back) that there's a complaint when a file listed in the exclusions doesn't
exist anymore (which may have been cppcheck, not Eclair, but still breaking CI)?
IOW can patch 4 really be separate from patch 3? Or, if its description was to
be trusted, wouldn't it need to go ahead of what is now patch 3?

> Cheers,
> Alejandro
> 
> Alejandro Vallejo (5):
>   x86/ucode: Add Kconfig option to remove microcode loading
>   xen: Allow lib-y targets to also be .init.o
>   earlycpio: lib-ify earlycpio.c
>   docs/misra: Remove earlycpio.c from the Eclair exclusion list.
>   automation: Disable ucode loading on AMD's analysis run
> 
>  automation/gitlab-ci/analyze.yaml      |  1 +
>  docs/admin-guide/microcode-loading.rst |  2 ++
>  docs/misc/efi.pandoc                   |  2 ++
>  docs/misc/xen-command-line.pandoc      |  7 ++++---
>  docs/misra/exclude-list.json           |  4 ----
>  xen/Rules.mk                           | 10 +++++-----
>  xen/arch/x86/Kconfig                   | 14 ++++++++++++++
>  xen/arch/x86/cpu/microcode/amd.c       | 16 +++++++++-------
>  xen/arch/x86/cpu/microcode/core.c      | 15 ++++++++++++---
>  xen/arch/x86/cpu/microcode/intel.c     | 11 +++++++----
>  xen/arch/x86/cpu/microcode/private.h   |  3 +++
>  xen/arch/x86/efi/efi-boot.h            |  3 ++-
>  xen/arch/x86/platform_hypercall.c      | 10 ++++++++--
>  xen/common/Makefile                    |  2 +-
>  xen/lib/Makefile                       |  1 +
>  xen/{common => lib}/earlycpio.c        |  0
>  16 files changed, 71 insertions(+), 30 deletions(-)
>  rename xen/{common => lib}/earlycpio.c (100%)
> 
> 
> base-commit: 7b3e1b4e848d34c9a5b6634009959a7b9dd42104

Re: [PATCH v4 0/4] Add Kconfig option to remove microcode loading support

[Alejandro Vallejo]

On Tue Jan 20, 2026 at 11:20 AM CET, Jan Beulich wrote:
> On 20.01.2026 10:38, Alejandro Vallejo wrote:
>> The only dependency here is patch 2 going in before patch 3. Everything else
>> can be freely rearranged.
>
> Is this correct? Didn't you say (confirming what I observed elsewhere a little
> while back) that there's a complaint when a file listed in the exclusions doesn't
> exist anymore (which may have been cppcheck, not Eclair, but still breaking CI)?
> IOW can patch 4 really be separate from patch 3? Or, if its description was to
> be trusted, wouldn't it need to go ahead of what is now patch 3?

Doh, you're right, they are out of order. Patch 4 now just removes the exclusion
so it's fine to do it separately.

So patch3 <-> patch4.

Cheers,
Alejandro

Re: [PATCH v4 0/4] Add Kconfig option to remove microcode loading support

[Jan Beulich]

On 20.01.2026 11:38, Alejandro Vallejo wrote:
> On Tue Jan 20, 2026 at 11:20 AM CET, Jan Beulich wrote:
>> On 20.01.2026 10:38, Alejandro Vallejo wrote:
>>> The only dependency here is patch 2 going in before patch 3. Everything else
>>> can be freely rearranged.
>>
>> Is this correct? Didn't you say (confirming what I observed elsewhere a little
>> while back) that there's a complaint when a file listed in the exclusions doesn't
>> exist anymore (which may have been cppcheck, not Eclair, but still breaking CI)?
>> IOW can patch 4 really be separate from patch 3? Or, if its description was to
>> be trusted, wouldn't it need to go ahead of what is now patch 3?
> 
> Doh, you're right, they are out of order. Patch 4 now just removes the exclusion
> so it's fine to do it separately.

I.e. the description there saying "it's clean" is accurate, and it was excluded
for (effectively) no reason?

> So patch3 <-> patch4.

Noted.

Jan

Re: [PATCH v4 0/4] Add Kconfig option to remove microcode loading support

[Alejandro Vallejo]

On Tue Jan 20, 2026 at 11:52 AM CET, Jan Beulich wrote:
> On 20.01.2026 11:38, Alejandro Vallejo wrote:
>> On Tue Jan 20, 2026 at 11:20 AM CET, Jan Beulich wrote:
>>> On 20.01.2026 10:38, Alejandro Vallejo wrote:
>>>> The only dependency here is patch 2 going in before patch 3. Everything else
>>>> can be freely rearranged.
>>>
>>> Is this correct? Didn't you say (confirming what I observed elsewhere a little
>>> while back) that there's a complaint when a file listed in the exclusions doesn't
>>> exist anymore (which may have been cppcheck, not Eclair, but still breaking CI)?
>>> IOW can patch 4 really be separate from patch 3? Or, if its description was to
>>> be trusted, wouldn't it need to go ahead of what is now patch 3?
>> 
>> Doh, you're right, they are out of order. Patch 4 now just removes the exclusion
>> so it's fine to do it separately.
>
> I.e. the description there saying "it's clean" is accurate, and it was excluded
> for (effectively) no reason?

All I can say is that I looked at the report after running Eclair and found no
trace of earlycpio.c in the violations. It's not clean, but I don't think it
is as of now.

As to why it was excluded in the first place, your guess is as good as mine.
Maybe all decompressors were excluded regardless of them being clean or not
(e.g: zstd is also excluded).

Cheers,
Alejandro

Re: [PATCH v4 0/4] Add Kconfig option to remove microcode loading support

[Nicola Vetrini]

On 2026-01-20 12:03, Alejandro Vallejo wrote:
> On Tue Jan 20, 2026 at 11:52 AM CET, Jan Beulich wrote:
>> On 20.01.2026 11:38, Alejandro Vallejo wrote:
>>> On Tue Jan 20, 2026 at 11:20 AM CET, Jan Beulich wrote:
>>>> On 20.01.2026 10:38, Alejandro Vallejo wrote:
>>>>> The only dependency here is patch 2 going in before patch 3. 
>>>>> Everything else
>>>>> can be freely rearranged.
>>>> 
>>>> Is this correct? Didn't you say (confirming what I observed 
>>>> elsewhere a little
>>>> while back) that there's a complaint when a file listed in the 
>>>> exclusions doesn't
>>>> exist anymore (which may have been cppcheck, not Eclair, but still 
>>>> breaking CI)?
>>>> IOW can patch 4 really be separate from patch 3? Or, if its 
>>>> description was to
>>>> be trusted, wouldn't it need to go ahead of what is now patch 3?
>>> 
>>> Doh, you're right, they are out of order. Patch 4 now just removes 
>>> the exclusion
>>> so it's fine to do it separately.
>> 
>> I.e. the description there saying "it's clean" is accurate, and it was 
>> excluded
>> for (effectively) no reason?
> 
> All I can say is that I looked at the report after running Eclair and 
> found no
> trace of earlycpio.c in the violations. It's not clean, but I don't 
> think it
> is as of now.
> 
> As to why it was excluded in the first place, your guess is as good as 
> mine.
> Maybe all decompressors were excluded regardless of them being clean or 
> not
> (e.g: zstd is also excluded).
> 

Well, the list was devised by AMD before even plumbing the MISRA 
checking infrastructure, so it may well be that some files in there can 
be removed because they have no violations on clean guidelines (that is 
not to say that they contain no violations at all: it may be that they 
have some additional ones in non-clean guidelines).

> Cheers,
> Alejandro

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253