Re: [Xen-devel] [rfc 00/18] ioemu: use devfn instead of slots as the unit for passthrough

[Simon Horman <horms@xxxxxxxxxxxx>]

On Mon, Feb 23, 2009 at 05:39:52PM +0900, Yuji Shimada wrote:
> On Mon, 23 Feb 2009 17:55:30 +1100
> Simon Horman <horms@xxxxxxxxxxxx> 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 <horms@xxxxxxxxxxxx> wrote:
> > > 
> > > > On Thu, Feb 19, 2009 at 09:38:24AM +0000, Keir Fraser wrote:
> > > > > On 19/02/2009 09:21, "Yuji Shimada" <shimada-yxb@xxxxxxxxxxxxxxx> 
> > > > > 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


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