Re: [PATCH v6 09/16] iommu/riscv: Reserve an MSI IOVA window for iommufd

[Andrew Jones <andrew.jones@linux.dev>]

On Thu, Oct 15, 2026 at 12:51:33PM -0700, Nicolin Chen wrote:
> On Thu, Oct 15, 2026 at 04:35:27PM -0300, Jason Gunthorpe wrote:
> > > Reserve one page per possible CPU, sufficient for each supervisor IMSIC
> > > page. Use a 16 MiB base instead of the 128 MiB convention used by ARM
> > > SMMU. kvmtool places its guest IMSIC at 128 MiB, so with IRQ bypass the
> > > domain-wide guest MSI address match can also capture host-delivered
> > > MSI writes to the SW MSI window and misdeliver them to the guest.
> > > 
> > > 16 MiB falls in a hole in the current kvmtool and QEMU virt memory maps,
> > > away from their guest IMSIC windows and RAM. Keep the window below
> > > 4 GiB so devices with 32-bit MSI address registers can use it.
> > 
> > And this is a good reason you should not follow ARM down this mad
> > road. Nicolin had some patches to allow userspace to select the SW_MSI
> > range instead of using a kernel hard coded value, which becomes a
> > sneaky ABI. It would be much better if riscv starts off on the right
> > foot instead of continuing this mistake.
> 
> It was paused due to lack of an immediate interest:
> https://lore.kernel.org/linux-iommu/cover.1760487869.git.nicolinc@nvidia.com/
> 
> If riscv wants it, maybe we can give a push.
>

I'll look into Nicolin's patches in a follow-on series and defer enabling
VFIO_IOMMU_TYPE1 for now. I'll see if I can avoid introducing
IOMMU_RESV_SW_MSI at all, which would rule out using the legacy Type1
backend as it stands. Instead, I'll try to support existing Type1
userspace through iommufd's compatibility interface, which will need to
manage MSI IOVA allocation without SW_MSI, since existing Type1 userspace
won't issue Nicolin's ioctls.

I'm posting a much simplified DMA-IOMMU-only v7 now.

Thanks,
drew