RISC-V Virtualization

RISC-V IOMMU v6: IMSIC MSI Remapping Turns On IOMMU_DMA and VFIO Device Assignment

📅 2026-10-04 ⏱ 6 min read 🔗 Source: LKML (Sep 25 2026, Andrew Jones)

On Friday 25 September 2026, Andrew Jones posted [PATCH v6 00/16] iommu/riscv: Enable MSI remapping, IOMMU_DMA and VFIO to the Linux kernel mailing list. The series carries 13 patches from Jones and 3 from Tomasz Jeznach, touching 22 files with 646 insertions and 127 deletions.

The one-line summary: it adds MSI remapping for IMSIC so that a device's MSI target address is translated the same way its DMA is, which in turn lets RISC-V enable IOMMU_DMA and paging domains by default. For anyone trying to hand a PCIe device to a RISC-V virtual machine, this is the missing plumbing.

Honesty note. This is a v6 posting to LKML, not a merge. It has picked up Reviewed-by and Tested-by tags and has addressed review comments from Anup Patel, but it is not upstream, is not in any released kernel, and carries no performance measurements. Timeline to mainline is not stated. Read nothing here as "RISC-V supports VFIO device assignment today".

Why MSI Remapping Is the Hard Part

On most architectures, an MSI is just a write to a physical address. Under an IOMMU, that breaks: a device behind an IOMMU writes I/O virtual addresses, not physical ones, so the interrupt target address has to be translated too.

RISC-V has an extra wrinkle. The IMSIC MSI target address changes with interrupt affinity — move an interrupt to another CPU and the target page changes. That means the translation cannot be a single static mapping.

The v1 approach (May 2026) used get_resv_regions() with IOMMU_RESV_DIRECT_RELAXABLE to identity-map IMSIC pages, and was rejected as a workaround. Versions 2 through 4 (August 2026) introduced a dedicated RISC-V IOMMU IRQ domain that pre-mapped every possible IMSIC target and maintained a domain-local physical-to-IOVA table. That worked but was heavy.

The v5/v6 Design

Discussion on v4 with Jason Gunthorpe (IOMMU/VFIO maintainer) identified a simpler path: extend the existing iommu_dma_prepare_msi() model to prepare an ordered list of MSI targets as one contiguous IOVA range. v5 was a complete redesign around that idea; v6 adds minor updates.

In the current design:

The IMSIC driver builds an array containing the supervisor IMSIC page for every possible CPU, indexed by logical CPU number.
On IRQ allocation, it passes the whole array to a new iommu_dma_prepare_msi_list() API.
That API maps the ordered physical address list into one contiguous IOVA range, via either DMA-IOMMU or iommufd, then caches the base IOVA and mapping granule in the MSI descriptor.
MSI composition then selects the target CPU with simple arithmetic, including during an affinity change, with no memory allocation and no lookup of IOMMU-owned state in atomic context.

Crucially, v5 and v6 drop the RISC-V IOMMU IRQ domain, the domain-local IMSIC mapping table and the IOMMU lookup during MSI composition. The IMSIC IRQ domain owns the target list and message composition; the IOMMU layers only provide mappings.

Two supporting changes matter operationally. DMA-IOMMU extends its per-page MSI cache to recognise 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 a single unit — so a descriptor's contiguous IOVA stays valid across paging-domain replacement.

VFIO and KVM Enablement

The series also carries the remaining plumbing for PCIe device assignment through VFIO/KVM on RISC-V:

Change	Author	Effect
`vfio: enable IOMMU_TYPE1 for RISC-V`	Jeznach	Classic VFIO type1 container works on RISC-V
`iommu/dma: Enable IOMMU_DMA for 64-bit RISC-V`	Jeznach	DMA-API translation through the IOMMU becomes the default path
`RISC-V: KVM: Enable KVM_VFIO interfaces on RISC-V arch`	Jeznach	KVM can accept assigned devices
`riscv: defconfig: Enable IOMMUFD and VFIO`	Jones	Ships as modules, with cdev support
`selftests/vfio: Allow building on RISC-V`	Jones	kselftest coverage arrives with the feature

Known Limitations, Stated by the Author

Two gaps are documented in the cover letter and should be read before anyone plans a deployment:

The RISC-V IOMMU specification provides no MSI data validation. VFIO device assignment therefore requires the allow_unsafe_interrupts=1 module parameter. That is a real security consideration: a guest can potentially program an MSI with arbitrary data.
Direct MSI routing to guest interrupt files (irqbypass) is not supported by this series and will be posted separately on top.

