On Thu, Dec 08, 2022 at 12:39:19PM -0500, Steven Sistare wrote: > 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. I think compared to 1 ioctl per map it is probably notably faster, it is just "horribly expensive" to do the ioctl preamble - eg you would not want to iterate it. Jason
