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 <[email protected]>
>>> Reviewed-by: Jan Beulich <[email protected]>
>>
>> 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