In v6, Jones also moved the software MSI window from 128 MiB to 16 MiB to avoid colliding with kvmtool's guest IMSIC window, and documented the limitations of using a fixed window in the commit message.

Status

The series has picked up review tags and addressed comments from Anup Patel across its six revisions — v1 (8 May 2026), v2–v4 (20 Aug 2026), v5 (31 Aug 2026), v6 (25 Sep 2026). The author discloses LLM assistance for code exploration, patch review, test execution and commit-message drafting in the cover letter — noted here for transparency; it does not change the technical content.

Builder Takeaways

VFIO passthrough is the last big virtualization gap on RISC-V. KVM runs guests, Xen boots, and this series targets the piece that lets a VM own a real PCIe device.
The design converged the hard way. Reserved-region identity maps (v1) to a dedicated IRQ domain (v2–v4) to a contiguous-IOVA MSI list (v5/v6) — each iteration moved work out of hot paths and closer to how DMA-IOMMU already thinks.
The security caveat is spec-level, not implementation-level. Until the RISC-V IOMMU spec grows MSI data validation, allow_unsafe_interrupts=1 remains the price of assignment — plan threat models accordingly.
Watch for irqbypass as the follow-up. Without it, assigned-device interrupts take the slow composition path; with it, posted interrupts can approach bare-metal latency.

2026 年 9 月 25 日（周五），Andrew Jones 向 Linux 内核邮件列表提交 [PATCH v6 00/16] iommu/riscv: Enable MSI remapping, IOMMU_DMA and VFIO。系列包含 Jones 的 13 个补丁与 Tomasz Jeznach 的 3 个补丁，涉及 22 个文件，新增 646 行、删除 127 行。

一句话概括：为 IMSIC 增加 MSI 重映射，让设备的 MSI 目标地址与其 DMA 一样被翻译，从而让 RISC-V 默认启用 IOMMU_DMA 与分页域。对想把 PCIe 设备直通给 RISC-V 虚拟机的人来说，这就是缺的最后一段管道。

诚实说明。 这是提交到 LKML 的 v6 版本，不是合入。系列已收获 Reviewed-by 与 Tested-by 标签，并吸收了 Anup Patel 的评审意见，但它不在上游、不在任何已发布内核中、也没有任何性能数据。进入主线的时间表未说明。请勿把本文读成"RISC-V 今天就支持 VFIO 设备直通"。

为什么 MSI 重映射是难点

在多数架构上，MSI 只是一次对物理地址的写。而在 IOMMU 之下这行不通：IOMMU 后面的设备写的是 I/O 虚拟地址而非物理地址，所以中断目标地址也必须被翻译。

RISC-V 还有一层额外麻烦：IMSIC 的 MSI 目标地址随中断亲和性变化 —— 把中断挪到另一个 CPU，目标页就变了。这意味着翻译不可能是单一的静态映射。

v1（2026 年 5 月）用 get_resv_regions() 配 IOMMU_RESV_DIRECT_RELAXABLE 把 IMSIC 页恒等映射，被否决为权宜之计。v2–v4（2026 年 8 月）引入了专门的 RISC-V IOMMU IRQ 域，预映射所有可能的 IMSIC 目标并维护一张域内物理地址到 IOVA 的表。能用，但太重。

v5/v6 的设计

v4 阶段与 Jason Gunthorpe（IOMMU/VFIO 维护者）的讨论找到了更简的路：扩展现有 iommu_dma_prepare_msi() 模型，把有序的 MSI 目标列表准备成一个连续 IOVA 区间。v5 围绕这个想法完全重写；v6 只做小幅更新。

当前设计：

IMSIC 驱动为每个可能的 CPU 构建一个数组，按逻辑 CPU 编号索引，存放其 supervisor IMSIC 页。
分配中断时，把整个数组传给新的 iommu_dma_prepare_msi_list() API。
该 API 把有序物理地址列表映射为一个连续 IOVA 区间（经 DMA-IOMMU 或 iommufd），并把基 IOVA 与映射粒度缓存在 MSI 描述符里。
MSI 组合随后用简单算术选择目标 CPU，亲和性变化时也一样，无内存分配、无原子上下文中的 IOMMU 状态查找。

关键在于，v5/v6 去掉了 RISC-V IOMMU IRQ 域、域内 IMSIC 映射表以及 MSI 组合期间的 IOMMU 查找。IMSIC IRQ 域拥有目标列表与消息组合；IOMMU 层只提供映射。

