From: Pasha Tatashin <pasha.tatashin@soleen.com>
To: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Cc: akpm@linux-foundation.org, bhe@redhat.com, rppt@kernel.org,
jasonmiu@google.com, arnd@arndb.de, coxu@redhat.com,
dave@vasilevsky.ca, ebiggers@google.com, graf@amazon.com,
kees@kernel.org, linux-kernel@vger.kernel.org,
kexec@lists.infradead.org, linux-mm@kvack.org,
ricardo.neri@intel.com
Subject: Re: [PATCH v2 11/13] kho: Allow kexec load before KHO finalization
Date: Thu, 18 Dec 2025 22:11:37 -0500 [thread overview]
Message-ID: <CA+CK2bBg9xpkNyeWVR5+YQhpZYxSvWzB=nXV_d4D+DmzLdSB1A@mail.gmail.com> (raw)
In-Reply-To: <20251219024341.GC17600@ranerica-svr.sc.intel.com>
On Thu, Dec 18, 2025 at 9:37 PM Ricardo Neri
<ricardo.neri-calderon@linux.intel.com> wrote:
>
> On Thu, Dec 18, 2025 at 07:26:19PM -0500, Pasha Tatashin wrote:
> > On Thu, Dec 18, 2025 at 4:49 PM Ricardo Neri
> > <ricardo.neri-calderon@linux.intel.com> wrote:
> > >
> > > On Fri, Nov 14, 2025 at 02:00:00PM -0500, Pasha Tatashin wrote:
> > > > Currently, kho_fill_kimage() checks kho_out.finalized and returns
> > > > early if KHO is not yet finalized. This enforces a strict ordering where
> > > > userspace must finalize KHO *before* loading the kexec image.
> > > >
> > > > This is restrictive, as standard workflows often involve loading the
> > > > target kernel early in the lifecycle and finalizing the state (FDT)
> > > > only immediately before the reboot.
> > > >
> > > > Since the KHO FDT resides at a physical address allocated during boot
> > > > (kho_init), its location is stable. We can attach this stable address
> > > > to the kimage regardless of whether the content has been finalized yet.
> > > >
> > > > Relax the check to only require kho_enable, allowing kexec_file_load
> > > > to proceed at any time.
> > > >
> > > > Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
> > > > Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> > > > Reviewed-by: Pratyush Yadav <pratyush@kernel.org>
> > > > ---
> > > > kernel/liveupdate/kexec_handover.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
> > > > index 461d96084c12..4596e67de832 100644
> > > > --- a/kernel/liveupdate/kexec_handover.c
> > > > +++ b/kernel/liveupdate/kexec_handover.c
> > > > @@ -1550,7 +1550,7 @@ int kho_fill_kimage(struct kimage *image)
> > > > int err = 0;
> > > > struct kexec_buf scratch;
> > > >
> > > > - if (!kho_out.finalized)
> > > > + if (!kho_enable)
> > > > return 0;
> > >
> > > Hi Pasha,
> > >
> > > Using v6.19-rc1 (which has this changeset) and with:
> > >
> > > CONFIG_KEXEC_HANDOVER=y
> > > CONFIG_KEXEC_HANDOVER_ENABLE_DEFAULT=y
> > > CONFIG_LIVEUPDATE=n (i.e., nobody calling kho_finalize())
> > > no reserve_mem= entries in the kernel command line
> > >
> > > I omit doing
> > >
> > > echo 1 > /sys/kernel/debug/kho/out/finalize
> > >
> > > before doing
> > >
> > > kexec -l <kernel> --initrd=<initrd> --commandline="$(cat /proc/cmdline)"
> > > kexec -e
> >
> > Hi Ricardo,
> >
> > Thank you for reporting this bug. I created a fix here:
> > https://lore.kernel.org/lkml/20251219002355.3323896-1-pasha.tatashin@soleen.com
> >
> > Please let me know if it works.
>
> Thanks for the quick reply, Pasha. Your patch does work for me (I saw you
> will post a v2).
I have sent v2:
https://lore.kernel.org/lkml/20251219030854.3527871-1-pasha.tatashin@soleen.com
>
> From this patchset, I gather that kho_finalize() can be called multiple
> times and in-kernel users of KHO should call it when done preparing their
> subrees. Is that correct?
This is correct, we now allow it to finalize multiple times. In kernel
users can choose to do that during reboot, we also removed abort.
Pasha
next prev parent reply other threads:[~2025-12-19 3:12 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-14 18:59 [PATCH v2 00/13] kho: simplify state machine and enable dynamic updates Pasha Tatashin
2025-11-14 18:59 ` [PATCH v2 01/13] kho: Fix misleading log message in kho_populate() Pasha Tatashin
2025-11-14 18:59 ` [PATCH v2 02/13] kho: Convert __kho_abort() to return void Pasha Tatashin
2025-11-14 18:59 ` [PATCH v2 03/13] kho: Introduce high-level memory allocation API Pasha Tatashin
2025-11-14 19:33 ` Pratyush Yadav
2025-11-16 6:49 ` Lance Yang
2025-11-16 14:57 ` Pasha Tatashin
2025-11-14 18:59 ` [PATCH v2 04/13] kho: Preserve FDT folio only once during initialization Pasha Tatashin
2025-11-14 18:59 ` [PATCH v2 05/13] kho: Verify deserialization status and fix FDT alignment access Pasha Tatashin
2025-11-14 19:33 ` Pratyush Yadav
2025-11-14 18:59 ` [PATCH v2 06/13] kho: Always expose output FDT in debugfs Pasha Tatashin
2025-11-14 18:59 ` [PATCH v2 07/13] kho: Simplify serialization and remove __kho_abort Pasha Tatashin
2025-11-14 18:59 ` [PATCH v2 08/13] kho: Remove global preserved_mem_map and store state in FDT Pasha Tatashin
2025-11-14 18:59 ` [PATCH v2 09/13] kho: Remove abort functionality and support state refresh Pasha Tatashin
2025-11-14 18:59 ` [PATCH v2 10/13] kho: Update FDT dynamically for subtree addition/removal Pasha Tatashin
2025-11-15 9:40 ` Mike Rapoport
2025-11-15 14:51 ` Pasha Tatashin
2025-11-16 5:46 ` Mike Rapoport
2025-11-14 19:00 ` [PATCH v2 11/13] kho: Allow kexec load before KHO finalization Pasha Tatashin
2025-12-18 21:56 ` Ricardo Neri
2025-12-19 0:26 ` Pasha Tatashin
2025-12-19 2:43 ` Ricardo Neri
2025-12-19 3:11 ` Pasha Tatashin [this message]
2025-11-14 19:00 ` [PATCH v2 12/13] kho: Allow memory preservation state updates after finalization Pasha Tatashin
2025-11-14 19:35 ` Pratyush Yadav
2025-11-14 19:00 ` [PATCH v2 13/13] kho: Add Kconfig option to enable KHO by default Pasha Tatashin
2025-11-14 19:35 ` Pratyush Yadav
2025-11-14 21:44 ` [PATCH v2 00/13] kho: simplify state machine and enable dynamic updates Andrew Morton
2025-11-14 22:00 ` Pasha Tatashin
2025-11-14 22:06 ` Pasha Tatashin
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='CA+CK2bBg9xpkNyeWVR5+YQhpZYxSvWzB=nXV_d4D+DmzLdSB1A@mail.gmail.com' \
--to=pasha.tatashin@soleen.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=bhe@redhat.com \
--cc=coxu@redhat.com \
--cc=dave@vasilevsky.ca \
--cc=ebiggers@google.com \
--cc=graf@amazon.com \
--cc=jasonmiu@google.com \
--cc=kees@kernel.org \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ricardo.neri-calderon@linux.intel.com \
--cc=ricardo.neri@intel.com \
--cc=rppt@kernel.org \
/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