[Bug 1884684] Re: QEMU 5.0: Guest VM hangs/freeze when unplugging USB device

2021-05-07 Thread TheCatFelix
Issue does not occur in latest version of QEMU anymore.

** Changed in: qemu
   Status: Incomplete => Fix Released

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

Title:
  QEMU 5.0: Guest VM hangs/freeze when unplugging USB device

Status in QEMU:
  Fix Released

Bug description:
  Setup:

  Host: Debian/SID, Kernel 5.6, QEMU 5.0
  Guest: Windows 10 VM with PCI and USB device passthrough.

  Problem: Guest VM suddenly hangs when pulling USB device out from the
  Host.

  Observations:
   - Issue appears to be related to QEMU 5.0
 - It started after an upgrade to QEMU 5.0.
 - Downgrading only QEMU on multiple systems fixes the issue.

   - Issue is very reproducible.
 - Most of the time within a few attempts of pulling/reconnecting the 
device.
 - Issue happens with multiple devices (I did try standard HID devices, a 
webcam and an x-ray sensor).

   - Guest just hangs.
 - Display output remains on last frame shown.
 - Ping to Guest immediately stops working.
 - Logs in the Guest stop logging immediately.

   - Host is fine and thinks the Guest is fine. 
 - Guest continues to show as running in "virsh list".
 - No suspicious entries in the QEMU logs.
 - No suspicious entries in Host syslogs/messages.
 - Host can can kill guest "virsh destroy" and respawn fine.

   - Issue seems widespread.
 - Multiple similar reports from ProxMox users after upgrade to ProxMox 6.2 
for both Windows and Linux guests (First version that uses QEMU 5.0)

  
https://forum.proxmox.com/threads/vm-freezes-when-disconnecting-usb-keyboard-and-mouse.70287/
  https://forum.proxmox.com/threads/usb-drive-crashes-vm.70214/
  
https://forum.proxmox.com/threads/latest-proxmox-usb-disconnects-freeze-kvm.70398/
  
https://forum.proxmox.com/threads/vm-with-gpu-passthrough-freezes-when-turning-off-monitor-after-proxmox-6-2-upgrade.69821/
  
https://forum.proxmox.com/threads/vm-with-gpu-passthrough-freezes-when-turning-off-monitor-after-proxmox-6-2-upgrade.69824/

  I'd be more than happy any debugs that might be helpful.

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



[Bug 1884684] Re: QEMU 5.0: Guest VM hangs/freeze when unplugging USB device

2020-08-11 Thread TheCatFelix
I do get get the same backtrace in gdb every time every time when we
reproduce the hang:

(gdb) thread apply all bt

