Re: [PATCH 3/7] vfio/pci: Add qcom-vfio-pci variant driver

[Jose Ignacio Tornos Martinez <jtornosm@redhat.com>]

Hi Jason,

Thank you for the review.

You're right that the commit message should better explain the current
driver behavior. The flow today is:

1. Linux allocates MSI-X vectors (standard PCI MSI-X table)
2. The Qualcomm firmware has its own interrupt controller with
   private registers that need to be programmed with MSI addr/data
3. The ath11k/ath12k driver extracts the addr/data from the MSI
   descriptor and programs the firmware's private registers
4. In a VM, the driver only sees virtual (IOVA) addr/data, but
   the firmware's private writes bypass the IOMMU, so they need
   the physical host values

I'll improve the commit message.

Regarding platform_device_msi_init_and_alloc_irqs(), I agree that
moving the driver to device MSI domains would be cleaner on the
driver side. However, even with that change, I think the VM problem
remains exactly the same: the device MSI domain in the VM would
allocate virtual addr/data pairs, and the firmware's private interrupt
controller still needs the physical host values. The problem is not
how the driver allocates MSI vectors, but that the firmware writes
to its own registers bypassing the IOMMU.

Also, the VFIO variant driver scheme would not fully break if the
driver moved to device MSI domains. The variant driver caches host
MSI values from the MSI descriptor, regardless of the allocation
method. The hook point may need adaptation, but the fundamental
approach (host caches physical values, VM reads them) remains valid.

Regarding the hypercall idea for device MSI domains, I think that
would be an interesting direction worth exploring as a generic
solution, but that's a multi-subsystem effort that will take time to
design and land. If there is any existing work or design discussion
in this direction, I'd be happy to look into it and contribute.
In the meantime, the VFIO variant driver provides an immediate path
for users with deployed hardware, using an established kernel
pattern. For now, it could coexist and be replaced later on when
everything is ready.

I completely agree that this could theoretically affect any device
with private MSI registers. However, in practice, I'm only aware of
this specific behavior in Qualcomm ath11k/ath12k firmware, where the
device's interrupt controller requires the host physical MSI
addresses to be programmed directly. I haven't seen this in other
devices, which is why I think a device-specific approach seems
appropriate, and the VFIO variant driver pattern fits well for this,
following the same pattern as mlx5-vfio-pci and nvgrace-gpu for
their own device-specific needs. I'd be happy to incorporate any
ideas or suggestions to improve the approach, make it acceptable,
and allow finally to use these devices from VMs.

It's also worth noting that the PCI reset support for these devices
has already landed in linux-next (commit 290153d46d1a "PCI: Add
device-specific reset for Qualcomm devices") [1], solving the
device reset path for VFIO passthrough. This MSI series is the
remaining piece, with both in place, these Qualcomm WiFi devices
would be fully operational in VMs for the first time.

[1] https://lore.kernel.org/all/20260721081301.205374-1-jtornosm@redhat.com/

Thanks

Best regards
Jose Ignacio