[PATCH v5 09/16] kexec: enable KHO support for memory preservation

[Jason Gunthorpe]

On Thu, Apr 10, 2025 at 05:51:51PM +0100, Matthew Wilcox wrote:
> On Wed, Apr 09, 2025 at 01:28:37PM -0300, Jason Gunthorpe wrote:
> > On Wed, Apr 09, 2025 at 07:19:30PM +0300, Mike Rapoport wrote:
> > > But we have memdesc today, it's struct page.
> > 
> > No, I don't think it is. struct page seems to be turning into
> > something legacy that indicates the code has not been converted to the
> > new stuff yet.
> 
> No, struct page will be with us for a while.  Possibly forever.  I have
> started reluctantly talking about a future in which there aren't struct
> pages, but it's really premature at this point.  That's a 2030 kind
> of future.

I was trying to say that code that uses struct page type might be
thought of as 'old code' and maybe in drivers that have been updated
to use KHO we can also insist they be modernized away from struct
page?

> For 2025-2029, we will still have alloc_page(s)().  It's just that
> the size of struct page will be gradually shrinking over that time.

For instance while we still have alloc_pages(), yes, but we could say
that KHO enabled drivers should not use it and be migrated to
folio_alloc or slab instead.

> > I don't want some weird KHO interface that doesn't align with using
> > __folio_alloc_node() and folio_put() as the lowest level allocator
> > interface.
> 
> I think it's fine to say "the KHO interface doesn't support bare pages;
> you must have a memdesc".  But I'm not sure that's the right approach.

The KHO interface needs to know how to initialize the memdesc. So if
the very lowest allocator function is:

        page = alloc_page_desc(gfp, order, MEMDESC_TYPE_FOLIO(folio));

Then we need a KHO 'restore' version of that that also accepts the
MEMDESC_TYPE_XX() too.

Bare pages would be built on top of that layering and supply a memdesc
that is equivalent to whatever a normal allocation of a a bare page
would get, so that normal freeing of a bare page works properly.

IOW the KHO preserve/restore APIs should mirror alloc/free APIs.

 struct folio *folio = folio_alloc()
 kho_folio_preserve(folio)
 folio = kho_folio_restore()
 folio_put()

 void *vmem = kvmalloc(PAGE_SIZE * N);
 kho_vmalloc_preserve(vmem)
 vmem = kho_vmalloc_restore()
 kvfree(vmem)

 void *mem = kmalloc(PAGE_SIZE)
 kho_slab_preserve(mem)
 mem = kho_slab_restore()
 kfree(mem)

The point of the restore function being to put everything back so that
the matching free function works.

I'm guessing if we imagine the above 3 options, then in a memdesc
world they will all be implemented under the covers by doing some
internal kho_restore_page_desc() which will be the lowest level
primitive.

So, I'm not sure what the API should be for bare pages (ie not use of
the memdesc). kmalloc(PAGE_SIZE) would certainly be nice if we can
make it work.

Jason