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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

Jan


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