Re: [BUG?] vfio/pci: VA alignment sensitivity of VFIO_IOMMU_MAP_DMA which target MMIO

[Jason Gunthorpe <jgg@nvidia.com>]

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