两个配套改动在工程上很重要。DMA-IOMMU 扩展了其按页 MSI 缓存，可识别并复用完整区间。iommufd 按需增长其软件 MSI 位图，把分配限制在保留 MSI 窗口内，并把一个区间的准备、安装、回滚与重放作为单一单元处理 —— 描述符的连续 IOVA 在分页域替换时保持有效。

VFIO 与 KVM 使能

系列还带着 RISC-V 上经 VFIO/KVM 直通 PCIe 设备所需的其余管道：

改动	作者	效果
`vfio: enable IOMMU_TYPE1 for RISC-V`	Jeznach	经典 VFIO type1 容器在 RISC-V 上可用
`iommu/dma: Enable IOMMU_DMA for 64-bit RISC-V`	Jeznach	经 IOMMU 的 DMA-API 翻译成为默认路径
`RISC-V: KVM: Enable KVM_VFIO interfaces on RISC-V arch`	Jeznach	KVM 可接受直通设备
`riscv: defconfig: Enable IOMMUFD and VFIO`	Jones	以模块形式随内核发布，含 cdev 支持
`selftests/vfio: Allow building on RISC-V`	Jones	kselftest 覆盖随功能一起到来

作者明示的已知局限

封面信记录了两处缺口，做部署规划前必须先读：

RISC-V IOMMU 规范不提供 MSI 数据校验。 因此 VFIO 设备直通需要 allow_unsafe_interrupts=1 模块参数。这是真实的安全考量：客户机可能用任意数据编程 MSI。
本系列不支持 MSI 直达客户机中断文件（irqbypass），将另行提交。

v6 中，Jones 还把软件 MSI 窗口从 128 MiB 缩到 16 MiB，避免与 kvmtool 的客户机 IMSIC 窗口冲突，并在提交说明中记录了使用固定窗口的局限。

状态

历经六个版本（v1：2026-05-08；v2–v4：2026-08-20；v5：2026-08-31；v6：2026-09-25），系列已收到评审标签并吸收了 Anup Patel 的意见。作者在封面信中披露使用 LLM 辅助代码探索、补丁评审、测试执行与提交说明撰写 —— 此处如实记录，不影响技术内容。

开发者要点

VFIO 直通是 RISC-V 虚拟化最后一块大拼图。 KVM 能跑客户机、Xen 能启动，而这一系列瞄准的是让虚拟机真正拥有一块 PCIe 设备的那一环。
设计是艰难收敛出来的。 保留区恒等映射（v1）到专用 IRQ 域（v2–v4）再到连续 IOVA 的 MSI 列表（v5/v6）—— 每一轮迭代都把工作从热路径上挪走，向 DMA-IOMMU 既有思维靠拢。
安全告警是规范级的，不是实现级的。 在 RISC-V IOMMU 规范长出 MSI 数据校验之前，allow_unsafe_interrupts=1 仍是直通的入场费 —— 威胁模型请照此规划。
关注 irqbypass 后续。 没有它，直通设备中断走慢速组合路径；有了它，posted interrupt 可逼近裸金属延迟。

Краткое содержание (RU)

25 сентября 2026 года Andrew Jones опубликовал v6 серии из 16 патчей «iommu/riscv: Enable MSI remapping, IOMMU_DMA and VFIO» (13 патчей Jones, 3 — Tomasz Jeznach; 22 файла, +646/−127). Суть: ремепинг MSI для IMSIC, чтобы целевой адрес MSI транслировался так же, как DMA. Дизайн v5/v6: IMSIC-драйвер передаёт список страниц всех возможных CPU в новый API iommu_dma_prepare_msi_list(), который отображает их в один непрерывный диапазон IOVA; выбор конечного CPU сводится к простой арифметике. Серия также включает IOMMU_TYPE1 для VFIO, IOMMU_DMA для 64-битного RISC-V и KVM_VFIO. Оговорки: спецификация RISC-V IOMMU не проверяет данные MSI — нужен allow_unsafe_interrupts=1; irqbypass не поддерживается. Не слито, это v6 на реконсидерации.

Resumen (ES)

