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

[Jason Gunthorpe]

On Tue, Feb 11, 2025 at 11:14:06AM -0500, Pasha Tatashin wrote:
> > think you should not add this when there are enough ideas on how to
> > completely avoid it.
> 
> Thinking about it some more, I'm actually leaning towards keeping
> things as they are, instead of going with a sparse FDT. 

What is a sparse FDT? My suggestion each driver make its own FDT?

The reason for this was sequencing because we need a more more
flexable way to manage all this serialization than just a notifier
chain. The existing FDT construction process is too restrictive to
accommodate this, IMHO.

That it also resolves the weird dt_max stuff above is a nice side
effect.

> With a sparse KHO-tree, we'd be kinda trying to fix something that
> should be handled higher up. All userspace preservable memory (like
> emulated pmem with devdax/fsdax and also pstore for logging) can
> already survive cold reboots with modified firmware Google and
> Microsoft do this.

I was hoping the VM memory wouldn't be in DAX. If you want some DAX
stuff to interact with FW, OK, but I think the design here should be
driving toward preserving a memfd/guestmemfd/hugetlbfs FDs directly
and eliminate the DAX backed VMs. We won't get to CC guestmemfd with
DAX.

fdbox of a guestmemfd, for instance.

To do that you need to preserve folios as the basic primitive.

> Similarly, the firmware could give the kernel the KHO-tree (generated
> by firmware or from the previous kernel) to keep stuff like telemetry,
> oops messages, time stamps etc. 

This feels like a mistake to comingle things like this. KHO is complex
enough, it should stay focused on its thing..

Jason