From: Jason Gunthorpe <jgg@nvidia.com>
To: Andrew Jones <andrew.jones@oss.qualcomm.com>
Cc: linux-riscv@lists.infradead.org, iommu@lists.linux.dev,
linux-kernel@vger.kernel.org, tomasz.jeznach@linux.dev,
tjeznach@rivosinc.com, joro@8bytes.org, will@kernel.org,
robin.murphy@arm.com, pjw@kernel.org, palmer@dabbelt.com,
anup@brainfault.org, tglx@kernel.org, kevin.tian@intel.com,
fangyu.yu@linux.alibaba.com
Subject: Re: [PATCH v4 02/21] iommufd: Add iommufd_sw_map_msi()
Date: Mon, 24 Aug 2026 14:04:17 -0300 [thread overview]
Message-ID: <20260824170417.GR244917@nvidia.com> (raw)
In-Reply-To: <fp5myre5qaersxxshitgoupbzkx2zwo3rsz3q5jfdiarmtwknh@gmfhz3cxuc33>
On Mon, Aug 24, 2026 at 05:43:19PM +0200, Andrew Jones wrote:
> VFIO cannot silently switch back to host delivery. We need plumbing
> to establish a guest-owned MSI mode, preserve and mask the guest
> descriptor across the VFIO vector lifecycle, and stop or reject the
> configuration if that mode cannot be maintained.
Yeah
> The guest descriptor itself is already available in
> kvm_arch_update_irqfd_routing(), so RISC-V still does not need to
> interpret or track the guest IOVA. The IOVA can be written directly to the
> device (since the IOMMU MSI table is pre-populated with all vIMSIC GPAs).
Yeah, and now you are getting in "fun" land about how should
information KVM has get shared with the IRQ subsystem and irqdomains
(?) that need to use it to make decisions.
> Indeed, irq_set_vcpu_affinity() alone will be insufficient for two-stage
> guests due to the VFIO vector lifecycle concerns with guest-owned MSI
> descriptors.
>
> RISC-V does not need S2 page-table mappings for MSIs, though. The VM's
> IMSIC topology identifies the vIMSIC GPAs used to populate the MSI table,
> and an MSI-table match bypasses the normal S2 page table.
Okay, so that's an odd twist, you won't need to get the physical into
the S2 then, but the VMM does need to reserve off a hole in the S2 for
the MSI table to land and manipulate the physical through a parallel
translation mechanism.
Then that means if an irqdomain wraps this translation it is actually
a *per VM* domain with a *per VM* translation, sitting on top of a
bunch of iommufd viommus, somehow. That's feeling pretty weird now.
> I agree there is some new terrain to travel here. It'd be great to discuss
> this at Plumber's.
I would still try to get basic baseline support landed for a 'bare'
translation using a RMR (?). That doesn't require any new inventions
at least.
Then the question of how to support a S1, guest controlled descriptor,
and per-vm vCPU to pCPU remapping table can be clearly articulated..
Jason
next prev parent reply other threads:[~2026-08-24 17:04 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-20 21:41 [PATCH v4 00/21] iommu/riscv: Enable MSI remapping, IOMMU_DMA and VFIO Andrew Jones
2026-08-20 21:41 ` [PATCH v4 01/21] iommufd: Convert struct iommufd_sw_msi_maps to a growable bitmap Andrew Jones
2026-08-20 21:41 ` [PATCH v4 02/21] iommufd: Add iommufd_sw_map_msi() Andrew Jones
2026-08-20 22:09 ` Jason Gunthorpe
2026-08-21 11:07 ` Andrew Jones
2026-08-21 12:02 ` Jason Gunthorpe
2026-08-21 13:47 ` Andrew Jones
2026-08-21 14:00 ` Jason Gunthorpe
2026-08-21 14:23 ` Andrew Jones
2026-08-21 14:31 ` Jason Gunthorpe
2026-08-21 15:18 ` Andrew Jones
2026-08-21 16:12 ` Jason Gunthorpe
2026-08-21 17:12 ` Andrew Jones
2026-08-21 17:20 ` Jason Gunthorpe
2026-08-22 13:50 ` Andrew Jones
2026-08-22 14:06 ` Jason Gunthorpe
2026-08-24 8:50 ` Andrew Jones
2026-08-24 12:52 ` Jason Gunthorpe
2026-08-24 15:43 ` Andrew Jones
2026-08-24 17:04 ` Jason Gunthorpe [this message]
2026-08-25 13:24 ` Andrew Jones
2026-08-25 14:03 ` Jason Gunthorpe
2026-08-25 16:14 ` Andrew Jones
2026-08-25 16:52 ` Jason Gunthorpe
2026-08-25 17:38 ` Andrew Jones
2026-08-25 17:59 ` Jason Gunthorpe
2026-08-26 8:23 ` Andrew Jones
2026-08-20 21:41 ` [PATCH v4 03/21] iommu/dma: Add iommu_dma_sw_map_msi() Andrew Jones
2026-08-20 21:41 ` [PATCH v4 04/21] iommu/dma: Add iommu_dma_map_msi() Andrew Jones
2026-08-20 21:41 ` [PATCH v4 05/21] iommu: Document MSI mapping during domain replacement Andrew Jones
2026-08-20 21:41 ` [PATCH v4 06/21] genirq/msi: Provide DOMAIN_BUS_MSI_REMAP Andrew Jones
2026-08-20 21:41 ` [PATCH v4 07/21] irqchip/riscv-imsic: Compose MSI updates through the hierarchy Andrew Jones
2026-08-20 21:41 ` [PATCH v4 08/21] iommu/riscv: Add IRQ domain for interrupt remapping Andrew Jones
2026-08-20 21:41 ` [PATCH v4 09/21] iommu/riscv: Refresh platform MSI domain before IR setup Andrew Jones
2026-08-20 21:41 ` [PATCH v4 10/21] iommu/riscv: Prepare info->domain for concurrent RCU read access Andrew Jones
2026-08-20 21:41 ` [PATCH v4 11/21] iommu/riscv: Reserve an MSI IOVA window for iommufd Andrew Jones
2026-08-20 21:41 ` [PATCH v4 12/21] iommu/riscv: Pre-map IMSIC MSI targets Andrew Jones
2026-08-20 21:41 ` [PATCH v4 13/21] iommu/riscv: Preserve MSI IOVA state across domain replacement Andrew Jones
2026-08-20 21:52 ` Jason Gunthorpe
2026-08-21 11:14 ` Andrew Jones
2026-08-21 13:22 ` Jason Gunthorpe
2026-08-21 13:56 ` Andrew Jones
2026-08-20 21:41 ` [PATCH v4 14/21] iommu/riscv: Gate direct identity boundary switches with live MSIs Andrew Jones
2026-08-20 21:41 ` [PATCH v4 15/21] iommu/riscv: Remap IMSIC targets during MSI composition Andrew Jones
2026-08-20 21:41 ` [PATCH v4 16/21] iommu/dma: Enable IOMMU_DMA for 64-bit RISC-V Andrew Jones
2026-08-20 21:41 ` [PATCH v4 17/21] iommu/riscv: Report cache coherency capability Andrew Jones
2026-08-20 21:47 ` Jason Gunthorpe
2026-08-21 11:15 ` Andrew Jones
2026-08-20 21:41 ` [PATCH v4 18/21] vfio: enable IOMMU_TYPE1 for RISC-V Andrew Jones
2026-08-20 21:41 ` [PATCH v4 19/21] RISC-V: KVM: Enable KVM_VFIO interfaces on RISC-V arch Andrew Jones
2026-08-20 21:41 ` [PATCH v4 20/21] riscv: defconfig: Enable IOMMUFD and VFIO Andrew Jones
2026-08-20 21:41 ` [PATCH v4 21/21] selftests/vfio: Allow building on RISC-V Andrew Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260824170417.GR244917@nvidia.com \
--to=jgg@nvidia.com \
--cc=andrew.jones@oss.qualcomm.com \
--cc=anup@brainfault.org \
--cc=fangyu.yu@linux.alibaba.com \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=pjw@kernel.org \
--cc=robin.murphy@arm.com \
--cc=tglx@kernel.org \
--cc=tjeznach@rivosinc.com \
--cc=tomasz.jeznach@linux.dev \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox