WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Simon Horman <horms@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [rfc 00/18] ioemu: use devfn instead of slots as the unit for passthrough
From: Yuji Shimada <shimada-yxb@xxxxxxxxxxxxxxx>
Date: Mon, 23 Feb 2009 17:39:52 +0900
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Mon, 23 Feb 2009 00:40:29 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20090223065530.GA22192@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20090223151928.84DA.27C06F64@xxxxxxxxxxxxxxx> <20090223065530.GA22192@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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.

> > When we make multi-function cards appear in guests as multi-function
> > cards, it is good that virtual INTx reflects the physical INTx. The
> > reason is one of functions of a device may share INTx of the other
> > function. In my environment, UHCI(00:1d.0) and EHCI(00:1d.7) share the
> > same INTA. If physical functions share physical INTx, virtual
> > functions should share virtual INTx. To achieve this, virtual INTx
> > needs to reflect the physical INTx.
> 
> Understood. The issue of assigning GSIs aside, this should
> be fairly straightforward.
> 
> > >    The latter assumption is not valid because even without my pacthes
> > >    it is possible to pass-through non-0 functions, its just that
> > >    they end up as the 0th function of the virtual slot in the guest.
> > > 
> > > I am now pretty sure that my change leads to incorrect usage of
> > > hvm_pci_intx_gsi(). Answers to the questions above will help me to
> > > understand how trivial to fix this is.
> > > 
> > > The most difficult cases seem to be 1) sharing of gsi between
> > > pass-through and non-pass-through devices is not permitted or 2)
> > > intx used inside ioemu:io/passthrough.c should reflect the physical
> > > intx. In either case I wonder if a reasonable solution would be to
> > > just allocate allocate GSI in a non-colliding manner. Say, GSI 16 for
> > > the first device to ask, 17 for the next one and so on. Or perhaps
> > > the existing hash + overflow to the next GSI on collision.
> > 
> > The another solution is expanding GSI to 127. I don't sure it is
> > possible, but sharing virtual GSI will not occur.
> 
> That thought crossed my mind too, I will investigate further.
> But I think that ideally it would need to be expanded to 143
> as the first 16 GSI are currently reserved for ISA.

That's exactly right.

Thanks,
--
Yuji Shimada

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

<Prev in Thread] Current Thread [Next in Thread>