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
