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

Re: [Xen-devel] [PATCH] [IOEMU] Fix wrong INTx for pass-through device



On Thu, Dec 31, 2009 at 02:08:03PM +0800, Zhai, Edwin wrote:
> Simon/Tom,
> We have 3 optinos:
> A. always INTA
> B. always physical INTx
> C. INTA if virtual function is 0, physical INTx for otherwise.
> 
> Difference of option B and C is that guest will see a function 0 on
> a single function device is linked to a PIN rather than INTA, say
> assign 0:1a.7 to guest as 0:4.0. Most of OS should handle this. so
> I'm okay with both.
> 
> For option A, I'm not sure the issue for the multiple-function
> device. Can we assign a multiple function device to a guest as it
> is? E.g. assign physical 0:a.0/0:a.1to guest as 0:4.0/0:4.1. In this
> way, with option A, there are performance issue when injecting intr
> as they share same virtual GSI.

Yes, the ability to make assignments like that is the crux
of the multi-function work that I did earlier in the year.
And the idea of not always using INTA was to avoid the
performance penalty of reusing the virtual GSI.

> If we can't do this now, I think option A is also good. Is any
> specific reason that we change to C? Does some specific multiple
> function driver assumes specific pin other than INTA?

... so A isn't such a good option (it was before and thats what was used).
I think that I chose C when I added multi-function because it
avoided introducing any incompatibility for single-function pass-through.
But at this point I think C just introduces complexity, so I now prefer B.

> BTW, pls. send your patch in attachment as I couldn't get it from
> your mail:(

Sure.

Attachment: pci_read_intx.patch
Description: Text Data

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

 


Rackspace

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