[PATCH v5 0/2]

[PATCH v5 0/2]

[Alejandro Vallejo]

Hi,

Not very related to microcode anymore, but this was part of the microcode
series, so...

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/
v4: https://lore.kernel.org/xen-devel/20260120093852.2380-1-alejandro.garciavallejo@amd.com/

Alejandro Vallejo (2):
  xen: Allow lib-y targets to also be .init.o
  earlycpio: lib-ify earlycpio.c

 docs/misra/exclude-list.json    |  4 ----
 xen/Rules.mk                    | 10 +++++-----
 xen/common/Makefile             |  2 +-
 xen/lib/Makefile                |  1 +
 xen/{common => lib}/earlycpio.c |  0
 5 files changed, 7 insertions(+), 10 deletions(-)
 rename xen/{common => lib}/earlycpio.c (100%)


base-commit: 61204ed24ba4537d6eff56594faa5d23cacb8310
-- 
2.43.0

[PATCH v5 1/2] 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>
Reviewed-by: Jan Beulich <jbeulich@suse.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

[PATCH v5 2/2] 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.

The exclude-list.json file goes stale after the move, so remove the entry
for earlycpio.c now that it's not included in AMD's build.

Its breakages will be fixed in due time and not ignored.

Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com> # lib-ify only
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com> # exclude-list.json
---
 docs/misra/exclude-list.json    | 4 ----
 xen/common/Makefile             | 2 +-
 xen/lib/Makefile                | 1 +
 xen/{common => lib}/earlycpio.c | 0
 4 files changed, 2 insertions(+), 5 deletions(-)
 rename xen/{common => lib}/earlycpio.c (100%)

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"
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 v5 2/2] earlycpio: lib-ify earlycpio.c

[Andrew Cooper]

On 21/01/2026 3:47 pm, 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.

Given what's committed, this becomes "when CONFIG_MICROCODE_LOADING=n" now.

> The exclude-list.json file goes stale after the move, so remove the entry
> for earlycpio.c now that it's not included in AMD's build.
>
> Its breakages will be fixed in due time and not ignored.

---8<---
exclude-list.json becomes stale with the move, but earlycpio is now
absent entirely in the *-amd target build, so the violations don't matter.

Simply drop the exclusion, so the logic gets scanned as part of the
*-allcode targets.
---8<---


>
> Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com> # lib-ify only
> Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com> # exclude-list.json

Consider my A-by extended to a full R-by, and this looks fine to go in now.

~Andrew

Re: [PATCH v5 2/2] earlycpio: lib-ify earlycpio.c

[Jan Beulich]

On 21.01.2026 16:47, Alejandro Vallejo wrote:
> --- 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"

Judging from Andrew's
https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2277362625
this doesn't quite work. As I had expected, since the file is compiled
unconditionally now in its new location, some violations are now also
unconditionally reported. (Some, checked for at linking time only, may not
be reported anymore for the *-amd analysis jobs.)

Jan

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

[Jan Beulich]

On 21.01.2026 16:47, 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>

I can't tell (yet) what it is, but as per CI something's clearly wrong with this
change. Both xilinx-smoke-dom0less-arm64-* and qemu-smoke-dom0*-debug* fail with
it in place. qemu-smoke-dom0-arm64-gcc (no "debug") was fine, suggesting it may
be an early assertion triggering. Nothing in the logs though.

Jan

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

[Jan Beulich]

On 22.01.2026 10:49, Jan Beulich wrote:
> On 21.01.2026 16:47, 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>
> 
> I can't tell (yet) what it is, but as per CI something's clearly wrong with this
> change. Both xilinx-smoke-dom0less-arm64-* and qemu-smoke-dom0*-debug* fail with
> it in place. qemu-smoke-dom0-arm64-gcc (no "debug") was fine, suggesting it may
> be an early assertion triggering.

Or an early UBSAN failure. I think ...

>> --- 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))

... this is the problem: You're _adding_ library files here which weren't there
before. Why $(lib-y) isn't here I don't really known, but as per the CI results
there must be a reason for this.

Jan

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

[Alejandro Vallejo]

On Thu Jan 22, 2026 at 11:01 AM CET, Jan Beulich wrote:
> On 22.01.2026 10:49, Jan Beulich wrote:
>> On 21.01.2026 16:47, 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>
>> 
>> I can't tell (yet) what it is, but as per CI something's clearly wrong with this
>> change. Both xilinx-smoke-dom0less-arm64-* and qemu-smoke-dom0*-debug* fail with
>> it in place. qemu-smoke-dom0-arm64-gcc (no "debug") was fine, suggesting it may
>> be an early assertion triggering.
>
> Or an early UBSAN failure. I think ...
>
>>> --- 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))
>
> ... this is the problem: You're _adding_ library files here which weren't there
> before. Why $(lib-y) isn't here I don't really known, but as per the CI results
> there must be a reason for this.

Apologies for the unintended breakage. I should've checked the baseline for
arm before ruling out this patch being the cause (it did fire in my pipeline,
but didn't consider how this could affect arm and attributed it to a spurious
failure).

So we're neither doing UBSAN nor collecting coverage data from libs? Great. One
more task to the pile, I guess. Seeing how...

 $(non-init-objects): _c_flags += $(cov-cflags-y)
 [snip]
 $(non-init-objects): _c_flags += $(UBSAN_FLAGS)

I'll try to clean this mess. :/

Cheers,
Alejandro

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

[Jan Beulich]

On 22.01.2026 12:02, Alejandro Vallejo wrote:
> On Thu Jan 22, 2026 at 11:01 AM CET, Jan Beulich wrote:
>> On 22.01.2026 10:49, Jan Beulich wrote:
>>> On 21.01.2026 16:47, 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>
>>>
>>> I can't tell (yet) what it is, but as per CI something's clearly wrong with this
>>> change. Both xilinx-smoke-dom0less-arm64-* and qemu-smoke-dom0*-debug* fail with
>>> it in place. qemu-smoke-dom0-arm64-gcc (no "debug") was fine, suggesting it may
>>> be an early assertion triggering.
>>
>> Or an early UBSAN failure. I think ...
>>
>>>> --- 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))
>>
>> ... this is the problem: You're _adding_ library files here which weren't there
>> before. Why $(lib-y) isn't here I don't really known, but as per the CI results
>> there must be a reason for this.
> 
> Apologies for the unintended breakage. I should've checked the baseline for
> arm before ruling out this patch being the cause (it did fire in my pipeline,
> but didn't consider how this could affect arm and attributed it to a spurious
> failure).
> 
> So we're neither doing UBSAN nor collecting coverage data from libs? Great. One
> more task to the pile, I guess. Seeing how...
> 
>  $(non-init-objects): _c_flags += $(cov-cflags-y)
>  [snip]
>  $(non-init-objects): _c_flags += $(UBSAN_FLAGS)
> 
> I'll try to clean this mess. :/

In the meantime, should I give your patch another try with that one change dropped?

Jan

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

[Alejandro Vallejo]

On Thu Jan 22, 2026 at 12:04 PM CET, Jan Beulich wrote:
> On 22.01.2026 12:02, Alejandro Vallejo wrote:
>> On Thu Jan 22, 2026 at 11:01 AM CET, Jan Beulich wrote:
>>> On 22.01.2026 10:49, Jan Beulich wrote:
>>>> On 21.01.2026 16:47, 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>
>>>>
>>>> I can't tell (yet) what it is, but as per CI something's clearly wrong with this
>>>> change. Both xilinx-smoke-dom0less-arm64-* and qemu-smoke-dom0*-debug* fail with
>>>> it in place. qemu-smoke-dom0-arm64-gcc (no "debug") was fine, suggesting it may
>>>> be an early assertion triggering.
>>>
>>> Or an early UBSAN failure. I think ...
>>>
>>>>> --- 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))
>>>
>>> ... this is the problem: You're _adding_ library files here which weren't there
>>> before. Why $(lib-y) isn't here I don't really known, but as per the CI results
>>> there must be a reason for this.
>> 
>> Apologies for the unintended breakage. I should've checked the baseline for
>> arm before ruling out this patch being the cause (it did fire in my pipeline,
>> but didn't consider how this could affect arm and attributed it to a spurious
>> failure).
>> 
>> So we're neither doing UBSAN nor collecting coverage data from libs? Great. One
>> more task to the pile, I guess. Seeing how...
>> 
>>  $(non-init-objects): _c_flags += $(cov-cflags-y)
>>  [snip]
>>  $(non-init-objects): _c_flags += $(UBSAN_FLAGS)
>> 
>> I'll try to clean this mess. :/
>
> In the meantime, should I give your patch another try with that one change dropped?
>
> Jan

