From: "Pratyush Yadav (Google)" <pratyush@kernel.org>

The term "KHO scratch" is vague and overloaded. It does not accurately
describe what the memory is for. This was discussed previously at [0].
The conclusion was to rename "KHO scratch" to "KHO bootmem", since this
is memory passed by the previous kernel for early boot allocations.

In addition, memblock does not care about the provenance of the memory.
It cares more about how it should use it. Use MEMBLOCK_KHO_NOPRSRV,
instead of MEMBLOCK_KHO_SCRATCH, to describe this memory to memblock.

This series does the renames. It also gets rid of a redundant Kconfig.

While the diffstat is big and scary, most of the changes are mechanical.
The most interesting functional change is in patch 4.

This series touches a lot of files across a lot of trees. But since all
of that is purely KHO-related code, I would like to collect ACKs from
the maintainers and take it via the liveupdate tree.

Ideally we should queue it in liveupdate/next early in the v7.4 cycle
since it will cause a lot of conflicts with other patches throughout the
KHO tree.

[0] https://lore.kernel.org/kexec/agHGOxSnP_VraH1M@kernel.org/T/#u

Pratyush Yadav (Google) (4):
  memblock: get rid of CONFIG_MEMBLOCK_KHO_SCRATCH
  memblock: rename KHO_SCRATCH to KHO_NOPRSRV
  kho: rename KHO scratch to KHO bootmem
  kho: rename kho_scratch= commandline parameter to kho_bootmem=

 .../admin-guide/kernel-parameters.txt         |  15 +-
 Documentation/admin-guide/mm/kho.rst          |  18 +-
 Documentation/core-api/kho/index.rst          |  36 +-
 arch/x86/boot/compressed/kaslr.c              |  12 +-
 arch/x86/include/uapi/asm/setup_data.h        |   4 +-
 arch/x86/kernel/e820.c                        |   2 +-
 arch/x86/kernel/kexec-bzimage64.c             |   6 +-
 arch/x86/kernel/setup.c                       |   2 +-
 arch/x86/realmode/init.c                      |   2 +-
 drivers/firmware/efi/efi-init.c               |   6 +-
 drivers/of/kexec.c                            |  16 +-
 include/asm-generic/kexec_handover.h          |   2 +-
 include/linux/kexec.h                         |   2 +-
 include/linux/kexec_handover.h                |  16 +-
 include/linux/memblock.h                      |  30 +-
 kernel/liveupdate/Kconfig                     |   1 -
 kernel/liveupdate/kexec_handover.c            | 340 +++++++++---------
 kernel/liveupdate/kexec_handover_debugfs.c    |  24 +-
 kernel/liveupdate/kexec_handover_internal.h   |   4 +-
 mm/Kconfig                                    |   4 -
 mm/memblock.c                                 |  56 +--
 mm/mm_init.c                                  |   6 +-
 tools/testing/memblock/internal.h             |   2 +-
 23 files changed, 302 insertions(+), 304 deletions(-)


base-commit: 352ebb57013a08679788bc18c7f9af90903db256
-- 
2.55.0.679.g6767b8d81c-goog

On Tue, Aug 11, 2026 at 06:26:36PM +0200, Pratyush Yadav wrote:
> From: "Pratyush Yadav (Google)" <pratyush@kernel.org>
> 
> The term "KHO scratch" is vague and overloaded. It does not accurately
> describe what the memory is for. This was discussed previously at [0].
> The conclusion was to rename "KHO scratch" to "KHO bootmem", since this
> is memory passed by the previous kernel for early boot allocations.
> 

This seems like a lot of churn to just rename some stuff, especially for
a term "scratch" which is very much understood to mean "temporary
working memory region" in common computing parlance.

The boot param name change would also cause breakage for existing
systems that update and depend on the scratch parameter.

Is there a non-verbiage reason to justify these changes?  Living with
"scratch" seems better than potentially breaking folks.

~Gregory

On Mon, Aug 17, 2026 at 10:42:00AM -0400, Gregory Price wrote:
> On Tue, Aug 11, 2026 at 06:26:36PM +0200, Pratyush Yadav wrote:
> > From: "Pratyush Yadav (Google)" <pratyush@kernel.org>
> > 
> > The term "KHO scratch" is vague and overloaded. It does not accurately
> > describe what the memory is for. This was discussed previously at [0].
> > The conclusion was to rename "KHO scratch" to "KHO bootmem", since this
> > is memory passed by the previous kernel for early boot allocations.
> > 
> 
> This seems like a lot of churn to just rename some stuff, especially for
> a term "scratch" which is very much understood to mean "temporary
> working memory region" in common computing parlance.
> 
> The boot param name change would also cause breakage for existing
> systems that update and depend on the scratch parameter.
> 
> Is there a non-verbiage reason to justify these changes?  Living with
> "scratch" seems better than potentially breaking folks.

I don't think these are the first breaking changes. And if the changes 
are fine, then that means more breaking changes are fine, too. So why is 
this upstream at all until the design is settled?

Rob

On Mon, Aug 17 2026, Rob Herring wrote:

> On Mon, Aug 17, 2026 at 10:42:00AM -0400, Gregory Price wrote:
>> On Tue, Aug 11, 2026 at 06:26:36PM +0200, Pratyush Yadav wrote:
>> > From: "Pratyush Yadav (Google)" <pratyush@kernel.org>
>> > 
>> > The term "KHO scratch" is vague and overloaded. It does not accurately
>> > describe what the memory is for. This was discussed previously at [0].
>> > The conclusion was to rename "KHO scratch" to "KHO bootmem", since this
>> > is memory passed by the previous kernel for early boot allocations.
>> > 
>> 
>> This seems like a lot of churn to just rename some stuff, especially for
>> a term "scratch" which is very much understood to mean "temporary
>> working memory region" in common computing parlance.

Gregory,

Maybe. The people who work with the code on a daily basis (me, Mike,
Pasha) think the rename is worthwhile because it helps us grok the code
better.

I think patch 1 and 2 should go in for sure. They make a noticeable
improvement to memblock's code. Without that, memblock might have some
memory marked as MEMBLOCK_KHO_SCRATCH that is part of "scratch" we got
from KHO, and then some other memory also marked as MEMBLOCK_KHO_SCRATCH
that we discovered at boot. Then later, the "scratch from KHO" needs to
be initialized in a different way from "scratch discovered at boot". The
rename to NOPRSRV makes it way more clear what the properties of the
memory are and how memblock should use it.

For patch 3, I am honestly surprised at how large it ended up being. But
I am in principle opposed to the idea that we should not do any
housekeeping because it might cause "churn". So I think if the end
result is better then churn shouldn't stop us.

Of course patch 3 has a lot of potential for bikeshedding so we can
argue all day on what is better.

>> 
>> The boot param name change would also cause breakage for existing
>> systems that update and depend on the scratch parameter.
>> 
>> Is there a non-verbiage reason to justify these changes?  Living with
>> "scratch" seems better than potentially breaking folks.

I renamed the commandline option because similar things have been done
in the past for other options too.

See commit c5bfece2d612 ("nohz: Switch from "extended nohz" to "full
nohz" based naming") for example. It renamed "nohz_extended" to
"nohz_full" because it is "a bit opaque and vague".

Or commit 9406415f46f6 ("sched/debug: Rename the sched_debug parameter
to sched_verbose"). Or a94e88cdd805 ("ACPICA: Tables: Avoid SSDT
installation with acpi_gbl_disable_ssdt_table_load."). Or 632ff6170647
("x86/microcode: Add microcode= cmdline parsing"). There are a handful
more.

So I think there is a bit of history of command line options being
renamed to names the developers think are better.

Also, I would imagine very few people are using kho_scratch= blindly.
Since kho=on already does a pretty good job of automatically selecting
the sizes, most people should not be using this option at all. Manual
sizing of scratch areas is tricky and should only be done very carefully
by observing each system's characteristics. And the numbers should be
re-calibrated on each kernel upgrade since a new kernel might use more
(or less) memory at boot. So really, I think the change is a lot less
disruptive than you think.

That said, I am not opposed to keeping backwards compatibility if
someone _does_ complain.

> I don't think these are the first breaking changes. And if the changes 

Rob,

What do you mean? None of the KHO's commandline options have changed
before. And KHO has no uAPI to break in the first place.

> are fine, then that means more breaking changes are fine, too. So why is 
> this upstream at all until the design is settled?
>
> Rob

-- 
Regards,
Pratyush Yadav

On Tue, Aug 18, 2026 at 12:58:55PM +0200, Pratyush Yadav wrote:
> On Mon, Aug 17 2026, Rob Herring wrote:
> 
> For patch 3, I am honestly surprised at how large it ended up being. But
> I am in principle opposed to the idea that we should not do any
> housekeeping because it might cause "churn". So I think if the end
> result is better then churn shouldn't stop us.
>

Not really concerned about churn itself, just that I didn't fully see
the value in moving from Scratch to NoPreserve - these things sort of
read the same to me.  The additional context you've provided is
reasonable, thank you for helping me understand better.

> 
> I renamed the commandline option because similar things have been done
> in the past for other options too.
> 
> See commit c5bfece2d612 ("nohz: Switch from "extended nohz" to "full
> nohz" based naming") for example. It renamed "nohz_extended" to
> "nohz_full" because it is "a bit opaque and vague".
>

Also not opposed to the rename, just worth the question since it will
break existing users. I know boot args don't have ABI guarantees, but
some are used more than others :].

>
> That said, I am not opposed to keeping backwards compatibility if
> someone _does_ complain.
> 

I think you've made the case well enough here, I appreciate the help in
understanding.

~Gregory

On Mon, Aug 17, 2026 at 09:52:31AM -0500, Rob Herring wrote:
> On Mon, Aug 17, 2026 at 10:42:00AM -0400, Gregory Price wrote:
> > 
> > Is there a non-verbiage reason to justify these changes?  Living with
> > "scratch" seems better than potentially breaking folks.
> 
> I don't think these are the first breaking changes. And if the changes 
> are fine, then that means more breaking changes are fine, too. So why is 
> this upstream at all until the design is settled?
> 

Surely we should not break deployments for the sake of renaming
something that is very arguably already aptly named?

~Gregory