[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [vfio-users] [FEEDBACK NEEDED] Rewriting the Arch wiki article





On 2016-04-12 18:32, Alex Williamson wrote:
On 2016-04-12 17:24, Alex Williamson wrote:
On Tue, Apr 12, 2016 at 2:30 PM, Bronek Kozicki <brok spamcop net> wrote:
 
2. does PCI bridge have to be in a separate IOMMU group than passed-through device?

No.  Blank is mostly correct on this, newer kernel remove the pcieport driver test and presumes any driver attached to a bridge device is ok.
Really? From what I understood reading your IOMMU article, plus from the issues I had getting my own GPU to work on the CPU-based PCIe slot on my E3-1200, I thought having a PCIe root port grouped with a PCI device made the GPU unsuited for passthrougs. What reccomendations should I give here, then?

The statement "(there's generally only one)" is completely incorrect regarding processor based root port slots.  That $30k PC that LinuxTechTips did has 7 processor based root ports between the 2 sockets.
You're right, I shouldn't have extrapolated from the fact that most of the consumer hardware I have access to works that way, I'll remove that line on my next edit.
IOMMU group isolation requires that a group is never shared between host and guest or between different guests.  However we assume that bridge devices only do DMA on behalf of the devices downstream of them, so we allow the bridge to be managed by a host driver.  So in your example, it's possible that the bridge could do redirections, but the only affected party would be the VM itself.  The same is true for a multi-function device like the GPU itself, internal routing may allow the devices to perform peer-to-peer internally.  So it's not ideal when the bridge is part of the group, but it generally works and is allowed because it can't interfere with anyone else. 
Ah, I see. I suppose the issues i was having with my 970 were due to something else, then. Now that I look back at it, it's probably because my CPU-based PCIe slot was the only one that could be set as a boot GPU. I'll try to rework that part and mention that it adresses a much more specific case than what I iniaially thought, then.
I have the identical setup on my E3-1245v2 and haven't had any problems.
The line is actually copy-pasted from your IOMMU blog-articles, since my own machine no longer follows that configuration and I needed a snippet for that specific exemple.

On 2016-04-12 18:57, Alex Williamson wrote:
Skimming...

Most of those AMD CPUs in the amd.com link do not support AMD-Vi
I should have double-checked, I was under the impression that RVI and AMD-Vi were the same thing. The fact that AMD doesn't really maintain any sort of public centralized database like Intel ARK makes it really complicated to give advices on this.
User-level access to devices... No, don't do this.  System mode libvirt manages device permissions.  If you want unprivileged, session mode libvirt you need a whole other wiki page.

Binding to VFIO... Gosh I wish those vfio-bind scripts would die.  Just use libvirt, virsh nodedev-detach

QEMU permissions... WRONG!  Don't touch any of this.

Complete example for QEMU with libvirtd... No, qemu:args are the worst.  This hides the assigned device from libvirt and is what causes you to need to do the QEMU permissions hacks that are completely wrong.  Use a wrapper script!

As others have said, ignore_msrs makes lots of things work, not just GeForce Experience
Yeah, I think you're starting to see why a rewrite is in order here. ;)

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]