Re: [PATCH v5 00/17] iommu/riscv: Enable MSI remapping, IOMMU_DMA and VFIO

[fangyu.yu@linux.alibaba.com]

>This series adds MSI remapping for IMSIC so a device's MSI target gets
>translated the same way its DMA does, allowing RISC-V to enable IOMMU_DMA
>and paging domains by default.
>
>v1[1] used get_resv_regions() with IOMMU_RESV_DIRECT_RELAXABLE to identity
>map IMSIC pages, but that was rejected as only a workaround. v2 through
>v4[2] instead introduced a RISC-V IOMMU IRQ domain which pre-mapped every
>possible IMSIC target and maintained a domain-local PA-to-IOVA table. The
>v4 discussion with Jason identified a simpler way to handle the RISC-V
>requirement that the MSI target address changes with interrupt affinity:
>extend the existing iommu_dma_prepare_msi() model to prepare an ordered
>list of MSI targets as one contiguous IOVA range. v5 is a complete redesign
>around that approach.
>
>The IMSIC driver now builds an array containing the supervisor IMSIC page
>for every possible CPU, indexed by logical CPU number. When allocating an
>IRQ, it passes the complete array to iommu_dma_prepare_msi_list(). The new
>API maps the ordered physical address list into one contiguous IOVA range
>through either DMA-IOMMU or iommufd, then caches the base IOVA and mapping
>granule in the MSI descriptor. MSI composition can therefore select the
>target for the current CPU with simple arithmetic, including during an
>affinity change, without allocating memory or consulting IOMMU-owned state
>in atomic context.
>
>DMA-IOMMU extends its existing per-page MSI cache to recognize and reuse
>complete ranges. iommufd grows its software-MSI bitmap on demand, bounds
>allocations to the reserved MSI window, and prepares, installs, rolls back,
>and replays a range as one unit. This keeps the descriptor's contiguous
>IOVA valid across iommufd paging-domain replacement without exposing a
>partially installed range.
>
>Unlike v4, v5 has no RISC-V IOMMU IRQ domain, no domain-local IMSIC mapping
>table, and no IOMMU lookup during MSI composition. The IMSIC IRQ domain
>owns the target list and message composition, while the IOMMU layers only
>provide the mappings. Devices which do not need IOMMU MSI translation keep
>using physical MSI addresses through the same IMSIC path.
>
>The series also carries the remaining plumbing needed for RISC-V PCIe
>device assignment through VFIO/KVM: the RISC-V IOMMU reports DMA
>cache-coherency capability for coherent devices, VFIO type1 and KVM_VFIO
>are enabled for RISC-V, defconfig enables IOMMUFD/VFIO as modules with cdev
>support, and the generic VFIO/iommufd selftests can be built for RISC-V.
>The RISC-V IOMMU specification does not provide MSI data validation, so
>VFIO device assignment requires the applicable allow_unsafe_interrupts=1
>module parameter. Direct MSI routing to guest interrupt files (irqbypass)
>is not yet supported by this series and will be posted separately on top.
>

Hi Andrew:

I tested this on riscv64 QEMU with an emulated NVMe device and e1000e
network adapter. The fio and iperf3 tests both completed successfully,
and the interrupt status was as expected.

For this series
Tested-by: Fangyu Yu <fangyu.yu@linux.alibaba.com>

>LLM-based coding assistants were used during development for code
>exploration, patch review, test execution, and drafting and editing
>commit messages and this cover letter. I reviewed and finalized all
>resulting code and text. Per-patch Assisted-by tags are omitted in
>light of ongoing discussions about simplifying coding-assistant
>attribution.
>
>Thanks,
>drew
>
>[1] https://lore.kernel.org/all/20260508212339.381933-1-andrew.jones@oss.qualcomm.com/
>[2] https://lore.kernel.org/all/20260820214150.545737-1-andrew.jones@oss.qualcomm.com/
>