From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Horman Subject: Re: [rfc 00/18] ioemu: use devfn instead of slots as the unit for passthrough Date: Mon, 23 Feb 2009 20:33:55 +1100 Message-ID: <20090223093354.GA27517@verge.net.au> References: <20090223151928.84DA.27C06F64@necst.nec.co.jp> <20090223065530.GA22192@verge.net.au> <20090223173804.84DD.27C06F64@necst.nec.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20090223173804.84DD.27C06F64@necst.nec.co.jp> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Yuji Shimada Cc: "xen-devel@lists.xensource.com" , Ian Jackson , Keir Fraser List-Id: xen-devel@lists.xenproject.org On Mon, Feb 23, 2009 at 05:39:52PM +0900, Yuji Shimada wrote: > On Mon, 23 Feb 2009 17:55:30 +1100 > Simon Horman wrote: > > > On Mon, Feb 23, 2009 at 03:24:41PM +0900, Yuji Shimada wrote: > > > On Fri, 20 Feb 2009 18:07:00 +1100 > > > Simon Horman wrote: > > > > > > > On Thu, Feb 19, 2009 at 09:38:24AM +0000, Keir Fraser wrote: > > > > > On 19/02/2009 09:21, "Yuji Shimada" wrote: > > > > > > > > > > >> To be honest I am a little confused about what the above maping > > > > > >> is supposed to achive. > > > > > > > > > > > > Please find the attached figure which shows the interrupt routing in > > > > > > xen hypervisor. > > > > > > > > > > The point being to deliberately permute the mapping to try to avoid > > > > > accidental GSI sharing even if there are patterns in DEV:INTX usage (e.g., > > > > > all devs use INTA). > > > > > > > > Thanks for the information, especially the diagram. It is very useful. > > > > > > > > Armed with this new kowledge I have a few questions. > > > > > > > > 1. Shimada-san stated that shared GSI are not permitted for > > > > pass-through devices. Is it permitted for a GSI to be shared > > > > between a pass-through device and a non-pass-through device? > > > > > > Yes, it is permitted. But guest software will receive spurious > > > interrupt. So it is not good. > > > > Ok, so it would be good to avoid if possible. > > > > > > The current scheme seems to leave scope for this as > > > > > > > > gsi 6 A = gsi 13 D = gsi 21 C = gsi 29 B > > > > gsi 7 A = gsi 14 D = gsi 22 C = gsi 30 B > > > > > > Do you mean this? > > > > > > Dev 6 INTA = Dev 13 INTD = Dev 21 INTC = Dev 29 INTB -> GSI 40 > > > Dev 7 INTA = Dev 14 INTD = Dev 22 INTC = Dev 30 INTB -> GSI 44 > > > > Yes, that is what I meant. > > > > > > 2. In several places in ioemu:io/passthrough.c e_intx is set to 0, > > > > corresponding to INTA. Is this because it is virtual and > > > > using INTA is convenient? Or is it because it is assumed > > > > that the physical device being passed-through is a 0 function > > > > (and 0 functions always use INTA) ? > > > > > > INTx is virtualized, because the single function device normally use > > > INTA. > > > > Suppose the case where 00:1d.0 has INTA and 00:1d.1 has INTB, > > and both these functions are passed-trhough into a guest > > without any of my patches applied. In the guest 00:1d.0 will > > appear as 00:06.0 with INTA. And 00:1d.1 will apepar as > > 00:06.1 with INTA. Is this ok? > > 00:1d.1 with INTB will appear as 00:07.0 with INTA, when we use > current xen. Thanks, my understanding of the code seems to be correct :-) -- Simon Horman VA Linux Systems Japan K.K., Sydney, Australia Satellite Office H: www.vergenet.net/~horms/ W: www.valinux.co.jp/en