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

Nicolas Roy-Renaud nicolas.roy-renaud.1 at ens.etsmtl.ca
Tue Apr 12 23:10:11 UTC 2016



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 at spamcop.net
>>     <mailto:brok at 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
>     <https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVMF#Plugging_your_guest_GPU_in_an_unisolated_CPU-based_PCIe_slot>,
>     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 
<https://www.redhat.com/archives/vfio-users/2015-October/msg00005.html>. 
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 <http://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. ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/vfio-users/attachments/20160412/ba6594fc/attachment.htm>


More information about the vfio-users mailing list