From: Mike Rapoport <rppt@kernel.org>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Changyuan Lyu <changyuanl@google.com>,
linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
anthony.yznaga@oracle.com, arnd@arndb.de, ashish.kalra@amd.com,
benh@kernel.crashing.org, bp@alien8.de, catalin.marinas@arm.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-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, saravanak@google.com,
skinsburskii@linux.microsoft.com, tglx@linutronix.de,
thomas.lendacky@amd.com, will@kernel.org, x86@kernel.org
Subject: Re: [PATCH v6 11/14] x86: add KHO support
Date: Tue, 29 Apr 2025 18:53:15 +0300 [thread overview]
Message-ID: <aBD165pVhOIl3_by@kernel.org> (raw)
In-Reply-To: <35c58191-f774-40cf-8d66-d1e2aaf11a62@intel.com>
On Mon, Apr 28, 2025 at 03:05:55PM -0700, Dave Hansen wrote:
> On 4/10/25 22:37, Changyuan Lyu wrote:
> > From: Alexander Graf <graf@amazon.com>
> >
> > +#ifdef CONFIG_KEXEC_HANDOVER
> > +static bool process_kho_entries(unsigned long minimum, unsigned long image_size)
> > +{
> > + struct kho_scratch *kho_scratch;
> > + struct setup_data *ptr;
> > + int i, nr_areas = 0;
>
> Do these really need actual #ifdefs or will a nice IS_ENABLED() check
> work instead?
>
> > + ptr = (struct setup_data *)(unsigned long)boot_params_ptr->hdr.setup_data;
>
> What's with the double cast?
The double cast is required for this to be compiled on 32 bits (just like
in mem_avoid_overlap). The setup_data is all u64 and to cast it to a
pointer on 32 bit it has to go via unsigned long.
If we keep actual #ifdef we can drop the double cast because KHO depends on
CONFIG_KEXEC_FILE which is only enabled for 64 bits.
> > diff --git a/arch/x86/kernel/kexec-bzimage64.c b/arch/x86/kernel/kexec-bzimage64.c
> > index 68530fad05f74..518635cc0876c 100644
> > --- a/arch/x86/kernel/kexec-bzimage64.c
> > +++ b/arch/x86/kernel/kexec-bzimage64.c
> > @@ -233,6 +233,31 @@ setup_ima_state(const struct kimage *image, struct boot_params *params,
> > #endif /* CONFIG_IMA_KEXEC */
> > }
> >
> > +static void setup_kho(const struct kimage *image, struct boot_params *params,
> > + unsigned long params_load_addr,
> > + unsigned int setup_data_offset)
> > +{
> > +#ifdef CONFIG_KEXEC_HANDOVER
>
> Can this #ifdef be replaced with IS_ENABLED()?
The KHO structures in kexec image are under #ifdef, so it won't compile
with IS_ENABLED().
> > @@ -312,6 +337,13 @@ setup_boot_parameters(struct kimage *image, struct boot_params *params,
> > sizeof(struct ima_setup_data);
> > }
> >
> > + if (IS_ENABLED(CONFIG_KEXEC_HANDOVER)) {
> > + /* Setup space to store preservation metadata */
> > + setup_kho(image, params, params_load_addr, setup_data_offset);
> > + setup_data_offset += sizeof(struct setup_data) +
> > + sizeof(struct kho_data);
> > + }
>
> This is a bit weird that it needs this IS_ENABLED() check and the
> earlier #ifdef. But I guess it's following the IMA_KEXEC code's pattern
> at least.
And with other #ifdefs as well :)
if (IS_ENABLED()) can be dropped here, but having it makes things more
explicit IMHO.
> > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> > index 766176c4f5ee8..496dae89cf95d 100644
> > --- a/arch/x86/kernel/setup.c
> > +++ b/arch/x86/kernel/setup.c
> > @@ -451,6 +451,28 @@ int __init ima_get_kexec_buffer(void **addr, size_t *size)
> > }
> > #endif
> >
> > +static void __init add_kho(u64 phys_addr, u32 data_len)
> > +{
> > +#ifdef CONFIG_KEXEC_HANDOVER
> > + struct kho_data *kho;
> > + u64 addr = phys_addr + sizeof(struct setup_data);
> > + u64 size = data_len - sizeof(struct setup_data);
> > +
> > + kho = early_memremap(addr, size);
> > + if (!kho) {
> > + pr_warn("setup: failed to memremap kho data (0x%llx, 0x%llx)\n",
> > + addr, size);
> > + return;
> > + }
> > +
> > + kho_populate(kho->fdt_addr, kho->fdt_size, kho->scratch_addr, kho->scratch_size);
> > +
> > + early_memunmap(kho, size);
> > +#else
> > + pr_warn("Passed KHO data, but CONFIG_KEXEC_HANDOVER not set. Ignoring.\n");
> > +#endif
> > +}
>
> Please axe the #ifdef in the .c file if at all possible, just like the
> others.
This one follows IMA, but it's easy to make it IS_ENABLED(). It's really up
to x86 folks preference.
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2025-04-29 16:15 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-11 5:37 [PATCH v6 00/14] kexec: introduce Kexec HandOver (KHO) Changyuan Lyu
2025-04-11 5:37 ` [PATCH v6 01/14] memblock: add MEMBLOCK_RSRV_KERN flag Changyuan Lyu
2025-04-11 5:37 ` [PATCH v6 02/14] memblock: Add support for scratch memory Changyuan Lyu
2025-04-11 5:37 ` [PATCH v6 03/14] memblock: introduce memmap_init_kho_scratch() Changyuan Lyu
2025-04-11 5:37 ` [PATCH v6 04/14] kexec: add Kexec HandOver (KHO) generation helpers Changyuan Lyu
2025-04-11 5:37 ` [PATCH v6 05/14] kexec: add KHO parsing support Changyuan Lyu
2025-04-11 5:37 ` [PATCH v6 06/14] kexec: enable KHO support for memory preservation Changyuan Lyu
2025-04-11 5:37 ` [PATCH v6 07/14] kexec: add KHO support to kexec file loads Changyuan Lyu
2025-04-11 5:37 ` [PATCH v6 08/14] kexec: add config option for KHO Changyuan Lyu
2025-04-11 5:37 ` [PATCH v6 09/14] arm64: add KHO support Changyuan Lyu
2025-04-11 5:37 ` [PATCH v6 10/14] x86/setup: use memblock_reserve_kern for memory used by kernel Changyuan Lyu
2025-04-28 22:15 ` Dave Hansen
2025-04-11 5:37 ` [PATCH v6 11/14] x86: add KHO support Changyuan Lyu
2025-04-28 22:05 ` Dave Hansen
2025-04-29 8:06 ` Mike Rapoport
2025-04-29 16:06 ` Dave Hansen
2025-04-29 16:32 ` Mike Rapoport
2025-04-29 15:53 ` Mike Rapoport [this message]
2025-04-29 16:05 ` Dave Hansen
2025-04-29 16:34 ` Mike Rapoport
2025-04-11 5:37 ` [PATCH v6 12/14] memblock: add KHO support for reserve_mem Changyuan Lyu
2025-04-22 13:31 ` Mike Rapoport
2025-04-24 8:32 ` Changyuan Lyu
2025-04-11 5:37 ` [PATCH v6 13/14] Documentation: add documentation for KHO Changyuan Lyu
2025-04-11 5:37 ` [PATCH v6 14/14] Documentation: KHO: Add memblock bindings Changyuan Lyu
2025-04-28 22:19 ` [PATCH v6 00/14] kexec: introduce Kexec HandOver (KHO) Dave Hansen
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=aBD165pVhOIl3_by@kernel.org \
--to=rppt@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=anthony.yznaga@oracle.com \
--cc=arnd@arndb.de \
--cc=ashish.kalra@amd.com \
--cc=benh@kernel.crashing.org \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=changyuanl@google.com \
--cc=corbet@lwn.net \
--cc=dave.hansen@intel.com \
--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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.