2 files changed, 99 insertions, 0 deletions
diff --git a/results/classifier/118/performance/1569 b/results/classifier/118/performance/1569
new file mode 100644
index 000000000..5b0a472cb
--- /dev/null
+++ b/results/classifier/118/performance/1569
@@ -0,0 +1,57 @@
+performance: 0.883
+debug: 0.873
+semantic: 0.856
+vnc: 0.850
+boot: 0.830
+graphic: 0.828
+virtual: 0.766
+device: 0.759
+architecture: 0.751
+PID: 0.740
+ppc: 0.704
+VMM: 0.695
+permissions: 0.679
+peripherals: 0.661
+kernel: 0.660
+register: 0.660
+hypervisor: 0.650
+files: 0.646
+network: 0.617
+socket: 0.599
+assembly: 0.583
+user-level: 0.548
+risc-v: 0.512
+x86: 0.472
+arm: 0.408
+i386: 0.405
+TCG: 0.392
+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)
diff --git a/results/classifier/118/performance/1569491 b/results/classifier/118/performance/1569491
new file mode 100644
index 000000000..96d86128b
--- /dev/null
+++ b/results/classifier/118/performance/1569491
@@ -0,0 +1,42 @@
+i386: 0.985
+performance: 0.975
+architecture: 0.896
+graphic: 0.872
+device: 0.793
+mistranslation: 0.694
+ppc: 0.667
+network: 0.626
+semantic: 0.565
+register: 0.447
+vnc: 0.415
+socket: 0.409
+boot: 0.409
+permissions: 0.408
+user-level: 0.389
+risc-v: 0.320
+files: 0.288
+arm: 0.284
+PID: 0.272
+debug: 0.225
+x86: 0.220
+TCG: 0.210
+peripherals: 0.210
+virtual: 0.202
+VMM: 0.179
+assembly: 0.134
+hypervisor: 0.132
+kernel: 0.052
+KVM: 0.029
+
+qemu system i386 poor performance on e5500 core
+
+I had been tested with generic core net building or with mtune e5500 but i have the same result: performances 
+are extremly low compared with other classes of powerpc cpu.
+The strange is the 5020 2ghz in all emulators been tested by me is comparable with a 970MP 2.7 ghz in speed and benchmarks but im facing the half of performance in i386-soft-mmu compared with a 2.5 ghz 970MP.
+
+I'm triaging old bugs: Can you provide command lines, versions, and steps to test and measure the relative performance?
+
+At the very least, please try to confirm on the latest version of QEMU (5.2.0-rc0, if possible) to update this report.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+