From: Changyuan Lyu <changyuanl@google.com>
To: bagasdotme@gmail.com, akpm@linux-foundation.org
Cc: anthony.yznaga@oracle.com, arnd@arndb.de, ashish.kalra@amd.com,
benh@kernel.crashing.org, bp@alien8.de, catalin.marinas@arm.com,
changyuanl@google.com, corbet@lwn.net,
dave.hansen@linux.intel.com, devicetree@vger.kernel.org,
dwmw2@infradead.org, ebiederm@xmission.com, graf@amazon.com,
hpa@zytor.com, jgowans@amazon.com, kexec@lists.infradead.org,
krzk@kernel.org, linux-arm-kernel@lists.infradead.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, luto@kernel.org, mark.rutland@arm.com,
mingo@redhat.com, pasha.tatashin@soleen.com,
pbonzini@redhat.com, peterz@infradead.org, ptyadav@amazon.de,
robh@kernel.org, rostedt@goodmis.org, rppt@kernel.org,
saravanak@google.com, skinsburskii@linux.microsoft.com,
tglx@linutronix.de, thomas.lendacky@amd.com, will@kernel.org,
x86@kernel.org
Subject: Re: [PATCH v7 17/18] Documentation: add documentation for KHO
Date: Wed, 7 May 2025 10:38:40 -0700 [thread overview]
Message-ID: <20250507173840.2541517-1-changyuanl@google.com> (raw)
In-Reply-To: <aBl0kUIKryH5AUD5@archie.me>
Hi Bagas,
On Tue, May 06, 2025 at 09:31:45 +0700, Bagas Sanjaya <bagasdotme@gmail.com> wrote:
> On Thu, May 01, 2025 at 03:54:24PM -0700, Changyuan Lyu wrote:
> > +This document expects that you are familiar with the base KHO
> > +:ref:`concepts <concepts>`. If you have not read
> The reference label is generic and can collide with future patches.
> It should've been disambiguated as kho_concepts instead.
I renamed `concepts` to `kho-concepts`.
> > +them yet, please do so now.
> > +
> > +Prerequisites
> > +=============
> > +
> > +KHO is available when the ``CONFIG_KEXEC_HANDOVER`` config option is set to y
> > +at compile time. Every KHO producer may have its own config option that you
> when the kernel is compiled with ``CONFIG_KEXEC_HANDOVER`` set to y.
Done.
> > +need to enable if you would like to preserve their respective state acro
> > +kexec.
> > +
> > <snipped>...
> > +First, before you perform a KHO kexec, you need to move the system into
> > +the :ref:`KHO finalization phase <finalization_phase>` ::
>
> kho_finalization_phase to disambiguate label.
>
I renamed finalization_phase to kho-finalization-phase.
> > +Next, load the target payload and kexec into it. It is important that you
> > +use the ``-s`` parameter to use the in-kernel kexec file loader, as user
> > +space kexec tooling currently has no support for KHO with the user space
> > +based file loader ::
> > +
> > + # kexec -l Image --initrd=initrd -s
> > + # kexec -e
>
> Use full paths to kernel and initramfs image.
>
Done.
> > +``/sys/kernel/debug/kho/out/scratch_len``
> > + To support continuous KHO kexecs, we need to reserve
> > + physically contiguous memory regions that will always stay
> > + available for future kexec allocations. This file describes
> > + the length of these memory regions. Kexec user space tooling
> > + can use this to determine where it should place its payload
> > + images.
>
> "Length of KHO scratch region, which is a physically contiguous memory regions
> that will always available for future kexec allocations. Kexec user space
> tools can use this file to determine where it should place its payload images."
>
Done.
> > +
> > +``/sys/kernel/debug/kho/out/scratch_phys``
> > + To support continuous KHO kexecs, we need to reserve
> > + physically contiguous memory regions that will always stay
> > + available for future kexec allocations. This file describes
> > + the physical location of these memory regions. Kexec user space
> > + tooling can use this to determine where it should place its
> > + payload images.
>
> "Physical location of KHO scratch region. Kexec user space tools can use this
> file in conjunction to scratch_phys to determine where it should place its
> payload images."
>
Done.
> > +.. SPDX-License-Identifier: GPL-2.0-or-later
> > +.. _concepts:
>
> The label can be ambiguous. It should've been _kho_concepts instead.
>
Done.
> > +.. _finalization_phase:
>
> The label should be _kho_finalization_phase.
>
Done.
> > +Generally, A KHO user serialize its state into its own FDT and instructs
> "Generally, a KHO user ..."
Done.
> > +KHO to preserve the underlying memory, such that after kexec, the new kernel
> > +can recover its state from the preserved FDT.
> > +
>
> Thanks.
>
> --
> An old man doll... just what I always wanted! - Clara
Best,
Changyuan
---- 8< ----
From: Changyuan Lyu <changyuanl@google.com>
Date: Wed, 7 May 2025 10:14:34 -0700
Subject: [PATCH] fixup! Documentation: add documentation for KHO
Signed-off-by: Changyuan Lyu <changyuanl@google.com>
---
Documentation/admin-guide/mm/kho.rst | 29 ++++++++++---------------
Documentation/core-api/kho/concepts.rst | 4 ++--
Documentation/core-api/kho/fdt.rst | 2 +-
3 files changed, 15 insertions(+), 20 deletions(-)
diff --git a/Documentation/admin-guide/mm/kho.rst b/Documentation/admin-guide/mm/kho.rst
index c64aa7aadb300..6dc18ed4b8861 100644
--- a/Documentation/admin-guide/mm/kho.rst
+++ b/Documentation/admin-guide/mm/kho.rst
@@ -8,14 +8,14 @@ Kexec HandOver (KHO) is a mechanism that allows Linux to preserve memory
regions, which could contain serialized system states, across kexec.
This document expects that you are familiar with the base KHO
-:ref:`concepts <concepts>`. If you have not read
+:ref:`concepts <kho-concepts>`. If you have not read
them yet, please do so now.
Prerequisites
=============
-KHO is available when the ``CONFIG_KEXEC_HANDOVER`` config option is set to y
-at compile time. Every KHO producer may have its own config option that you
+KHO is available when the kernel is compiled with ``CONFIG_KEXEC_HANDOVER``
+set to y. Every KHO producer may have its own config option that you
need to enable if you would like to preserve their respective state across
kexec.
@@ -29,7 +29,7 @@ Perform a KHO kexec
===================
First, before you perform a KHO kexec, you need to move the system into
-the :ref:`KHO finalization phase <finalization_phase>` ::
+the :ref:`KHO finalization phase <kho-finalization-phase>` ::
$ echo 1 > /sys/kernel/debug/kho/out/finalize
@@ -43,7 +43,7 @@ use the ``-s`` parameter to use the in-kernel kexec file loader, as user
space kexec tooling currently has no support for KHO with the user space
based file loader ::
- # kexec -l Image --initrd=initrd -s
+ # kexec -l /path/to/Image --initrd /path/to/initrd -s
# kexec -e
The new kernel will boot up and contain some of the previous kernel's state.
@@ -89,20 +89,15 @@ stabilized.
as input file for the KHO payload image.
``/sys/kernel/debug/kho/out/scratch_len``
- To support continuous KHO kexecs, we need to reserve
- physically contiguous memory regions that will always stay
- available for future kexec allocations. This file describes
- the length of these memory regions. Kexec user space tooling
- can use this to determine where it should place its payload
- images.
+ Lengths of KHO scratch regions, which are physically contiguous
+ memory regions that will always stay available for future kexec
+ allocations. Kexec user space tools can use this file to determine
+ where it should place its payload images.
``/sys/kernel/debug/kho/out/scratch_phys``
- To support continuous KHO kexecs, we need to reserve
- physically contiguous memory regions that will always stay
- available for future kexec allocations. This file describes
- the physical location of these memory regions. Kexec user space
- tooling can use this to determine where it should place its
- payload images.
+ Physical locations of KHO scratch regions. Kexec user space tools
+ can use this file in conjunction to scratch_phys to determine where
+ it should place its payload images.
``/sys/kernel/debug/kho/out/sub_fdts/``
In the KHO finalization phase, KHO producers register their own
diff --git a/Documentation/core-api/kho/concepts.rst b/Documentation/core-api/kho/concepts.rst
index f1826ac10da75..36d5c05cfb307 100644
--- a/Documentation/core-api/kho/concepts.rst
+++ b/Documentation/core-api/kho/concepts.rst
@@ -1,5 +1,5 @@
.. SPDX-License-Identifier: GPL-2.0-or-later
-.. _concepts:
+.. _kho-concepts:
=======================
Kexec Handover Concepts
@@ -56,7 +56,7 @@ for boot memory allocations and as target memory for kexec blobs, some parts
of that memory region may be reserved. These reservations are irrelevant for
the next KHO, because kexec can overwrite even the original kernel.
-.. _finalization_phase:
+.. _kho-finalization-phase:
KHO finalization phase
======================
diff --git a/Documentation/core-api/kho/fdt.rst b/Documentation/core-api/kho/fdt.rst
index 4a5d53c670d4b..62505285d60d6 100644
--- a/Documentation/core-api/kho/fdt.rst
+++ b/Documentation/core-api/kho/fdt.rst
@@ -32,7 +32,7 @@ KHO process will be bypassed.
Property ``fdt``
----------------
-Generally, A KHO user serialize its state into its own FDT and instructs
+Generally, a KHO user serialize its state into its own FDT and instructs
KHO to preserve the underlying memory, such that after kexec, the new kernel
can recover its state from the preserved FDT.
--
2.49.0.987.g0cc8ee98dc-goog
next prev parent reply other threads:[~2025-05-07 17:38 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-01 22:54 [PATCH v7 00/18] kexec: introduce Kexec HandOver (KHO) Changyuan Lyu
2025-05-01 22:54 ` [PATCH v7 01/18] memblock: add MEMBLOCK_RSRV_KERN flag Changyuan Lyu
2025-05-01 22:54 ` [PATCH v7 02/18] memblock: Add support for scratch memory Changyuan Lyu
2025-05-01 22:54 ` [PATCH v7 03/18] memblock: introduce memmap_init_kho_scratch() Changyuan Lyu
2025-05-01 22:54 ` [PATCH v7 04/18] kexec: add Kexec HandOver (KHO) generation helpers Changyuan Lyu
2025-05-01 22:54 ` [PATCH v7 05/18] kexec: add KHO parsing support Changyuan Lyu
2025-05-01 22:54 ` [PATCH v7 06/18] kexec: include asm/early_ioremap.h Changyuan Lyu
2025-05-02 0:35 ` Andrew Morton
2025-05-02 18:37 ` Changyuan Lyu
2025-05-01 22:54 ` [PATCH v7 07/18] kexec: enable KHO support for memory preservation Changyuan Lyu
2025-05-01 22:54 ` [PATCH v7 08/18] kexec: add KHO support to kexec file loads Changyuan Lyu
2025-05-01 22:54 ` [PATCH v7 09/18] kexec: add config option for KHO Changyuan Lyu
2025-05-01 22:54 ` [PATCH v7 10/18] arm64: add KHO support Changyuan Lyu
2025-05-01 22:54 ` [PATCH v7 11/18] x86/setup: use memblock_reserve_kern for memory used by kernel Changyuan Lyu
2025-05-01 22:54 ` [PATCH v7 12/18] x86/kexec: add support for passing kexec handover (KHO) data Changyuan Lyu
2025-05-02 18:39 ` Dave Hansen
2025-05-01 22:54 ` [PATCH v7 13/18] x86/e820: temporarily enable KHO scratch for memory below 1M Changyuan Lyu
2025-05-02 18:39 ` Dave Hansen
2025-05-01 22:54 ` [PATCH v7 14/18] x86/boot: make sure KASLR does not step over KHO preserved memory Changyuan Lyu
2025-05-02 18:48 ` Dave Hansen
2025-05-02 21:16 ` Mike Rapoport
2025-05-02 21:36 ` Dave Hansen
2025-05-05 20:07 ` Changyuan Lyu
2025-05-01 22:54 ` [PATCH v7 15/18] x86/Kconfig: enable kexec handover for 64 bits Changyuan Lyu
2025-05-01 22:54 ` [PATCH v7 16/18] memblock: add KHO support for reserve_mem Changyuan Lyu
2025-05-01 22:54 ` [PATCH v7 17/18] Documentation: add documentation for KHO Changyuan Lyu
2025-05-06 2:31 ` Bagas Sanjaya
2025-05-07 17:38 ` Changyuan Lyu [this message]
2025-05-07 23:54 ` Bagas Sanjaya
2025-05-01 22:54 ` [PATCH v7 18/18] Documentation: KHO: Add memblock bindings Changyuan Lyu
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=20250507173840.2541517-1-changyuanl@google.com \
--to=changyuanl@google.com \
--cc=akpm@linux-foundation.org \
--cc=anthony.yznaga@oracle.com \
--cc=arnd@arndb.de \
--cc=ashish.kalra@amd.com \
--cc=bagasdotme@gmail.com \
--cc=benh@kernel.crashing.org \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=devicetree@vger.kernel.org \
--cc=dwmw2@infradead.org \
--cc=ebiederm@xmission.com \
--cc=graf@amazon.com \
--cc=hpa@zytor.com \
--cc=jgowans@amazon.com \
--cc=kexec@lists.infradead.org \
--cc=krzk@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=pasha.tatashin@soleen.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=ptyadav@amazon.de \
--cc=robh@kernel.org \
--cc=rostedt@goodmis.org \
--cc=rppt@kernel.org \
--cc=saravanak@google.com \
--cc=skinsburskii@linux.microsoft.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=will@kernel.org \
--cc=x86@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