[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Thu, Feb 28, 2019 at 03:50:14AM -0700, Jan Beulich wrote:
> >>> On 27.02.19 at 16:18, <marmarek@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> > On Wed, Feb 27, 2019 at 04:07:54AM -0700, Jan Beulich wrote:
> >> >>> On 08.02.19 at 11:17, <marmarek@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> >> > @@ -190,19 +190,19 @@ int create_irq(nodeid_t node)
> >> >          desc->arch.used = IRQ_UNUSED;
> >> >          irq = ret;
> >> >      }
> >> > -    else if ( hardware_domain )
> >> > +    else if ( dm_domain )
> >> >      {
> >> > -        ret = irq_permit_access(hardware_domain, irq);
> >> > +        ret = irq_permit_access(dm_domain, irq);
> >> 
> >> Doesn't this imply that Dom0 has no way of cleaning up after the
> >> guest/stubdom pair? IOW I wonder whether both dm and hwdom
> >> should be granted access.
> > 
> > See discussion with Roger on this very patch.
> > In short: since permissions are stored in domain struct, not irq, there
> > is not much to cleanup after domain destruction.
> 
> My point wasn't about cleaning up permissions, but about cleaning
> up the IRQs. Dom0 can't do anything with them without being
> given permission.

Irqs should be cleaned up by the domain model in case of hot-unplug,
or by Xen when the domain is destroyed and the device is deassigned.
This will be fixed by the Intel patches posted by Chao IIRC.

AFAICT this is no different from when the device model in dom0 crashes
and Xen has to perform the clean up of MSI/MSI-X irqs, since neither
pciback, nor the toolstack know anything about those irqs.

Thanks, Roger.

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.