Thread 9 (Thread 0x7fd1415ff700 (LWP 3202)):
#0  0x7fd323d154bf in __GI___poll (fds=0x7fd1415fe6c0, nfds=2, timeout=-1) 
at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x7fd324978bb2 in ?? () from 
target:/lib/x86_64-linux-gnu/libusb-1.0.so.0
#2  0x7fd323defea7 in start_thread (arg=) at 
pthread_create.c:477
#3  0x7fd323d1feaf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 8 (Thread 0x7fd1437fe700 (LWP 3171)):
#0  0x7fd323d16d87 in ioctl () at ../sysdeps/unix/syscall-template.S:120
#1  0x55a5daef74f7 in kvm_vcpu_ioctl ()
#2  0x55a5daef7631 in kvm_cpu_exec ()
#3  0x55a5daedaede in ?? ()
#4  0x55a5db32194b in ?? ()
#5  0x7fd323defea7 in start_thread (arg=) at 
pthread_create.c:477
#6  0x7fd323d1feaf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 7 (Thread 0x7fd143fff700 (LWP 3170)):
#0  0x7fd323d16d87 in ioctl () at ../sysdeps/unix/syscall-template.S:120
#1  0x55a5daef74f7 in kvm_vcpu_ioctl ()
#2  0x55a5daef7631 in kvm_cpu_exec ()
#3  0x55a5daedaede in ?? ()
#4  0x55a5db32194b in ?? ()
#5  0x7fd323defea7 in start_thread (arg=) at 
pthread_create.c:477
#6  0x7fd323d1feaf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 6 (Thread 0x7fd150dfd700 (LWP 3169)):
#0  __lll_lock_wait (futex=futex@entry=0x55a5db80a540, private=0) at 
lowlevellock.c:52
#1  0x7fd323df2843 in __GI___pthread_mutex_lock (mutex=0x55a5db80a540) at 
../nptl/pthread_mutex_lock.c:80
#2  0x55a5db321b43 in qemu_mutex_lock_impl ()
#3  0x55a5daedac8e in qemu_mutex_lock_iothread_impl ()
#4  0x55a5dae92ac9 in ?? ()
#5  0x55a5dae97de7 in flatview_read_continue ()
#6  0x55a5dae98023 in ?? ()
#7  0x55a5dae9813b in address_space_read_full ()
#8  0x55a5daef78cf in kvm_cpu_exec ()
#9  0x55a5daedaede in ?? ()
#10 0x55a5db32194b in ?? ()
#11 0x7fd323defea7 in start_thread (arg=) at 
pthread_create.c:477
#12 0x7fd323d1feaf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 5 (Thread 0x7fd1515fe700 (LWP 3168)):
#0  __lll_lock_wait (futex=futex@entry=0x55a5db80a540, private=0) at 
lowlevellock.c:52
#1  0x7fd323df2843 in __GI___pthread_mutex_lock (mutex=0x55a5db80a540) at 
../nptl/pthread_mutex_lock.c:80
#2  0x55a5db321b43 in qemu_mutex_lock_impl ()
#3  0x55a5daedac8e in qemu_mutex_lock_iothread_impl ()
#4  0x55a5dae92ac9 in ?? ()
#5  0x55a5dae97de7 in flatview_read_continue ()
#6  0x55a5dae98023 in ?? ()
#7  0x55a5dae9813b in address_space_read_full ()
#8  0x55a5daef78cf in kvm_cpu_exec ()
#9  0x55a5daedaede in ?? ()
#10 0x55a5db32194b in ?? ()
#11 0x7fd323defea7 in start_thread (arg=) at 
pthread_create.c:477
#12 0x7fd323d1feaf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 4 (Thread 0x7fd151dff700 (LWP 3167)):
#0  __lll_lock_wait (futex=futex@entry=0x55a5db80a540, private=0) at 
lowlevellock.c:52
#1  0x7fd323df2843 in __GI___pthread_mutex_lock (mutex=0x55a5db80a540) at 
../nptl/pthread_mutex_lock.c:80
--Type  for more, q to quit, c to continue without paging--
#2  0x55a5db321b43 in qemu_mutex_lock_impl ()
#3  0x55a5daedac8e in qemu_mutex_lock_iothread_impl ()
#4  0x55a5dae92ac9 in ?? ()
#5  0x55a5dae97de7 in flatview_read_continue ()
#6  0x55a5dae98023 in ?? ()
#7  0x55a5dae9813b in address_space_read_full ()
#8  0x55a5daef78cf in kvm_cpu_exec ()
#9  0x55a5daedaede in ?? ()
#10 0x55a5db32194b in ?? ()
#11 0x7fd323defea7 in start_thread (arg=) at 
pthread_create.c:477
#12 0x7fd323d1feaf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 3 (Thread 0x7fd320d97700 (LWP 3166)):
#0  0x7fd323d154bf in __GI___poll (fds=0x7fd318003180, nfds=3, timeout=-1) 
at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x7fd324a097ee in ?? () from 
target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7fd324a09b53 in g_main_loop_run () from 
target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x55a5db016c71 in ?? ()
#4  0x55a5db32194b in ?? ()
#5  0x7fd323defea7 in start_thread (arg=) at 
pthread_create.c:477
#6  0x7fd323d1feaf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 2 (Thread 0x7fd3224de700 (LWP 3156)):
#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1  0x55a5db3226fa in qemu_event_wait ()
#2  0x55a5db33466a in ?? ()
#3  0x55a5db32194b in ?? ()
#4  0x7fd323defea7 in start_thread (arg=) at 
pthread_create.c:477
#5  0x7fd323d1feaf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 1 (Thread 0x7fd3224dff40 (LWP 3148)):
#0  0x7fd323d154bf in __GI___poll (fds=0x55a5dca30150, nfds=3, timeout=3) 
at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x7fd324971f4d in ?? () from 
target:/lib/x86_64-linux-gnu/libusb-1.0.so.0
#2  0x7fd32497316c

[Bug 1884684] Re: QEMU 5.0: Guest VM hangs/freeze when unplugging USB device

2020-08-11 Thread TheCatFelix
Link to bug on the proxmox side:

https://bugzilla.proxmox.com/show_bug.cgi?id=2781

** Bug watch added: bugzilla.proxmox.com/ #2781
   https://bugzilla.proxmox.com/show_bug.cgi?id=2781

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

Title:
  QEMU 5.0: Guest VM hangs/freeze when unplugging USB device

Status in QEMU:
  New

Bug description:
  Setup:

  Host: Debian/SID, Kernel 5.6, QEMU 5.0
  Guest: Windows 10 VM with PCI and USB device passthrough.

  Problem: Guest VM suddenly hangs when pulling USB device out from the
  Host.

  Observations:
   - Issue appears to be related to QEMU 5.0
 - It started after an upgrade to QEMU 5.0.
 - Downgrading only QEMU on multiple systems fixes the issue.

   - Issue is very reproducible.
 - Most of the time within a few attempts of pulling/reconnecting the 
device.
 - Issue happens with multiple devices (I did try standard HID devices, a 
webcam and an x-ray sensor).

   - Guest just hangs.
 - Display output remains on last frame shown.
 - Ping to Guest immediately stops working.
 - Logs in the Guest stop logging immediately.

   - Host is fine and thinks the Guest is fine. 
 - Guest continues to show as running in "virsh list".
 - No suspicious entries in the QEMU logs.
 - No suspicious entries in Host syslogs/messages.
 - Host can can kill guest "virsh destroy" and respawn fine.

   - Issue seems widespread.
 - Multiple similar reports from ProxMox users after upgrade to ProxMox 6.2 
for both Windows and Linux guests (First version that uses QEMU 5.0)

  
https://forum.proxmox.com/threads/vm-freezes-when-disconnecting-usb-keyboard-and-mouse.70287/
  https://forum.proxmox.com/threads/usb-drive-crashes-vm.70214/
  
https://forum.proxmox.com/threads/latest-proxmox-usb-disconnects-freeze-kvm.70398/
  
https://forum.proxmox.com/threads/vm-with-gpu-passthrough-freezes-when-turning-off-monitor-after-proxmox-6-2-upgrade.69821/
  
https://forum.proxmox.com/threads/vm-with-gpu-passthrough-freezes-when-turning-off-monitor-after-proxmox-6-2-upgrade.69824/

  I'd be more than happy any debugs that might be helpful.

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



[Bug 1884684] Re: QEMU 5.0: Guest VM hangs/freeze when unplugging USB device

2020-07-30 Thread TheCatFelix
Following reports on Proxmox forums, this is still very much seen by
multiple users with no known workaround.

I was able to run QEMU 5.0.13 (Debian) with all traces turned on and
capture the following:

