Re: [Xen-devel] [RFC 06/19] xen/arm: Implement hypercall PHYSDEVOP_map_pirq

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2014-07-03 at 13:02 +0100, Julien Grall wrote:
> >>> Handling virq != pirq will be more complex as we need to take into
> >>> account of the hotplug solution.
> > 
> > What's the issue here? Something to do with irqdesc->irq-pending lookup?
> > 
> > Seems like irqdesc needs to store the domain and virq number when the
> > irq is passed through. I assume it must store the dmain already.
> 
> The issues are mostly:
>       - we need to defer the vGIC IRQs allocation
>       - Add a new hypercall to setup the number of IRQs
>       - How do we handle hotplug?

Those all sound like issues with having dynamic numbers of irqs, rather
than with a non-1:1 virq<->pirq mapping per-se.

> >>> The vgic has a register which provide the number of lines, I suspect
> >>> this number can't grow up while the guest is running.
> >>
> >> Of course not. But keep in mind that for non-PCI passthrough we would be
> >> fully aware of all the assigned interrupts before starting the VM.
> > 
> > Are we ruling out hotplug of such devices? (I don't have a problem with
> > that BTW)
> > 
> >> PCI passthrough and MSI-X are the issue because there can be many MSI
> >> per device and the device can be hotplugged into the guest.
> > 
> > MSI(-X) AKA LPIs are in a different more dynamic number space though
> > (from 8192 onwards). I think for that specific case we can dynamically
> > do things.
> > 
> > The bigger issue would be the legacy INT-x interrupts (which I expect
> > look like SPIs), those would no doubt need exposing somehow.
> 
> INT-x is shared between different PCI and this will means lots of rework
> in the interrupt code (mostly now with the no maintenance interrupt
> series). I hope we won't have to handle them.

I've no idea what PCI on ARM is going to be like in this respect. Xgene
PCI controller exports them though and I suppose if the h/w wants to
support all PCI devices it might be needed.

Not sure how PCI-X changes that though.

> 
> > Do we think it is the case that we are eventually going to need a guest
> > cfg option pci = 0|1? I think the answer is yes. Assinging a pci device
> > would cause pci=1, or you can set pci=1 to enable hotplug of pci devices
> > later (i.e. mmio space is reserved, INTx interrupts are assigned etc).
> 
> I'm not sure to understand what we would need a "pci" cfg option... For
> now, this series doesn't aim to support PCI. So I think we could defer
> this problem later.

Yeah, we got onto PCI somehow.

So long as we are happy not being able to hotplug platform devices I
think we don't need an equivalent option (the point would be to only
setup huge numbers of SPIs, reserve MMIO space etc if it was going to be
used).



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel