Re: [Xen-devel] Multi-Function PCI passthrough not implemented?

["Wu, Feng" <feng.wu@xxxxxxxxx>]

> -----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