Nonsensical XSM Flask denial

[Jason Andryuk <jandryuk@xxxxxxxxx>]

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?

Thanks,
Jason