Re: [PATCH v6 02/20] liveupdate: luo_core: integrate with KHO

[Mike Rapoport]

On Sat, Nov 15, 2025 at 06:33:48PM -0500, Pasha Tatashin wrote:
> Integrate the LUO with the KHO framework to enable passing LUO state
> across a kexec reboot.
> 
> When LUO is transitioned to a "prepared" state, it tells KHO to
> finalize, so all memory segments that were added to KHO preservation
> list are getting preserved. After "Prepared" state no new segments
> can be preserved. If LUO is canceled, it also tells KHO to cancel the
> serialization, and therefore, later LUO can go back into the prepared
> state.
> 
> This patch introduces the following changes:
> - During the KHO finalization phase allocate FDT blob.

This happens much earlier, isn't it?

> - Populate this FDT with a LUO compatibility string ("luo-v1").
> 
> 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>
> ---
>  include/linux/liveupdate/abi/luo.h |  54 ++++++++++
>  kernel/liveupdate/luo_core.c       | 153 ++++++++++++++++++++++++++++-
>  2 files changed, 206 insertions(+), 1 deletion(-)
>  create mode 100644 include/linux/liveupdate/abi/luo.h
> 
> diff --git a/include/linux/liveupdate/abi/luo.h b/include/linux/liveupdate/abi/luo.h
> new file mode 100644
> index 000000000000..9483a294287f
> --- /dev/null
> +++ b/include/linux/liveupdate/abi/luo.h
> @@ -0,0 +1,54 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +
> +/*
> + * Copyright (c) 2025, Google LLC.
> + * Pasha Tatashin <pasha.tatashin@xxxxxxxxxx>
> + */
> +
> +/**
> + * DOC: Live Update Orchestrator ABI
> + *
> + * This header defines the stable Application Binary Interface used by the
> + * Live Update Orchestrator to pass state from a pre-update kernel to a
> + * post-update kernel. The ABI is built upon the Kexec HandOver framework
> + * and uses a Flattened Device Tree to describe the preserved data.
> + *
> + * This interface is a contract. Any modification to the FDT structure, node
> + * properties, compatible strings, or the layout of the `__packed` serialization
> + * structures defined here constitutes a breaking change. Such changes require
> + * incrementing the version number in the relevant `_COMPATIBLE` string to
> + * prevent a new kernel from misinterpreting data from an old kernel.

I'd add a sentence that stresses that ABI changes are possible as long they
include changes to the FDT version.
This is indeed implied by the last paragraph, but I think it's worth
spelling it explicitly.

Another thing that I think this should mention is that compatibility is
only guaranteed for the kernels that use the same ABI version.

> + *
> + * FDT Structure Overview:
> + *   The entire LUO state is encapsulated within a single KHO entry named "LUO".
> + *   This entry contains an FDT with the following layout:
> + *
> + *   .. code-block:: none
> + *
> + *     / {
> + *         compatible = "luo-v1";
> + *         liveupdate-number = <...>;
> + *     };
> + *
> + * Main LUO Node (/):
> + *
> + *   - compatible: "luo-v1"
> + *     Identifies the overall LUO ABI version.
> + *   - liveupdate-number: u64
> + *     A counter tracking the number of successful live updates performed.
> + */
...

> +static int __init liveupdate_early_init(void)
> +{
> +	int err;
> +
> +	err = luo_early_startup();
> +	if (err) {
> +		pr_err("The incoming tree failed to initialize properly [%pe], disabling live update\n",
> +		       ERR_PTR(err));

How do we report this to the userspace?
I think the decision what to do in this case belongs there. Even if it's
down to choosing between plain kexec and full reboot, it's still a policy
that should be implemented in userspace.

> +		luo_global.enabled = false;
> +	}
> +
> +	return err;
> +}
> +early_initcall(liveupdate_early_init);

-- 
Sincerely yours,
Mike.