On Mon, Sep 02, 2024 at 11:09:49AM +1000, Alexey Kardashevskiy wrote: > On 30/8/24 22:35, Jason Gunthorpe wrote: > > On Fri, Aug 30, 2024 at 01:47:40PM +1000, Alexey Kardashevskiy wrote: > > > > > > Yes, we want a DMA MAP from memfd sort of API in general. So it should > > > > > > go directly to guest memfd with no kvm entanglement. > > > > > > > > > > A uAPI like ioctl(MAP_DMA, gmemfd, offset, iova) still means userspace > > > > > takes control of the IOMMU mapping in the unsecure world. > > > > > > > > Yes, such is how it seems to work. > > > > > > > > It doesn't actually have much control, it has to build a mapping that > > > > matches the RMP table exactly but still has to build it.. > > > > > > Sorry, I am missing the point here. IOMMU maps bus addresses (IOVAs) to host > > > physical, if we skip IOMMU, then how RMP (maps host pfns to guest pfns) will > > > help to map IOVA (in fact, guest pfn) to host pfn? Thanks, > > > > It is the explanation for why this is safe. > > > > For CC the translation of IOVA to physical must not be controlled by > > the hypervisor, for security. This can result in translation based > > attacks. > > > > AMD is weird because it puts the IOMMU page table in untrusted > > hypervisor memory, everyone else seems to put it in the trusted > > world's memory. > > > > This works for AMD because they have two copies of this translation, > > in two different formats, one in the RMP which is in trusted memory > > and one in the IO page table which is not trusted. Yes you can't use > > the RMP to do an IOVA lookup, but it does encode exactly the same > > information. > > It is exactly the same because today VFIO does 1:1 IOVA->guest mapping on > x86 (and some/most other architectures) but it is not for when guests get > hardware-assisted vIOMMU support. Yes, you are forced into a nesting IOMMU architecture with CC guests. Jason
