On Thu, Jan 30, 2025 at 11:50:27AM +0100, Simona Vetter wrote: > On Wed, Jan 29, 2025 at 09:47:57AM -0400, Jason Gunthorpe wrote: > > On Wed, Jan 29, 2025 at 02:38:58PM +0100, Simona Vetter wrote: > > > > > > The pgmap->owner doesn't *have* to fixed, certainly during early boot before > > > > you hand out any page references it can be changed. I wouldn't be > > > > surprised if this is useful to some requirements to build up the > > > > private interconnect topology? > > > > > > The trouble I'm seeing is device probe and the fundemantal issue that you > > > never know when you're done. And so if we entirely rely on pgmap->owner to > > > figure out the driver private interconnect topology, that's going to be > > > messy. That's why I'm also leaning towards both comparing owners and > > > having an additional check whether the interconnect is actually there or > > > not yet. > > > > Hoenstely, I'd rather invest more effort into being able to update > > owner for those special corner cases than to slow down the fast path > > in hmm_range_fault.. > > I'm not sure how you want to make the owner mutable. You'd probably have to use a system where you never free them until all the page maps are destroyed. You could also use an integer instead of a pointer to indicate the cluster of interconnect, I think there are many options.. > And I've looked at the lifetime fun of unregistering a dev_pagemap for > device hotunplug and pretty firmly concluded it's unfixable and that I > should run away to do something else :-P ? It is supposed to work, it blocks until all the pages are freed, but AFAIK ther is no fundamental life time issue. The driver is responsible to free all its usage. > An optional callback is a lot less scary to me here (or redoing > hmm_range_fault or whacking the migration helpers a few times) looks a lot > less scary than making pgmap->owner mutable in some fashion. It extra for every single 4k page on every user :\ And what are you going to do better inside this callback? Jason
