[Qemu-devel] [Bug 1580459] Re: Windows (10?) guest freezes entire host on shutdown if using PCI passthrough

[Chris McCarron]

Well for now my issue is resolved.  This morning when I was shutting
down my unRaid server to blacklist the intel sound module, snd-hda-
intel, I first stopped my ubuntu vm and my two dockers then logged out
of unraid.  I then proceeded to shutdown my Windows 10 VM and like magic
it shutdown nicely without locking up the entire system.  Also, I found
out from unRaid tech support that the unRaid kernel does not include any
sound modules and it was not necessary to blacklist them.

So this is what I have changed since the last lockup last Thursday
night.

1.  Removed the NVIDIA Audio hardware from the VM Setup.  I did this because 
the sound was lagging horribly and I could not figure out how to fix it.  So I 
removed the sound hardware and I am now using a USB sound card that is plugged 
into the USB3 PCI-Express card that is being passed to the VM.
2.  I enabled MSI Interrupts on the GPU using this URL as my reference.
    
http://lime-technology.com/wiki/index.php/UnRAID_6/VM_Guest_Support#Enable_MSI_for_Interrupts_to_Fix_HDMI_Audio_Support

I should also mention that while I have the system NIC, USB1, and USB2
virtual modules mapped, they are disabled in the VM.  I did this to
improve latency issues inside the VM.  I am using a wireless NIC plugged
into the USB3 PCI-Express card and I do not require USB1 or USB2.  These
changes where made on Thursday prior to the last lockup, so while I do
believe they have helped overall latency they had no effect on the
system locking up.

USB3 card is handling Logitech G910 keyboard, WOW MMO Legendary Gaming
Mouse, ASUS XONARU3 Sound Card, ASUS USB-AC56 Wireless NIC, and a USB
Mouse.

I still would like to add the NVIDIA Sound card back into the VM and
when I do I will enable MSI Interrupts.  My goal is not not have to use
the USB Sound card.

See next post for current VM setup.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1580459

Title:
  Windows (10?) guest freezes entire host on shutdown if using PCI
  passthrough

Status in libvirt:
  New
Status in QEMU:
  New
Status in Arch Linux:
  New
Status in Debian:
  New
Status in Fedora:
  New

Bug description:
  Problem: after leaving a Windows VM that uses PCI passthrough (as we
  do for gaming graphics cards, sound cards, and in my case, a USB card)
  running for some amount of time between 1 and 2 hours (it's not
  consistent with exactly how long), and for any amount of time longer
  than that, shutting down that guest will, right as it finishes
  shutting down, freeze the host computer, making it require a hard
  reboot. Unbinding (or in the other user's case, unbinding and THEN
  binding) any PCI device in sysfs, even one that has nothing to do with
  the VM, also has the same effect as shutting down the VM (if the VM
  has been running long enough). So, it's probably an issue related to
  unbinding and binding PCI devices.

  There's a lot of info on this problem over at 
https://bbs.archlinux.org/viewtopic.php?id=206050
  Here's a better-organized list of main details:
  -at least 2 confirmed victims of this bug; 2 (including me) have provided 
lots of info in the link
  -I'm on Arch Linux and the other one is on Gentoo (distro-nonspecific)
  -issue affects my Windows 10 guest and others' Windows guests, but not my 
Arch Linux guest (the others don't have non-Windows guests to test)
  -I'm using libvirt but the other user is not, so it's not an issue with 
libvirt
  -It seems to be version non-specific, too. I first noticed it at, or when 
testing versions still had the issue at (whichever version is lower), Linux 4.1 
and qemu 2.4.0. It still persists in all releases of both since, including the 
newest ones.
  -I can't track down exactly what package downgrade can fix it, as downgrading 
further than Linux 4.1 and qemu 2.4.0 requires Herculean and system-destroying 
changes such as downgrading ncurses, meaning I don't know whether it's a bug in 
QEMU, the Linux kernel, or some weird seemingly unrelated thing.
  -According to the other user, "graphics intensive gameplay (GTA V) can cause 
the crash to happen sooner," as soon as "15 minutes"
  -Also, "bringing up a second passthrough VM with separate hardware will cause 
the same crash," and "bringing up another VM before the two-hour mark will not 
result in a crash," further cementing that it's triggered by the un/binding of 
PCI devices.
  -This is NOT related to the very similar bug that can be worked around by not 
passing through the HDMI device or sound card. Even when we removed all traces 
of any sort of sound card from the VM, it still had the same behavior.

To manage notifications about this bug go to:
https://bugs.launchpad.net/libvirt/+bug/1580459/+subscriptions