From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Zhai, Edwin" Subject: Re: [PATCH] [IOEMU] Fix wrong INTx for pass-through device Date: Thu, 31 Dec 2009 15:40:53 +0800 Message-ID: <4B3C5585.9040600@intel.com> References: <4B38589B.8060307@intel.com> <8686c3cd0912280633u27839f56k74abcd73fb041e4@mail.gmail.com> <4B394BCB.30607@intel.com> <20091229020128.GG10172@verge.net.au> <8686c3cd0912290051t76c771fdq15314f25287d3973@mail.gmail.com> <4B39C4DE.8050103@intel.com> <8686c3cd0912300020n1284bf0ele160985f5118aad4@mail.gmail.com> <20091231043241.GA30174@verge.net.au> <4B3C3FC3.40301@intel.com> <20091231064531.GB12237@verge.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20091231064531.GB12237@verge.net.au> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Simon Horman Cc: Tom Rotenberg , Xen Developers , Ian Jackson List-Id: xen-devel@lists.xenproject.org Regarding this patch, I think we need move the pci_read_intx up, or I would get compilation error with the reference in pt_irqpin_reg_init. I have tested this path, both linux and windows can work, so Let's use physical PIN policy. Could you pls. send a new patch to Ian Jakson in a new thread, so that he can check in it after holiday without tracking this long discussion:) BTW, could you pls. tell me how to assign the multiple function device to guest as it is? Setting the same virtual PCI slot? Thanks, Simon Horman wrote: > 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. > > -- best rgds, edwin