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
