<div dir="ltr">Because vfio-pci.ids can make vfio directly access GPU with VID:PID. You have to write another script to make VFIO mount GPU manually if using pci-stub.<div><br></div><div>Also, on Fedora, directly using vfio-pci can let you install same GPUs and work on host and guest at the same time.</div><div>For example, you can installed 2 x R9-285 on your host and let one working in host and another one mount into guest.</div><div>It can't do this if using pci-stub only, because pci-stub only works on VID:PID.</div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-09-27 19:07 GMT+08:00 José Ramón Muñoz <span dir="ltr"><<a href="mailto:koalinux@gmail.com" target="_blank">koalinux@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Hi,<br>
<br>
Actually it's more funny, it really works like you said, but, for any<br>
reason vfio-pci.ids doesn't prevent radeon and my xorg server to take the p-t<br>
gpu, and do their business. So using pci-stub.ids I can avoid ioh3420.<br>
<br>
Then my question is, how vfio-pci.ids is different to pci-stub.ids, and why<br>
it works better with the latest?<br>
<br>
Thanks!<br>
<span class="HOEnZb"><font color="#888888"><br>
José.<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Saturday 26 September 2015 02:04:48 Blank Field wrote:<br>
> That messages about FM2 platform made me laugh.<br>
> My current W10+OVMF system outputs video until starting windows spinning<br>
> logo, then the video driver crashes.<br>
> The thing is: this behavior is dependent on OVMF version, guest driver<br>
> version and it is "phantom" - if the OS failed to show video output on the<br>
> first boot, a simple VM reboot will solve this.<br>
> Too bad i lack the skill to debug it further and can't afford building a<br>
> bunch of test configs.<br>
> On Sep 25, 2015 11:38 PM, "Alex Williamson" <<a href="mailto:alex.l.williamson@gmail.com">alex.l.williamson@gmail.com</a>><br>
><br>
> wrote:<br>
> > On Fri, Sep 25, 2015 at 12:48 PM, Jose Ramon Muñoz Pekkarinen <<br>
> ><br>
> > <a href="mailto:koalinux@gmail.com">koalinux@gmail.com</a>> wrote:<br>
> >> Hi,<br>
> >><br>
> >> I'm sorry to report that, at least for FM2 platform, if there is no<br>
> >><br>
> >> ioh3420, it doesn't work at all, w7 and w10 stalls in the windows logo on<br>
> >> 440fx. Well w10 doesn't work anyways, but w7 does.<br>
> ><br>
> > More and more it seems like if you get anything working on an FM2<br>
> > platform, you should count yourself lucky, but that doesn't mean that that<br>
> > combination of QEMU components were ever intended to be put together or<br>
> > make any kind of sense from a PCI perspective.<br>
> ><br>
> > _______________________________________________<br>
> > vfio-users mailing list<br>
> > <a href="mailto:vfio-users@redhat.com">vfio-users@redhat.com</a><br>
> > <a href="https://www.redhat.com/mailman/listinfo/vfio-users" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/vfio-users</a><br>
<br>
<br>
_______________________________________________<br>
vfio-users mailing list<br>
<a href="mailto:vfio-users@redhat.com">vfio-users@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/vfio-users" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/vfio-users</a><br>
</div></div></blockquote></div><br></div>