I’m running a KVM virtual machine with Windows 10 on Fedora 26. Everything MOSTLY works great, except for disk I/O.
I’ve tried setting it up on a virtual HD, and passing thru a raw SDD. Either way, the I/O is not good. I’t SO close to being usable for playing games, but just not quite there. I’ve tried using SATA and VirtIO drivers. I’ve tried setting drive performance options…cache mode writeback, none, etc. and I/O mode Hypervisor default, native, etc.
AMD GPU drivers are installed just fine. I don’t believe this is a GPU issue. It’s taking way too long to load games, and then terrible stuttering while playing.
I’ve done all the usual things…CPU Pinning, etc. I’m out of ideas.
This is a known drawback with this setup, but I was able to achieve acceptable performance using virtio to pass through an ssd’s block device (/dev/sd*).
The only way to get native performance is to passthrough your SATA controller like you did with your GPU, or to passthrough an NVMe SSD.
It sounds like you either you forgot a step setting up gpu pass through or one of the settings n the configure fils for links is set wrong it is hard the help since you didn’t list your omputer part list. I would leave suggest searching this form for any information on Ryzen GPU passhrough, and Paching NPT on Ryzen for better performance.
Also, are you using NPT=1 and are you sure that the software you are using includes the fixes for the NPT bug? I/O is typically something that is affected negatively by NPT=0, though IME virtio-scsi offsets a lot of that problem too (this shouldn’t be a problem anymore in either case, given a new enough linux kernel… or maybe you still need to patch, I am not sure whether the fix has made it into the kernel).
I tried passing through an nvme ssd and got the same result. I’m not sure I’m doing something right, though. My NVME controller has its own IOMMU group, but when I add it to the VM, the VM won’t start (it says it can’t find the nvme drive). Then I realized I hadn’t added it to vfio.conf. So I added it to vfio.conf and rebooted. And the VM still won’t start (same thing…can’t find the nvme drive).
I’ve tried passing the Asmedia controller too, and using those raw drives…same thing…can’t find the drives if the controller is passed through. Am I missing something simple with this?
Is there a procedure somewhere for the NPT=1 patch for Fedora…that just overwrites that kernel module and not have to recompile kernel? Besides the one wendell posted (that one is impossible to follow). I’ve patched plenty of FreeBSD kernels before, but doing it in Linux is really confusing.
I don’t know, really, I guess that compiling only a module would require you to download the entire source tree anyway. Though I guess it won’t be a problem if you take the source of the exact kernel you are running, then you could perhaps make a super-minimal config file containing only what you need, and modprobe should in theory work with the resulting module… though I haven’t needed to compile a linux kernel in 5+ years, so I’m no expert here…
In any case, NPT=1 should be functional (except that it hits PCI passthrough performance) on your setup currently and the bug would only affect passed-through devices (PCI, not block devices), so you should get the same I/O performance with NPT=1 regardless of whether you have patched the kernel or not. You can test this way whether your performance issues have to do with NPT at all, and if so bother with kernels in the next step. The reason I mention this is that I have actually owned one machine that was affected by the NPT bug before the fix was around, a K10 Opteron, and I had no notable problems with Windows-guest I/O performance on that one.
(I realise that I might have mislead you somewhat in my earlier post - NPT=1 should be enough for I/O to work optimally - at least if you don’t do controller passthrough - patching the kernel is about getting the GPU to perform well given NPT=1. But personally I never found NPT=0 as detrimental as some reddit discussions make it sound. But again, it was not on Ryzen, there might be architectural differences playing a role)