When booting WS2025 with following CLI 1) -M q35,hpet=off -cpu host -enable-kvm -smp 240,sockets=4 the guest boots very slow and is sluggish after boot or it's stuck on boot at spinning circle.
pref shows that VM is experiencing heavy BQL contention on IO path which happens to be ACPI PM timer read access. A variation with HPET enabled moves contention to HPET timer read access. And it only gets worse with increasing number of VCPUs. Series prevents large VM vCPUs contending on BQL due to PM|HPET timer access and lets it move on with boot process. It's basically resurecting Jan's idea [2] of BQL-free IO access, with a twist that whitelist reads access only to minimze chances of [3] issues. If we hit issues later on, it might be better to actually find a root cause and perhaps fix guest side if possible. (so I tested series with a bucn of different guests instead, RHEL-[6..10]x64, WS2012R2, WS2016, WS2022, WS2025) In my tests, with [1] CLI WS2025 guest wasn't able to boot within 30min on both hosts * 32 core 2NUMA nodes * 448 cores 8NUMA nodes With ACPI PM timer in BQL-free read mode, guest boots within approx: * 2min * 1min respectively. With HPET enabled boot time shrinks ~2x * 4m13 -> 2m21 * 2m19 -> 1m15 respectively. Using hv-time=on cpu option helps a lot (when it works) and lets [1] guest boot fine in ~1-2min (this series reduces boot time on ~10% on top of hv-time improvements). 2) 196ea13104f (memory: Add global-locking property to memory regions) ... de7ea885c539 (kvm: Switch to unlocked MMIO) 3) https://bugzilla.redhat.com/show_bug.cgi?id=1322713 1beb99f787 (Revert "acpi: mark PMTIMER as unlocked") Igor Mammedov (3): memory: reintroduce BQL-free fine-grained PIO/MMIO acpi: mark PMTIMER as unlocked mark HPET as unlocked include/system/memory.h | 10 +++++++++- hw/acpi/core.c | 2 ++ hw/remote/vfio-user-obj.c | 2 +- hw/timer/hpet.c | 2 ++ system/memory.c | 5 +++++ system/memory_ldst.c.inc | 18 +++++++++--------- system/physmem.c | 9 +++++---- 7 files changed, 33 insertions(+), 15 deletions(-) -- 2.43.5
