I’d like to direct you to this thread. There’s a lot of TR passthrough discussion here. I’m fairly certain it will be fixed soon, since it appears to be an issue that should be able to be fixed via UEFI.
2 Likes
As far as I know the issues are still there.
It’s same issue reported by @bsodmike and by others on the VFIO reddit / AMD Support forums.
It’s basically that PCIe devices got stuck in “off/powersave mode” (D3 powerstate crap). Could not pass through NV graphics cards, USB card or a Soundblaster Z.
RMA’d the system for X299 parts (which sucked, because $$). X299 is running pretty good with VFIO for me (OpenSUSE Tumbleweed and Fedora 27), except for some snags with hugepages 
Edit: the TR system wouldn’t even boot (no post) with Fresco Logic chipset USB PCIe cards.
Edit2: post above is awesome, @SgtAwesomesauce delivers again!
1 Like
Ugh… Thanks! So, if I’m understanding correctly: threadripper – which should be the obvious choice for virtualization with its PCIe lanes – is currently “unusable” for that task?
What about the i9s (especially with nVidia’s 1070/1080 passthrough)? Don’t really want to pay more (for less…) and am willing to patch kernels, etc., but ultimately need something that, well, actually works.
The SMT for Zen only affects people who do cpu pinning and try to pass SMT to guest.
Qemu will not provide correct SMT information to identify core to cpu topology.
Guest will schedule 2 heavy threads on 1 physical core, even if there are unused ones, and host will not be able to schedule them to different cores due to pinning.
Thanks darling, I’m just your humble information broker.
2 Likes
i9 works. I pass through a 1080ti, soundcard, nic and a usb card. I use an RX460 for the host, amd gpus in linux are great!
On the flipside, Nvidia are douchebags. Just follow the archwikiguidethingy for how to work around error code 43.
1 Like