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
