On Wed, Mar 26, 2025 at 10:40:29PM +0000, Pratyush Yadav wrote: > Ideally, kho_preserve_folio() should be similar to freeing the folio, > except that it doesn't go to buddy for re-allocation. In that case, > re-using those pages should not be a problem as long as the driver made > sure the page was properly "freed", and there are no stale references to > it. They should be doing that anyway since they should make sure the > file doesn't change after it has been serialized. I don't know if this is a good idea, it seems to make error recovery much more complex. > > Then you have the issue that I don't actually imagine shutting down > > something like iommufd, I was intending to leave it frozen in place > > with all its allocations and so on. If you try to de-serialize you > > can't de-serialize into the thing that is frozen, you'd create a new > > one from empty. Now you have two things pointing at the same stuff, > > what a mess. > > What do you mean by "frozen in place"? Isn't that the same as being > serialized? I mean all the memory and internal state is still there, it is just not changing. It is not the same as being serialized, as the de-serialized versions of everything would still exist in parallel. > Considering that we want to make sure a file is not opened by any > process before we serialize it, what do we get by keeping the struct > file around (assuming we can safely deserialize it without going > through kexec)? We do alot less work. Having serialize reliably but the entire system into a fully post-live-update state, including dependent things like the iommufd/vfio attachment and iommu driver, is very hard. This stuff is quite complex. I imagine instead we have three data states - Fully operating - Frozen and all preserved memory logged in KHO - post-live-update where there are hints scattered around the drivers about what is in the KHO
