Re: [PATCH v4 5/9] x86/passthrough: Introduce pt_irq_bind_msi() as canonical MSI bind path

[Jan Beulich <jbeulich@xxxxxxxx>]

On 27.04.2026 15:54, Julian Vetter wrote:
> @@ -448,13 +451,29 @@ int pt_irq_create_bind(
>      switch ( pt_irq_bind->irq_type )
>      {
>      case PT_IRQ_TYPE_MSI:
> -        return pt_irq_bind_msi(d, pirq,
> -                               pt_irq_bind->u.msi.gvec,
> -                               pt_irq_bind->u.msi.gflags &
> -                                   ~XEN_DOMCTL_VMSI_X86_UNMASKED,
> +    {
> +        uint32_t gflags = pt_irq_bind->u.msi.gflags;
> +        uint64_t msi_addr;
> +        uint32_t msi_data;
> +
> +        msi_addr = MSI_ADDR_HEADER |
> +                   MASK_INSR(MASK_EXTR(gflags, 
> XEN_DOMCTL_VMSI_X86_DEST_ID_MASK),
> +                             MSI_ADDR_DEST_ID_MASK) |
> +                   (gflags & XEN_DOMCTL_VMSI_X86_RH_MASK ?
> +                    MSI_ADDR_REDIRECTION_LOWPRI : MSI_ADDR_REDIRECTION_CPU) |
> +                   (gflags & XEN_DOMCTL_VMSI_X86_DM_MASK ?
> +                    MSI_ADDR_DESTMODE_LOGIC : MSI_ADDR_DESTMODE_PHYS);
> +        msi_data = pt_irq_bind->u.msi.gvec |
> +                   MASK_INSR(MASK_EXTR(gflags, 
> XEN_DOMCTL_VMSI_X86_DELIV_MASK),
> +                             MSI_DATA_DELIVERY_MODE_MASK) |
> +                   (gflags & XEN_DOMCTL_VMSI_X86_TRIG_MASK ?
> +                    MSI_DATA_TRIGGER_LEVEL : 0);
> +
> +        return pt_irq_bind_msi(d, pt_irq_bind->machine_irq,
> +                               msi_addr, msi_data,
>                                 pt_irq_bind->u.msi.gtable,
> -                               !!(pt_irq_bind->u.msi.gflags &
> -                                  XEN_DOMCTL_VMSI_X86_UNMASKED));
> +                               !!(gflags & XEN_DOMCTL_VMSI_X86_UNMASKED));
> +    }
>  
>      case PT_IRQ_TYPE_PCI:
>      case PT_IRQ_TYPE_MSI_TRANSLATE:
> @@ -617,7 +636,6 @@ int pt_irq_create_bind(
>      }
>  
>      default:
> -        write_unlock(&d->event_lock);
>          return -EOPNOTSUPP;
>      }

Just as a preliminary comment, as I had to come look here for patch 2:
With no other locking changes in this function, how can the above be
correct? Does this hunk belong into another patch?

Jan