- Behavior is reproducible by unbinding usb device on the host (ex. "echo '1-8' 
> /sys/bus/usb/drivers/usb/unbind")
- qemu trace logs stops at exactly the same time when VM freezes
- Last few lines of the qemu trace:

1592303@1596123157.254134:virtio_notify vdev 0x56193d04d820 vq 0x7fcd5c48a010
1592320@1596123158.822309:usb_xhci_oper_read off 0x0004, ret 0x0008
1592320@1596123158.822397:usb_xhci_port_read port 1, off 0x, ret 0x0e0002a0
1592320@1596123158.822459:usb_xhci_port_read port 2, off 0x, ret 0x0e0002a0
1592320@1596123158.822513:usb_xhci_port_read port 3, off 0x, ret 0x0e0002a0
1592320@1596123158.822565:usb_xhci_port_read port 4, off 0x, ret 0x0e0002a0
1592303@1596123159.858372:virtqueue_alloc_element elem 0x56193c8c8990 size 56 
in_num 2 out_num 0
1592303@1596123159.858435:virtqueue_pop vq 0x7fcd5c48a010 elem 0x56193c8c8990 
in_num 2 out_num 0
1592303@1596123159.858482:virtqueue_fill vq 0x7fcd5c48a010 elem 0x56193c8c8990 
len 72 idx 0
1592303@1596123159.858533:virtqueue_flush vq 0x7fcd5c48a010 count 1
1592303@1596123159.858565:virtio_notify vdev 0x56193d04d820 vq 0x7fcd5c48a010
1592303@1596123160.272641:virtqueue_alloc_element elem 0x56193c8c8990 size 56 
in_num 2 out_num 0
1592303@1596123160.272702:virtqueue_pop vq 0x7fcd5c48a010 elem 0x56193c8c8990 
in_num 2 out_num 0
1592303@1596123160.272751:virtqueue_fill vq 0x7fcd5c48a010 elem 0x56193c8c8990 
len 104 idx 0
1592303@1596123160.272802:virtqueue_flush vq 0x7fcd5c48a010 count 1
1592303@1596123160.272833:virtio_notify vdev 0x56193d04d820 vq 0x7fcd5c48a010
1592303@1596123160.845694:lockcnt_unlock_attempt lockcnt 0x56193bea6514 unlock 
5->4
1592303@1596123160.846821:lockcnt_unlock_success lockcnt 0x56193bea6514 unlock 
5->4 succeeded
1592303@1596123160.847923:usb_host_req_complete dev 1:4, packet 0x7fcb84000ea8, 
status 0, length 0
1592303@1596123160.849369:usb_packet_state_change bus 0, port 1, ep 2, packet 
0x7fcb84000ea8, state async -> complete
1592303@1596123160.851157:usb_xhci_xfer_success 0x7fcb84000ea0: len 0
1592303@1596123160.851214:usb_xhci_queue_event v 3, idx 5, ER_TRANSFER, 
CC_SHORT_PACKET, p 0xac0c62444ae3, s 0x0d00, c 0x02058005
1592303@1596123160.851285:usb_xhci_irq_msix nr 3
1592303@1596123160.851331:usb_xhci_ep_kick slotid 2, epid 5, streamid 0
1592303@1596123160.851374:usb_host_req_data dev 1:4, packet 0x56193cce8da8, in 
1, ep 2, size 4
1592303@1596123160.851434:usb_host_req_complete dev 1:4, packet 0x56193cce8da8, 
status -1, length 0
1592303@1596123160.851485:usb_packet_state_change bus 0, port 1, ep 2, packet 
0x56193cce8da8, state queued -> complete
1592303@1596123160.851541:usb_xhci_xfer_error 0x56193cce8da0: ret -1
1592303@1596123160.851577:usb_xhci_queue_event v 3, idx 6, ER_TRANSFER, 
CC_USB_TRANSACTION_ERROR, p 0x0001c18a4e20, s 0x0404, c 0x02058001
1592303@1596123160.851647:usb_xhci_ep_state slotid 2, epid 5, running -> halted
1592303@1596123160.852700:usb_xhci_ep_kick slotid 2, epid 5, streamid 0
1592303@1596123160.852744:usb_host_req_complete dev 1:4, packet 0x7fcb84000b98, 
status 0, length 0
1592303@1596123160.852788:usb_packet_state_change bus 0, port 1, ep 1, packet 
0x7fcb84000b98, state async -> complete
1592303@1596123160.852845:usb_xhci_xfer_success 0x7fcb84000b90: len 0
1592303@1596123160.852879:usb_xhci_queue_event v 3, idx 7, ER_TRANSFER, 
CC_SHORT_PACKET, p 0xac0c6229aae3, s 0x0d00, c 0x02038005
1592303@1596123160.852945:usb_xhci_ep_kick slotid 2, epid 3, streamid 0
1592303@1596123160.852977:usb_host_req_data dev 1:4, packet 0x56193c9da348, in 
1, ep 1, size 8
1592303@1596123160.853031:usb_host_req_complete dev 1:4, packet 0x56193c9da348, 
status -1, length 0
1592303@1596123160.853080:usb_packet_state_change bus 0, port 1, ep 1, packet 
0x56193c9da348, state queued -> complete
1592303@1596123160.853136:usb_xhci_xfer_error 0x56193c9da340: ret -1
1592303@1596123160.853170:usb_xhci_queue_event v 3, idx 8, ER_TRANSFER, 
CC_USB_TRANSACTION_ERROR, p 0x0001c18a4c20, s 0x0408, c 0x02038001
1592303@1596123160.853240:usb_xhci_ep_state slotid 2, epid 3, running -> halted
1592303@1596123160.853280:usb_xhci_ep_kick slotid 2, epid 3, streamid 0
1592303@1596123160.853316:lockcnt_unlock_attempt lockcnt 0x56193bea6514 unlock 
1->4
1592303@1596123160.853352:lockcnt_unlock_success lockcnt 0x56193bea6514 unlock 
1->4 succeeded
1592303@1596123160.853564:usb_host_close dev 1:4
libusb: error [udev_hotplug_event] ignoring udev action unbind

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

Title:
  QEMU 5.0: Guest VM hangs/freeze when unplugging USB device

Status in QEMU:
  New

Bug description:
  Setup:

  Host: Debian/SID, Kernel 5.6, QEMU 5.0
  Guest: Windows 10 VM with 

[Bug 1884684] [NEW] QEMU 5.0: Guest VM hangs/freeze when unplugging USB device

2020-06-22 Thread TheCatFelix
Public bug reported:

Setup:

Host: Debian/SID, Kernel 5.6, QEMU 5.0
Guest: Windows 10 VM with PCI and USB device passthrough.

Problem: Guest VM suddenly hangs when pulling USB device out from the
Host.

Observations:
 - Issue appears to be related to QEMU 5.0
   - It started after an upgrade to QEMU 5.0.
   - Downgrading only QEMU on multiple systems fixes the issue.

 - Issue is very reproducible.
   - Most of the time within a few attempts of pulling/reconnecting the device.
   - Issue happens with multiple devices (I did try standard HID devices, a 
webcam and an x-ray sensor).

 - Guest just hangs.
   - Display output remains on last frame shown.
   - Ping to Guest immediately stops working.
   - Logs in the Guest stop logging immediately.

 - Host is fine and thinks the Guest is fine. 
   - Guest continues to show as running in "virsh list".
   - No suspicious entries in the QEMU logs.
   - No suspicious entries in Host syslogs/messages.
   - Host can can kill guest "virsh destroy" and respawn fine.

 - Issue seems widespread.
   - Multiple similar reports from ProxMox users after upgrade to ProxMox 6.2 
for both Windows and Linux guests (First version that uses QEMU 5.0)

https://forum.proxmox.com/threads/vm-freezes-when-disconnecting-usb-keyboard-and-mouse.70287/
https://forum.proxmox.com/threads/usb-drive-crashes-vm.70214/
https://forum.proxmox.com/threads/latest-proxmox-usb-disconnects-freeze-kvm.70398/
https://forum.proxmox.com/threads/vm-with-gpu-passthrough-freezes-when-turning-off-monitor-after-proxmox-6-2-upgrade.69821/
https://forum.proxmox.com/threads/vm-with-gpu-passthrough-freezes-when-turning-off-monitor-after-proxmox-6-2-upgrade.69824/

I'd be more than happy any debugs that might be helpful.

** 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/1884684

Title:
  QEMU 5.0: Guest VM hangs/freeze when unplugging USB device

Status in QEMU:
  New

Bug description:
  Setup:

  Host: Debian/SID, Kernel 5.6, QEMU 5.0
  Guest: Windows 10 VM with PCI and USB device passthrough.

  Problem: Guest VM suddenly hangs when pulling USB device out from the
  Host.

  Observations:
   - Issue appears to be related to QEMU 5.0
 - It started after an upgrade to QEMU 5.0.
 - Downgrading only QEMU on multiple systems fixes the issue.

   - Issue is very reproducible.
 - Most of the time within a few attempts of pulling/reconnecting the 
device.
 - Issue happens with multiple devices (I did try standard HID devices, a 
webcam and an x-ray sensor).

   - Guest just hangs.
 - Display output remains on last frame shown.
 - Ping to Guest immediately stops working.
 - Logs in the Guest stop logging immediately.

   - Host is fine and thinks the Guest is fine. 
 - Guest continues to show as running in "virsh list".
 - No suspicious entries in the QEMU logs.
 - No suspicious entries in Host syslogs/messages.
 - Host can can kill guest "virsh destroy" and respawn fine.

   - Issue seems widespread.
 - Multiple similar reports from ProxMox users after upgrade to ProxMox 6.2 
for both Windows and Linux guests (First version that uses QEMU 5.0)

  
https://forum.proxmox.com/threads/vm-freezes-when-disconnecting-usb-keyboard-and-mouse.70287/
  https://forum.proxmox.com/threads/usb-drive-crashes-vm.70214/
  
https://forum.proxmox.com/threads/latest-proxmox-usb-disconnects-freeze-kvm.70398/
  
https://forum.proxmox.com/threads/vm-with-gpu-passthrough-freezes-when-turning-off-monitor-after-proxmox-6-2-upgrade.69821/
  
https://forum.proxmox.com/threads/vm-with-gpu-passthrough-freezes-when-turning-off-monitor-after-proxmox-6-2-upgrade.69824/

  I'd be more than happy any debugs that might be helpful.

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



[Bug 1879175] Re: GVTd not working (black screen) after upgrade to qemu-5.0.0

2020-06-09 Thread TheCatFelix
egion_del region_del 0xe - 0xf 
  vfio_listener_region_del region_del 0xe - 0xf
  vfio_listener_region_del region_del 0x10 - 0xbfff 
  vfio_listener_region_del region_del 0x10 - 
0xbfff
  vfio_listener_region_add_ram region_add [ram] 0x0 - 0xc [0x7f5b41e0]  
 |vfio_listener_region_add_ram region_add [ram] 0x0 - 
0xc [0x7f2bb1e0]

  We can see here, the following key lines are not printed in 5.0.0:

  vfio_pci_igd_lpc_bridge_enabled :00:02.0  
 <
  vfio_pci_igd_host_bridge_enabled :00:02.0 
 <
  vfio_pci_igd_opregion_enabled :00:02.0
 <
  vfio_pci_igd_bdsm_enabled :00:02.0 40MB   
 <

  Looking through the code and bisecting the problem (I can provide more
  detail if helpful), shows the following ifdef statement lines
  introduce the problem:

  https://github.com/qemu/qemu/blob/master/hw/vfio/pci-quirks.c#L1253

1246  void vfio_bar_quirk_setup(VFIOPCIDevice *vdev, int nr)
1247  {
1248  vfio_probe_ati_bar4_quirk(vdev, nr);
1249  vfio_probe_ati_bar2_quirk(vdev, nr);
1250  vfio_probe_nvidia_bar5_quirk(vdev, nr);
1251  vfio_probe_nvidia_bar0_quirk(vdev, nr);
1252  vfio_probe_rtl8168_bar2_quirk(vdev, nr);
1253  #ifdef CONFIG_VFIO_IGD
1254  vfio_probe_igd_bar4_quirk(vdev, nr);
1255  #endif
1256  }

  This was added by the following commits:

  https://github.com/qemu/qemu/commit/29d62771c81d8fd244a67c14a1d968c268d3fb19
  #diff-38093e21794c7a4987feb71e498dbdc6

  Reading through the commit message, I suspect the something may be
  happening with the Kconfig switches mentioned there.


  === Validation/Workaround ===

  I have rebuilt the package with the following two changes:

  root@debian:/home/test/src# diff debian_*/qemu-5.0/hw/vfio/pci-quirks.c
  0a1
  > #define CONFIG_VFIO_IGD y
  root@debian:/home/test/src# diff debian_*/qemu-5.0/hw/vfio/Kconfig
  42c42
  < default y if PC_PCI
  ---
  > default y
  root@debian:/home/test/src#

  GVTd started working fine again (Screen shows output again).

  I have tried with either change alone:

  - with only the ifdef in pci-quirks.c compilation fails with linker errors
  - with only the Kconfig it compiles, but GVTd still does not work (black 
screen)


  Please take a look and thank you very much for a fantastic product!

  TheCatFelix

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



[Bug 1882784] Re: Legacy IGD passthrough in QEMU 5 disabled

2020-06-09 Thread TheCatFelix
Looks similar to https://bugs.launchpad.net/qemu/+bug/1879175

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

Title:
  Legacy IGD passthrough in QEMU 5 disabled

Status in QEMU:
  New

Bug description:
  Bug with tag v5.0.0, or commit
  fdd76fecdde1ad444ff4deb7f1c4f7e4a1ef97d6

  As of QEMU 5 Legacy IGD PT is no longer working.

  Host is a Xeon E3-1226 v3 and my method to test is to run the
  following:

  ./qemu-system-x86_64 \
-device 'pci-bridge,id=pci.1,chassis_nr=1,bus=pci.0,addr=0x1f' \
-device 'vfio-pci,host=00:02.0,addr=02.0' \
-L '/usr/share/kvm' \
-nographic \
-vga none \
-nodefaults

  in the hope of seeing a "IGD device :00:02.0 cannot support legacy
  mode due to existing devices at address 1f.0" error.

  The culprit appears to be this commit:

  https://github.com/qemu/qemu/commit/29d62771c81d8fd244a67c14a1d968c268d3fb19

  Specifically the following block in pci-quirks.c:

  #ifdef CONFIG_VFIO_IGD
  vfio_probe_igd_bar4_quirk(vdev, nr);
  #endif

  as the kconfig variable CONFIG_VFIO_IGD doesn't appear to be available
  outside of makefiles as described here:
  https://qemu.weilnetz.de/doc/devel/kconfig.html. I can confirm that
  the igd code is being pulled in as removing this check, as would
  defining the variable I presume, makes Legacy IGD PT work again (ie I
  see the expected "existing devices" error).

  I first spotted this in Proxmox, but have confirmed the bug by
  building QEMU sources.

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



[Bug 1879175] Re: GVTd not working (black screen) after upgrade to qemu-5.0.0

2020-05-17 Thread TheCatFelix
egion_del 0x10 - 
0xbfff
  vfio_listener_region_add_ram region_add [ram] 0x0 - 0xc [0x7f5b41e0]  
 |vfio_listener_region_add_ram region_add [ram] 0x0 - 
0xc [0x7f2bb1e0]

  We can see here, the following key lines are not printed in 5.0.0:

  vfio_pci_igd_lpc_bridge_enabled :00:02.0  
 <
  vfio_pci_igd_host_bridge_enabled :00:02.0 
 <
  vfio_pci_igd_opregion_enabled :00:02.0
 <
  vfio_pci_igd_bdsm_enabled :00:02.0 40MB   
 <

  Looking through the code and bisecting the problem (I can provide more
  detail if helpful), shows the following ifdef statement lines
  introduce the problem:

  https://github.com/qemu/qemu/blob/master/hw/vfio/pci-quirks.c#L1253

1246  void vfio_bar_quirk_setup(VFIOPCIDevice *vdev, int nr)
1247  {
1248  vfio_probe_ati_bar4_quirk(vdev, nr);
1249  vfio_probe_ati_bar2_quirk(vdev, nr);
1250  vfio_probe_nvidia_bar5_quirk(vdev, nr);
1251  vfio_probe_nvidia_bar0_quirk(vdev, nr);
1252  vfio_probe_rtl8168_bar2_quirk(vdev, nr);
1253  #ifdef CONFIG_VFIO_IGD
1254  vfio_probe_igd_bar4_quirk(vdev, nr);
1255  #endif
1256  }

  This was added by the following commits:

  https://github.com/qemu/qemu/commit/29d62771c81d8fd244a67c14a1d968c268d3fb19
  #diff-38093e21794c7a4987feb71e498dbdc6

  Reading through the commit message, I suspect the something may be
  happening with the Kconfig switches mentioned there.


  === Validation/Workaround ===

  I have rebuilt the package with the following two changes:

  root@debian:/home/test/src# diff debian_*/qemu-5.0/hw/vfio/pci-quirks.c
  0a1
  > #define CONFIG_VFIO_IGD y
  root@debian:/home/test/src# diff debian_*/qemu-5.0/hw/vfio/Kconfig
  42c42
  < default y if PC_PCI
  ---
  > default y
  root@debian:/home/test/src#

  GVTd started working fine again (Screen shows output again).

  I have tried with either change alone:

  - with only the ifdef in pci-quirks.c compilation fails with linker errors
  - with only the Kconfig it compiles, but GVTd still does not work (black 
screen)


  Please take a look and thank you very much for a fantastic product!

  TheCatFelix

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



[Bug 1879175] [NEW] GVTd not working after upgrade to qemu-5.0.0

2020-05-17 Thread TheCatFelix
   <
vfio_pci_igd_opregion_enabled :00:02.0  
   <
vfio_pci_igd_bdsm_enabled :00:02.0 40MB 
   <

Looking through the code and bisecting the problem (I can provide more
detail if helpful), shows the following ifdef statement lines introduce
the problem:

https://github.com/qemu/qemu/blob/master/hw/vfio/pci-quirks.c#L1253

  1246  void vfio_bar_quirk_setup(VFIOPCIDevice *vdev, int nr)
  1247  {
  1248  vfio_probe_ati_bar4_quirk(vdev, nr);
  1249  vfio_probe_ati_bar2_quirk(vdev, nr);
  1250  vfio_probe_nvidia_bar5_quirk(vdev, nr);
  1251  vfio_probe_nvidia_bar0_quirk(vdev, nr);
  1252  vfio_probe_rtl8168_bar2_quirk(vdev, nr);
  1253  #ifdef CONFIG_VFIO_IGD
  1254  vfio_probe_igd_bar4_quirk(vdev, nr);
  1255  #endif
  1256  }

This was added by the following commits:

https://github.com/qemu/qemu/commit/29d62771c81d8fd244a67c14a1d968c268d3fb19
#diff-38093e21794c7a4987feb71e498dbdc6

Reading through the commit message, I suspect the something may be
happening with the Kconfig switches mentioned there.


=== Validation/Workaround ===

I have rebuilt the package with the following two changes:

root@debian:/home/test/src# diff debian_*/qemu-5.0/hw/vfio/pci-quirks.c
0a1
> #define CONFIG_VFIO_IGD y
root@debian:/home/test/src# diff debian_*/qemu-5.0/hw/vfio/Kconfig
42c42
< default y if PC_PCI
---
> default y
root@debian:/home/test/src#

GVTd started working fine again (Screen shows output again).

I have tried with either change alone:

- with only the ifdef in pci-quirks.c compilation fails with linker errors
- with only the Kconfig it compiles, but GVTd still does not work (black screen)


Please take a look and thank you very much for a fantastic product!

TheCatFelix

** Affects: qemu
 Importance: Undecided
 Status: New


** Tags: gvt gvtd igd vfio

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

Title:
  GVTd not working after upgrade to qemu-5.0.0

Status in QEMU:
  New

Bug description:
  Hi QEMU team,

  
  === Problem Summary ===

  I have recently upgraded from QEMU-3.1.0 to to QEMU-5.0.0 on Debian
  Unstable. Unfortunately GVTd (legacy passthrough of the integrated
  intel gpu) stopped working correctly. The guest can still see and
  loads the driver for the GPU, but the screen stays black.

  The following is the version used:

  $ /usr/bin/qemu-system-x86_64 --version
  QEMU emulator version 5.0.0 (Debian 1:5.0-5)
  Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers


  === Investigation/Triage done so far ===

  Running QEMU with trace flags enabled shows the following behavior
  change for the same VM (left: 3.1.0, right: 5.0.0):

  vfio_realize  (:00:02.0) group 1  
  vfio_realize  (:00:02.0) group 1
  vfio_listener_region_add_ram region_add [ram] 0x0 - 0xb [0x7f5b41e0]  
 |vfio_listener_region_add_ram region_add [ram] 0x0 - 
0xb [0x7f2bb1e0]
  vfio_listener_region_add_ram region_add [ram] 0xc - 0xd 
[0x7f5d1d40]   |vfio_listener_region_add_ram region_add 
[ram] 0xc - 0xd [0x7f2d7c80]
  vfio_listener_region_add_ram region_add [ram] 0xe - 0xf 
[0x7f5d1d62]   |vfio_listener_region_add_ram region_add 
[ram] 0xe - 0xf [0x7f2d8422]
  vfio_listener_region_add_ram region_add [ram] 0x10 - 0xbfff 
[0x7f5b41f0]   |vfio_listener_region_add_ram region_add 
[ram] 0x10 - 0xbfff [0x7f2bb1f0]
  vfio_listener_region_add_skip SKIPPING region_add 0xfec0 - 0xfec00fff 
  vfio_listener_region_add_skip SKIPPING region_add 
0xfec0 - 0xfec00fff
  vfio_listener_region_add_skip SKIPPING region_add 0xfee0 - 0xfeef 
  vfio_listener_region_add_skip SKIPPING region_add 
0xfee0 - 0xfeef
  vfio_listener_region_add_ram region_add [ram] 0xfffc - 0x 
[0x7f5d1d60] |vfio_listener_region_add_ram region_add [ram] 
0xfffc - 0x [0x7f2d8420]
  vfio_listener_region_add_ram region_add [ram] 0x1 - 0x201ff 
[0x7f5c01e0]   |vfio_listener_region_add_ram region_add [ram] 
0x1 - 0x201ff [0x7f2c71e0]
  vfio_mdev  (:00:02.0) is_mdev 0   
  vfio_mdev  (:00:02.0) is_mdev 0
  vfio_get_device Device :00:02.0 flags: 3, regions: 12, irqs: 5
  vfio_get_device Device :00:02.0 flags: 3, 
regions: 12, irqs: 5
  vfio_region_setup Device :00:02.0, region 0 ":00:02.0 BAR 0", flags: 
0x7, offset: 0x0, svfio_region_setup Device :00:02.0, region 0 
":