Sure, thanks.

Cheers,
Alejandro

Re: [PATCH v5 2/2] earlycpio: lib-ify earlycpio.c

[Andrew Cooper]

On 22/01/2026 8:27 am, Jan Beulich wrote:
> On 21.01.2026 16:47, Alejandro Vallejo wrote:
>> --- 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"
> Judging from Andrew's
> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2277362625
> this doesn't quite work. As I had expected, since the file is compiled
> unconditionally now in its new location, some violations are now also
> unconditionally reported. (Some, checked for at linking time only, may not
> be reported anymore for the *-amd analysis jobs.)

Yeah, in hindsight this seems obvious, given that we're compiling then
discarding.

There are two options:

1. Use an earlier form which adds the new location to the exclude list 
(Still needs to be in this patch for bisectibility.)
2. Fix up the violations first (only 6 in total)

Two of the violations look easy to fix, two need the deviation for octal
numbers, but two essentially-char violations look to be hard.  The logic
is doing ASCII manipulation in what I would consider to be the
appropriate/canonical way, but Eclair does not like the mixture of ints
and character literals.

I dislike option 1, but as (contrary to my expectations) this is
interfering with the *-amd build, I'll tolerate it.

~Andrew

Re: [PATCH v5 2/2] earlycpio: lib-ify earlycpio.c

[Nicola Vetrini]

On 2026-01-22 13:50, Andrew Cooper wrote:
> On 22/01/2026 8:27 am, Jan Beulich wrote:
>> On 21.01.2026 16:47, Alejandro Vallejo wrote:
>>> --- 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"
>> Judging from Andrew's
>> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2277362625
>> this doesn't quite work. As I had expected, since the file is compiled
>> unconditionally now in its new location, some violations are now also
>> unconditionally reported. (Some, checked for at linking time only, may 
>> not
>> be reported anymore for the *-amd analysis jobs.)
> 
> Yeah, in hindsight this seems obvious, given that we're compiling then
> discarding.
> 
> There are two options:
> 
> 1. Use an earlier form which adds the new location to the exclude list 
> (Still needs to be in this patch for bisectibility.)
> 2. Fix up the violations first (only 6 in total)
> 
> Two of the violations look easy to fix, two need the deviation for 
> octal
> numbers, but two essentially-char violations look to be hard.  The 
> logic
> is doing ASCII manipulation in what I would consider to be the
> appropriate/canonical way, but Eclair does not like the mixture of ints
> and character literals.
> 
> I dislike option 1, but as (contrary to my expectations) this is
> interfering with the *-amd build, I'll tolerate it.
> 

