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

[Jason Gunthorpe <jgg@nvidia.com>]

On Wed, Apr 09, 2025 at 07:28:47PM +0300, Mike Rapoport wrote:
> On Mon, Apr 07, 2025 at 11:16:26AM -0300, Jason Gunthorpe wrote:
> > On Sun, Apr 06, 2025 at 07:11:14PM +0300, Mike Rapoport wrote:
> > 
> > KHO needs to provide a way to give back an allocated struct page/folio
> > that can be freed back to the buddy alloactor, of the proper
> > order. Whatever you call that function it belongs to KHO as it is
> > KHO's primary responsibility to manage the buddy allocator and the
> > struct pages.
> 
> If order is only important for freeing memory back to page allocator, you
> don't really need it. Freeing contiguous power-of-two number of pages with
> proper alignment will give the same result, just a tad slower.

What I'm asking for is transparency for the driver.

iommu going to be doing:

  folio = __folio_alloc_node(order >= 0)
  [.. init struct ioptdesc that is overlayed with struct folio ]
  folio_put(folio);

As that is how you make memdescs work today. So when we add KHO, I
want to see:

  folio = __folio_alloc_node(order >= 0);
  [.. init struct ioptdesc that is overlayed with struct folio ]
  kho_preserve_folio(folio);

  // kexec

  folio = kho_restore_folio(phys);
  [.. init struct ioptdesc that is overlayed with struct folio ]

  folio_put(folio);

Working fully.

I do not want to mess with the existing folio_put() code just because
KHO can't preserve __folio_alloc_node().

Tomorrow someday I think we will switch to a flow more like

   memory = memdesc_alloc(&ioptdesc, order >= 0);
   [.. init struct ioptdesc that is a new allocation]
   kho_preserve_memdesc(ioptdesc)

   // kexec

   memory = kho_restore_memdesc(phys, &ioptdesc)
   [.. init struct ioptdesc that is a new allocation]
   memdesc_free(memory, ioptdesc);

Jason