On Tue, Mar 17, 2026 at 09:26:21AM +0100, Jiri Pirko wrote:
...although, why *shouldn't* this be allowed with a vIOMMU? (Especially given that a vIOMMU for untrusted devices can be emulated by the host VMM without the CoCo hypervisor having to care at all - again, at least on Arm and other architectures where IOMMUs are regular driver model devices)
Well, when iommu path is able to consume the attr, this restriction should be lifted. This is basically a sanity check for the dma_map_phys() caller.
Right we eventually need a matching IOMMU_DECRYPTED.
It needs to mirror how the CPUs work - any place that would use pgprot_decrypted to create a PTE should use IOMMU_PROT_DECRYPTED to create an iommu mapping.
The current hack in AMD assumes IOMMU_DECRYPTED behavior for IOMMU_MMIO, but that isn't general enough..
There is some maze to get there but for the moment I think it is fine to just not support vIOMMU, it isn't like any vIOMMU drivers even exist for CC VMs right now.
Jason