I agree that Solution 1 is the easiest to implement. An alternative 
could be to fix the regressions for R7.1 and R20.7 (they're trivial) 
regardless and add casts to sidestep MISRA for R10.2.

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

Re: [PATCH v5 2/2] earlycpio: lib-ify earlycpio.c

[Alejandro Vallejo]

On Thu Jan 22, 2026 at 3:18 PM CET, Nicola Vetrini wrote:
> On 2026-01-22 13:50, Andrew Cooper wrote:
>> On 22/01/2026 8:27 am, Jan Beulich wrote:
>>> On 21.01.2026 16:47, Alejandro Vallejo wrote:
>>>> --- 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"
>>> Judging from Andrew's
>>> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2277362625
>>> this doesn't quite work. As I had expected, since the file is compiled
>>> unconditionally now in its new location, some violations are now also
>>> unconditionally reported. (Some, checked for at linking time only, may 
>>> not
>>> be reported anymore for the *-amd analysis jobs.)
>> 
>> Yeah, in hindsight this seems obvious, given that we're compiling then
>> discarding.
>> 
>> There are two options:
>> 
>> 1. Use an earlier form which adds the new location to the exclude list 
>> (Still needs to be in this patch for bisectibility.)
>> 2. Fix up the violations first (only 6 in total)
>> 
>> Two of the violations look easy to fix, two need the deviation for 
>> octal
>> numbers, but two essentially-char violations look to be hard.  The 
>> logic
>> is doing ASCII manipulation in what I would consider to be the
>> appropriate/canonical way, but Eclair does not like the mixture of ints
>> and character literals.
>> 
>> I dislike option 1, but as (contrary to my expectations) this is
>> interfering with the *-amd build, I'll tolerate it.
>> 
>
> I agree that Solution 1 is the easiest to implement. An alternative 
> could be to fix the regressions for R7.1 and R20.7 (they're trivial) 
> regardless and add casts to sidestep MISRA for R10.2.

Easy as it is, and while I'd prefer to fix earlycpio.c, I just don't have
time to do it now. The original incarnation of the patch I sent that moved the
exclusion would work here.

That patch, followed by the lib move (as it was back then) ought to work for the
time being. I'm not in a hurry though so I'm happy for the move to wait until
someone finds the time to fix the errors. Whatever you prefer.

Cheers,
Alejandro

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

[Orzel, Michal]

On 22/01/2026 11:01, Jan Beulich wrote:
> On 22.01.2026 10:49, Jan Beulich wrote:
>> On 21.01.2026 16:47, 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>
>>
>> I can't tell (yet) what it is, but as per CI something's clearly wrong with this
>> change. Both xilinx-smoke-dom0less-arm64-* and qemu-smoke-dom0*-debug* fail with
>> it in place. qemu-smoke-dom0-arm64-gcc (no "debug") was fine, suggesting it may
>> be an early assertion triggering.
> 
> Or an early UBSAN failure. I think ...
I did a test and it looks like the problem is division by zero in
generic_muldiv64. At this point, time is not yet initialized on Arm, so cpu_khz
is 0 in ticks_to_ns.

(XEN) [000000005019d0ee] UBSAN: Undefined behaviour in lib/muldiv64.c:23:21
(XEN) [00000000501cfc11] division by zero
(XEN) [0000000050211d11] Xen WARN at common/ubsan/ubsan.c:176
(XEN) [000000005023b3ec] ----[ Xen-4.22-unstable  arm64  debug=y ubsan=y  Not
tainted ]----
(XEN) [0000000050afc964] Xen call trace:
(XEN) [0000000050b0e4ec]    [<00000a000032ab44>]
ubsan.c#ubsan_epilogue+0x14/0xec (PC)
(XEN) [0000000050b2f1c1]    [<00000a000032b35c>]
__ubsan_handle_divrem_overflow+0x114/0x1e4 (LR)
(XEN) [0000000050b577dd]    [<00000a000032b35c>]
__ubsan_handle_divrem_overflow+0x114/0x1e4
(XEN) [0000000050b790fb]    [<00000a00003eb9d0>] generic_muldiv64+0x7c/0xbc
(XEN) [0000000050b94539]    [<00000a00003bfb9c>] ticks_to_ns+0x24/0x2c
(XEN) [0000000050bad89d]    [<00000a00003bfc04>] get_s_time+0x34/0x54
(XEN) [0000000050bc731b]    [<00000a000032dec8>]
console.c#printk_start_of_line+0x2bc/0x374
(XEN) [0000000050be7987]    [<00000a000032ef3c>]
console.c#vprintk_common+0x454/0x484
(XEN) [0000000050c06033]    [<00000a000032ef94>] vprintk+0x28/0x30
(XEN) [0000000050c1e4df]    [<00000a000032eff8>] printk+0x5c/0x64
(XEN) [0000000050c3904b]    [<00000a00005548f8>] end_boot_allocator+0x31c/0x548
(XEN) [0000000050c55a86]    [<00000a0000585c58>] start_xen+0x150/0xe68
(XEN) [0000000050c70232]    [<00000a00002001a4>] head.o#primary_switched+0x4/0x24
(XEN) [0000000050c8d2bf]

~Michal

> 
>>> --- 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))
> 
> ... this is the problem: You're _adding_ library files here which weren't there
> before. Why $(lib-y) isn't here I don't really known, but as per the CI results
> there must be a reason for this.
> 
> Jan

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

[Jan Beulich]

