[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