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. Thanks,
Both must agree on the IOVA to physical mapping otherwise the HW
rejects it. Meaning the IOMMU configuration must perfectly match the
RMP configuration.
--
Alexey
