Re: [Xen-devel] [PATCH v9 12/14] tools/libxl: read from config if passing through primary GPU

[Sander Eikelenboom <linux@xxxxxxxxxxxxxx>]

Thursday, July 3, 2014, 5:25:56 PM, you wrote:

> On Thu, 2014-07-03 at 16:17 +0100, Jan Beulich wrote:
>> >>> On 03.07.14 at 16:53, <Ian.Campbell@xxxxxxxxxx> wrote:
>> > On Thu, 2014-07-03 at 15:50 +0100, Ian Campbell wrote:
>> >> What specifically should Arianna be looking for? THe PCI device class or
>> >> something else?
>> > 
>> > Qemu-trad seems to use:
>> >     if ( !gfx_passthru || real_device->pci_dev->device_class != 0x0300 )
>> >         return ret;
>> > 
>> > Is that sufficient?
>> 
>> I don't think so - I'd expect secondary cards to also be showing this
>> class/sub-class (but I have no system with two or more cards where
>> I could at least empirically check), i.e. that would only be sufficient
>> when there's no upstream bridge. PCI_BRIDGE_CTL_VGA (on
>> upstream bridges) and maybe (but unlikely)
>> PCI_COMMAND_VGA_PALETTE (on the device itself and perhaps also
>> upstream bridges) would seem to be the indicators. But I'm afraid
>> this really needs to be properly answered by a PCI expert.

> Hrm, I'm not sure I see that happening any time soon...

I'm by *NOOOO* means an expert, however:

There has been some dicussion on the lkml / qemu list which has some comments 
about what is in specs:
https://lists.gnu.org/archive/html/qemu-devel/2014-01/msg01985.html

So the most prominent seems to be the ordering of the pci devices, boot vga ==  
first vga adapter. An other way suggested of setting the primary card was 
indeed 
with  PCI_BRIDGE_CTL_VGA, but that required the other VGA devices not being on 
the root bus (as it is now in qemu). Perhaps that would make things more 
flexible, putting passed through devices behind bridges in guests ?

> Given that the above class-based check has apparently been fine since
> however long could we live with it in the context of this series?

> Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel