Re: [RFC v2 05/16] luo: luo_core: integrate with KHO

[Pasha Tatashin]

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