Re: [Xen-devel] [PATCH v5 4/6] xen/x86: Allow stubdom access to irq created for msi.

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Sun, Jul 21, 2019 at 07:05:16PM +0100, Julien Grall wrote:
> Hi,
> 
> On 7/20/19 10:21 PM, Marek Marczykowski-Górecki wrote:
> > On Sat, Jul 20, 2019 at 05:48:56PM +0100, Julien Grall wrote:
> > > Hi,
> > > 
> > > Sorry for jumping late in the discussion.
> > > 
> > > On 7/17/19 2:00 AM, Marek Marczykowski-Górecki wrote:
> > > > diff --git a/xen/include/xen/irq.h b/xen/include/xen/irq.h
> > > > index 586b783..c7a6a83 100644
> > > > --- a/xen/include/xen/irq.h
> > > > +++ b/xen/include/xen/irq.h
> > > > @@ -91,6 +91,7 @@ typedef struct irq_desc {
> > > >        spinlock_t lock;
> > > >        struct arch_irq_desc arch;
> > > >        cpumask_var_t affinity;
> > > > +    domid_t creator_domid; /* weak reference to domain handling this 
> > > > IRQ */
> > > 
> > > This x86 only. Can this be moved in arch_irq_desc to avoid increasing the
> > > structure on Arm?
> > 
> > How (if at all) PCI passthrough is supported on ARM? Is qemu involved?
> > If so, and if that qemu would be isolated in stubdomain, I think ARM
> > would need a similar feature. If it not the case right now, but it is
> > planned, do you think it's worth moving it to arch_irq_desc and possibly
> > move back later?
> 
> PCI passthrough is not yet supported on Arm. However, I would not expect
> QEMU to be involved at all for Arm.
> 
> In any case, I would still prefer to keep field in arch_irq_desc until we
> see any usage on Arm.

I'm fine with putting it inside of the arch struct, but there's
nothing x86 specific about this field. Regardless of whether you use
QEMU or something different, if you want to allow passthrough on ARM
from domains != dom0 you will need this field anyway, so that the
domain running the passthrough emulator can properly manage interrupts
on behalf of the guest.

If you only plan to support something like vPCI inside of Xen then I
guess there's no need for the field, since Xen is always going to be
the one doing the passthrough.

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel