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