Re: [PATCH v8 07/15] iommupt: Add map_pages op

[Jason Gunthorpe <jgg@nvidia.com>]

On Thu, Jan 29, 2026 at 11:33:06AM +1100, Alexey Kardashevskiy wrote:
> > > > What happens if you don't have a VIOMMU, have a single translation
> > > > stage and only use the S1 (AMDv2) page table in the hypervisor? Then
> > > > does the HW fix it? Or does it only fix it with two stages enabled?
> > > 
> > > The HW translates a DMA handle to a host pfn, and then RMP checks if
> > > that [pfn..pfn+size] is assigned to the correct ASID and the page
> > > size matches and the gfn matches.
> > > 
> > > RMP does not check S1 translations inside the guest, only S2. RMP is
> > > not fixing page sizes or anything, it says yes/no to the access.
> > 
> > Your explanation doesn't make alot of sense.
> > 
> > If we have a vIOMMU and the guest has a 4K IOPTE in S1 then it goes
> > 
> >   S1[4k] -> S2[2M] -- [4k] --> RMP[2M] ==> OK 4k IOTLB entry
> 
> Should be 2MB IOTLB.

That would be a catastrophic HW bug to take the VM's 4k IOPTE and
expand it to a 2M IOTLB entry.

> > While if we have no vIOMMU, the same effective scenario:
> > 
> >   S2[4k] ------- [4k] -------> RMP[2M] ==> FAIL
> 
> The host should have made sure S2 and RMP use the same page size.

The HW could have installed a 4K IOTLB like it does above.

It is obviously possible because the CPU TLB is doing this, the S1
case is doing it...

> > Maybe your answer is the entity that is building the RMP also has to
> > build a matching S2 IOTLB as one unit and
> 
> Yes, the host OS updates both RMP and S2, and the host uses the same
> page size. Because when the guest accepts memory/MMIO ("validates"
> in AMD words, it prevents the host from changing it quietly), it
> accepts a page of a specific size so then the guest can be sure that
> that S2 mapping won't be remapped by the (untrusted) host.

I don't mean in such broad terms a "the host", I mean a specific
kernel unit, probably KVM.

> > we somehow just plumb the
> > page table pointer and invalidations into the IOMMU driver.
> > 
> > Such a messy design.
> 
> Not sure about that, I dislike other designs more. At least with
> this one S2 tables (IOMMU, NPT) stay the same vs having firmwares
> dealing with them with KVM having to manage some of it. I also
> suspect I am explaining RMP rather poorly (which is a control
> mechanism, not for translation). May be Vasant could help :) Thanks,

Maybe, but if the HW is really so dumb that it has to be perfectly in
sync with special engines to change them, I don't see you have much
option other than make KVM maintain both tables (where the CPU and IO
S2 have identical content and exactly match the RMP) and somehow pick
up the IO S2 from KVM into the iommu DTE.

But I bet the KVM guys will tell you this is not possible because they
have always said it is not possible for the IOMMU to share the KVM S2.

Maybe they are relenting on that because ARM CCA works that way, IDK.

Or give up on 2M RMP support and Linux only supports 4K until the HW
is improved.

Or maybe the IOMMU can own the RMP, but that sounds pretty much
nonsensical to me.

It is just a horrible HW design for the software stack we have today.

Jason