On Thu, Sep 04, 2025 at 02:57:35PM +0200, Pratyush Yadav wrote: > I don't think it matters if they are preserved or not. The serialization > and deserialization is independent of that. You can very well create a > KHO array that you don't KHO-preserve. On next boot, you can still use > it, you just have to be careful of doing it while scratch-only. Same as > we do now. The KHO array machinery itself can't preserve its own memory either. > For the _hypervisor_ live update case, sure. Though even there, I have a > feeling we will start seeing userspace components on the hypervisor use > memfd for stashing some of their state. Sure, but don't make excessively sparse memfds for kexec use, why should that be hard? > applications. Think big storage nodes with memory in order of TiB. Those > can use a memfd to back their caches so on a kernel upgrade the caches > don't have to be re-fetched. Sparseness is to be expected for such use > cases. Oh? I'm surpised you'd have sparseness there. sparseness seems like such a weird feature to want to rely on :\ > But perhaps it might be a better idea to come up with a mechanism for > the kernel to discover which formats the "next" kernel speaks so it can > for one decide whether it can do the live update at all, and for another > which formats it should use. Maybe we give a way for luod to choose > formats, and give it the responsibility for doing these checks? I have felt that we should catalog the formats&versions the kernel can read/write in some way during kbuild. Maybe this turns into a sysfs directory of all the data with an 'enable_write' flag that luod could set to 0 to optimize. And maybe this could be a kbuild report that luod could parse to do this optimization. And maybe distro/csps use this information mechanically to check if version pairs are kexec compatible. Which re-enforces my feeling that the formats/version should be first class concepts, every version should be registered and luo should sequence calling the code for the right version at the right time. Jason
