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?
> 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.
--
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
|
Home