[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Multi-Function PCI passthrough not implemented?
> -----Original Message----- > From: xen-devel-bounces@xxxxxxxxxxxxx > [mailto:xen-devel-bounces@xxxxxxxxxxxxx] On Behalf Of Antonin Bas > Sent: Wednesday, September 18, 2013 1:55 AM > To: Sander Eikelenboom > Cc: xen-devel@xxxxxxxxxxxxx; Antonin Bas; Ian Campbell; Jan Beulich; Stefano > Stabellini > Subject: Re: [Xen-devel] Multi-Function PCI passthrough not implemented? > > What would be really useful is that the BDF notation extension > described at http://wiki.xen.org/wiki/Bus:Device.Function_(BDF)_Notation > actually be supported. > Just supporting the '*' notation (with or without giving a vslot) is > not entirely satisfying. People may want to assign some funcs (e.g. > 0-3) to one vslot and the others (4-7) to another vslot, like is > possible with the libvirt multifunction='on' attribute (since libvirt > 0.9.7, with QEMU > 0.1.3). The '*' notation should also handle the > case where the device has less than 8 funcs and assign the existing > funcs without crashing. > Seems the current implementation of xl only supports "*" notation, the following notations mentioned at http://wiki.xen.org/wiki/Bus:Device.Function_(BDF)_Notation are not supported: 0000:00:1d.0-2 0000:00:1d.0,3,5,7 0000:00:1d.2=0-0=2 0000:00:1d.0=3,3=2,5=1,7=0 > Best, > > Antonin > > 2013/9/16 Sander Eikelenboom <linux@xxxxxxxxxxxxxx>: > > > > Monday, September 16, 2013, 2:32:52 PM, you wrote: > > > >>>>> On 16.09.13 at 14:11, Sander Eikelenboom <linux@xxxxxxxxxxxxxx> > wrote: > > > >>> Monday, September 16, 2013, 9:27:58 AM, you wrote: > >>> > >>>>>>> On 13.09.13 at 23:52, Antonin Bas <antoninb@xxxxxxxxxxxxxxx> > wrote: > >>>>> There are several mentions of these features on the wiki > >>>>> (http://wiki.xen.org/wiki/VTdHowTo, > >>>>> http://wiki.xen.org/wiki/Bus:Device.Function_(BDF)_Notation). > However, > >>>>> this is definitely not working and I could not see it implemented > >>>>> anywhere in libxl. > >>>>> > >>>>> I actually even think there is a bug in the code: > >>>>> > >>>>> xlu_pci_parse_bdf in libxlu_pci.c accepts inputs of the form > >>>>> "domain:bus:dev.*" (* is really a star here), which is supposed to > >>>>> designate all the functions for this PCI device. > >>>>> In this case, pcidev->func will be set to an uninitiated value by > >>>>> pcidev_struct_fill(). > >>>>> Later on, libxl__device_pci_add() and libxl_pcidev_assignable() > >>>>> (libxl_pci.c) are called with pcidev as an argument. And because > >>>>> pcidev->func is garbage, an error is thrown. > >>> > >>>> You not mentioning the Xen version I'd assume you talk about > >>>> -unstable, yet looking at the code I can't match things up with > >>>> what you say above. In fact it looks to me as if multi-function > >>>> support was properly dealt with by libxl{u,}_pci.c... > >>> > >>> Hi Jan, > >>> > >>> It is easy to trigger with unstable. > >>> > >>> libxl__device_pci_add early on calls libxl_pcidev_assignable to verify the > >>> device func is assignable, > >>> but this function isn't multifunction aware and tries to match the > >>> non-existant function number used > >>> to to the assignable list which only contains the individual reserved > >>> device > >>> and function numbers. > >>> > >>> So it returns false and xl gives an error like: > >>> libxl: error: libxl_pci.c:1056:libxl__device_pci_add: PCI device 0:7:0.f0 > >>> is > >>> not assignable > >>> > >>> > >>> So libxl_pcidev_assignable should check if it's multifunction is > >>> specified, > >>> and if so check if all 8 func's for this devices > >>> are assignable. > > > >> Ah, okay, I needed to check one call hierarchy level deeper... > > > >> Anyway - just wanted to get the situation confirmed, I'll leave > >> fixing this to our tools experts anyway. > > > > CC'ed IanC and Stefano. (resend because i accidentally removed the old CC's) > > > > I tried to see how far i could come with outcommenting the safety checks in > libxl_pcidev_assignable. > > > > It works with qemu-xen-traditional when i specify a vslot for the > > multifunction > pcidev (f.e. pci="00:03:00.*@7"), > > but i can't see why it is necessary to specify it by hand (unless one would > > like it > to end up at a particular slot for some reason) ? > > Or is there no other way to "group" the individual functions in the qmp > > syntax > and have them end up on the same vdev ? > > > > With qem-xen-(upstream) this fails with a qmp error since it doesn't seem to > have no knowledge of the "addr" parameter that gets added by specifying the > vslot. > > > > -- > > Sander > > > > > >> Jan > > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxx > http://lists.xen.org/xen-devel Thanks, Feng _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |