dkabot

You may want to avoid passing in SMT cores, but you should be fine to put in as many real cores as you want. QEMU (I think it was QEMU) is actually hardcoded to assume that AMD processors can't do SMT, and will pass through any SMT cores as if they were real ones. In my basic testing, while this does improve CPU performance a bit, you also lose some GPU performance for it.

We've been discussing this the entire page, though the update is appreciated regardless. Looking forward to trying the new build! I'll be sure to look into a license (been using trials every month or two to check the situation) once things are cooperating.

Now we're talking.

Theoretically they should be able to apply the patch, but I'd be inclined toward thinking they won't. Edit: I don't have any reason to actually think so or not, just my gut.

Now we just need to hope the patch makes it in for 4.1X or something, then we can bug LimeTech to use it.

Yes, KVM is in the kernel and as such, this would require building a kernel yourself. Considering how old the only documentation for that (on Unraid) is, not something I'd recommend.

Hopefully it's just a matter of time before something gets upstream and Unraid gets an update. I'm still tempted by the idea of being lazy and using Unraid for the management aspect, even if I can just install a normal distro. I suppose someone could try to compile a kernel on top of current Unraid, but considering the documentation, I don't think I'll be doing that.

I linked the wrong one, thought I had to remove and repost for some reason, and then forgot to. Sorry, that was me being dumb. There is, however, further good news in that a KVM maintainer has seen this and is trying to make a real patch. Edit: Sarnex has graced me with the link to this development: https://marc.info/?l=kvm&m=150891787704371&w=2

You haven't seen anything because nothing's happened. It's still there, and the only "discovery" is that this bug is 10 years old and on other AMD processors. If you have a more technical hand, you can try other hypervisors which apparently are unaffected, such as Xen or ESXi. Xen seems to be very lenient on what you can pass through, but requires modifying nVidia drivers to install them and setup is obtuse. ESXi apparently works, and has a far easier way to just hide the VM status (like KVM), but I know of no way to work around my poor IOMMU groupings. There's also the possibility that some other hypervisor like Bhyve (BSD) will add GPU passthrough, in which case it could probably be used instead, but we have no estimate for if/when that'll happen. As much as I hate to say it, if you want things to Just Work(TM) get an Intel processor.

Yeah, I'd be using Xen right now (which doesn't have the NPT bug at all, so I hear), but it refused to acknowledge that I had SVM on regardless of the fact that it definitely was. Running bare Windows is a tragedy, but I'm not the type to dual boot. Edit: My recollection was wrong. It knew I had SVM on, but due to some ACPI table thing, it was unable to enable AMD-Vi (IOMMU).

It's been quite a while since I've touched this, but I'm fairly certain NPT can be toggled without changes to the VMs. NPT is a host hardware setting, not something you apply to virtual hardware on the guest. As such, while performance will differ, as far as the VM is concerned, nothing has changed.

NPT is still busted as ever from what I can tell; it murders GPU performance, but turning it off hurts CPU performance a good deal.

Alright, reverted my board back to latest stable. While the GPUs were detected in their own group, neither Unraid nor Arch were able to actually pass it through. Going into the VM externally with TeamViewer showed the resolution was 640x480 and there were no graphics adapters at all. Also, the RGB light cycle was messed up, and it would show red instead of purple on my CPU fan. Clearly the worst of tragedies. Anyway, looks promising, be nice to see what happens on stable release.

With ACS on this board, one USB controller is exposed, which is for the two USB 3.1 (one of them Type-C) ports. The rest are intermingled with other system components, even with the patch.

