diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/108/other/1042 | 35 | ||||
| -rw-r--r-- | results/classifier/108/other/1042561 | 52 |
2 files changed, 87 insertions, 0 deletions
diff --git a/results/classifier/108/other/1042 b/results/classifier/108/other/1042 new file mode 100644 index 00000000..03f47958 --- /dev/null +++ b/results/classifier/108/other/1042 @@ -0,0 +1,35 @@ +device: 0.796 +performance: 0.759 +PID: 0.722 +semantic: 0.712 +graphic: 0.709 +vnc: 0.643 +socket: 0.612 +other: 0.592 +boot: 0.591 +permissions: 0.569 +network: 0.449 +files: 0.435 +debug: 0.432 +KVM: 0.217 + +windows 10 guest freezes the host on shutdown +Description of problem: +Windows 10 guest sometimes freezes the QEMU host when shutting down. + +There has been a bug reported about this in the past here: +https://bugs.launchpad.net/qemu/+bug/1580459 + +I am also using PCI Passthrough with an NVIDIA GPU. +Some users have claimed to have fixed this issue by enabling Message Signaled-based Interrupts-mode on the PCI Devices the (GPU/HDMI-AUDIO). I have have these enabled and confirmed they are enabled, but the issue still persists. + +This bug has been effecting me for over a year, I just never bothered to look deeper into it after I seen the issue still persists after enabling the MSI stuff. + +There is something I noticed about this issue. Basically, it appears that I can mostly avoid the issue entirely, by making sure that as the guest is shutting down, that I move the mouse a bit. +The host almost never freezes if I do this, and only happens very rarely. +But if I start a shutdown, and just don't move the mouse at all, it is very likely the host will lock up, requiring a complete reboot. I am pretty sure the mouse movement, should be a big clue, because I can consistently reproduce the issue. The issue itself does not (atleast) for me appear to be tied to how long the VM is running or if gaming on it or not, though I have not thoroughly tested this. + +I have gone through various kernel/qemu/libvirt updates, the issue occurs in all of them, and has been an issue from the very beginning of my setup. +Steps to reproduce: +1. Start Windows 10 guest. +2. Shutdown Windows 10 guest diff --git a/results/classifier/108/other/1042561 b/results/classifier/108/other/1042561 new file mode 100644 index 00000000..fd0ddf40 --- /dev/null +++ b/results/classifier/108/other/1042561 @@ -0,0 +1,52 @@ +KVM: 0.794 +device: 0.721 +performance: 0.621 +PID: 0.595 +network: 0.531 +graphic: 0.525 +semantic: 0.460 +other: 0.455 +socket: 0.448 +boot: 0.388 +vnc: 0.373 +permissions: 0.336 +files: 0.298 +debug: 0.232 + +Guest has no "xsave" feature with parameter "-cpu qemu64,+xsave" in qemu command line. + +Environment: +------------ +Host OS (ia32/ia32e/IA64):ia32e +Guest OS (ia32/ia32e/IA64):ia32e +Guest OS Type (Linux/Windows):Linux +kvm.git Commit:1a577b72475d161b6677c05abe57301362023bb2 +qemu-kvm Commit:98f1f30a89901c416e51cc70c1a08d9dc15a2ad4 +Host Kernel Version:3.5.0-rc1 +Hardware:Romley-EP, Ivy-bridge + + +Bug detailed description: +-------------------------- +Guest has no "xsave" feature when create guest with parameter "-cpu qemu64,+xsave,+avx" in qemu command line, but the guest has avx feature. +When starting a guest with parameter "-cpu host" in qemu command line, the guest has 'avx' and 'xsave' features (as /proc/cpuinfo shows). + +This is not a recent regression; it exists for a long time. + +Reproduce steps: +---------------- +1. qemu-system-x86_64 -m 1024 -smp 2 -hda rhel6u3.img -cpu qemu64,+xsave +2. cat /proc/cpuinfo | grep xsave ( check guest's xsave feature) + +Current result: +---------------- +The guest has no xsave feature + +Expected result: +---------------- +The guest has xsave feature + +Basic root-causing log: + +xsave needs level >= 13, and qemu64 has level=4. Try "-cpu qemu64,+xsave,+avx,level=13". + |