El 25 de septiembre de 2026, Andrew Jones publicó la v6 de la serie de 16 parches «iommu/riscv: Enable MSI remapping, IOMMU_DMA and VFIO» (13 parches de Jones, 3 de Tomasz Jeznach; 22 archivos, +646/−127). La idea: remapear MSI para IMSIC, de modo que la dirección objetivo de un MSI se traduzca igual que su DMA. El diseño de v5/v6: el driver IMSIC pasa la lista de páginas de todos los CPU posibles al nuevo API iommu_dma_prepare_msi_list(), que las mapea en un único rango contiguo de IOVA; elegir el CPU destino queda reducido a aritmética simple. La serie añade además IOMMU_TYPE1 para VFIO, IOMMU_DMA para RISC-V de 64 bits y KVM_VFIO. Advertencias: la especificación RISC-V IOMMU no valida los datos de MSI — hace falta allow_unsafe_interrupts=1; irqbypass no está soportado. No fusionado: es una v6 en revisión.

Résumé (FR)

Le 25 septembre 2026, Andrew Jones a publié la v6 de la série de 16 patchs « iommu/riscv: Enable MSI remapping, IOMMU_DMA and VFIO » (13 patchs de Jones, 3 de Tomasz Jeznach ; 22 fichiers, +646/−127). L'idée : remapper les MSI pour IMSIC afin que l'adresse cible d'un MSI soit traduite comme son DMA. La conception v5/v6 : le pilote IMSIC transmet la liste des pages de tous les CPU possibles au nouvel API iommu_dma_prepare_msi_list(), qui les mappe en une seule plage d'IOVA contiguë ; choisir le CPU cible se réduit à une simple arithmétique. La série ajoute aussi IOMMU_TYPE1 pour VFIO, IOMMU_DMA pour le RISC-V 64 bits et KVM_VFIO. Réservations : la spécification RISC-V IOMMU ne valide pas les données MSI — allow_unsafe_interrupts=1 est requis ; irqbypass n'est pas pris en charge. Pas fusionné : c'est une v6 en revue.

Kurzfassung (DE)

Am 25. September 2026 veröffentlichte Andrew Jones v6 der 16-Patch-Serie »iommu/riscv: Enable MSI remapping, IOMMU_DMA and VFIO« (13 Patches von Jones, 3 von Tomasz Jeznach; 22 Dateien, +646/−127). Kernidee: MSI-Remapping für IMSIC, damit die Zieladresse eines MSI genauso übersetzt wird wie sein DMA. Das v5/v6-Design: Der IMSIC-Treiber übergibt die Seitenliste aller möglichen CPUs an die neue API iommu_dma_prepare_msi_list(), die sie in einen einzigen zusammenhängenden IOVA-Bereich mappt; die Ziel-CPU-Auswahl reduziert sich auf einfache Arithmetik. Die Serie bringt außerdem IOMMU_TYPE1 für VFIO, IOMMU_DMA für 64-Bit-RISC-V und KVM_VFIO mit. Einschränkungen: Die RISC-V-IOMMU-Spezifikation validiert keine MSI-Daten — allow_unsafe_interrupts=1 ist nötig; irqbypass wird nicht unterstützt. Nicht gemerged — eine v6 im Review.

خلاصه (FA)

در ۲۵ سپتامبر ۲۰۲۶، Andrew Jones نسخهٔ ششم سری ۱۶ پچی «iommu/riscv: Enable MSI remapping, IOMMU_DMA and VFIO» را منتشر کرد (۱۳ پچ Jones، ۳ پچ Tomasz Jeznach؛ ۲۲ فایل، +۶۴۶/−۱۲۷). ایدهٔ اصلی: بازنگاشت MSI برای IMSIC، تا آدرس هدف MSI همان‌طور ترجمه شود که DMA ترجمه می‌شود. طراحی v5/v6: درایور IMSIC فهرست صفحه‌های همهٔ CPUهای ممکن را به API تازهٔ iommu_dma_prepare_msi_list() می‌دهد و آن API همه را به یک بازهٔ پیوستهٔ IOVA نگاشت می‌کند؛ انتخاب CPU هدف به حساب ساده فرو می‌کاهد. این سری IOMMU_TYPE1 برای VFIO، IOMMU_DMA برای RISC-V ۶۴ بیتی و KVM_VFIO را نیز می‌آورد. هشدارها: مشخصات RISC-V IOMMU داده‌های MSI را اعتبارسنجی نمی‌کند — allow_unsafe_interrupts=1 لازم است؛ irqbypass پشتیبانی نمی‌شود. ادغام نشده — یک v6 در حال بازبینی است.

Sources / 参考来源

← Back to Tech Blog