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

* [Qemu-devel] [Bug 1580459] [NEW] Windows (10?) guest freezes entire host on shutdown if using PCI passthrough
@ 2016-05-11  6:19 Jimi
  2016-05-19 18:07 ` [Qemu-devel] [Bug 1580459] " kachaffeous
                   ` (59 more replies)
  0 siblings, 60 replies; 62+ messages in thread
From: Jimi @ 2016-05-11  6:19 UTC (permalink / raw)
  To: qemu-devel

Public bug reported:

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.

** Affects: qemu
     Importance: Undecided
         Status: New

-- 
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 QEMU:
  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/qemu/+bug/1580459/+subscriptions

^ permalink raw reply	[flat|nested] 62+ messages in thread