On 23.01.2026 11:56, Orzel, Michal wrote:
> On 22/01/2026 11:01, Jan Beulich wrote:
>> On 22.01.2026 10:49, Jan Beulich wrote:
>>> On 21.01.2026 16:47, 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>
>>>
>>> I can't tell (yet) what it is, but as per CI something's clearly wrong with this
>>> change. Both xilinx-smoke-dom0less-arm64-* and qemu-smoke-dom0*-debug* fail with
>>> it in place. qemu-smoke-dom0-arm64-gcc (no "debug") was fine, suggesting it may
>>> be an early assertion triggering.
>>
>> Or an early UBSAN failure. I think ...
> I did a test and it looks like the problem is division by zero in
> generic_muldiv64. At this point, time is not yet initialized on Arm, so cpu_khz
> is 0 in ticks_to_ns.

And division by 0 is otherwise benign on Arm64? (On x86 it raises an exception
and hence would be a problem also without UBSAN.)

Jan

> (XEN) [000000005019d0ee] UBSAN: Undefined behaviour in lib/muldiv64.c:23:21
> (XEN) [00000000501cfc11] division by zero
> (XEN) [0000000050211d11] Xen WARN at common/ubsan/ubsan.c:176
> (XEN) [000000005023b3ec] ----[ Xen-4.22-unstable  arm64  debug=y ubsan=y  Not
> tainted ]----
> (XEN) [0000000050afc964] Xen call trace:
> (XEN) [0000000050b0e4ec]    [<00000a000032ab44>]
> ubsan.c#ubsan_epilogue+0x14/0xec (PC)
> (XEN) [0000000050b2f1c1]    [<00000a000032b35c>]
> __ubsan_handle_divrem_overflow+0x114/0x1e4 (LR)
> (XEN) [0000000050b577dd]    [<00000a000032b35c>]
> __ubsan_handle_divrem_overflow+0x114/0x1e4
> (XEN) [0000000050b790fb]    [<00000a00003eb9d0>] generic_muldiv64+0x7c/0xbc
> (XEN) [0000000050b94539]    [<00000a00003bfb9c>] ticks_to_ns+0x24/0x2c
> (XEN) [0000000050bad89d]    [<00000a00003bfc04>] get_s_time+0x34/0x54
> (XEN) [0000000050bc731b]    [<00000a000032dec8>]
> console.c#printk_start_of_line+0x2bc/0x374
> (XEN) [0000000050be7987]    [<00000a000032ef3c>]
> console.c#vprintk_common+0x454/0x484
> (XEN) [0000000050c06033]    [<00000a000032ef94>] vprintk+0x28/0x30
> (XEN) [0000000050c1e4df]    [<00000a000032eff8>] printk+0x5c/0x64
> (XEN) [0000000050c3904b]    [<00000a00005548f8>] end_boot_allocator+0x31c/0x548
> (XEN) [0000000050c55a86]    [<00000a0000585c58>] start_xen+0x150/0xe68
> (XEN) [0000000050c70232]    [<00000a00002001a4>] head.o#primary_switched+0x4/0x24
> (XEN) [0000000050c8d2bf]
> 
> ~Michal

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

[Orzel, Michal]

On 23/01/2026 12:37, Jan Beulich wrote:
> On 23.01.2026 11:56, Orzel, Michal wrote:
>> On 22/01/2026 11:01, Jan Beulich wrote:
>>> On 22.01.2026 10:49, Jan Beulich wrote:
>>>> On 21.01.2026 16:47, 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>
>>>>
>>>> I can't tell (yet) what it is, but as per CI something's clearly wrong with this
>>>> change. Both xilinx-smoke-dom0less-arm64-* and qemu-smoke-dom0*-debug* fail with
>>>> it in place. qemu-smoke-dom0-arm64-gcc (no "debug") was fine, suggesting it may
>>>> be an early assertion triggering.
>>>
>>> Or an early UBSAN failure. I think ...
>> I did a test and it looks like the problem is division by zero in
>> generic_muldiv64. At this point, time is not yet initialized on Arm, so cpu_khz
>> is 0 in ticks_to_ns.
> 
> And division by 0 is otherwise benign on Arm64? (On x86 it raises an exception
> and hence would be a problem also without UBSAN.)
From the ARM ARM spec:
"A division by zero results in a zero being written to the destination register,
without any indication that the division by
zero occurred."

~Michal