On Thu, Jun 05, 2025 at 12:09:16PM -0300, Jason Gunthorpe wrote: > On Thu, Jun 05, 2025 at 05:41:17PM +0800, Xu Yilun wrote: > > > No, this is not device side TDISP requirement. It is host side > > requirement to fix DMA silent drop issue. TDX enforces CPU S2 PT share > > with IOMMU S2 PT (does ARM do the same?), so unmap CPU S2 PT in KVM equals > > unmap IOMMU S2 PT. > > > > If we allow IOMMU S2 PT unmapped when TDI is running, host could fool > > guest by just unmap some PT entry and suppress the fault event. Guest > > thought a DMA writting is successful but it is not and may cause > > data integrity issue. > > So, TDX prevents *any* unmap, even of normal memory, from the S2 while > a guest is running? Seems extreme?
Prevents any unmap *not intended* by guest, even for normal memory. Guest could show its unmapping intention by issuing an "page release" firmware call then host is OK to unmap. This for normal memory. For MMIO, Guest implicitly hwo the intention by unbind the TDI first. > > MMIO isn't special, if you have a rule like that for such a security > reason it should cover all of the S2. It does. Thanks, Yilun > > > This is not a TDX specific problem, but different vendors has different > > mechanisms for this. For TDX, firmware fails the MMIO unmap for S2. For > > AMD, will trigger some HW protection called "ASID fence" [1]. Not sure > > how ARM handles this? > > This seems even more extreme, if the guest gets a bad DMA address into > the device then the entire device gets killed? No chance to debug it? > > Jason >
