On 17/03/2022 17:52, Jason Andryuk wrote:
> I shut down a domU (HVM dom9 w/ Linux stubdom dom10) with a single PCI
> device assigned. Xen logged the following Flask denial for a second
> PVH dom5 (uivm) without any PCI devices assigned. This is Xen 4.14.4.
>
> (XEN) avc: denied { remove_irq } for domid=5 irq=17
> scontext=system_u:system_r:uivm_t
> tcontext=system_u:object_r:shared_irq_t tclass=resource
>
> Domain 5 as uivm_t and irq 17 as shared_irq_t both look correct. But
> it doesn't make sense that uivm would make a hypercall for an irq.
>
> Could this be from RCU calling complete_domain_destroy() when current
> is dom5 (uivm)? What would current be set to when RCU runs its
> callbacks?
RCU runs in softirq context, so yes - (almost) any use of current would
be bogus.
But I can't spot any overlap between the physdevop_unmap_pirq XSM check,
and complete_domain_destroy().
Any chance you can reproduce this with a WARN() in the AVC denied path,
so we can see what's going on here?
~Andrew
