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

[Jason Gunthorpe]

On Fri, Apr 04, 2025 at 12:54:25PM +0300, Mike Rapoport wrote:
> > IMHO it should not call kho_preserve_phys() at all.
> 
> Do you mean that for preserving large physical ranges we need something
> entirely different?

If they don't use the buddy allocator, then yes?

> Then we don't need the bitmaps at this point, as we don't have any users
> for kho_preserve_folio() and we should not worry ourself with orders and
> restoration of high order folios until then ;-)

Arguably yes :\

Maybe change the reserved regions code to put the region list in a
folio and preserve the folio instead of using FDT as a "demo" for the
functionality.

> The xarrays + bitmaps do have the limitation that we cannot store any
> information about the folio except its order and if we are anyway need
> something else to preserve physical ranges, I suggest starting with
> preserving ranges and then adding optimizations for the folio case.

Why? What is the use case for physical ranges that isn't handled
entirely by reserved_mem_add()?

We know what the future use case is for the folio preservation, all
the drivers and the iommu are going to rely on this.

> Here's something that implements preservation of ranges (compile tested
> only) and adding folios with their orders and maybe other information would
> be quite easy.

But folios and their orders is the *whole point*, again I don't see
any use case for preserving ranges, beyond it being a way to optimize
the memblock reserve path. But that path should be fixed up to just
use the bitmap directly..

Jason