From: Mike Rapoport <rppt@kernel.org>
To: Pasha Tatashin <pasha.tatashin@soleen.com>
Cc: pratyush@kernel.org, jasonmiu@google.com, graf@amazon.com,
changyuanl@google.com, dmatlack@google.com, rientjes@google.com,
corbet@lwn.net, rdunlap@infradead.org,
ilpo.jarvinen@linux.intel.com, kanie@linux.alibaba.com,
ojeda@kernel.org, aliceryhl@google.com, masahiroy@kernel.org,
akpm@linux-foundation.org, tj@kernel.org, yoann.congal@smile.fr,
mmaurer@google.com, roman.gushchin@linux.dev,
chenridong@huawei.com, axboe@kernel.dk, mark.rutland@arm.com,
jannh@google.com, vincent.guittot@linaro.org, hannes@cmpxchg.org,
dan.j.williams@intel.com, david@redhat.com,
joel.granados@kernel.org, rostedt@goodmis.org,
anna.schumaker@oracle.com, song@kernel.org,
zhangguopeng@kylinos.cn, linux@weissschuh.net,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
linux-mm@kvack.org, gregkh@linuxfoundation.org,
tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
rafael@kernel.org, dakr@kernel.org,
bartosz.golaszewski@linaro.org, cw00.choi@samsung.com,
myungjoo.ham@samsung.com, yesanishhere@gmail.com,
Jonathan.Cameron@huawei.com, quic_zijuhu@quicinc.com,
aleksander.lobakin@intel.com, ira.weiny@intel.com,
andriy.shevchenko@linux.intel.com, leon@kernel.org,
lukas@wunner.de, bhelgaas@google.com, wagi@kernel.org,
djeffery@redhat.com, stuart.w.hayes@gmail.com, ptyadav@amazon.de
Subject: Re: [RFC v2 05/16] luo: luo_core: integrate with KHO
Date: Mon, 26 May 2025 10:18:45 +0300 [thread overview]
Message-ID: <aDQV1bAt0i8d95MQ@kernel.org> (raw)
In-Reply-To: <20250515182322.117840-6-pasha.tatashin@soleen.com>
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.
> 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@soleen.com>
> ---
> 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?
> +#define LUO_KHO_ENTRY_NAME "LUO"
> +#define LUO_COMPATIBLE "luo-v1"
> +
> static int __init early_liveupdate_param(char *buf)
> {
> return kstrtobool(buf, &luo_enabled);
> @@ -79,6 +88,60 @@ static inline void luo_set_state(enum liveupdate_state state)
> __luo_set_state(state);
> }
>
> +/* Called during the prepare phase, to create LUO fdt tree */
> +static int luo_fdt_setup(struct kho_serialization *ser)
> +{
> + void *fdt_out;
> + int ret;
> +
> + fdt_out = (void *)__get_free_pages(GFP_KERNEL | __GFP_ZERO,
> + get_order(LUO_FDT_SIZE));
> + if (!fdt_out) {
> + pr_err("failed to allocate FDT memory\n");
> + return -ENOMEM;
> + }
> +
> + ret = fdt_create_empty_tree(fdt_out, LUO_FDT_SIZE);
> + if (ret)
> + goto exit_free;
> +
> + ret = fdt_setprop(fdt_out, 0, "compatible", LUO_COMPATIBLE,
> + strlen(LUO_COMPATIBLE) + 1);
> + if (ret)
> + goto exit_free;
> +
> + ret = kho_preserve_phys(__pa(fdt_out), LUO_FDT_SIZE);
> + if (ret)
> + goto exit_free;
> +
> + ret = kho_add_subtree(ser, LUO_KHO_ENTRY_NAME, fdt_out);
> + if (ret)
> + goto exit_unpreserve;
> + luo_fdt_out = fdt_out;
> +
> + return 0;
> +
> +exit_unpreserve:
> + kho_unpreserve_phys(__pa(fdt_out), LUO_FDT_SIZE);
> +exit_free:
> + free_pages((unsigned long)fdt_out, get_order(LUO_FDT_SIZE));
> + pr_err("failed to prepare LUO FDT: %d\n", ret);
> +
> + return ret;
> +}
> +
> +static void luo_fdt_destroy(void)
> +{
> + kho_unpreserve_phys(__pa(luo_fdt_out), LUO_FDT_SIZE);
> + free_pages((unsigned long)luo_fdt_out, get_order(LUO_FDT_SIZE));
> + luo_fdt_out = NULL;
> +}
> +
> +static int luo_do_prepare_calls(void)
> +{
> + return 0;
> +}
> +
> static int luo_do_freeze_calls(void)
> {
> return 0;
> @@ -88,11 +151,111 @@ static void luo_do_finish_calls(void)
> {
> }
>
> -int luo_prepare(void)
> +static void luo_do_cancel_calls(void)
> +{
> +}
> +
> +static int __luo_prepare(struct kho_serialization *ser)
> {
> + int ret;
> +
> + if (down_write_killable(&luo_state_rwsem)) {
> + pr_warn("[prepare] event canceled by user\n");
> + return -EAGAIN;
> + }
> +
> + if (!is_current_luo_state(LIVEUPDATE_STATE_NORMAL)) {
> + pr_warn("Can't switch to [%s] from [%s] state\n",
> + luo_state_str[LIVEUPDATE_STATE_PREPARED],
> + LUO_STATE_STR);
> + ret = -EINVAL;
> + goto exit_unlock;
> + }
> +
> + ret = luo_fdt_setup(ser);
> + if (ret)
> + goto exit_unlock;
At this point LUO should know how many subsystems are participating in live
update, I believe it can properly size the fdt.
> +
> + ret = luo_do_prepare_calls();
> + if (ret)
> + goto exit_unlock;
> +
> + luo_set_state(LIVEUPDATE_STATE_PREPARED);
> +
> +exit_unlock:
> + up_write(&luo_state_rwsem);
> +
> + return ret;
> +}
> +
> +static int __luo_cancel(void)
> +{
> + if (down_write_killable(&luo_state_rwsem)) {
> + pr_warn("[cancel] event canceled by user\n");
> + return -EAGAIN;
> + }
> +
> + if (!is_current_luo_state(LIVEUPDATE_STATE_PREPARED) &&
> + !is_current_luo_state(LIVEUPDATE_STATE_FROZEN)) {
> + pr_warn("Can't switch to [%s] from [%s] state\n",
> + luo_state_str[LIVEUPDATE_STATE_NORMAL],
> + LUO_STATE_STR);
> + up_write(&luo_state_rwsem);
> +
> + return -EINVAL;
> + }
> +
> + luo_do_cancel_calls();
> + luo_fdt_destroy();
> + luo_set_state(LIVEUPDATE_STATE_NORMAL);
> +
> + up_write(&luo_state_rwsem);
> +
> return 0;
> }
>
> +static int luo_kho_notifier(struct notifier_block *self,
> + unsigned long cmd, void *v)
> +{
> + int ret;
> +
> + switch (cmd) {
> + case KEXEC_KHO_FINALIZE:
> + ret = __luo_prepare((struct kho_serialization *)v);
> + break;
> + case KEXEC_KHO_ABORT:
> + ret = __luo_cancel();
> + break;
> + default:
> + return NOTIFY_BAD;
> + }
> +
> + return notifier_from_errno(ret);
> +}
> +
> +static struct notifier_block luo_kho_notifier_nb = {
> + .notifier_call = luo_kho_notifier,
> +};
> +
> +/**
> + * luo_prepare - Initiate the live update preparation phase.
> + *
> + * This function is called to begin the live update process. It attempts to
> + * transition the luo to the ``LIVEUPDATE_STATE_PREPARED`` state.
> + *
> + * If the calls complete successfully, the orchestrator state is set
> + * to ``LIVEUPDATE_STATE_PREPARED``. If any call fails a
> + * ``LIVEUPDATE_CANCEL`` is sent to roll back any actions.
> + *
> + * @return 0 on success, ``-EAGAIN`` if the state change was cancelled by the
> + * user while waiting for the lock, ``-EINVAL`` if the orchestrator is not in
> + * the normal state, or a negative error code returned by the calls.
> + */
> +int luo_prepare(void)
> +{
> + return kho_finalize();
> +}
> +
> /**
> * luo_freeze() - Initiate the final freeze notification phase for live update.
> *
> @@ -188,9 +351,23 @@ int luo_finish(void)
> return 0;
> }
>
> +/**
> + * luo_cancel - Cancel the ongoing live update from prepared or frozen states.
> + *
> + * This function is called to abort a live update that is currently in the
> + * ``LIVEUPDATE_STATE_PREPARED`` state.
> + *
> + * If the state is correct, it triggers the ``LIVEUPDATE_CANCEL`` notifier chain
> + * to allow subsystems to undo any actions performed during the prepare or
> + * freeze events. Finally, the orchestrator state is transitioned back to
> + * ``LIVEUPDATE_STATE_NORMAL``.
> + *
> + * @return 0 on success, or ``-EAGAIN`` if the state change was cancelled by the
> + * user while waiting for the lock.
> + */
> int luo_cancel(void)
> {
> - return 0;
> + return kho_abort();
> }
>
> void luo_state_read_enter(void)
> @@ -205,7 +382,46 @@ void luo_state_read_exit(void)
>
> static int __init luo_startup(void)
> {
> - __luo_set_state(LIVEUPDATE_STATE_NORMAL);
> + phys_addr_t fdt_phys;
> + int ret;
> +
> + if (!kho_is_enabled()) {
> + if (luo_enabled)
> + pr_warn("Disabling liveupdate because KHO is disabled\n");
> + luo_enabled = false;
> + return 0;
> + }
> +
> + ret = register_kho_notifier(&luo_kho_notifier_nb);
> + if (ret) {
> + luo_enabled = false;
> + pr_warn("Failed to register with KHO [%d]\n", ret);
> + }
> +
> + /*
> + * Retrieve LUO subtree, and verify its format. Panic in case of
> + * exceptions, since machine devices and memory is in unpredictable
> + * state.
> + */
> + ret = kho_retrieve_subtree(LUO_KHO_ENTRY_NAME, &fdt_phys);
> + if (ret) {
> + if (ret != -ENOENT) {
> + panic("failed to retrieve FDT '%s' from KHO: %d\n",
> + LUO_KHO_ENTRY_NAME, ret);
> + }
> + __luo_set_state(LIVEUPDATE_STATE_NORMAL);
> +
> + return 0;
> + }
> +
> + luo_fdt_in = __va(fdt_phys);
> + ret = fdt_node_check_compatible(luo_fdt_in, 0, LUO_COMPATIBLE);
> + if (ret) {
> + panic("FDT '%s' is incompatible with '%s' [%d]\n",
> + LUO_KHO_ENTRY_NAME, LUO_COMPATIBLE, ret);
> + }
> +
> + __luo_set_state(LIVEUPDATE_STATE_UPDATED);
>
> return 0;
> }
> --
> 2.49.0.1101.gccaa498523-goog
>
>
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2025-05-26 7:19 UTC|newest]
Thread overview: 102+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-15 18:23 [RFC v2 00/16] Live Update Orchestrator Pasha Tatashin
2025-05-15 18:23 ` [RFC v2 01/16] kho: make debugfs interface optional Pasha Tatashin
2025-06-04 16:03 ` Pratyush Yadav
2025-06-06 16:12 ` Pasha Tatashin
2025-05-15 18:23 ` [RFC v2 02/16] kho: allow to drive kho from within kernel Pasha Tatashin
2025-05-15 18:23 ` [RFC v2 03/16] kho: add kho_unpreserve_folio/phys Pasha Tatashin
2025-06-04 15:00 ` Pratyush Yadav
2025-06-06 16:22 ` Pasha Tatashin
2025-05-15 18:23 ` [RFC v2 04/16] luo: luo_core: Live Update Orchestrator Pasha Tatashin
2025-05-26 6:31 ` Mike Rapoport
2025-05-30 5:00 ` Pasha Tatashin
2025-06-04 15:17 ` Pratyush Yadav
2025-06-07 17:11 ` Pasha Tatashin
2025-05-15 18:23 ` [RFC v2 05/16] luo: luo_core: integrate with KHO Pasha Tatashin
2025-05-26 7:18 ` Mike Rapoport [this message]
2025-06-07 17:50 ` Pasha Tatashin
2025-06-09 2:14 ` Pasha Tatashin
2025-06-04 16:00 ` Pratyush Yadav
2025-06-07 23:30 ` Pasha Tatashin
2025-06-13 14:58 ` Pratyush Yadav
2025-06-17 15:23 ` Jason Gunthorpe
2025-06-17 19:32 ` Pasha Tatashin
2025-06-18 13:11 ` Pratyush Yadav
2025-06-18 14:48 ` Pasha Tatashin
2025-06-18 16:40 ` Mike Rapoport
2025-06-18 17:00 ` Pasha Tatashin
2025-06-18 17:43 ` Pasha Tatashin
2025-06-19 12:00 ` Mike Rapoport
2025-06-19 14:22 ` Pasha Tatashin
2025-06-20 15:28 ` Pratyush Yadav
2025-06-20 16:03 ` Pasha Tatashin
2025-06-24 16:12 ` Pratyush Yadav
2025-06-24 16:55 ` Pasha Tatashin
2025-06-24 18:31 ` Jason Gunthorpe
2025-06-23 7:32 ` Mike Rapoport
2025-06-23 11:29 ` Pasha Tatashin
2025-06-25 13:46 ` Mike Rapoport
2025-05-15 18:23 ` [RFC v2 06/16] luo: luo_subsystems: add subsystem registration Pasha Tatashin
2025-05-26 7:31 ` Mike Rapoport
2025-06-07 23:42 ` Pasha Tatashin
2025-05-28 19:12 ` David Matlack
2025-06-07 23:58 ` Pasha Tatashin
2025-06-04 16:30 ` Pratyush Yadav
2025-06-08 0:04 ` Pasha Tatashin
2025-05-15 18:23 ` [RFC v2 07/16] luo: luo_subsystems: implement subsystem callbacks Pasha Tatashin
2025-05-15 18:23 ` [RFC v2 08/16] luo: luo_files: add infrastructure for FDs Pasha Tatashin
2025-05-15 23:15 ` James Houghton
2025-05-23 18:09 ` Pasha Tatashin
2025-05-26 7:55 ` Mike Rapoport
2025-06-05 11:56 ` Pratyush Yadav
2025-06-08 13:13 ` Pasha Tatashin
2025-06-05 15:56 ` Pratyush Yadav
2025-06-08 13:37 ` Pasha Tatashin
2025-06-13 15:27 ` Pratyush Yadav
2025-06-15 18:02 ` Pasha Tatashin
2025-05-15 18:23 ` [RFC v2 09/16] luo: luo_files: implement file systems callbacks Pasha Tatashin
2025-06-05 16:03 ` Pratyush Yadav
2025-06-08 13:49 ` Pasha Tatashin
2025-06-13 15:18 ` Pratyush Yadav
2025-06-13 20:26 ` Pasha Tatashin
2025-06-16 10:43 ` Pratyush Yadav
2025-06-16 14:57 ` Pasha Tatashin
2025-06-18 13:16 ` Pratyush Yadav
2025-05-15 18:23 ` [RFC v2 10/16] luo: luo_ioctl: add ioctl interface Pasha Tatashin
2025-05-26 8:42 ` Mike Rapoport
2025-06-08 15:08 ` Pasha Tatashin
2025-05-28 20:29 ` David Matlack
2025-06-08 16:32 ` Pasha Tatashin
2025-06-05 16:15 ` Pratyush Yadav
2025-06-08 16:35 ` Pasha Tatashin
2025-06-24 9:50 ` Christian Brauner
2025-06-24 14:27 ` Pasha Tatashin
2025-06-25 9:36 ` Christian Brauner
2025-06-25 16:12 ` David Matlack
2025-06-26 15:42 ` Pratyush Yadav
2025-06-26 16:24 ` David Matlack
2025-07-14 14:56 ` Pratyush Yadav
2025-07-17 16:17 ` David Matlack
2025-07-23 14:51 ` Pratyush Yadav
2025-07-06 14:33 ` Mike Rapoport
2025-07-07 12:56 ` Jason Gunthorpe
2025-06-25 16:58 ` pasha.tatashin
2025-07-06 14:24 ` Mike Rapoport
2025-07-09 21:27 ` Pratyush Yadav
2025-07-10 7:26 ` Mike Rapoport
2025-07-14 14:34 ` Jason Gunthorpe
2025-07-16 9:43 ` Greg KH
2025-05-15 18:23 ` [RFC v2 11/16] luo: luo_sysfs: add sysfs state monitoring Pasha Tatashin
2025-06-05 16:20 ` Pratyush Yadav
2025-06-08 16:36 ` Pasha Tatashin
2025-06-13 15:13 ` Pratyush Yadav
2025-05-15 18:23 ` [RFC v2 12/16] reboot: call liveupdate_reboot() before kexec Pasha Tatashin
2025-05-15 18:23 ` [RFC v2 13/16] luo: add selftests for subsystems un/registration Pasha Tatashin
2025-05-26 8:52 ` Mike Rapoport
2025-06-08 16:47 ` Pasha Tatashin
2025-05-15 18:23 ` [RFC v2 14/16] selftests/liveupdate: add subsystem/state tests Pasha Tatashin
2025-05-15 18:23 ` [RFC v2 15/16] docs: add luo documentation Pasha Tatashin
2025-05-26 9:00 ` Mike Rapoport
2025-05-15 18:23 ` [RFC v2 16/16] MAINTAINERS: add liveupdate entry Pasha Tatashin
2025-05-20 7:25 ` [RFC v2 00/16] Live Update Orchestrator Mike Rapoport
2025-05-23 18:07 ` Pasha Tatashin
2025-05-26 6:32 ` Mike Rapoport
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aDQV1bAt0i8d95MQ@kernel.org \
--to=rppt@kernel.org \
--cc=Jonathan.Cameron@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=aleksander.lobakin@intel.com \
--cc=aliceryhl@google.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=anna.schumaker@oracle.com \
--cc=axboe@kernel.dk \
--cc=bartosz.golaszewski@linaro.org \
--cc=bhelgaas@google.com \
--cc=bp@alien8.de \
--cc=changyuanl@google.com \
--cc=chenridong@huawei.com \
--cc=corbet@lwn.net \
--cc=cw00.choi@samsung.com \
--cc=dakr@kernel.org \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=david@redhat.com \
--cc=djeffery@redhat.com \
--cc=dmatlack@google.com \
--cc=graf@amazon.com \
--cc=gregkh@linuxfoundation.org \
--cc=hannes@cmpxchg.org \
--cc=hpa@zytor.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=ira.weiny@intel.com \
--cc=jannh@google.com \
--cc=jasonmiu@google.com \
--cc=joel.granados@kernel.org \
--cc=kanie@linux.alibaba.com \
--cc=leon@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux@weissschuh.net \
--cc=lukas@wunner.de \
--cc=mark.rutland@arm.com \
--cc=masahiroy@kernel.org \
--cc=mingo@redhat.com \
--cc=mmaurer@google.com \
--cc=myungjoo.ham@samsung.com \
--cc=ojeda@kernel.org \
--cc=pasha.tatashin@soleen.com \
--cc=pratyush@kernel.org \
--cc=ptyadav@amazon.de \
--cc=quic_zijuhu@quicinc.com \
--cc=rafael@kernel.org \
--cc=rdunlap@infradead.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=rostedt@goodmis.org \
--cc=song@kernel.org \
--cc=stuart.w.hayes@gmail.com \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
--cc=vincent.guittot@linaro.org \
--cc=wagi@kernel.org \
--cc=x86@kernel.org \
--cc=yesanishhere@gmail.com \
--cc=yoann.congal@smile.fr \
--cc=zhangguopeng@kylinos.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).