Re: [PATCH 2/6] x86/pass-through: no locking around pt_irq_{create,destroy}_bind()

[Roger Pau Monné <roger@xxxxxxxxxxxxxx>]

On Tue, Sep 08, 2026 at 03:01:51PM +0200, Jan Beulich wrote:
> The questionable use of pcidevs_lock() there was discussed more than once.
> It really is pointless: The functions synchronize primarily via the per-
> domain event lock. They also may already be called with the global PCI
> devices lock not held: See hvm/vmsi.c:vpci_msi_update(),
> hvm/vmsi.c:vpci_msi_arch_update(), and hvm/vmsi.c:vpci_msi_disable().
> 
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -636,10 +636,7 @@ long arch_do_domctl(
>              ret = -EPERM;
>          else if ( is_iommu_enabled(d) )
>          {
> -            pcidevs_lock();
>              ret = pt_irq_create_bind(d, bind);
> -            pcidevs_unlock();

pt_irq_create_bind() might call into msixtbl_pt_register() which
requires either the pcidevs_lock() or the per-domain d->pci_lock lock
to be taken, which I think is not the case in the context here?

Adding such locking aroiund the calls would mimic the vPCI context,
where d->pci_lock is also taken while executing the vPCI handlers.

Thanks, Roger.