On 11.03.2026 17:04, Jan Beulich wrote:
> On 09.03.2026 13:31, Julian Vetter wrote:
>> @@ -607,6 +631,83 @@ int dm_op(const struct dmop_args *op_args)
>> break;
>> }
>>
>> + case XEN_DMOP_bind_pt_msi_irq:
>> + {
>> + const struct xen_dm_op_bind_pt_msi_irq *data =
>> + &op.u.bind_pt_msi_irq;
>> + struct xen_domctl_bind_pt_irq bind = {
>> + .machine_irq = data->machine_irq,
>> + .irq_type = PT_IRQ_TYPE_MSI,
>> + };
>> + int irq;
>> +
>> + rc = -EINVAL;
>> + if ( data->pad0 || data->pad1 )
>> + break;
>> +
>> + if ( data->flags & ~XEN_DMOP_MSI_FLAG_UNMASKED )
>> + break;
>> +
>> + irq = domain_pirq_to_irq(d, bind.machine_irq);
>> +
>> + rc = -EPERM;
>> + if ( irq <= 0 || !irq_access_permitted(current->domain, irq) )
>> + break;
>> +
>> + bind.u.msi.gvec = data->gvec;
>> + bind.u.msi.gflags =
>> + msi_addr_to_gflags(data->addr, data->data,
>> + !(data->flags & XEN_DMOP_MSI_FLAG_UNMASKED));
>> + bind.u.msi.gtable = data->gtable;
>> +
>> + rc = -ESRCH;
>> + if ( is_iommu_enabled(d) )
>> + {
>> + pcidevs_lock();
>> + rc = pt_irq_create_bind(d, &bind);
>> + pcidevs_unlock();
>
> I understand the same locking is used at the other call site, but it's as
> questionable there as it is here. We should try hard to avoid use of this
> global lock when something lighter-weight would do.
I should perhaps have added that I have this on my own list of things to look
into, just that I didn't get to it yet.
Jan
