I am sometimes/rarely (about 1-in-20) observing severe VM slowdowns when booting up VMs using snp-latest
(as of friday 07/12, i had the most recent repo state: ovmf 4b6ee06a09, kernel-guest a38297e3fb01, kernel-host 05b10142ac6a, qemu fb924a5139 using the AmdSevX64 VM BIOS)
I have not yet been able to reproducibly trigger this error, have not seen any other reports on cpu softlocks occurring and would be thankful for any advice on how to further debug this situation.
During boot or soon after the VM comes up it prints watchdog timeouts for stuck CPUs
[ 24.713693] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
[ 24.715447] rcu: 9-...0: (1 ticks this GP) idle=9d74/1/0x4000000000000000 softirq=30/30 fqs=2062
[ 24.718017] rcu: (detected by 20, t=5252 jiffies, g=-831, q=85 ncpus=24)
[ 24.719390] Sending NMI from CPU 20 to CPUs 9:
Message from syslogd@ns31614456 at Jul 11 03:12:58 ...
kernel:[ 4796.249920] watchdog: BUG: soft lockup - CPU#24 stuck for 26s! [qemu-system-x86:263413]
The VM remains responsive but slows to a crawl, VM and Host power operations such as sudo reboot fail and the only way to recover the box is to physically power cycle it, after which both host and VM boot back up and work normally.
If a VM does not run into this issue during/early-after start up, it seems to run stably and not randomly trigger this issue later on.
Here's a trace recorded in host's dmesg in one such situation in case it's helpful.
I am sometimes/rarely (about 1-in-20) observing severe VM slowdowns when booting up VMs using
snp-latest(as of friday 07/12, i had the most recent repo state: ovmf 4b6ee06a09, kernel-guest a38297e3fb01, kernel-host 05b10142ac6a, qemu fb924a5139 using the AmdSevX64 VM BIOS)I have not yet been able to reproducibly trigger this error, have not seen any other reports on
cpu softlocks occurring and would be thankful for any advice on how to further debug this situation.During boot or soon after the VM comes up it prints watchdog timeouts for stuck CPUs
The VM remains responsive but slows to a crawl, VM and Host power operations such as
sudo rebootfail and the only way to recover the box is to physically power cycle it, after which both host and VM boot back up and work normally.If a VM does not run into this issue during/early-after start up, it seems to run stably and not randomly trigger this issue later on.
Here's a trace recorded in host's dmesg in one such situation in case it's helpful.