Ryzen 7 2700 + Vega 56 single gpu passthrough - no more output when guest is shutdown

Hi all,

I never thought I’d actually ask for help for this but here I am. Here are my specs before I go and provide more details:

  • Distribution: Fedora 32
  • Kernel: 5.6.12-300.fc32.x86_64
  • Processor: Ryzen 7 2700 (no igpu)
  • GPU: Vega 56
  • Motherboard: MSI X470 GAMING PLUS
  • One monitor for everything

So, I managed yesterday to get a Windows 10 guest VM working with libvirtd in Fedora 32. What basically happens is that I start the Windows VM (the GPU is perfectly recognized and the driver installation went well) and that:

  • whenever I restart the VM from within, I can tell it does restart but I just don’t get anything at all displayed on the monitor anymore
  • whenever I shutdown the VM from within, it’s the same end result: I don’t get anything displayed on the monitor anymore

I’m aware of the “reset bug” that plagues those AMD gpus and have tried a couple of different things so far, including to specify the path of the gpu rom file in the xml of the VM; this didn’t change anything. I started looking into the logs and this is what I found when I shutdown the VM for the last time (sorry but as a new user I can’t yet upload files and I’m not sure that preformatted text would be the best option):

log
1. May 17 13:18:21 localhost kernel: virbr0: port 2(vnet0) entered disabled state

2. May 17 13:18:21 localhost kernel: device vnet0 left promiscuous mode

3. May 17 13:18:21 localhost kernel: virbr0: port 2(vnet0) entered disabled state

4. May 17 13:18:21 localhost audit: ANOM_PROMISCUOUS dev=vnet0 prom=0 old_prom=256 auid=4294967295 uid=107 gid=107 ses=4294967295

5. May 17 13:18:21 localhost journal[6540]: internal error: End of file from qemu monitor

6. May 17 13:18:21 localhost kernel: usb 1-4: reset full-speed USB device number 3 using xhci_hcd

7. May 17 13:18:22 localhost kernel: input: Compx 2.4G Wireless Receiver as /devices/pci0000:00/0000:00:01.3/0000:03:00.0/usb1/1-4/1-4:1.0/0003:25A7:FA70.0010/input/input77

8. May 17 13:18:22 localhost kernel: hid-generic 0003:25A7:FA70.0010: input,hidraw0: USB HID v1.10 Keyboard [Compx 2.4G Wireless Receiver] on usb-0000:03:00.0-4/input0

9. May 17 13:18:22 localhost kernel: input: Compx 2.4G Wireless Receiver Mouse as /devices/pci0000:00/0000:00:01.3/0000:03:00.0/usb1/1-4/1-4:1.1/0003:25A7:FA70.0011/input/input78

10. May 17 13:18:22 localhost kernel: input: Compx 2.4G Wireless Receiver as /devices/pci0000:00/0000:00:01.3/0000:03:00.0/usb1/1-4/1-4:1.1/0003:25A7:FA70.0011/input/input79

11. May 17 13:18:22 localhost kernel: input: Compx 2.4G Wireless Receiver Keyboard as /devices/pci0000:00/0000:00:01.3/0000:03:00.0/usb1/1-4/1-4:1.1/0003:25A7:FA70.0011/input/input80

12. May 17 13:18:22 localhost kernel: input: Compx 2.4G Wireless Receiver Consumer Control as /devices/pci0000:00/0000:00:01.3/0000:03:00.0/usb1/1-4/1-4:1.1/0003:25A7:FA70.0011/input/input81

13. May 17 13:18:22 localhost kernel: input: Compx 2.4G Wireless Receiver System Control as /devices/pci0000:00/0000:00:01.3/0000:03:00.0/usb1/1-4/1-4:1.1/0003:25A7:FA70.0011/input/input82

14. May 17 13:18:22 localhost kernel: hid-generic 0003:25A7:FA70.0011: input,hiddev96,hidraw1: USB HID v1.10 Mouse [Compx 2.4G Wireless Receiver] on usb-0000:03:00.0-4/input1

15. May 17 13:18:22 localhost systemd-logind[5177]: Watching system buttons on /dev/input/event7 (Compx 2.4G Wireless Receiver Consumer Control)

16. May 17 13:18:22 localhost systemd-logind[5177]: Watching system buttons on /dev/input/event6 (Compx 2.4G Wireless Receiver Keyboard)

17. May 17 13:18:22 localhost systemd-logind[5177]: Watching system buttons on /dev/input/event8 (Compx 2.4G Wireless Receiver System Control)

18. May 17 13:18:22 localhost systemd-logind[5177]: Watching system buttons on /dev/input/event2 (Compx 2.4G Wireless Receiver)

19. May 17 13:18:22 localhost kernel: usb 1-3: reset full-speed USB device number 2 using xhci_hcd

20. May 17 13:18:22 localhost kernel: logitech-djreceiver 0003:046D:C534.0012: hidraw2: USB HID v1.11 Keyboard [Logitech USB Receiver] on usb-0000:03:00.0-3/input0

