[REGRESSION][BISECTED] Long boot time with Xen HVM guests during PV spinlock initialization

[Teddy Astie <teddy.astie@xxxxxxxxxx>]

Hello,

In 6.12.5+ kernels on AMD CPUs, we observe abnormally long boot times 
where the guest is struggling on PV spinlock initialization.
This occurs starting with 6.12.5, and also on more recent kernels on 
Intel platforms, but that hasn't been fully investigated at this time 
(but I assume it's a variant of the same issue).
This occurs since a backport of 76031d9 ("clocksource: Make negative 
motion detection more robust").
Some (claude-based) analysis made appears to relate that to the lack of 
proper max_raw_delta in the jiffies clocksource which appears to make 
the clock fail to progress meaningfully.
Here is a raw summary of the analysis
> We tracked it down to a single stable backport in 6.12.5: commit 
1a678f6829a8 ("clocksource: Make negative motion detection more robust", 
upstream 76031d9536a0). It introduces a max_raw_delta field on struct 
clocksource but never initializes it for the default boot timekeeper 
(the jiffies clocksource), so clocksource_delta() clamps every delta to 
0 and CLOCK_MONOTONIC freezes while that clocksource is active. On this 
HVM guest, SMP bring-up runs while the jiffies clocksource is still the 
timekeeper, and the Xen single shot (high resolution) tick then advances 
jiffies far too slowly, so the secondary CPUs burn seconds in 
calibrate_delay().
Teddy

Attachment: OpenPGP_0x660FA9D102CBCFD0.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature