diff options
Diffstat (limited to 'results/classifier/zero-shot/105/semantic/1569')
| -rw-r--r-- | results/classifier/zero-shot/105/semantic/1569 | 40 |
1 files changed, 40 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/105/semantic/1569 b/results/classifier/zero-shot/105/semantic/1569 new file mode 100644 index 000000000..944cb513e --- /dev/null +++ b/results/classifier/zero-shot/105/semantic/1569 @@ -0,0 +1,40 @@ +semantic: 0.856 +vnc: 0.850 +boot: 0.830 +graphic: 0.828 +device: 0.759 +network: 0.617 +socket: 0.599 +assembly: 0.583 +instruction: 0.515 +other: 0.405 +KVM: 0.213 +mistranslation: 0.200 + +NVMe FS operations hang after suspending and resuming both guest and host +Description of problem: +Hello and thank you for your work on QEMU! + +Using the NVMe driver with my Seagate FireCuda 530 2TB M.2 works fine until I encounter this problem, which is reliably reproducible for me. + +When I suspend the guest and then suspend (s2idle) my host all is well until I resume the guest (manually with `virsh dompmwakeup $VMNAME`, after the host has resumed). Although the guest resumes and is interactive, it seems that anything involving filesystem operations hang forever and do not return. + +Suspending and resuming the Linux guest seems to work perfectly if I don't suspend/resume the host. + +Ultimately what I'm wanting to do is share the drive between VMs with qemu-storage-daemon. I can reproduce the problem in that scenario in much the same way. Using PCI passthrough with the same VM and device works fine and doesn't exhibit this problem. + +Hopefully that's clear enough - let me know if there's anything else I can provide. +Steps to reproduce: +1. Create a VM with a dedicated NVMe disk. +2. Boot an ISO and install to the disk. +3. Verify that suspend and resume works when not suspending the host. +4. Suspend the guest. +5. Suspend the host. +6. Wake the host. +7. Wake the guest. +8. Try just about anything that isn't likely already cached somewhere: `du -s /etc`. +Additional information: +I've attached the libvirt domain XML[1] and libvirtd debug logs for QEMU[2] ("1:qemu") that covers suspending the guest & host, resuming host & guest and doing something to cause a hang. I tried to leave enough time afterwards for any timeout to occur. + +1. [nvme-voidlinux.xml](/uploads/1dea47af096ce58175f7aa526eca455e/nvme-voidlinux.xml) +2. [nvme-qemu-debug.log](/uploads/42d3bed456a795069023a61d38fa5ccd/nvme-qemu-debug.log) |