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

[Alexey Kardashevskiy]

On 29/1/26 00:32, Jason Gunthorpe wrote:
> On Wed, Jan 28, 2026 at 12:42:08PM +1100, Alexey Kardashevskiy wrote:
>>>> 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.
> 
> Yes, and there is no reason that can't come from the same allocator as
> SWIOTLB and use 2M aligned blocks.

I am rather surprised that even now, with SWIOTLB_FORCE, dma_alloc_coherent chooses not to use SWIOTLB in confidential VM.

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

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

> It makes no sense at all. Why build something like that?
> 
> It is not a "firewall" it is a huge software obstacle.
> 
> 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.

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


>>>>> 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,
> 
> I'm not sure what the plan is, I think ARM can do both ways - map all
> guest physical and rely on the GPT to prevent access or dynamically
> map only shared pages.
> 
> Jason

-- 
Alexey