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

[Alexey Kardashevskiy]

On 28/1/26 01:25, Jason Gunthorpe wrote:
> On Tue, Jan 27, 2026 at 07:08:39PM +1100, Alexey Kardashevskiy wrote:
>>> Oh so it doesn't actually check the RMP, it is just rounding down to
>>> two fixed sizes?
>>
>> No, it does check RMP.
>>
>> If the IOMMU page walk ends at a >=2MB page - it will round down to
>> 2MB (to the nearest supported RMP size) and check for 2MB RMP and if
>> that check fails because of the page size - it won't try 4K (even
>> though it could theoretically).
>>
>> The expectation is that the host OS makes sure the IOMMU uses page
>> sizes equal or bigger than closest smaller RMP page size so there is
>> no need in two RMP checks.
> 
> Seems dynfunctional to me.
>>>>>> ARM is pushing a thing where encrypt/decrypt has to work on certain aligned
>>>>> granual sizes > PAGE_SIZE, you could use that mechanism to select a 2M
>>>>> size for AMD too and avoid this.
>>>>
>>>> 2M minimum on every DMA map?
>>> On every swiotlb allocation pool chunk, yeah.
>>
>> Nah, it is quite easy to force 2MB on swiotlb (just do it once and
>> forget) but currently any guest page can be converted to shared and
>> DMA-mapped and this skips swiotlb.
> 
> Upstream Linux doesn't support that, only SWIOTLB or special DMA
> coherent memory can be DMA mapped in CC systems. You can't take a
> random page, make it shared and then DMA map it.

Well, my test device driver calls dma_alloc_coherent() which does that - alloc + convert 4K.

>>>>> What happens if the guest puts 4K pages into it's AMDv2 table and RMP
>>>>> is 2M?
>>>>
>>>> Is this AMDv2 - an NPT (then it is going to fail)? or nested IOMMU (never tried, in the works, I suspect failure)?
>>>
>>> Yes, some future nested vIOMMU
>>>
>>> If guest can't have a 4K page in it's vIOMMU while the host is using
>>> 2M RMP then the whole architecture is broken, sorry.
>>
>> I re-read what I wrote and I think I was wrong, the S2 table (guest
>> physical -> host physical) has to match RMP, not the S1.
> 
> Really? So the HW can fix the 4k/2M mismatch for the S1 but doesn't
> bother for the S2? Seems like a crazy design to me.

S2 is controlled by the HV and RMP protects against wrong mapping of the guest physical memory in that S2, RMP is a HW firewall.

> 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.


>>> iommufd won't deal with memory maps for IO, the secure world will
>>> handle that through KVM.
>>
>> Is QEMU going to skip on IOMMU mapping entirely? So when the device
>> is transitioned from untrusted (when everything mapped via VFIO or
>> IOMMU) to trusted - QEMU will unmap everything and then the guest
>> will map everything but this time via KVM and bypassing QEMU
>> entirely? Thanks,
> 
> On ARM there are different S2s for the IOMMU, one for T=1 and one for
> T=0 traffic. The T=1 is fully controlled by the secure world is equal
> to the CPU S2. The T=0 one is fully controlled by qemu and acts like a
> normal system. The T=0 can only access guest shared memory.

Does the T=0 table still have all the guest memory mapped (with the expectation that what is not allowed - won't be accessed using that table)? Thanks,


> 
> Jason

-- 
Alexey