[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.