[PATCH v1 0/2] powerpc: enable Kexec HandOver (KHO)

[PATCH v1 0/2] powerpc: enable Kexec HandOver (KHO)

[Sourabh Jain]

The first patch fixes the KHO scratch alignment check by moving it from
a compile-time static assertion to a runtime check. On powerpc,
CMA_MIN_ALIGNMENT_BYTES can depend on pageblock_order and it may not be a
compile-time constant with some configurations. The runtime check
allows KHO to be enabled for these configurations and disables KHO if
the required scratch alignment is not met.

The second patch enables KHO support for powerpc and adds the call to
early_init_dt_check_kho() from the powerpc architecture setup path,
where KHO information needs to be checked early during boot.
early_init_dt_check_kho() is also made public so that the powerpc code
can make use of it.

There is a generic issue with KHO scratch sizing when other memory
reservations, such as crashkernel, are made before the KHO scratch
reservation. Such reservations can be included when calculating the
scratch size and may cause the KHO scratch reservation to fail. This
will be addressed separately in a follow-up patch. To know more on
this [1]

Testing:
========
This series was tested in the following two environments with
CONFIG_TEST_KEXEC_HANDOVER enabled and the kho_test kernel module:

- pSeries LPAR
- pSeries guest running on PowerNV
- pSeries guest running on Pseries LPAR

The KHO test module successfully verified KHO state restoration:
> dmesg | grep -i kho

Linux version 7.3.0-rc4kho-ppc-upstream+ (root@ltcrain85-lp7.ltc.tadn.ibm.com) (gcc (GCC) 15.3.1 20260722 (Red Hat 15.3.1-1), GNU ld version 2.45.1-5.fc43) #2 SMP PREEMPT_DYNAMIC
KHO: found kexec handover data.
Kernel command line: BOOT_IMAGE=(ieee1275//vdevice/v-scsi@3000006b/disk@8100000000000000,gpt2)/vmlinuz-7.3.0-rc4kho-ppc-upstream+ root=/dev/mapper/fedora_root ro rd.lvm.lv=fedora
KHO: exec from: 7.3.0-rc4kho-ppc-upstream+ (count 5)
test_kho: KHO restore succeeded

Changelog:
==========

RFC: https://lore.kernel.org/all/20260821105609.983622-1-sourabhjain@linux.ibm.com/ [1]

v1:
- Drop the first patch from the RFC series, which added KEXEC_FILE as a
  dependency of KEXEC_HANDOVER, and use select instead.
- Replace the SCRATCH_ALIGNMENT_BYTES static assertion with a runtime
  check to fix the build failure on powerpc configurations where
  CMA_MIN_ALIGNMENT_BYTES is not a compile-time constant.
- Remove the CRASH_DUMP dependency from ARCH_SUPPORTS_KEXEC_HANDOVER.
- Reuse the existing early_init_dt_check_kho() function to process the
  KHO FDT properties.

Cc: Aditya Gupta <adityag@linux.ibm.com>
Cc: Alexander Graf <graf@amazon.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Baoquan He <baoquan.he@linux.dev>
Cc: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
Cc: Hari Bathini <hbathini@linux.ibm.com>
Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Pasha Tatashin <pasha.tatashin@soleen.com>
Cc: Pratyush Yadav <pratyush@kernel.org>
Cc: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Cc: Shivang Upadhyay <shivangu@linux.ibm.com>
Cc: Shrikanth Hegde <sshegde@linux.ibm.com>
Cc: linux-kernel@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org

Sourabh Jain (2):
  kho: check scratch vs CMA alignment at runtime
  powerpc: add support for Kexec HandOver (KHO)

 arch/powerpc/Kconfig               |  3 +++
 arch/powerpc/kernel/setup-common.c |  2 ++
 drivers/of/fdt.c                   |  2 +-
 include/linux/of_fdt.h             |  1 +
 kernel/liveupdate/kexec_handover.c | 23 +++++++++++++++--------
 5 files changed, 22 insertions(+), 9 deletions(-)

-- 
2.55.0

[PATCH v1 1/2] kho: check scratch vs CMA alignment at runtime

[Sourabh Jain]

KHO requires the scratch alignment to be at least CMA_MIN_ALIGNMENT_BYTES,
and this is currently enforced with a static_assert().

That assertion breaks the build on powerpc once CONFIG_KEXEC_HANDOVER is
enabled together with CONFIG_TRANSPARENT_HUGEPAGE or CONFIG_HUGETLB_PAGE:

    kernel/liveupdate/kexec_handover.c:49:39: error: expression in static assertion is not constant
       49 | static_assert(SCRATCH_ALIGNMENT_BYTES >= CMA_MIN_ALIGNMENT_BYTES);
    ./include/linux/build_bug.h:80:56: note: in definition of macro '__static_assert'
       80 | #define __static_assert(expr, msg, ...) _Static_assert(expr, msg)
          |                                                        ^~~~
    kernel/liveupdate/kexec_handover.c:49:1: note: in expansion of macro 'static_assert'
       49 | static_assert(SCRATCH_ALIGNMENT_BYTES >= CMA_MIN_ALIGNMENT_BYTES);

CMA_MIN_ALIGNMENT_BYTES depends on pageblock_order, which is not a
compile-time constant with certain configs, such as
CONFIG_HUGETLB_PAGE_SIZE_VARIABLE on powerpc. The next patch in this
series enables KHO on powerpc, so the alignment must be checked at
runtime instead.

Replace the static_assert() with a runtime check at the start of
kho_reserve_scratch(), before any scratch memory is reserved. If the
scratch alignment is smaller than the CMA minimum alignment, warn once
and disable KHO rather than continue with a misaligned reservation.

Cc: Aditya Gupta <adityag@linux.ibm.com>
Cc: Alexander Graf <graf@amazon.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Baoquan He <baoquan.he@linux.dev>
Cc: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
Cc: Hari Bathini <hbathini@linux.ibm.com>
Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Pasha Tatashin <pasha.tatashin@soleen.com>
Cc: Pratyush Yadav <pratyush@kernel.org>
Cc: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Cc: Shivang Upadhyay <shivangu@linux.ibm.com>
Cc: Shrikanth Hegde <sshegde@linux.ibm.com>
Cc: linux-kernel@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
---
 kernel/liveupdate/kexec_handover.c | 23 +++++++++++++++--------
 1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
index 7c4d86daf86d..dc76dd6b74da 100644
--- a/kernel/liveupdate/kexec_handover.c
+++ b/kernel/liveupdate/kexec_handover.c
@@ -39,15 +39,7 @@
 #include "../kexec_internal.h"
 #include "kexec_handover_internal.h"
 
-/*
- * This is the minimal alignment required by deferred struct page init.
- * deferred_init_memmap_chunk frees memory to the buddy allocator, which looks
- * at the neighboring pages (up to MAX_PAGE_ORDER) to merge them.
- * If KHO scratch is not aligned to that value, buddy can access uninitialized
- * struct pages, which can cause a crash.
- */
 #define SCRATCH_ALIGNMENT_BYTES (PAGE_SIZE * MAX_ORDER_NR_PAGES)
-static_assert(SCRATCH_ALIGNMENT_BYTES >= CMA_MIN_ALIGNMENT_BYTES);
 
 /* The magic token for preserved pages */
 #define KHO_PAGE_MAGIC 0x4b484f50U /* ASCII for 'KHOP' */
@@ -836,6 +828,21 @@ static void __init kho_reserve_scratch(void)
 	if (!kho_enable)
 		return;
 
+	/*
+	 * This is the minimal alignment required by deferred struct page init.
+	 * deferred_init_memmap_chunk frees memory to the buddy allocator, which looks
+	 * at the neighboring pages (up to MAX_PAGE_ORDER) to merge them.
+	 * If KHO scratch is not aligned to that value, buddy can access uninitialized
+	 * struct pages, which can cause a crash.
+	 */
+	if (WARN_ON_ONCE(SCRATCH_ALIGNMENT_BYTES < CMA_MIN_ALIGNMENT_BYTES)) {
+		pr_err("scratch alignment %lu < CMA minimum %lu, disabling\n",
+		       (unsigned long)SCRATCH_ALIGNMENT_BYTES,
+		       (unsigned long)CMA_MIN_ALIGNMENT_BYTES);
+		kho_enable = false;
+		return;
+	}
+
 	scratch_size_update();
 
 	/* FIXME: deal with node hot-plug/remove */
-- 
2.55.0

Re: [PATCH v1 1/2] kho: check scratch vs CMA alignment at runtime

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] kho: bypassed scratch alignment check during resume causes memory corruption
--

commit cbd7cb7f008e704b389d8dfe3306e1e83e49e8a8
Author: Sourabh Jain <sourabhjain@linux.ibm.com>

kho: check scratch vs CMA alignment at runtime

KHO requires the scratch alignment to be at least CMA_MIN_ALIGNMENT_BYTES,
which was previously enforced with a static_assert(). This commit replaces
the static_assert() with a runtime check in kho_reserve_scratch() to allow
KHO on configurations where the minimum alignment is not a constant.

> diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
> index 7c4d86daf86d5..dc76dd6b74da7 100644
> --- a/kernel/liveupdate/kexec_handover.c
> +++ b/kernel/liveupdate/kexec_handover.c

[ ... ]

> @@ -836,6 +828,21 @@ static void __init kho_reserve_scratch(void)
>  	if (!kho_enable)
>  		return;
>  
> +	/*
> +	 * This is the minimal alignment required by deferred struct page init.
> +	 * deferred_init_memmap_chunk frees memory to the buddy allocator, which looks
> +	 * at the neighboring pages (up to MAX_PAGE_ORDER) to merge them.
> +	 * If KHO scratch is not aligned to that value, buddy can access uninitialized
> +	 * struct pages, which can cause a crash.
> +	 */
> +	if (WARN_ON_ONCE(SCRATCH_ALIGNMENT_BYTES < CMA_MIN_ALIGNMENT_BYTES)) {
> +		pr_err("scratch alignment %lu < CMA minimum %lu, disabling\n",
> +		       (unsigned long)SCRATCH_ALIGNMENT_BYTES,
> +		       (unsigned long)CMA_MIN_ALIGNMENT_BYTES);
> +		kho_enable = false;
> +		return;
> +	}
> +

[Severity: High]
Does this new runtime check get bypassed during a KHO resume?

During a KHO resume, kho_memory_init() skips kho_reserve_scratch():

kernel/liveupdate/kexec_handover.c:kho_memory_init() {
	if (kho_in.scratch_phys)
		kho_mem_retrieve();
	else
		kho_reserve_scratch();
}

If a predecessor kernel passes a scratch region with a smaller alignment,
and the successor kernel has a larger pageblock_order, bypassing this check
means kho_init() will iterate over the provided scratch memory using the
successor kernel's larger pageblock_nr_pages:

kernel/liveupdate/kexec_handover.c:kho_init() {
		for (pfn = base_pfn; pfn < base_pfn + count;
		     pfn += pageblock_nr_pages)
			init_cma_reserved_pageblock(pfn_to_page(pfn));
}

Can this lead to init_cma_reserved_pageblock() overwriting state for pages
outside the actual scratch region bounds, or cause a crash in the buddy
allocator if __free_pages() is called on an unaligned PFN?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260928083226.107807-1-sourabhjain@linux.ibm.com?part=1

Re: [PATCH v1 1/2] kho: check scratch vs CMA alignment at runtime

[Sourabh Jain]

On 28/09/26 14:11, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] kho: bypassed scratch alignment check during resume causes memory corruption
> --
>
> commit cbd7cb7f008e704b389d8dfe3306e1e83e49e8a8
> Author: Sourabh Jain <sourabhjain@linux.ibm.com>
>
> kho: check scratch vs CMA alignment at runtime
>
> KHO requires the scratch alignment to be at least CMA_MIN_ALIGNMENT_BYTES,
> which was previously enforced with a static_assert(). This commit replaces
> the static_assert() with a runtime check in kho_reserve_scratch() to allow
> KHO on configurations where the minimum alignment is not a constant.
>
>> diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
>> index 7c4d86daf86d5..dc76dd6b74da7 100644
>> --- a/kernel/liveupdate/kexec_handover.c
>> +++ b/kernel/liveupdate/kexec_handover.c
> [ ... ]
>
>> @@ -836,6 +828,21 @@ static void __init kho_reserve_scratch(void)
>>   	if (!kho_enable)
>>   		return;
>>   
>> +	/*
>> +	 * This is the minimal alignment required by deferred struct page init.
>> +	 * deferred_init_memmap_chunk frees memory to the buddy allocator, which looks
>> +	 * at the neighboring pages (up to MAX_PAGE_ORDER) to merge them.
>> +	 * If KHO scratch is not aligned to that value, buddy can access uninitialized
>> +	 * struct pages, which can cause a crash.
>> +	 */
>> +	if (WARN_ON_ONCE(SCRATCH_ALIGNMENT_BYTES < CMA_MIN_ALIGNMENT_BYTES)) {
>> +		pr_err("scratch alignment %lu < CMA minimum %lu, disabling\n",
>> +		       (unsigned long)SCRATCH_ALIGNMENT_BYTES,
>> +		       (unsigned long)CMA_MIN_ALIGNMENT_BYTES);
>> +		kho_enable = false;
>> +		return;
>> +	}
>> +
> [Severity: High]
> Does this new runtime check get bypassed during a KHO resume?
>
> During a KHO resume, kho_memory_init() skips kho_reserve_scratch():
>
> kernel/liveupdate/kexec_handover.c:kho_memory_init() {
> 	if (kho_in.scratch_phys)
> 		kho_mem_retrieve();
> 	else
> 		kho_reserve_scratch();
> }
>
> If a predecessor kernel passes a scratch region with a smaller alignment,
> and the successor kernel has a larger pageblock_order, bypassing this check
> means kho_init() will iterate over the provided scratch memory using the
> successor kernel's larger pageblock_nr_pages:
>
> kernel/liveupdate/kexec_handover.c:kho_init() {
> 		for (pfn = base_pfn; pfn < base_pfn + count;
> 		     pfn += pageblock_nr_pages)
> 			init_cma_reserved_pageblock(pfn_to_page(pfn));
> }
> Can this lead to init_cma_reserved_pageblock() overwriting state for pages
> outside the actual scratch region bounds, or cause a crash in the buddy
> allocator if __free_pages() is called on an unaligned PFN?

Yes, if the kexeced kernel has a higher pageblock_order than the
kernel that initiated the kexec with KHO, this can cause problems when
the code above hands scratch-memory pages back to the buddy allocator
in the kexeced kernel.

Would it make sense to handle this by keeping only the unaligned pages
reserved and handing the remaining pages back to the buddy?

Something like this:

diff --git a/kernel/liveupdate/kexec_handover.c 
b/kernel/liveupdate/kexec_handover.c
index 2e3a36054851..dea6e7790972 100644
--- a/kernel/liveupdate/kexec_handover.c
+++ b/kernel/liveupdate/kexec_handover.c
@@ -1928,7 +1928,8 @@ static __init int kho_init(void)

         for (int i = 0; i < kho_scratch_cnt; i++) {
                 unsigned long base_pfn = PHYS_PFN(kho_scratch[i].addr);
-               unsigned long count = kho_scratch[i].size >> PAGE_SHIFT;
+              unsigned long count = ALIGN_DOWN(kho_scratch[i].size >> 
PAGE_SHIFT,
+ pageblock_nr_pages);
                 unsigned long pfn;


Thanks,
Sourabh Jain

Re: [PATCH v1 1/2] kho: check scratch vs CMA alignment at runtime

[Pratyush Yadav]

On Thu, Oct 01 2026, Sourabh Jain wrote:

> On 28/09/26 14:11, sashiko-bot@kernel.org wrote:
>> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>> - [High] kho: bypassed scratch alignment check during resume causes memory corruption
>> --
>>
>> commit cbd7cb7f008e704b389d8dfe3306e1e83e49e8a8
>> Author: Sourabh Jain <sourabhjain@linux.ibm.com>
>>
>> kho: check scratch vs CMA alignment at runtime
>>
>> KHO requires the scratch alignment to be at least CMA_MIN_ALIGNMENT_BYTES,
>> which was previously enforced with a static_assert(). This commit replaces
>> the static_assert() with a runtime check in kho_reserve_scratch() to allow
>> KHO on configurations where the minimum alignment is not a constant.
>>
>>> diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
>>> index 7c4d86daf86d5..dc76dd6b74da7 100644
>>> --- a/kernel/liveupdate/kexec_handover.c
>>> +++ b/kernel/liveupdate/kexec_handover.c
>> [ ... ]
>>
>>> @@ -836,6 +828,21 @@ static void __init kho_reserve_scratch(void)
>>>   	if (!kho_enable)
>>>   		return;
>>>   +	/*
>>> +	 * This is the minimal alignment required by deferred struct page init.
>>> +	 * deferred_init_memmap_chunk frees memory to the buddy allocator, which looks
>>> +	 * at the neighboring pages (up to MAX_PAGE_ORDER) to merge them.
>>> +	 * If KHO scratch is not aligned to that value, buddy can access uninitialized
>>> +	 * struct pages, which can cause a crash.
>>> +	 */
>>> +	if (WARN_ON_ONCE(SCRATCH_ALIGNMENT_BYTES < CMA_MIN_ALIGNMENT_BYTES)) {
>>> +		pr_err("scratch alignment %lu < CMA minimum %lu, disabling\n",
>>> +		       (unsigned long)SCRATCH_ALIGNMENT_BYTES,
>>> +		       (unsigned long)CMA_MIN_ALIGNMENT_BYTES);
>>> +		kho_enable = false;
>>> +		return;
>>> +	}
>>> +
>> [Severity: High]
>> Does this new runtime check get bypassed during a KHO resume?
>>
>> During a KHO resume, kho_memory_init() skips kho_reserve_scratch():
>>
>> kernel/liveupdate/kexec_handover.c:kho_memory_init() {
>> 	if (kho_in.scratch_phys)
>> 		kho_mem_retrieve();
>> 	else
>> 		kho_reserve_scratch();
>> }
>>
>> If a predecessor kernel passes a scratch region with a smaller alignment,
>> and the successor kernel has a larger pageblock_order, bypassing this check
>> means kho_init() will iterate over the provided scratch memory using the
>> successor kernel's larger pageblock_nr_pages:
>>
>> kernel/liveupdate/kexec_handover.c:kho_init() {
>> 		for (pfn = base_pfn; pfn < base_pfn + count;
>> 		     pfn += pageblock_nr_pages)
>> 			init_cma_reserved_pageblock(pfn_to_page(pfn));
>> }
>> Can this lead to init_cma_reserved_pageblock() overwriting state for pages
>> outside the actual scratch region bounds, or cause a crash in the buddy
>> allocator if __free_pages() is called on an unaligned PFN?
>
> Yes, if the kexeced kernel has a higher pageblock_order than the
> kernel that initiated the kexec with KHO, this can cause problems when
> the code above hands scratch-memory pages back to the buddy allocator
> in the kexeced kernel.
>
> Would it make sense to handle this by keeping only the unaligned pages
> reserved and handing the remaining pages back to the buddy?
>
> Something like this:
>
> diff --git a/kernel/liveupdate/kexec_handover.c
> b/kernel/liveupdate/kexec_handover.c
> index 2e3a36054851..dea6e7790972 100644
> --- a/kernel/liveupdate/kexec_handover.c
> +++ b/kernel/liveupdate/kexec_handover.c
> @@ -1928,7 +1928,8 @@ static __init int kho_init(void)
>
>         for (int i = 0; i < kho_scratch_cnt; i++) {
>                 unsigned long base_pfn = PHYS_PFN(kho_scratch[i].addr);
> -               unsigned long count = kho_scratch[i].size >> PAGE_SHIFT;
> +              unsigned long count = ALIGN_DOWN(kho_scratch[i].size >>
> PAGE_SHIFT,
> + pageblock_nr_pages);
>                 unsigned long pfn;

This code only runs on cold boot. So it will never run for kexec-ed
kernel. See the if (fdt) check above. It is very subtle and easy to
miss.

For kexeced kernels, the migrate type is set via
kho_scratch_migratetype() (see its callers). The logic it uses is that
if any page in the whole page block overlaps with scratch, mark it as
MIGRATE_CMA. So I think it already works with variable pageblock sizes.

>

Also, off-topic nit: your email client seems to like sending
"non-breaking space" (0xC2 0xA0 in UTF-8). For example, for indentation
in the diff above, it uses non-breaking space, and makes the diff hard
to apply. Perhaps tinker with the settings and see if you can avoid it?

-- 
Regards,
Pratyush Yadav

Re: [PATCH v1 1/2] kho: check scratch vs CMA alignment at runtime

[Mike Rapoport]

Hi,

On Mon, Sep 28, 2026 at 02:02:25PM +0530, Sourabh Jain wrote:
> KHO requires the scratch alignment to be at least CMA_MIN_ALIGNMENT_BYTES,
> and this is currently enforced with a static_assert().
> 
> That assertion breaks the build on powerpc once CONFIG_KEXEC_HANDOVER is
> enabled together with CONFIG_TRANSPARENT_HUGEPAGE or CONFIG_HUGETLB_PAGE:
> 
>     kernel/liveupdate/kexec_handover.c:49:39: error: expression in static assertion is not constant
>        49 | static_assert(SCRATCH_ALIGNMENT_BYTES >= CMA_MIN_ALIGNMENT_BYTES);
>     ./include/linux/build_bug.h:80:56: note: in definition of macro '__static_assert'
>        80 | #define __static_assert(expr, msg, ...) _Static_assert(expr, msg)
>           |                                                        ^~~~
>     kernel/liveupdate/kexec_handover.c:49:1: note: in expansion of macro 'static_assert'
>        49 | static_assert(SCRATCH_ALIGNMENT_BYTES >= CMA_MIN_ALIGNMENT_BYTES);
> 
> CMA_MIN_ALIGNMENT_BYTES depends on pageblock_order, which is not a
> compile-time constant with certain configs, such as
> CONFIG_HUGETLB_PAGE_SIZE_VARIABLE on powerpc. The next patch in this
> series enables KHO on powerpc, so the alignment must be checked at
> runtime instead.
> 
> Replace the static_assert() with a runtime check at the start of
> kho_reserve_scratch(), before any scratch memory is reserved. If the
> scratch alignment is smaller than the CMA minimum alignment, warn once
> and disable KHO rather than continue with a misaligned reservation.

Can we keep static_assert() for everything !powerpc please? 
Like something along these lines:

#ifndef CONFIG_HUGETLB_PAGE_SIZE_VARIABLE
#define check_scratch_alignment static_assert(...)
#else
static inline bool check_scratch_alignment()
{
...
}
#endif

 
> Cc: Aditya Gupta <adityag@linux.ibm.com>
> Cc: Alexander Graf <graf@amazon.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Baoquan He <baoquan.he@linux.dev>
> Cc: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
> Cc: Hari Bathini <hbathini@linux.ibm.com>
> Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
> Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Mike Rapoport <rppt@kernel.org>
> Cc: Nicholas Piggin <npiggin@gmail.com>
> Cc: Pasha Tatashin <pasha.tatashin@soleen.com>
> Cc: Pratyush Yadav <pratyush@kernel.org>
> Cc: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
> Cc: Shivang Upadhyay <shivangu@linux.ibm.com>
> Cc: Shrikanth Hegde <sshegde@linux.ibm.com>
> Cc: linux-kernel@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
> ---
>  kernel/liveupdate/kexec_handover.c | 23 +++++++++++++++--------
>  1 file changed, 15 insertions(+), 8 deletions(-)
> 
> diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
> index 7c4d86daf86d..dc76dd6b74da 100644
> --- a/kernel/liveupdate/kexec_handover.c
> +++ b/kernel/liveupdate/kexec_handover.c
> @@ -39,15 +39,7 @@
>  #include "../kexec_internal.h"
>  #include "kexec_handover_internal.h"
>  
> -/*
> - * This is the minimal alignment required by deferred struct page init.
> - * deferred_init_memmap_chunk frees memory to the buddy allocator, which looks
> - * at the neighboring pages (up to MAX_PAGE_ORDER) to merge them.
> - * If KHO scratch is not aligned to that value, buddy can access uninitialized
> - * struct pages, which can cause a crash.
> - */
>  #define SCRATCH_ALIGNMENT_BYTES (PAGE_SIZE * MAX_ORDER_NR_PAGES)
> -static_assert(SCRATCH_ALIGNMENT_BYTES >= CMA_MIN_ALIGNMENT_BYTES);
>  
>  /* The magic token for preserved pages */
>  #define KHO_PAGE_MAGIC 0x4b484f50U /* ASCII for 'KHOP' */
> @@ -836,6 +828,21 @@ static void __init kho_reserve_scratch(void)
>  	if (!kho_enable)
>  		return;
>  
> +	/*
> +	 * This is the minimal alignment required by deferred struct page init.
> +	 * deferred_init_memmap_chunk frees memory to the buddy allocator, which looks
> +	 * at the neighboring pages (up to MAX_PAGE_ORDER) to merge them.
> +	 * If KHO scratch is not aligned to that value, buddy can access uninitialized
> +	 * struct pages, which can cause a crash.
> +	 */
> +	if (WARN_ON_ONCE(SCRATCH_ALIGNMENT_BYTES < CMA_MIN_ALIGNMENT_BYTES)) {
> +		pr_err("scratch alignment %lu < CMA minimum %lu, disabling\n",
> +		       (unsigned long)SCRATCH_ALIGNMENT_BYTES,
> +		       (unsigned long)CMA_MIN_ALIGNMENT_BYTES);
> +		kho_enable = false;
> +		return;
> +	}
> +
>  	scratch_size_update();
>  
>  	/* FIXME: deal with node hot-plug/remove */
> -- 
> 2.55.0
> 

-- 
Sincerely yours,
Mike.

Re: [PATCH v1 1/2] kho: check scratch vs CMA alignment at runtime

[Sourabh Jain]

On 03/10/26 13:29, Mike Rapoport wrote:
> Hi,
>
> On Mon, Sep 28, 2026 at 02:02:25PM +0530, Sourabh Jain wrote:
>> KHO requires the scratch alignment to be at least CMA_MIN_ALIGNMENT_BYTES,
>> and this is currently enforced with a static_assert().
>>
>> That assertion breaks the build on powerpc once CONFIG_KEXEC_HANDOVER is
>> enabled together with CONFIG_TRANSPARENT_HUGEPAGE or CONFIG_HUGETLB_PAGE:
>>
>>      kernel/liveupdate/kexec_handover.c:49:39: error: expression in static assertion is not constant
>>         49 | static_assert(SCRATCH_ALIGNMENT_BYTES >= CMA_MIN_ALIGNMENT_BYTES);
>>      ./include/linux/build_bug.h:80:56: note: in definition of macro '__static_assert'
>>         80 | #define __static_assert(expr, msg, ...) _Static_assert(expr, msg)
>>            |                                                        ^~~~
>>      kernel/liveupdate/kexec_handover.c:49:1: note: in expansion of macro 'static_assert'
>>         49 | static_assert(SCRATCH_ALIGNMENT_BYTES >= CMA_MIN_ALIGNMENT_BYTES);
>>
>> CMA_MIN_ALIGNMENT_BYTES depends on pageblock_order, which is not a
>> compile-time constant with certain configs, such as
>> CONFIG_HUGETLB_PAGE_SIZE_VARIABLE on powerpc. The next patch in this
>> series enables KHO on powerpc, so the alignment must be checked at
>> runtime instead.
>>
>> Replace the static_assert() with a runtime check at the start of
>> kho_reserve_scratch(), before any scratch memory is reserved. If the
>> scratch alignment is smaller than the CMA minimum alignment, warn once
>> and disable KHO rather than continue with a misaligned reservation.
> Can we keep static_assert() for everything !powerpc please?

Yeah, that's a good idea. We can have a dynamic check for cases
where a static check is not possible.

Thanks for the suggestion.

- Sourabh Jain


> Like something along these lines:
>
> #ifndef CONFIG_HUGETLB_PAGE_SIZE_VARIABLE
> #define check_scratch_alignment static_assert(...)
> #else
> static inline bool check_scratch_alignment()
> {
> ...
> }
> #endif
>
>   
>> Cc: Aditya Gupta <adityag@linux.ibm.com>
>> Cc: Alexander Graf <graf@amazon.com>
>> Cc: Andrew Morton <akpm@linux-foundation.org>
>> Cc: Baoquan He <baoquan.he@linux.dev>
>> Cc: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
>> Cc: Hari Bathini <hbathini@linux.ibm.com>
>> Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
>> Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
>> Cc: Michael Ellerman <mpe@ellerman.id.au>
>> Cc: Mike Rapoport <rppt@kernel.org>
>> Cc: Nicholas Piggin <npiggin@gmail.com>
>> Cc: Pasha Tatashin <pasha.tatashin@soleen.com>
>> Cc: Pratyush Yadav <pratyush@kernel.org>
>> Cc: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
>> Cc: Shivang Upadhyay <shivangu@linux.ibm.com>
>> Cc: Shrikanth Hegde <sshegde@linux.ibm.com>
>> Cc: linux-kernel@vger.kernel.org
>> Cc: linuxppc-dev@lists.ozlabs.org
>> Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
>> ---
>>   kernel/liveupdate/kexec_handover.c | 23 +++++++++++++++--------
>>   1 file changed, 15 insertions(+), 8 deletions(-)
>>
>> diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
>> index 7c4d86daf86d..dc76dd6b74da 100644
>> --- a/kernel/liveupdate/kexec_handover.c
>> +++ b/kernel/liveupdate/kexec_handover.c
>> @@ -39,15 +39,7 @@
>>   #include "../kexec_internal.h"
>>   #include "kexec_handover_internal.h"
>>   
>> -/*
>> - * This is the minimal alignment required by deferred struct page init.
>> - * deferred_init_memmap_chunk frees memory to the buddy allocator, which looks
>> - * at the neighboring pages (up to MAX_PAGE_ORDER) to merge them.
>> - * If KHO scratch is not aligned to that value, buddy can access uninitialized
>> - * struct pages, which can cause a crash.
>> - */
>>   #define SCRATCH_ALIGNMENT_BYTES (PAGE_SIZE * MAX_ORDER_NR_PAGES)
>> -static_assert(SCRATCH_ALIGNMENT_BYTES >= CMA_MIN_ALIGNMENT_BYTES);
>>   
>>   /* The magic token for preserved pages */
>>   #define KHO_PAGE_MAGIC 0x4b484f50U /* ASCII for 'KHOP' */
>> @@ -836,6 +828,21 @@ static void __init kho_reserve_scratch(void)
>>   	if (!kho_enable)
>>   		return;
>>   
>> +	/*
>> +	 * This is the minimal alignment required by deferred struct page init.
>> +	 * deferred_init_memmap_chunk frees memory to the buddy allocator, which looks
>> +	 * at the neighboring pages (up to MAX_PAGE_ORDER) to merge them.
>> +	 * If KHO scratch is not aligned to that value, buddy can access uninitialized
>> +	 * struct pages, which can cause a crash.
>> +	 */
>> +	if (WARN_ON_ONCE(SCRATCH_ALIGNMENT_BYTES < CMA_MIN_ALIGNMENT_BYTES)) {
>> +		pr_err("scratch alignment %lu < CMA minimum %lu, disabling\n",
>> +		       (unsigned long)SCRATCH_ALIGNMENT_BYTES,
>> +		       (unsigned long)CMA_MIN_ALIGNMENT_BYTES);
>> +		kho_enable = false;
>> +		return;
>> +	}
>> +
>>   	scratch_size_update();
>>   
>>   	/* FIXME: deal with node hot-plug/remove */
>> -- 
>> 2.55.0
>>

Re: [PATCH v1 1/2] kho: check scratch vs CMA alignment at runtime

[Pratyush Yadav]

On Mon, Sep 28 2026, Sourabh Jain wrote:

> KHO requires the scratch alignment to be at least CMA_MIN_ALIGNMENT_BYTES,
> and this is currently enforced with a static_assert().
>
> That assertion breaks the build on powerpc once CONFIG_KEXEC_HANDOVER is
> enabled together with CONFIG_TRANSPARENT_HUGEPAGE or CONFIG_HUGETLB_PAGE:
>
>     kernel/liveupdate/kexec_handover.c:49:39: error: expression in static assertion is not constant
>        49 | static_assert(SCRATCH_ALIGNMENT_BYTES >= CMA_MIN_ALIGNMENT_BYTES);
>     ./include/linux/build_bug.h:80:56: note: in definition of macro '__static_assert'
>        80 | #define __static_assert(expr, msg, ...) _Static_assert(expr, msg)
>           |                                                        ^~~~
>     kernel/liveupdate/kexec_handover.c:49:1: note: in expansion of macro 'static_assert'
>        49 | static_assert(SCRATCH_ALIGNMENT_BYTES >= CMA_MIN_ALIGNMENT_BYTES);
>
> CMA_MIN_ALIGNMENT_BYTES depends on pageblock_order, which is not a
> compile-time constant with certain configs, such as
> CONFIG_HUGETLB_PAGE_SIZE_VARIABLE on powerpc. The next patch in this
> series enables KHO on powerpc, so the alignment must be checked at
> runtime instead.
>
> Replace the static_assert() with a runtime check at the start of
> kho_reserve_scratch(), before any scratch memory is reserved. If the
> scratch alignment is smaller than the CMA minimum alignment, warn once
> and disable KHO rather than continue with a misaligned reservation.
>
> Cc: Aditya Gupta <adityag@linux.ibm.com>
> Cc: Alexander Graf <graf@amazon.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Baoquan He <baoquan.he@linux.dev>
> Cc: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
> Cc: Hari Bathini <hbathini@linux.ibm.com>
> Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
> Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Mike Rapoport <rppt@kernel.org>
> Cc: Nicholas Piggin <npiggin@gmail.com>
> Cc: Pasha Tatashin <pasha.tatashin@soleen.com>
> Cc: Pratyush Yadav <pratyush@kernel.org>
> Cc: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
> Cc: Shivang Upadhyay <shivangu@linux.ibm.com>
> Cc: Shrikanth Hegde <sshegde@linux.ibm.com>
> Cc: linux-kernel@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
> ---
>  kernel/liveupdate/kexec_handover.c | 23 +++++++++++++++--------
>  1 file changed, 15 insertions(+), 8 deletions(-)
>
> diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
> index 7c4d86daf86d..dc76dd6b74da 100644
> --- a/kernel/liveupdate/kexec_handover.c
> +++ b/kernel/liveupdate/kexec_handover.c
> @@ -39,15 +39,7 @@
>  #include "../kexec_internal.h"
>  #include "kexec_handover_internal.h"
>  
> -/*
> - * This is the minimal alignment required by deferred struct page init.
> - * deferred_init_memmap_chunk frees memory to the buddy allocator, which looks
> - * at the neighboring pages (up to MAX_PAGE_ORDER) to merge them.
> - * If KHO scratch is not aligned to that value, buddy can access uninitialized
> - * struct pages, which can cause a crash.
> - */
>  #define SCRATCH_ALIGNMENT_BYTES (PAGE_SIZE * MAX_ORDER_NR_PAGES)
> -static_assert(SCRATCH_ALIGNMENT_BYTES >= CMA_MIN_ALIGNMENT_BYTES);
>  
>  /* The magic token for preserved pages */
>  #define KHO_PAGE_MAGIC 0x4b484f50U /* ASCII for 'KHOP' */
> @@ -836,6 +828,21 @@ static void __init kho_reserve_scratch(void)
>  	if (!kho_enable)
>  		return;
>  
> +	/*
> +	 * This is the minimal alignment required by deferred struct page init.
> +	 * deferred_init_memmap_chunk frees memory to the buddy allocator, which looks
> +	 * at the neighboring pages (up to MAX_PAGE_ORDER) to merge them.
> +	 * If KHO scratch is not aligned to that value, buddy can access uninitialized
> +	 * struct pages, which can cause a crash.
> +	 */
> +	if (WARN_ON_ONCE(SCRATCH_ALIGNMENT_BYTES < CMA_MIN_ALIGNMENT_BYTES)) {

Nit: do we need both the WARN_ON_ONCE() and the pr_err()? Can't we drop
the WARN and keep the pr_err only?

LGTM otherwise.

> +		pr_err("scratch alignment %lu < CMA minimum %lu, disabling\n",
> +		       (unsigned long)SCRATCH_ALIGNMENT_BYTES,
> +		       (unsigned long)CMA_MIN_ALIGNMENT_BYTES);
> +		kho_enable = false;
> +		return;
> +	}
> +
>  	scratch_size_update();
>  
>  	/* FIXME: deal with node hot-plug/remove */

-- 
Regards,
Pratyush Yadav

[PATCH v1 2/2] powerpc: add support for Kexec HandOver (KHO)

[Sourabh Jain]

Add the architecture bits needed to enable CONFIG_KEXEC_HANDOVER on
powerpc.

Set ARCH_SUPPORTS_KEXEC_HANDOVER for PPC64.

On the boot path, check for KHO information in the device tree before
unflatten_device_tree(). This allows a kernel booted via KHO kexec to
recover the FDT and scratch region left by the previous kernel.

Move early_init_dt_check_kho() out of the device tree implementation
and call it from setup_arch() before the device tree is unflattened.

Note:
Crashkernel reservation impacts KHO scratch reservation. Crashkernel
memory is reserved first using memblock, and this memory is included
when calculating the KHO scratch size. As a result, a large crashkernel
reservation can increase the KHO scratch size and may cause the KHO
scratch reservation to fail.

This issue also exists on other architectures and will be handled
separately.

Cc: Aditya Gupta <adityag@linux.ibm.com>
Cc: Alexander Graf <graf@amazon.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Baoquan He <baoquan.he@linux.dev>
Cc: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
Cc: Hari Bathini <hbathini@linux.ibm.com>
Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Pasha Tatashin <pasha.tatashin@soleen.com>
Cc: Pratyush Yadav <pratyush@kernel.org>
Cc: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Cc: Shivang Upadhyay <shivangu@linux.ibm.com>
Cc: Shrikanth Hegde <sshegde@linux.ibm.com>
Cc: linux-kernel@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
---
 arch/powerpc/Kconfig               | 3 +++
 arch/powerpc/kernel/setup-common.c | 2 ++
 drivers/of/fdt.c                   | 2 +-
 include/linux/of_fdt.h             | 1 +
 4 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 2580e27e4328..3517d74949d0 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -716,6 +716,9 @@ config ARCH_SELECTS_CRASH_DUMP
 	depends on CRASH_DUMP
 	select RELOCATABLE if PPC64 || 44x || PPC_85xx
 
+config ARCH_SUPPORTS_KEXEC_HANDOVER
+	def_bool PPC64
+
 config ARCH_SUPPORTS_CRASH_HOTPLUG
 	def_bool y
 	depends on PPC64
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index 4afaba19b586..53c2f1897bfe 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -923,6 +923,8 @@ void __init setup_arch(char **cmdline_p)
 	/* Set a half-reasonable default so udelay does something sensible */
 	loops_per_jiffy = 500000000 / HZ;
 
+	early_init_dt_check_kho();
+
 	/* Unflatten the device-tree passed by prom_init or kexec */
 	unflatten_device_tree();
 
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index a64afc3ded3d..69e6ad868fa3 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -926,7 +926,7 @@ void __init early_init_dt_check_for_usable_mem_range(void)
 /**
  * early_init_dt_check_kho - Decode info required for kexec handover from DT
  */
-static void __init early_init_dt_check_kho(void)
+void __init early_init_dt_check_kho(void)
 {
 	unsigned long node = chosen_node_offset;
 	u64 fdt_start, fdt_size, scratch_start, scratch_size;
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index 51dadbaa3d63..5e9d6af0c7dd 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -83,6 +83,7 @@ extern int early_init_dt_scan_root(void);
 extern bool early_init_dt_scan(void *dt_virt, phys_addr_t dt_phys);
 extern bool early_init_dt_verify(void *dt_virt, phys_addr_t dt_phys);
 extern void early_init_dt_scan_nodes(void);
+extern void early_init_dt_check_kho(void);
 
 extern const char *of_flat_dt_get_machine_name(void);
 extern const void *of_flat_dt_match_machine(const void *default_match,
-- 
2.55.0

Re: [PATCH v1 2/2] powerpc: add support for Kexec HandOver (KHO)

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] boot: late KHO initialization allows memblock to clobber preserved memory
--

commit 2f581dec390379323e7a0b4e4badb03487eea55f
Author: Sourabh Jain <sourabhjain@linux.ibm.com>

powerpc: add support for Kexec HandOver (KHO)

Add architecture bits to enable CONFIG_KEXEC_HANDOVER on powerpc. This
patch checks for KHO information in the device tree before unflattening it,
allowing a kernel booted via KHO kexec to recover the FDT and scratch region.
It also moves early_init_dt_check_kho() to be called from setup_arch().

> diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
> index 4afaba19b5867..53c2f1897bfe1 100644
> --- a/arch/powerpc/kernel/setup-common.c
> +++ b/arch/powerpc/kernel/setup-common.c
> @@ -923,6 +923,8 @@ void __init setup_arch(char **cmdline_p)
>  	/* Set a half-reasonable default so udelay does something sensible */
>  	loops_per_jiffy = 500000000 / HZ;
>  
> +	early_init_dt_check_kho();
> +
>  	/* Unflatten the device-tree passed by prom_init or kexec */
>  	unflatten_device_tree();

[Severity: High]
Does calling early_init_dt_check_kho() in setup_arch() happen too late to
protect against early memblock allocations clobbering preserved KHO memory?

The Kexec HandOver (KHO) mechanism uses a scratch memory region to strictly
confine early boot memory allocations in the successor kernel. This prevents
them from overwriting memory pages preserved by the previous kernel, and is
enforced when kho_populate() invokes memblock_set_kho_scratch_only().

However, setup_arch() is invoked from start_kernel() long after early_setup()
completes. During early_setup(), substantial dynamic memblock allocations occur
before KHO scratch memory confinement is enforced.

For example, move_device_tree() allocates memory for the FDT:

arch/powerpc/kernel/prom.c:move_device_tree() {
	...
	p = memblock_alloc_raw(size, PAGE_SIZE);
	...
}

This is called via early_init_devtree() from early_setup():

arch/powerpc/kernel/setup_64.c:early_setup() {
	...
	early_init_devtree(__va(dt_ptr));

	allocate_paca_ptrs();
	allocate_paca(boot_cpuid);
	... 
	early_init_mmu();
	...
}

Because KHO scratch-only mode has not yet been enforced during these early
allocations, could they use standard memblock policies and overwrite preserved
KHO memory state, corrupting the handover?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260928083226.107807-1-sourabhjain@linux.ibm.com?part=2

Re: [PATCH v1 2/2] powerpc: add support for Kexec HandOver (KHO)

[Pratyush Yadav]

On Mon, Sep 28 2026, sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] boot: late KHO initialization allows memblock to clobber preserved memory
> --
>
> commit 2f581dec390379323e7a0b4e4badb03487eea55f
> Author: Sourabh Jain <sourabhjain@linux.ibm.com>
>
> powerpc: add support for Kexec HandOver (KHO)
>
> Add architecture bits to enable CONFIG_KEXEC_HANDOVER on powerpc. This
> patch checks for KHO information in the device tree before unflattening it,
> allowing a kernel booted via KHO kexec to recover the FDT and scratch region.
> It also moves early_init_dt_check_kho() to be called from setup_arch().
>
>> diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
>> index 4afaba19b5867..53c2f1897bfe1 100644
>> --- a/arch/powerpc/kernel/setup-common.c
>> +++ b/arch/powerpc/kernel/setup-common.c
>> @@ -923,6 +923,8 @@ void __init setup_arch(char **cmdline_p)
>>  	/* Set a half-reasonable default so udelay does something sensible */
>>  	loops_per_jiffy = 500000000 / HZ;
>>  
>> +	early_init_dt_check_kho();
>> +
>>  	/* Unflatten the device-tree passed by prom_init or kexec */
>>  	unflatten_device_tree();
>
> [Severity: High]
> Does calling early_init_dt_check_kho() in setup_arch() happen too late to
> protect against early memblock allocations clobbering preserved KHO memory?
>
> The Kexec HandOver (KHO) mechanism uses a scratch memory region to strictly
> confine early boot memory allocations in the successor kernel. This prevents
> them from overwriting memory pages preserved by the previous kernel, and is
> enforced when kho_populate() invokes memblock_set_kho_scratch_only().
>
> However, setup_arch() is invoked from start_kernel() long after early_setup()
> completes. During early_setup(), substantial dynamic memblock allocations occur
> before KHO scratch memory confinement is enforced.
>
> For example, move_device_tree() allocates memory for the FDT:
>
> arch/powerpc/kernel/prom.c:move_device_tree() {
> 	...
> 	p = memblock_alloc_raw(size, PAGE_SIZE);
> 	...
> }
>
> This is called via early_init_devtree() from early_setup():
>
> arch/powerpc/kernel/setup_64.c:early_setup() {
> 	...
> 	early_init_devtree(__va(dt_ptr));
>
> 	allocate_paca_ptrs();
> 	allocate_paca(boot_cpuid);
> 	... 
> 	early_init_mmu();
> 	...
> }
>
> Because KHO scratch-only mode has not yet been enforced during these early
> allocations, could they use standard memblock policies and overwrite preserved
> KHO memory state, corrupting the handover?

Sashiko seems to have a point. early_init_devtree() (called from
early_setup()) already does a lot of initialization that x86's
setup_arch() does, including making memblock allocations, allowing
resize, etc.

So perhaps you need to move this early_init_dt_check_kho() call to
early_setup()?

-- 
Regards,
Pratyush Yadav