2 paths we are doing in parallel:

1. We are doing our best to make it upstream in Linux, it's a regression after all. We know how to fix it, so hopefully this will be fixed quickly. Then, we'll have to wait for a Linux kernel update in main distros.
2. Invariant TSC in Xen is also a way to fix it, because we want to improve that anyway. But as Teddy said, it's more work and it will take more time.

Expect news in the next XO release

Ping @Team-Hypervisor-Kernel for reference.

Found the culprit, made & tested a patch that works.

Recap at https://notes.vates.tech/share/v5jtq0iytw/p/slow-hvm-boot-on-linux-6-12-5wrvOvZKJ7

I will let the rest of my team to try to get it fixed in upstream.

• 6.12.90 -> bad
• 6.12.45 -> bad
• 6.12.22 -> bad
• 6.12.11 -> bad
• 6.12.5 -> bad

BUT 6.12.2 is GOOD! Almost there!

edit: now 6.12.3 is also good. Getting close…

edit: since 6.12.4 is good, then the issue is within 6.12.5. Investigating now.

Luckily I have enough cores to build a kernel in 2 minutes, because it's been a LOT of them already built to find the culprit

I'm currently bisecting various kernel builds, I think I'm close to find the culprit.

That would be interesting to group your findings/issues on RPU in a dedicated topic, because I don't think the logic changed recently So it's an interesting investigation to make.

I can reproduce on Debian 13 with stock kernel and a Ryzen 5 7600.

Yes, there's a weird issue when using both XOSTOR and HA, probably due to the HA mechanism itself. @Team-Storage is on it

There's no open source driver for ReFS, so…

Maybe you can check for a bigger timeout on your UDM?

And how that change in architecture would disconnect you? Your SD-WAN is cutting the feed?

Hi,

Can you be more specific on the error you have?

Ping @julienxovates

Please disable HA and report if you still have the issue.

Is this cluster using HA or not?

Interesting Ping @florent and @julienxovates

Hi,

Please ping @julienxovates it will be more efficient

Ping @Team-XAPI-Network