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

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

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

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

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

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