[PW_SID:1149352] iommu/riscv: Enable MSI remapping, IOMMU_DMA and VFIO - #2508
[PW_SID:1149352] iommu/riscv: Enable MSI remapping, IOMMU_DMA and VFIO#2508linux-riscv-bot wants to merge 24 commits into
Conversation
…_RWX When CONFIG_STRICT_MODULE_RWX is not set, execmem cannot create temporary writable mappings for read-only executable pages. In this case, the execmem ranges must already have writable permissions. Currently EXECMEM_KPROBES unconditionally uses PAGE_KERNEL_READ_EXEC, which causes kprobe instruction slot writes to trigger page faults on systems where CONFIG_STRICT_MODULE_RWX is not enabled. Fix this by using PAGE_KERNEL_EXEC when CONFIG_STRICT_MODULE_RWX is not available. Signed-off-by: Xiaofeng Yuan <xiaofengmian@163.com> Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Nam Cao <namcao@linutronix.de> Link: https://patch.msgid.link/20260814082742.148403-2-xiaofengmian@163.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
patch_map() always creates a temporary writable mapping via fixmap for kernel text addresses, even when CONFIG_STRICT_KERNEL_RWX is disabled and the kernel text is already mapped with _PAGE_WRITE. This is unnecessary overhead at best, and on minimal configurations it can cause page faults. Skip the fixmap path for kernel text when CONFIG_STRICT_KERNEL_RWX is not enabled, since the text pages are already writable in that case. The module text path is already gated on CONFIG_STRICT_MODULE_RWX and is kept unchanged. Reported-by: Klara Modin <klara@kasm.eu> Closes: https://lore.kernel.org/all/ant_8TaBbov_GS4i@soda.int.kasm.eu/ Reported-by: Lad Prabhakar <prabhakar.csengg@gmail.com> Closes: https://lore.kernel.org/all/CA+V-a8tQK8rih9SGGTyqrEBGpNkx4H0eX2YccCRrgkVAPr+EBg@mail.gmail.com/ Tested-by: Klara Modin <klarasmodin@gmail.com> Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://patch.msgid.link/20260814082742.148403-3-xiaofengmian@163.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
struct iommufd_sw_msi_maps uses a fixed 64-bit bitmap, limiting each group and hardware page table to 64 software MSI mappings. RISC-V interrupt remapping needs a mapping for every possible CPU, so this limit is insufficient. Make the bitmap grow on demand and treat IDs beyond its current size as absent. Cap it at 16K entries to bound allocation size while leaving ample room for expected software MSI users. Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
Add a descriptor-free counterpart to iommufd_sw_msi(). The existing function is tied to a struct msi_desc and stores the result in the descriptor. This variant returns the IOVA directly so callers can pre-map MSI targets before any descriptor has been allocated. Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
Add a descriptor-free counterpart to iommu_dma_sw_msi(). The existing function is tied to a struct msi_desc and stores the result in the descriptor. This variant returns the IOVA directly so callers can pre-map MSI targets before any descriptor has been allocated. Callers may pass a required mapping size so MSI doorbells that must not share a larger IOMMU leaf, such as RISC-V IMSIC files, can fail before a mapping is installed. Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
Interrupt-remapping drivers may need to map MSI targets before any MSI descriptor exists and retain their own PA-to-IOVA lookup table. Add iommu_dma_map_msi() to return the IOVA and mapping granule for both DMA-IOMMU and iommufd domains. Allow callers to require an exact mapping size. This prevents doorbells such as RISC-V IMSIC files from sharing a larger IOMMU leaf. Building a table requires the domain to remain stable across every mapping. The IOMMU group mutex provides that serialization, but its structure is private to the core. Expose lock helpers and a scoped guard so external callers can hold it for the complete operation. Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
Interrupt-remapping drivers may need to prepare software MSI mappings for an incoming domain from their attach_dev() callback. At that point the device is not yet attached to the supplied domain and, for an iommufd replacement, the current attach handle still describes the old domain. Document that iommu_dma_map_msi() supports this use. Clarify the DMA backend only requires a compatible device and that the iommufd backend intentionally combines context from the current handle with the explicitly supplied destination HWPT. Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
Add a bus token for MSI domains that remap interrupts, needed by the upcoming RISC-V IOMMU interrupt-remapping domain to distinguish itself from NEXUS domains. The token is generic because remapping itself is the only property that needs to be conveyed -- there is nothing RISC-V-specific about it. Such a domain implements init_dev_msi_info() via msi_parent_init_dev_msi_info(), which leaves 'domain' pointing at the NEXUS domain while 'real_parent' points at the remap domain itself. Accept that combination in msi_lib_init_dev_msi_info(); no other msi-lib changes are needed. Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com> Reviewed-by: Nutty Liu <nutty.liu@hotmail.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
imsic_irq_set_affinity() currently writes a newly composed MSI message directly to the device. This bypasses intermediate irqdomains, so an IOMMU remapping domain cannot translate the target after an affinity change. Compose affinity updates from the top of the hierarchy instead. This allows each intermediate domain to update the message and any descriptor state before the device is programmed. Non-atomic moves temporarily use the old address with the new interrupt ID before switching to the new vector. Preserve that transition by composing the temporary message before publishing the new vector, then compose the final message after publishing it, but before the old vector is retired. Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
Create a per-device MSI parent domain as a hook for interrupt remapping. Keep the remapping tables with the attached paging domain because MSI IOVA mappings are part of its page tables. Initially, the new domain only forwards operations to its parent. Later commits add MSI target mappings for paging domains, while non-paging domains continue to use physical IMSIC addresses. Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
Platform devices receive their MSI domain when they are created. On RISC-V, the IMSIC is itself a platform device, so consumer devices may be created before the IMSIC driver registers its MSI domain. fw_devlink delays consumer driver probing but does not refresh dev->msi.domain, leaving it NULL when the IOMMU probe_device callback runs. Refresh the OF or ACPI platform MSI domain before creating the per-device interrupt-remapping domain. Leave PCI devices alone because PCI establishes their MSI domain during device setup. This mirrors the workaround currently used by other RISC-V platform MSI consumers. A proposed driver-core change would perform the refresh from platform_dma_configure(), but until that is merged the local refresh avoids silently skipping interrupt-remapping setup. Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
An upcoming compose_msi_msg() implementation reads info->domain from potentially atomic context, concurrent with domain switches. Apply RCU in preparation. Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
iommufd requires an IOMMU_RESV_SW_MSI region to allocate stable IOVAs for MSI targets. Advertise such a region when the device uses an IMSIC MSI hierarchy so interrupt remapping can map IMSIC pages instead of falling back to physical addresses. Reserve one page per possible CPU, sufficient for each supervisor IMSIC page. Place the window at 128 MiB, matching the established ARM SMMU MSI IOVA convention rather than introducing an architecture-specific choice. Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
IMSIC target addresses change with interrupt affinity, which may be updated in atomic context. Therefore, an interrupt-remapping domain cannot create mappings on demand while composing an MSI message. Pre-map the supervisor IMSIC page for each possible CPU when a paging domain first allocates remapped interrupts. Also prepare the mappings when attaching a paging domain to a device with allocated interrupts, so an incoming domain is ready before the hardware switches to it. Reject passthrough mapping results because interrupt remapping requires the IMSIC page IOVA and its fixed page shift. Store the resulting IOVAs in a domain-local table so message composition only requires a lookup. Use the IMSIC group and hart fields as the table index, matching the RISC-V IOMMU MSI address extraction scheme. These topology fields do not necessarily produce dense CPU indices, so size the table for their full encoded range and leave unused entries empty. Create the per-device interrupt-remapping domain during IOMMU probe, but publish it from probe_finalize() after the IOMMU core has assigned the device to its group. This ensures the allocation callback can safely lock the group. Select IRQ_MSI_IOMMU for the generic MSI mapping API. Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
MSI IOVAs belong to a paging domain, but iommufd may replace a device's domain while its interrupts remain allocated. Waiting for another IRQ allocation to populate the new table would leave existing interrupts without valid MSI IOVAs. Track live IRQ allocations so the attach path knows when the incoming domain needs an MSI IOVA table. Rebuild the table through iommu_dma_map_msi(), allowing each backend to preserve its own IOVA allocation rules. Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
MSI composition may run concurrently with a domain switch and derives the target address from the attached domain. A stale domain read across a direct paging-to-identity or identity-to-paging transition can select the wrong addressing mode, so reject these transitions while IRQs remain allocated. Keep the blocking domain available as an immediate fail-stop mode. Since it does not retain the previous translation mode, transitions through it cannot be checked reliably and still require callers to quiesce MSI state. Paging-to-paging replacement remains supported because the new domain's MSI IOVA table is prepared before attachment. Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
Translate composed IMSIC target addresses through the attached paging domain's pre-mapped IOVA table. This keeps affinity updates on the interrupt hierarchy while directing device MSI writes through the IOMMU. MSI composition may run in atomic context, so publish each fully built table with release ordering and consume it with acquire ordering under RCU. This permits lockless lookup without exposing incomplete table state. When no translated table is available, retain the physical IMSIC target for domains that do not use MSI address translation. Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
Enable IOMMU_DMA for 64-bit RISC-V now that the RISC-V IOMMU driver supports MSI remapping. Signed-off-by: Tomasz Jeznach <tjeznach@rivosinc.com> Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
VFIO and iommufd require IOMMU_CAP_CACHE_COHERENCY because they use IOMMU_CACHE mappings and have no userspace cache-maintenance path. RISC-V page tables preserve physical memory attributes for IOMMU_CACHE mappings. Svpbmt marks mappings without IOMMU_CACHE as non-cacheable, but preserving physical attributes cannot make a noncoherent device path coherent. Report the capability only for devices marked DMA coherent. This limits userspace assignment to paths that can honor cacheable mappings. Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
Enable VFIO support on RISC-V architecture, now that the RISC-V IOMMU driver reports the IOMMU_CAP_CACHE_COHERENCY capability VFIO_TYPE1 and iommufd both require before allowing a device to be bound. Signed-off-by: Tomasz Jeznach <tjeznach@rivosinc.com> Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com> Reviewed-by: Nutty Liu <nutty.liu@hotmail.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
Enable KVM/VFIO support on RISC-V architecture, now that VFIO device assignment is available on RISC-V through VFIO_IOMMU_TYPE1, so a RISC-V KVM guest can be notified about VFIO-assigned devices. Signed-off-by: Tomasz Jeznach <tjeznach@rivosinc.com> Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com> Reviewed-by: Nutty Liu <nutty.liu@hotmail.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
Enable iommufd and VFIO in the default configuration now that the RISC-V IOMMU provides the DMA and MSI remapping needed for userspace device access, including assignment to virtual machines. Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
The generic VFIO selftests, including iommufd coverage, require no RISC-V-specific source changes. Include riscv64 in their build list. Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
bb1a926 to
6f6f7c0
Compare
|
Patch 1: "[v4,01/21] iommufd: Convert struct iommufd_sw_msi_maps to a growable bitmap" |
|
Patch 1: "[v4,01/21] iommufd: Convert struct iommufd_sw_msi_maps to a growable bitmap" |
|
Patch 1: "[v4,01/21] iommufd: Convert struct iommufd_sw_msi_maps to a growable bitmap" |
|
Patch 1: "[v4,01/21] iommufd: Convert struct iommufd_sw_msi_maps to a growable bitmap" |
|
Patch 19: "[v4,19/21] RISC-V: KVM: Enable KVM_VFIO interfaces on RISC-V arch" |
|
Patch 19: "[v4,19/21] RISC-V: KVM: Enable KVM_VFIO interfaces on RISC-V arch" |
|
Patch 19: "[v4,19/21] RISC-V: KVM: Enable KVM_VFIO interfaces on RISC-V arch" |
|
Patch 19: "[v4,19/21] RISC-V: KVM: Enable KVM_VFIO interfaces on RISC-V arch" |
|
Patch 20: "[v4,20/21] riscv: defconfig: Enable IOMMUFD and VFIO" |
|
Patch 20: "[v4,20/21] riscv: defconfig: Enable IOMMUFD and VFIO" |
|
Patch 20: "[v4,20/21] riscv: defconfig: Enable IOMMUFD and VFIO" |
|
Patch 20: "[v4,20/21] riscv: defconfig: Enable IOMMUFD and VFIO" |
|
Patch 20: "[v4,20/21] riscv: defconfig: Enable IOMMUFD and VFIO" |
|
Patch 20: "[v4,20/21] riscv: defconfig: Enable IOMMUFD and VFIO" |
|
Patch 20: "[v4,20/21] riscv: defconfig: Enable IOMMUFD and VFIO" |
|
Patch 20: "[v4,20/21] riscv: defconfig: Enable IOMMUFD and VFIO" |
|
Patch 20: "[v4,20/21] riscv: defconfig: Enable IOMMUFD and VFIO" |
|
Patch 20: "[v4,20/21] riscv: defconfig: Enable IOMMUFD and VFIO" |
|
Patch 20: "[v4,20/21] riscv: defconfig: Enable IOMMUFD and VFIO" |
|
Patch 20: "[v4,20/21] riscv: defconfig: Enable IOMMUFD and VFIO" |
|
Patch 21: "[v4,21/21] selftests/vfio: Allow building on RISC-V" |
|
Patch 21: "[v4,21/21] selftests/vfio: Allow building on RISC-V" |
|
Patch 21: "[v4,21/21] selftests/vfio: Allow building on RISC-V" |
|
Patch 21: "[v4,21/21] selftests/vfio: Allow building on RISC-V" |
|
Patch 21: "[v4,21/21] selftests/vfio: Allow building on RISC-V" |
|
Patch 21: "[v4,21/21] selftests/vfio: Allow building on RISC-V" |
|
Patch 21: "[v4,21/21] selftests/vfio: Allow building on RISC-V" |
|
Patch 21: "[v4,21/21] selftests/vfio: Allow building on RISC-V" |
|
Patch 21: "[v4,21/21] selftests/vfio: Allow building on RISC-V" |
|
Patch 21: "[v4,21/21] selftests/vfio: Allow building on RISC-V" |
|
Patch 21: "[v4,21/21] selftests/vfio: Allow building on RISC-V" |
|
Patch 21: "[v4,21/21] selftests/vfio: Allow building on RISC-V" |
4 participants
PR for series 1149352 applied to workflow__riscv__fixes
Name: iommu/riscv: Enable MSI remapping, IOMMU_DMA and VFIO
URL: https://patchwork.kernel.org/project/linux-riscv/list/?series=1149352
Version: 4