Re: [PATCH v4 05/14] kexec: Add Kexec HandOver (KHO) generation helpers

[Mike Rapoport <rppt@kernel.org>]

Hi Jason,

On Wed, Feb 12, 2025 at 11:23:36AM -0400, Jason Gunthorpe wrote:
> On Tue, Feb 11, 2025 at 12:37:20PM -0400, Jason Gunthorpe wrote:
> 
> > To do that you need to preserve folios as the basic primitive.
> 
> I made a small sketch of what I suggest.
> 
> I imagine the FDT schema for this would look something like this:
> 
> /dts-v1/;
> / {
>   compatible = "linux-kho,v1";
>   phys-addr-size = 64;
>   void-p-size = 64;
>   preserved-folio-map = <phys_addr>;
> 
>   // The per "driver" storage
>   instance@1 {..};
>   instance@2 {..};
> };
> 
> I think this is alot better than what is in this series. It uses much
> less memory when there are alot of allocation, it supports any order
> folios, it is efficient for 1G guestmemfd folios, and it only needs a
> few bytes in the FDT. It could preserve and restore the high order
> folio struct page folding (HVO).
> 
> The use cases I'm imagining for drivers would be pushing gigabytes of
> memory into this preservation mechanism. It needs to be scalable!
> 
> This also illustrates my point that I don't think FDT is a good
> representation to use exclusively. This in-memory structure is much
> better and faster than trying to represent the same information
> embedded directly into the FDT. I imagine this to be the general
> pattern that drivers will want to use. A few bytes in the FDT pointing
> at a scalable in-memory structure for the bulk of the data.

As I've mentioned off-list earlier, KHO in its current form is the lowest
level of abstraction for state preservation and it is by no means is
intended to provide complex drivers with all the tools necessary.

It's sole purpose is to allow preserving simple properties and ensure that
memory ranges KHO clients need to preserve won't be overwritten.

What you propose is a great optimization for memory preservation mechanism,
and additional and very useful abstraction layer on top of "basic KHO"!

But I think it will be easier to start with something *very simple* and
probably suboptimal and then extend it rather than to try to build complex
comprehensive solution from day one.

-- 
Sincerely yours,
Mike.