From: "Huang, Kai" <kai.huang@intel.com>
To: "thomas.lendacky@amd.com" <thomas.lendacky@amd.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"peterz@infradead.org" <peterz@infradead.org>,
"Hansen, Dave" <dave.hansen@intel.com>,
"mingo@redhat.com" <mingo@redhat.com>,
"bp@alien8.de" <bp@alien8.de>, "hpa@zytor.com" <hpa@zytor.com>
Cc: "ashish.kalra@amd.com" <ashish.kalra@amd.com>,
"Edgecombe, Rick P" <rick.p.edgecombe@intel.com>,
"seanjc@google.com" <seanjc@google.com>,
"x86@kernel.org" <x86@kernel.org>,
"kas@kernel.org" <kas@kernel.org>,
"Gao, Chao" <chao.gao@intel.com>,
"Chatre, Reinette" <reinette.chatre@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Williams, Dan J" <dan.j.williams@intel.com>,
"sagis@google.com" <sagis@google.com>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"dwmw@amazon.co.uk" <dwmw@amazon.co.uk>,
"Yamahata, Isaku" <isaku.yamahata@intel.com>,
"nik.borisov@suse.com" <nik.borisov@suse.com>
Subject: Re: [PATCH v4 1/7] x86/kexec: Consolidate relocate_kernel() function parameters
Date: Mon, 21 Jul 2025 21:20:08 +0000 [thread overview]
Message-ID: <45ecb02603958fa6b741a87bc415ec2639604faa.camel@intel.com> (raw)
In-Reply-To: <5dc4745c-4608-a070-d8a8-6afb6f9b14a9@amd.com>
On Mon, 2025-07-21 at 09:40 -0500, Tom Lendacky wrote:
> On 7/17/25 16:46, Kai Huang wrote:
> > During kexec, the kernel jumps to the new kernel in relocate_kernel(),
> > which is implemented in assembly and both 32-bit and 64-bit have their
> > own version.
> >
> > Currently, for both 32-bit and 64-bit, the last two parameters of the
> > relocate_kernel() are both 'unsigned int' but actually they only convey
> > a boolean, i.e., one bit information. The 'unsigned int' has enough
> > space to carry two bits information therefore there's no need to pass
> > the two booleans in two separate 'unsigned int'.
> >
> > Consolidate the last two function parameters of relocate_kernel() into a
> > single 'unsigned int' and pass flags instead.
> >
> > Only consolidate the 64-bit version albeit the similar optimization can
> > be done for the 32-bit version too. Don't bother changing the 32-bit
> > version while it is working (since assembly code change is required).
> >
> > Signed-off-by: Kai Huang <kai.huang@intel.com>
> > ---
> > arch/x86/include/asm/kexec.h | 12 ++++++++++--
> > arch/x86/kernel/machine_kexec_64.c | 22 +++++++++++++---------
> > arch/x86/kernel/relocate_kernel_64.S | 19 +++++++++----------
> > 3 files changed, 32 insertions(+), 21 deletions(-)
> >
> > diff --git a/arch/x86/include/asm/kexec.h b/arch/x86/include/asm/kexec.h
> > index f2ad77929d6e..5f09791dc4e9 100644
> > --- a/arch/x86/include/asm/kexec.h
> > +++ b/arch/x86/include/asm/kexec.h
> > @@ -13,6 +13,15 @@
> > # define KEXEC_DEBUG_EXC_HANDLER_SIZE 6 /* PUSHI, PUSHI, 2-byte JMP */
> > #endif
> >
> > +#ifdef CONFIG_X86_64
> > +
> > +#include <linux/bits.h>
> > +
> > +#define RELOC_KERNEL_PRESERVE_CONTEXT BIT(0)
> > +#define RELOC_KERNEL_HOST_MEM_ACTIVE BIT(1)
>
> This isn't as descriptive with "ENC" removed from the name. It's almost
> like you read this and think it should always be 1 because the kernel
> always has host memory active.
Hi Tom,
Thanks for review.
Right. I'll add "ENC" to the name.
>
> > +
> > +#endif
> > +
> > # define KEXEC_CONTROL_PAGE_SIZE 4096
> > # define KEXEC_CONTROL_CODE_MAX_SIZE 2048
> >
> > @@ -121,8 +130,7 @@ typedef unsigned long
> > relocate_kernel_fn(unsigned long indirection_page,
> > unsigned long pa_control_page,
> > unsigned long start_address,
> > - unsigned int preserve_context,
> > - unsigned int host_mem_enc_active);
> > + unsigned int flags);
> > #endif
> > extern relocate_kernel_fn relocate_kernel;
> > #define ARCH_HAS_KIMAGE_ARCH
> > diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c
> > index 697fb99406e6..25cff38f5e60 100644
> > --- a/arch/x86/kernel/machine_kexec_64.c
> > +++ b/arch/x86/kernel/machine_kexec_64.c
> > @@ -384,16 +384,10 @@ void __nocfi machine_kexec(struct kimage *image)
> > {
> > unsigned long reloc_start = (unsigned long)__relocate_kernel_start;
> > relocate_kernel_fn *relocate_kernel_ptr;
> > - unsigned int host_mem_enc_active;
> > + unsigned int relocate_kernel_flags;
> > int save_ftrace_enabled;
> > void *control_page;
> >
> > - /*
> > - * This must be done before load_segments() since if call depth tracking
> > - * is used then GS must be valid to make any function calls.
> > - */
> > - host_mem_enc_active = cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT);
> > -
> > #ifdef CONFIG_KEXEC_JUMP
> > if (image->preserve_context)
> > save_processor_state();
> > @@ -427,6 +421,17 @@ void __nocfi machine_kexec(struct kimage *image)
> > */
> > relocate_kernel_ptr = control_page + (unsigned long)relocate_kernel - reloc_start;
> >
> > + relocate_kernel_flags = 0;
> > + if (image->preserve_context)
> > + relocate_kernel_flags |= RELOC_KERNEL_PRESERVE_CONTEXT;
> > +
> > + /*
> > + * This must be done before load_segments() since if call depth tracking
> > + * is used then GS must be valid to make any function calls.
> > + */
> > + if (cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT))
> > + relocate_kernel_flags |= RELOC_KERNEL_HOST_MEM_ACTIVE;
> > +
> > /*
> > * The segment registers are funny things, they have both a
> > * visible and an invisible part. Whenever the visible part is
> > @@ -443,8 +448,7 @@ void __nocfi machine_kexec(struct kimage *image)
> > image->start = relocate_kernel_ptr((unsigned long)image->head,
> > virt_to_phys(control_page),
> > image->start,
> > - image->preserve_context,
> > - host_mem_enc_active);
> > + relocate_kernel_flags);
> >
> > #ifdef CONFIG_KEXEC_JUMP
> > if (image->preserve_context)
> > diff --git a/arch/x86/kernel/relocate_kernel_64.S b/arch/x86/kernel/relocate_kernel_64.S
> > index ea604f4d0b52..1dfa323b33d5 100644
> > --- a/arch/x86/kernel/relocate_kernel_64.S
> > +++ b/arch/x86/kernel/relocate_kernel_64.S
> > @@ -66,8 +66,7 @@ SYM_CODE_START_NOALIGN(relocate_kernel)
> > * %rdi indirection_page
> > * %rsi pa_control_page
> > * %rdx start address
> > - * %rcx preserve_context
> > - * %r8 host_mem_enc_active
> > + * %rcx flags: RELOC_KERNEL_*
> > */
> >
> > /* Save the CPU context, used for jumping back */
> > @@ -111,7 +110,7 @@ SYM_CODE_START_NOALIGN(relocate_kernel)
> > /* save indirection list for jumping back */
> > movq %rdi, pa_backup_pages_map(%rip)
> >
> > - /* Save the preserve_context to %r11 as swap_pages clobbers %rcx. */
> > + /* Save the flags to %r11 as swap_pages clobbers %rcx. */
> > movq %rcx, %r11
> >
> > /* setup a new stack at the end of the physical control page */
> > @@ -129,9 +128,8 @@ SYM_CODE_START_LOCAL_NOALIGN(identity_mapped)
> > /*
> > * %rdi indirection page
> > * %rdx start address
> > - * %r8 host_mem_enc_active
> > * %r9 page table page
> > - * %r11 preserve_context
> > + * %r11 flags: RELOC_KERNEL_*
> > * %r13 original CR4 when relocate_kernel() was invoked
> > */
> >
> > @@ -204,7 +202,7 @@ SYM_CODE_START_LOCAL_NOALIGN(identity_mapped)
> > * entries that will conflict with the now unencrypted memory
> > * used by kexec. Flush the caches before copying the kernel.
> > */
> > - testq %r8, %r8
> > + testq $RELOC_KERNEL_HOST_MEM_ACTIVE, %r11
>
> Hmmm... can't both bits be set at the same time? If so, then this will
> fail. This should be doing bit tests now.
TEST instruction performs logical AND of the two operands, therefore the
above equals to:
set ZF if "R11 AND BIT(1) == 0".
Whether there's any other bits set in R11 doesn't impact the above, right?
>
> > jz .Lsme_off
> > wbinvd
> > .Lsme_off:
> > @@ -220,7 +218,7 @@ SYM_CODE_START_LOCAL_NOALIGN(identity_mapped)
> > movq %cr3, %rax
> > movq %rax, %cr3
> >
> > - testq %r11, %r11 /* preserve_context */
> > + testq $RELOC_KERNEL_PRESERVE_CONTEXT, %r11
> > jnz .Lrelocate
> >
> > /*
> > @@ -273,7 +271,7 @@ SYM_CODE_START_LOCAL_NOALIGN(identity_mapped)
> > ANNOTATE_NOENDBR
> > andq $PAGE_MASK, %r8
> > lea PAGE_SIZE(%r8), %rsp
> > - movl $1, %r11d /* Ensure preserve_context flag is set */
> > + movl $RELOC_KERNEL_PRESERVE_CONTEXT, %r11d /* Ensure preserve_context flag is set */
>
> And this will clear any value that was in r11 vs setting a single bit.
> Not sure it currently has any effect because r8 (where the memory
> encryption setting was held) is modified just before this. But if any
> bits are added in the future that are needed past here, this will be a
> problem.
Right. It's just for the
call swap_pages
right after it. Nothing else later uses RELOC_KERNEL_PRESERVE_CONTEXT or
RELOC_KERNEL_HOST_MEM_ACTIVE.
Maybe we can add a comment to remind that all other flags are not restored
so if someone wants to add a new bit and use it at a later he/she can see?
/*
* Ensure RELOC_KERNEL_PRESERVE_CONTEXT flag is set so swap_pages
* can do things correctly. Note this doesn't restore any other
* RELOC_KERNEL_* flags that were passed to relocate_kernel().
*/
>
> > call swap_pages
> > movq kexec_va_control_page(%rip), %rax
> > 0: addq $virtual_mapped - 0b, %rax
> > @@ -321,7 +319,7 @@ SYM_CODE_START_LOCAL_NOALIGN(swap_pages)
> > UNWIND_HINT_END_OF_STACK
> > /*
> > * %rdi indirection page
> > - * %r11 preserve_context
> > + * %r11 flags: RELOC_KERNEL_*
> > */
> > movq %rdi, %rcx /* Put the indirection_page in %rcx */
> > xorl %edi, %edi
> > @@ -357,7 +355,8 @@ SYM_CODE_START_LOCAL_NOALIGN(swap_pages)
> > movq %rdi, %rdx /* Save destination page to %rdx */
> > movq %rsi, %rax /* Save source page to %rax */
> >
> > - testq %r11, %r11 /* Only actually swap for ::preserve_context */
> > + /* Only actually swap for ::preserve_context */
> > + testq $RELOC_KERNEL_PRESERVE_CONTEXT, %r11
>
> Ditto here on the bit testing.
I don't see any problem? Please see above.
next prev parent reply other threads:[~2025-07-21 21:20 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-17 21:46 [PATCH v4 0/7] TDX host: kexec/kdump support Kai Huang
2025-07-17 21:46 ` [PATCH v4 1/7] x86/kexec: Consolidate relocate_kernel() function parameters Kai Huang
2025-07-21 14:40 ` Tom Lendacky
2025-07-21 21:20 ` Huang, Kai [this message]
2025-07-21 21:27 ` Tom Lendacky
2025-07-21 21:36 ` Huang, Kai
2025-07-21 23:05 ` H. Peter Anvin
2025-07-21 23:29 ` Huang, Kai
2025-07-21 23:42 ` Huang, Kai
2025-07-22 0:44 ` H. Peter Anvin
2025-07-22 0:53 ` Huang, Kai
2025-07-23 8:13 ` Huang, Kai
2025-07-22 14:58 ` Borislav Petkov
2025-07-23 2:13 ` Huang, Kai
2025-07-17 21:46 ` [PATCH v4 2/7] x86/sme: Use percpu boolean to control WBINVD during kexec Kai Huang
2025-07-17 21:46 ` [PATCH v4 3/7] x86/virt/tdx: Mark memory cache state incoherent when making SEAMCALL Kai Huang
2025-07-22 14:52 ` Chao Gao
2025-07-23 1:59 ` Huang, Kai
2025-07-23 6:47 ` Chao Gao
2025-07-17 21:46 ` [PATCH v4 4/7] x86/kexec: Disable kexec/kdump on platforms with TDX partial write erratum Kai Huang
2025-07-17 21:46 ` [PATCH v4 5/7] x86/virt/tdx: Remove the !KEXEC_CORE dependency Kai Huang
2025-07-17 21:46 ` [PATCH v4 6/7] x86/virt/tdx: Update the kexec section in the TDX documentation Kai Huang
2025-07-17 21:46 ` [PATCH v4 7/7] KVM: TDX: Explicitly do WBINVD when no more TDX SEAMCALLs Kai Huang
2025-07-21 13:08 ` [PATCH v4 0/7] TDX host: kexec/kdump support Tom Lendacky
2025-07-21 14:50 ` Tom Lendacky
2025-07-21 21:30 ` Huang, Kai
2025-07-21 21:30 ` Huang, Kai
2025-07-22 13:50 ` Paolo Bonzini
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=45ecb02603958fa6b741a87bc415ec2639604faa.camel@intel.com \
--to=kai.huang@intel.com \
--cc=ashish.kalra@amd.com \
--cc=bp@alien8.de \
--cc=chao.gao@intel.com \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@intel.com \
--cc=dwmw@amazon.co.uk \
--cc=hpa@zytor.com \
--cc=isaku.yamahata@intel.com \
--cc=kas@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=nik.borisov@suse.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=reinette.chatre@intel.com \
--cc=rick.p.edgecombe@intel.com \
--cc=sagis@google.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--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
Powered by JetHome