On Fri, Jun 06, 2025 at 11:49:46AM -0700, Alex Mastro wrote: > Hi Jason, > > By the way, we have been following progress on IOMMUFD, and would be interested > in dogfooding it for our use case when ready. The main blocker is IOMMUFD's > current lack of P2P support (IOMMU_IOAS_MAP fails when the VA range is backed > by MMIO). Nicolin has a OOT tree patch that makes iommufd work in the same insecure way as VFIO. Several places are using that for now. > dma-buf as a less ambiguous semantic for communicating this intent (rather than > the struggles of inferring what kind of memory is behind some VA range) makes a > lot of sense. Yes, I hope > Based on tidbits we have gleaned, IOMMUFD P2P support intends to be built on > top of "Provide a new two step DMA mapping API" [1] and "vfio/pci: Allow MMIO > regions to be exported through dma-buf" [2]. Yes, that would be the first basis. We also need to enhance DMABUF to add 'revoke' semantic And enhance it to allow the physical page list to be given the iommufd instead of a scatterlist. > Item [2] appears to have been picked up by "Host side (KVM/VFIO/IOMMUFD) support > for TDISP using TSM" [3]. I hope to see #2 redone on top of #1 this next cycle, Leon is working on the incremental changes to allow the new DMA API to work without struct page. > On top of this, there would need to be a new IOMMUFD uapi, or extension to > existing, which would accept an input dma-buf to map. Are there any patches in > progress which include this? No, I haven't seen patches for dmabuf revoke, or iommufd. The patches for the physical address list need redoing to try again following Sima's directions. There are lots of steps here for someone to contribute to :) Jason
