On Tue, Jan 21, 2025 at 08:34:43AM -0700, Alex Williamson wrote: > This description is unclear to me. As others have noted, we probably > need to look at whether the flag should be automatically applied by the > kernel. We certainly know in the vfio IOMMU layer whether we're > mapping a page or a pfnmap. It is not page or pfnmap.. When vfio is using follow_pte() it should extract information from the PTE and then relay it to the IOMMU. The iommu page table and the CPU page table should have the same PTE flags. So, a pte that is pgprot_cached() should be IOMMU_CACHE, otherwise IOMMU_MMIO. The encrypted bit in the PTE should be mapped to some new IOMMU_ENCRYPTED. I suspect AMD has created a troublesome issue that IOMMU_CACHE conditionally implies encrypted depending on their platform features (meaning cachable decrypted is impossible). Arguably a higher level should be deciding this and the iommu page table code should simply follow IOMMU_ENCRYPTED always. That might be something for later, but I would note it :\ > In any case, we're in the process of phasing out the vfio type1 > IOMMU backend for iommufd, so whatever the implementation, and > especially if there's a uapi component, it needs to be implemented > in iommufd first. Since iommufd won't be using follow_pte() it will have to get this meta information from the FD, eg through DMABUf, and there is a huge thread on how to go about doing that.. There should be no uapi component. Jason
