On Tue, Sep 09 2025, Pasha Tatashin wrote: > On Tue, Sep 9, 2025 at 10:53 AM Pratyush Yadav <me@xxxxxxxxxxxxxxxxx> wrote: >> >> On Thu, Sep 04 2025, Jason Gunthorpe wrote: >> >> > On Thu, Sep 04, 2025 at 02:57:35PM +0200, Pratyush Yadav wrote: [...] >> >> 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. >> >> Or maybe we put that information in a ELF section in the kernel image? >> Not sure how feasible it would be for tooling to read but I think that >> would very closely associate the versions info with the kernel. The >> other option might be to put it somewhere with modules I guess. > > To me, all this sounds like hardening, which, while important, can be > added later. The pre-kexec check for compatibility can be defined and > implemented once we have all live update components ready > (KHO/LUO/PCI/IOMMU/VFIO/MEMFD), once we stabilize the versioning > story, and once we start discussing update stability. Right. I don't think this is something the current LUO patches have to solve. This is for later down the line. > > Currently, we've agreed that there are no stability guarantees. > Sometime in the future, we may guarantee minor-to-minor stability, and > later, stable-to-stable. Once we start working on minor-to-minor > stability, it would be a good idea to also add hardening where a > pre-live update would check for compatibility. > > In reality, this is not something that is high priority for cloud > providers, because these kinds of incompatibilities would be found > during qualification; the kernel will fail to update by detecting a > version mismatch during boot instead of during shutdown. I think it would help with making a wider range of roll back and forward options available. For example, if your current kernel can speak version A and B, and you are rolling back to a kernel that only speaks A, this information can be used to choose the right serialization formats. [...] -- Regards, Pratyush Yadav