On Sun, Mar 16, 2025 at 08:52:43PM -0700, David Rientjes wrote: > Pasha asked how drivers would know if reservations would be denied in the > first 4GB of memory. Mike said an error code would be returned. Pasha > was specific about devices that wanted to preserve the memory because > they knew DMA would be on-going during the reboot. This became a more > general question: what devices should we support for KHO and what should > we not (what is considered too legacy?). In the meantime, Pratyush > suggested explicit checks for this. IMHO supports DMA to all memory, and doesn't require swiotlb seem like reasonable starting points for device capability. If you can't start swiotlb later, after the buddy allocator, maybe just make it KConfig conflicting with KHO? You could probably also preserve the swiotlb memory across the kexec to bootstrap it, but why? It should never be used on modern HW.. > Pratyush noted there was no way to preserve folio orders in KHO and he > also noted there was a need for page flags. I think the xarray idea will preserve folio orders, that was a big point of it. Not clear why we'd need to preserve page flags. The same page flags may not even exist in the new kernel? New kernel should set the page flags correctly based on what it is doing. Shouldn't, say, memfd know exactly what it's page flags should be in the new kernel when adopting the memory? > Pasha asked how cgroups would be handled, but there was no current > support for that. Pratyush said the current RFC focused on anon memfd > and has not yet looked at hugetlb. Pasha emphasized the importance of > focusing on one type of memory to start. I'd say userspace should deal with this. It should de-serialize the FD within the context of the cgroup it wants to charge that FD too, and the de-serializing process should charge that cgroups accounting with whatever is restored inside the FD. Is that possible? > Andrey had recently sent another patch series for KSTATE[3] that was > discussed, now in v2, which was closer to being a formal submission > rather than an RFC. He noted his concern with KHO was how hard it was to > write serialization code. His goal was to give drivers the ability to > migrate structs across kexec which could be more elegant (see the > struct kstate_description). I think we will have structs, I think most things will be structs. The KHO just gives a small FDT area to keep track of the top level struct pointers in a more understandable and auditable way. > Mike suggested on top of KHO we have FDT, then what Pasha is proposing > for dynamic tree on top of that, then perhaps kstate on top of that. He > would need to look more into kstate. This makes sense to me. I think the FDT should be the first layer, and then we can go item by item and decide the best serialization to use, always starting from the FDT. At worst the FD is just an expensive way to store a pointer to a struct. If we determine at the end that the FDT is predominantly used for very simple struct things then maybe it gets replaced.. Regards, Jason
