Re: [PATCH V1 7/8] vfio: change dma owner

[Jason Gunthorpe <jgg@ziepe.ca>]

On Thu, Dec 08, 2022 at 11:48:08AM -0500, Steven Sistare wrote:

> > Anyhow, I came up with this thing. Needs a bit of polishing, the
> > design is a bit odd for performance reasons, and I only compiled it.
> 
> Thanks, I'll pull an iommfd development environment together and try it.
> However, it will also need an interface to change vaddr for each dma region.
> In general the vaddr will be different when the memory object is re-mapped 
> after exec.

Ahh that is yuky :\

So I still like the one shot approach because it has nice error
handling properties, and it lets us use the hacky very expensive "stop
the world" lockng to avoid slowing the fast paths.

Passing in a sorted list of old_vaddr,new_vaddr is possibly fine, the
kernel can bsearch it as it goes through all the pages objects.

Due to the way iommufd works, especially with copy, you end up with
the 'pages' handle that holds the vaddr that many different IOVAs may
refer to. So it is kind of weird to ask to change a single IOVA's
mapping, it must always change all the mappings that have been copied
that share vaddr, pin accounting and so forth.

This is another reason why I liked the one-shot global everything
approach, as narrowing the objects to target cannot be done by IOVA -
at best you could target a specific mm and vaddr range.

FWIW, there is a nice selftest in iommufd in
tools/testing/selftests/iommu/iommufd.c and the way to develop
something like this is to add a simple selftes to exercise your
scenario and get everything sorted like that before going to qemu.

Using the vfio compat you can keep the existing qemu vfio type1 and
just hack in a call the IOMMUFD ioctl in the right spot. No need to
jump to the iommfd version of qemu for testing.

Jason