Re: [Xen-devel] [PATCH]: xl: pci multi-function passthrough v2

[Simon Horman <horms@xxxxxxxxxxxx>]

On Tue, Aug 10, 2010 at 04:31:18PM +0100, Gianni Tedesco wrote:
> On Tue, 2010-08-10 at 16:25 +0100, Simon Horman wrote:
> > On Tue, Aug 10, 2010 at 12:25:46PM +0100, Gianni Tedesco wrote:
> > > On Mon, 2010-08-09 at 21:27 +0100, Simon Horman wrote:
> > > > On Mon, Aug 09, 2010 at 01:00:39PM +0100, Gianni Tedesco wrote:
> > > > > Changes since last time:
> > > > >  1. Incorporate Stefanos feedback wrt. coding style, commenting
> > > > >     non-obvious code and making single-function a special-case of
> > > > >     multi-function
> > > > >  2. Also fix the case for passing through a single sub-function and
> > > > >     re-mapping it as a single-function virtual device. (ie: pfunc =
> > > > >     non-zero, vfunc = zero). Apparently needed for SR-IOV.
> > > > >  3. One-liner format change in xl pci-list-assignable to make it
> > > > >    print a copy-and-pasteable BDF.
> > > > > 8<----------------------------------------
> > > > > 
> > > > > Implement PCI pass-through for multi-function devices. The supported 
> > > > > BDF
> > > > > notation is: BB:DD.* - therefore passing-through a subset of 
> > > > > functions or
> > > > > remapping the function numbers is not supported except for when 
> > > > > passing
> > > > > through a single function which will be a virtual function 0.
> > > > 
> > > > Is there any plan to extend this to allow for re-mapping and the like.
> > > > When I worked on the original multi-function support (last year)
> > > > this seemed to be a requirement of some people.
> > > 
> > > I am glad you asked
> > > 
> > > I initially planned to support this but it seemed like a nightmare:
> > > 1. The BDF notation practically becomes a regex language ;)
> > 
> > I don't think its reasonable to say it becomes a regex language.
> > But I do agree that it becomes more complex.
> 
> Well, for example BB:DD.0=7-7=0 is supposed to reverse the
> assignments.... but why? :)

Because 0 maps to 7, 7 maps to 0 and everything in between is implied.
I don't dispute that this is complex. And actually this mapping bit
really pushes the extension of the notation further than I initially
envisaged.

So yes, I think that it is complex. But I don't think its a regex language.

> 
> > > 2. For HVM, if a function 0 is not passed through then you don't
> > >    generate an SCI interrupt for PCI hotplug.
> > 
> > Isn't it sufficient to make sure that the guest sees a function 0,
> > regardless of what the physical function number is? Or am I missing
> > something?
> 
> Yes that's all that's required.
> 
> > > 3. I couldn't imagine a scenario where this wasn't erroneous thing to do
> > 
> > I'm not sure that I understand this point.
> > I agree that your system should always produce a valid result.
> > But I think that there are other configurations that are
> > both valid and useful.
> 
> Passing various functions in to different VM's and/or re-mapping the
> function numbers may produce a totally invalid configuration that isn't
> useful (AFAICT). That may be paranoia but I just want to be convinced
> that this is actually useful for something.

Yes, I agree that the scheme that I implemented can produce invalid results.
I was concerned about that too. And initially I resisted allowing arbitrary
mappings for that reason. But I was convinced/requested to allow them.

> > > But if someone can convince me that this is a worth-while thing to do
> > > (3) then (1) and (2) are just technical problems which can be
> > > overcome...
> > 
> > People convinced me that it was worthwhile, but I'm not those people.
> 
> Well, please put them in touch or maybe forward the relevant
> discussions? (off-list is OK, if the discussions are private)
> 
> Like I say, I am not dead against the idea, I am just loathe to
> implement it until I can see what the point of it is.

I think that its a wise position for you to take.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel