On 12/8/2022 12:15 PM, Jason Gunthorpe wrote: > 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. Sorry, I was imprecise. I meant to say, "it will also need an interface to change all vaddrs". Passing an array or list of new vaddrs in a one-shot ioctl. I hope the "very expensive path" is not horribly slow, as it is in the critical path for guest pause time. Right now the pause time is less than 100 millisecs. - Steve > 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
