host-passthrough caused the VM to enter a boot loop. Back to Opteron G3 for the time being.
If it is a reset bug, could the Radeon be triggering the entire PCIe bus to reset causing the host Nvidia card to reset as well? I’m not very familiar with the reset bug, so I don’t know if it would have that effect.
That’s interesting. Did it get past the BIOS initialization?
No. The AMD Reset bug simply does nothing when you try to reset it, well… it does something, but not everything we need it to.
Yes, but the OS rebooted only a few seconds after POST.
Okay. That’s odd. I’m usually able to change CPU model with no problem in KVM/W10
I’m starting to run out of places to look here. I’m not sure why we’ve got so many problems on the system.
Just for fun I’m going to try dropping an Nvidia card in the Radeon’s slot. Maybe it’s a long shot, but I’m not seeing many other options.
Reconfiguring hardware is a good idea if you’re having weird problems.
Wanted to post a quick update before I hit the sack. Swapped in a GTX 970 (host) and transferred the 1050 Ti to the guest. Interesting results.
No more IOTLB or AMD-Vi errors or white screens of death, but I am still seeing this one:
May 10 15:31:27 deb5675 kernel: [14282.783539] kvm [12849]: vcpu0, guest rIP: 0xfffff807b20916c9 unhandled rdmsr: 0xc0010071
As per Gray Wolf’s tutorial some extra sauce had to be added to the vm’s xml file to allow Nvidia cards to load without Code 43. For some reason, this also allowed the CPU to be recognized as a Ryzen 7 instead of an Opteron G3. Not really seeing a big jump in CPU performance though.
3dmark indicates that 1050 Ti has only half the power of the RX 580. However, in Assassin’s Creed Origins the 1050 TI was hitting 49 fps, whereas the RX 580 only got 41.
Enough for now. I’ll try upgrading to 1803 tomorrow, or maybe overnight.
Well the VM seems to work well enough, but I can’t convince it to upgrade to 1803. I keep getting error 0xc1900101 which seems to indicate a problem loading a driver or accessing the disk. Surprise, surprise.
This may not be an immediate problem - I have a disk image with 1803 installed, but it seems to point to an underlying problem accessing the disk image. I’ve currently got SATA selected instead of VirtIO in virt-manager, but the update keeps having problems accessing the disk. Any thoughts?
This gets stranger and stranger. If I try to boot the VM off the Windows 1803 ISO, the VM boot loops. It boots fine off a 1709 ISO. I’m totally befuddled at this point.
Maybe Virtualbox or Proxmox can do this better? OTOH, I may just move forward with 1709 and hope someone fixes compatibility with 1803 at some point.
Yeah, I’m having similar issues. I can’t tell you why 1803 is causing problems. It’s definitely a windows problem though.
I had to give up on it and use 1709.
That’s what I’ve done too. A Win10 Pro install will let you defer the update for a year. Someone should have it figured out by then.
At least I’m not alone…
Over the last day or two, I’ve encountered at least 3 other people on the forums who have had this issue. I think it was another thread where I mentioned that it’s most likely a QA/QC problem. Since they don’t have that anymore…
I’ve seen in other threads that this problem can be worked around by choosing an older CPU model to pass to the Windows guest (e.g., Core2Duo). However regardless of which CPU model I choose it always gets passed through as a Ryzen 7 1700.
I followed this tutorial to get GPU pass through working, but something in Gray Wolf’s process seems to enable CPU pass through and disable any ‘downgrades’.
It’s academic for the time being, since I can defer the upgrade for a year, but I would like to get this sorted out before my time runs out.