Re: [RFC PATCH v2 14/22] iommufd: Add TIO calls

[Jason Gunthorpe <jgg@ziepe.ca>]

On Wed, Mar 05, 2025 at 02:09:09PM +1100, Alexey Kardashevskiy wrote:
> 
> 
> On 1/3/25 11:32, Jason Gunthorpe wrote:
> > On Thu, Feb 27, 2025 at 11:33:31AM +1100, Alexey Kardashevskiy wrote:
> > > 
> > > 
> > > On 27/2/25 00:12, Jason Gunthorpe wrote:
> > > > On Wed, Feb 26, 2025 at 06:49:18PM +0800, Xu Yilun wrote:
> > > > 
> > > > > E.g. I don't think VFIO driver would expect its MMIO access suddenly
> > > > > failed without knowing what happened.
> > > > 
> > > > What do people expect to happen here anyhow? Do you still intend to
> > > > mmap any of the MMIO into the hypervisor? No, right? It is all locked
> > > > down?
> > > 
> > > This patchset expects it to be mmap'able as this is how MMIO gets mapped in
> > > the NPT and SEV-SNP still works with that (and updates the RMPs on top), the
> > > host os is not expected to access these though. TDX will handle this somehow
> > > different. Thanks,
> > 
> > I'm expecting you'll wrap that in a FD,
> 
> A KVM memslot from VFIO's fd similar to gmemfd's fd, and skip VMA? Doable
> but 1) creates a KVM->VFIO dependency to do gpa->hpa translation 2) is not
> necessary in the AMD case (although host-mmap of guest-assigned private BAR
> is way too easy way of shooting yourself in the foot).

But since it is necessary in other cases, the code will be there and
everyone should just use it..

> > since iommufd will not be accessing MMIO through mmaps.
> 
> here I do not follow, why would iommufd care about MMIO? or it is about p2p
> DMA? Thanks,

Yes, p2p dma

Jason