21. May 17 13:18:22 localhost kernel: logitech-djreceiver 0003:046D:C534.0013: hiddev97,hidraw3: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-0000:03:00.0-3/input1

22. May 17 13:18:22 localhost kernel: logitech-djreceiver 0003:046D:C534.0013: device of type eQUAD nano Lite (0x0a) connected on slot 2

23. May 17 13:18:22 localhost kernel: input: Logitech Wireless Mouse as /devices/pci0000:00/0000:00:01.3/0000:03:00.0/usb1/1-3/1-3:1.1/0003:046D:C534.0013/0003:046D:4054.0014/input/input83

24. May 17 13:18:22 localhost kernel: logitech-hidpp-device 0003:046D:4054.0014: input,hidraw4: USB HID v1.11 Mouse [Logitech Wireless Mouse] on usb-0000:03:00.0-3/input1:2

25. May 17 13:18:23 localhost systemd[1]: machine-qemu\x2d1\x2dwin10.scope: Succeeded.

26. May 17 13:18:23 localhost systemd[1]: machine-qemu\x2d1\x2dwin10.scope: Consumed 46.759s CPU time.

27. May 17 13:18:23 localhost systemd-machined[5182]: Machine qemu-1-win10 terminated.

28. May 17 13:18:23 localhost libvirtd[6737]: 2020-05-17 11:18:23.999+0000: 6737: info : libvirt version: 6.1.0, package: 2.fc32 (Fedora Project, 2020-03-24-15:45:44, )

29. May 17 13:18:23 localhost libvirtd[6737]: 2020-05-17 11:18:23.999+0000: 6737: info : hostname: localhost.localdomain

30. May 17 13:18:23 localhost libvirtd[6737]: 2020-05-17 11:18:23.999+0000: 6737: warning : virSecuritySELinuxRestoreFileLabel:1503 : cannot lookup default selinux label for /run/media/sib/STOCKAGE/VMs/virsh W10/win10-2.qcow2

31. May 17 13:18:24 localhost kernel: snd_hda_intel 0000:1f:00.1: Force to non-snoop mode

32. May 17 13:18:24 localhost audit: BPF prog-id=66 op=UNLOAD

33. May 17 13:18:24 localhost kernel: input: HDA ATI HDMI HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:03.1/0000:1d:00.0/0000:1e:00.0/0000:1f:00.1/sound/card0/input84

34. May 17 13:18:24 localhost kernel: input: HDA ATI HDMI HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:03.1/0000:1d:00.0/0000:1e:00.0/0000:1f:00.1/sound/card0/input85

35. May 17 13:18:24 localhost kernel: input: HDA ATI HDMI HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:03.1/0000:1d:00.0/0000:1e:00.0/0000:1f:00.1/sound/card0/input86

36. May 17 13:18:24 localhost kernel: input: HDA ATI HDMI HDMI/DP,pcm=9 as /devices/pci0000:00/0000:00:03.1/0000:1d:00.0/0000:1e:00.0/0000:1f:00.1/sound/card0/input87

37. May 17 13:18:24 localhost kernel: input: HDA ATI HDMI HDMI/DP,pcm=10 as /devices/pci0000:00/0000:00:03.1/0000:1d:00.0/0000:1e:00.0/0000:1f:00.1/sound/card0/input88

38. May 17 13:18:24 localhost kernel: input: HDA ATI HDMI HDMI/DP,pcm=11 as /devices/pci0000:00/0000:00:03.1/0000:1d:00.0/0000:1e:00.0/0000:1f:00.1/sound/card0/input89

39. May 17 13:18:24 localhost audit[6540]: VIRT_CONTROL pid=6540 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=kvm op=stop reason=shutdown vm="win10" uuid=07e33e1d-192a-4a5b-9216-45d43b386da8 vm-pid=-1 exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=success'

40. May 17 13:18:24 localhost pipewire[4293]: #033[1;31m[E][000001137.498884][alsa-udev.c:205 emit_object_info()] can't open control for card hw:0: Permission denied#033[0m

41. May 17 13:18:24 localhost kernel: logitech-hidpp-device 0003:046D:4054.0014: HID++ 4.5 device connected.

42. May 17 13:19:28 localhost systemd[1]: libvirtd.service: Succeeded.

43. May 17 13:19:28 localhost audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=libvirtd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

I can’t find anything that would explain why the host display doesn’t resume working…

Any ideas? Thanks!

SilentSib

I am pretty sure that this is the reset bug.

Take a look at this thread- Vega 10 and 12 reset application

You can format logs or code blocks with three back ticks ``` both on the top and bottom.

Thanks. I posted the same thing on Reddit and the person who replied said it was not the reset bug xD

I’m currently building the same kernel with the patch applied and will see what happens then. It’s incredible that AMD still hasn’t fixed this officially though.

1 Like