I tossed a beta BIOS on my Crosshair VI Hero, disabled the ACS patch, and here are my groupings: IOMMU group 0 [1022:1452] 00:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1452 IOMMU group 1 [1022:1453] 00:01.3 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 1453 IOMMU group 2 [1022:1452] 00:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1452 IOMMU group 3 [1022:1452] 00:03.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1452 IOMMU group 4 [1022:1453] 00:03.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 1453 IOMMU group 5 [1022:1453] 00:03.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 1453 IOMMU group 6 [1022:1452] 00:04.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1452 IOMMU group 7 [1022:1452] 00:07.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1452 [1022:1454] 00:07.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 1454 [1022:145a] 2b:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Device 145a [1022:1456] 2b:00.2 Encryption controller: Advanced Micro Devices, Inc. [AMD] Device 1456 [1022:145c] 2b:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Device 145c IOMMU group 8 [1022:1452] 00:08.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1452 [1022:1454] 00:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 1454 [1022:1455] 2c:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Device 1455 [1022:7901] 2c:00.2 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 51) [1022:1457] 2c:00.3 Audio device: Advanced Micro Devices, Inc. [AMD] Device 1457 IOMMU group 9 [1022:790b] 00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 59) [1022:790e] 00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev 51) IOMMU group 10 [1022:1460] 00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1460 [1022:1461] 00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1461 [1022:1462] 00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1462 [1022:1463] 00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1463 [1022:1464] 00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1464 [1022:1465] 00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1465 [1022:1466] 00:18.6 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1466 [1022:1467] 00:18.7 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1467 IOMMU group 11 [1022:43b9] 03:00.0 USB controller: Advanced Micro Devices, Inc. [AMD] Device 43b9 (rev 02) [1022:43b5] 03:00.1 SATA controller: Advanced Micro Devices, Inc. [AMD] Device 43b5 (rev 02) [1022:43b0] 03:00.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 43b0 (rev 02) [1022:43b4] 1d:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 43b4 (rev 02) [1022:43b4] 1d:02.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 43b4 (rev 02) [1022:43b4] 1d:03.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 43b4 (rev 02) [1022:43b4] 1d:04.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 43b4 (rev 02) [1022:43b4] 1d:05.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 43b4 (rev 02) [1022:43b4] 1d:06.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 43b4 (rev 02) [1022:43b4] 1d:07.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 43b4 (rev 02) [1b21:1343] 21:00.0 USB controller: ASMedia Technology Inc. Device 1343 [8086:1539] 23:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection (rev 03) IOMMU group 12 [10de:1380] 29:00.0 VGA compatible controller: NVIDIA Corporation GM107 [GeForce GTX 750 Ti] (rev a2) [10de:0fbc] 29:00.1 Audio device: NVIDIA Corporation Device 0fbc (rev a1) IOMMU group 13 [10de:13c0] 2a:00.0 VGA compatible controller: NVIDIA Corporation GM204 [GeForce GTX 980] (rev a1) [10de:0fbb] 2a:00.1 Audio device: NVIDIA Corporation GM204 High Definition Audio Controller (rev a1) Looks like GPUs can readily be passed through without hacks, but USB, onboard audio, SATA, etc. are still off the table as-is. EDIT: After trying on both an existing USB and a new one, I now cannot get Unraid to pass through a GPU for some reason. Ver. 6.3.4. Going to try a normal linux again now that I don't need to compile a kernel for ACS patch and see how far I can get.

Additional observations about VM-related Freezes: Debian Netinst (non-GUI) freezes when I hit Choose Language. Antergos freezes once you choose your disk partitioning style, but the cursor can still move. When the host freezes, the system is not technically hung; WebUI, SSH and (seemingly) the local console hang, but I can upload an ISO and it stays across the reset. Still no closer to any progress (I'd test normal linux but I can't get a compiled kernel to boot...), but the last one was something I thought was interesting. EDIT: Because I don't want to double post... I'm an idiot; I finally decided that since I needed the QEMU Emulated CPU rather than Host Passthrough to get Windows running, I'd try it on Linux. Tried Antergos, and the installer itself errored out, oh well. Tried Kubuntu, and it actually succeeded, though it failed to restart I could just Force Stop the VM at that point. Trying to install a 4.11 kernel on Kubuntu made it stop booting, so there's still a good deal to poke at, but at least I get further than everything crashing, it seems.

No; while I did encounter issues with setting up Windows, they were alleviated fairly easily with the instructions I noted. My current issue is that as a guest, Kubuntu's installer will fairly consistently hang the system, Ubuntu's will occasionally do so and even Windows has managed to do it once. Trying to poke at other Linux host setups to see if they change the situation, and so far the only one I got far enough to work (kernel 4.10) hung the guest when I tried to load Kubuntu, with the host then noting that the process for KVM was hung every ~2 minutes. Because of that, I haven't even gotten into trying disabling NPT or any other workarounds for the GPU hit; just trying to sort out if there's anything to deal with hard locks.

Something odd I've encountered but not seen in here based on some searches: Windows 8.1/10 refused to start the installer on the default VM settings. It'd get to the Windows logo flag, I'd get some HDD access for a little while, followed by absolutely nothing at all to indicate it was doing anything. I followed some instructions I saw elsewhere about doing an upgrade to 10 where they said to set CPU to "Emulated (QEMU64)" with one core, and that got it booting. The passed through GPU seems to be irrelevant to this occurring, as the failure and success cases were the same with VNC or a passed through GPU. It seems once it's been installed and downloaded a round of updates (probably unnecessary?) I was able to switch it back and have it not fail to boot. May be common knowledge, I'm not certain, but tossing it in this thread for completeness' sake since it doesn't appear to be mentioned.

My Ryzen 1700 gear arrived today (sans case) so I'm hoping to join the testing club soon as well. Got it using Windows on an unimportant disk at the moment, going to make an Unraid USB and see how it runs.

I do not have firsthand experience, but have read about it in a few places. For some reason, Ryzen/AMD appears to tank framerates unless you disable NPT (Nested Page Tables). Disabling it, though, degrades CPU performance; the extent of which seems to vary on who you ask. We've only got a few places it's referenced, but the story is still fairly similar all around. It's been posted on this thread, at reddit (twice), and on the VFIO mailing list with no response. Hopefully a less harmful workaround than disabling NPT is found; the second reddit post looks interesting.