On Mon, May 26, 2025 at 3:19 AM Mike Rapoport <rppt@xxxxxxxxxx> wrote:
>
> On Thu, May 15, 2025 at 06:23:09PM +0000, Pasha Tatashin wrote:
> > Integrate the LUO with the KHO framework to enable passing LUO state
> > across a kexec reboot.
> >
> > This patch introduces the following changes:
> > - During the KHO finalization phase allocate FDT blob.
> > - Populate this FDT with a LUO compatibility string ("luo-v1") and the
> > current LUO state (`luo_state`).
> > - Implement a KHO notifier
>
> Would be nice to have more details about how LUO interacts with KHO, like
> how LUO states correspond to the state of KHO, what may trigger
> corresponding state transitions etc.
Updated.
>
> > LUO now depends on `CONFIG_KEXEC_HANDOVER`. The core state transition
> > logic (`luo_do_*_calls`) remains unimplemented in this patch.
> >
> > Signed-off-by: Pasha Tatashin <pasha.tatashin@xxxxxxxxxx>
> > ---
> > drivers/misc/liveupdate/luo_core.c | 222 ++++++++++++++++++++++++++++-
> > 1 file changed, 219 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/misc/liveupdate/luo_core.c b/drivers/misc/liveupdate/luo_core.c
> > index 919c37b0b4d1..a76e886bc3b1 100644
> > --- a/drivers/misc/liveupdate/luo_core.c
> > +++ b/drivers/misc/liveupdate/luo_core.c
> > @@ -36,9 +36,12 @@
> > #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> >
> > #include <linux/err.h>
> > +#include <linux/kexec_handover.h>
> > #include <linux/kobject.h>
> > +#include <linux/libfdt.h>
> > #include <linux/liveupdate.h>
> > #include <linux/rwsem.h>
> > +#include <linux/sizes.h>
> > #include <linux/string.h>
> > #include "luo_internal.h"
> >
> > @@ -55,6 +58,12 @@ const char *const luo_state_str[] = {
> >
> > bool luo_enabled;
> >
> > +static void *luo_fdt_out;
> > +static void *luo_fdt_in;
> > +#define LUO_FDT_SIZE SZ_1M
>
> Does LUO really need that much?
Not, really, but I am keeping it simple in this patch. I added the
following comment:
/*
* The LUO FDT size depends on the number of participating subsystems,
* preserved file descriptors, and devices. While the total size could be
* calculated precisely during the "prepare" phase, it would require
* iterating through all participants twice: once to calculate the required
* size, and a second time to actually preserve the data and populate the FDT.
*
* Given that each participant stores only a small amount of metadata
* (e.g., an 8-byte payload or pointer) directly in the LUO FDT, and that
* this FDT is used only during the relatively short kexec transition
* period (including the blackout window and early boot of the next kernel),
* a fixed size is used for simplicity.
*
* The current fixed size (1M) is large enough to handle reasonable number of
* preserved entities. If this size ever becomes insufficient, it can either be
* increased, or a dynamic size calculation mechanism could be implemented in
* the future.
*/
Pasha
