On 3/9/24 09:52, Jason Gunthorpe wrote:
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.
Up to two I/O page tables and the RMP table allow both 1:1 and vIOMMU,
what am I forced into, and by what? Thanks,
Jason
--
Alexey
