From: "Huang, Kai" <kai.huang@intel.com>
To: "tglx@linutronix.de" <tglx@linutronix.de>,
"peterz@infradead.org" <peterz@infradead.org>,
"mingo@redhat.com" <mingo@redhat.com>,
"Hansen, Dave" <dave.hansen@intel.com>,
"Edgecombe, Rick P" <rick.p.edgecombe@intel.com>,
"bp@alien8.de" <bp@alien8.de>,
"kirill.shutemov@linux.intel.com"
<kirill.shutemov@linux.intel.com>
Cc: "ashish.kalra@amd.com" <ashish.kalra@amd.com>,
"dyoung@redhat.com" <dyoung@redhat.com>,
"thomas.lendacky@amd.com" <thomas.lendacky@amd.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"seanjc@google.com" <seanjc@google.com>,
"dwmw@amazon.co.uk" <dwmw@amazon.co.uk>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"bhe@redhat.com" <bhe@redhat.com>,
"Yamahata, Isaku" <isaku.yamahata@intel.com>,
"nik.borisov@suse.com" <nik.borisov@suse.com>,
"Chatre, Reinette" <reinette.chatre@intel.com>,
"hpa@zytor.com" <hpa@zytor.com>,
"sagis@google.com" <sagis@google.com>,
"david.kaplan@amd.com" <david.kaplan@amd.com>,
"x86@kernel.org" <x86@kernel.org>,
"Williams, Dan J" <dan.j.williams@intel.com>
Subject: Re: [RFC PATCH 2/5] x86/kexec: Do unconditional WBINVD for bare-metal in relocate_kernel()
Date: Wed, 19 Mar 2025 09:57:14 +0000 [thread overview]
Message-ID: <a0e5d74162354028b80912ab4fcdd0b35692090b.camel@intel.com> (raw)
In-Reply-To: <15521a8142a83acfd2f41712e4cd93a3d1a8a28d.camel@intel.com>
> >
> > > > --- a/arch/x86/kernel/machine_kexec_64.c
> > > > +++ b/arch/x86/kernel/machine_kexec_64.c
> > > > @@ -346,16 +346,9 @@ 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;
> > > > 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();
> > > > @@ -398,6 +391,11 @@ void __nocfi machine_kexec(struct kimage *image)
> > > > *
> > > > * I take advantage of this here by force loading the
> > > > * segments, before I zap the gdt with an invalid value.
> > > > + *
> > > > + * load_segments() resets GS to 0. Don't make any function call
> > > > + * after here since call depth tracking uses per-CPU variables to
> > > > + * operate (relocate_kernel() is explicitly ignored by call depth
> > > > + * tracking).
> > >
> > > I think I suggested you should call out the opportunistic change here in the
> > > log. Did you disagree?
> >
> > I replied this was suggested by David Kaplan, but I guess I forgot to reply the
> > "opportunistic" part.
> >
> > I don't think this is opportunistic change. It's a valid comment after the
> > 'host_mem_enc_active' variable and the comment around it were removed.
>
> It's valid before too. So it's a separate change.
>
I tried to understand what you mean here, but I am not sure I am following. My
thinking:
Before this code change, in the existing code there's a comment right before the
'host_mem_enc_active' variable to explain why this variable is needed (which is
because of depth tracking).
After we remove 'host_mem_enc_active' and the comment before it, there's no
comment to mention anything about depth tracking here. So comparing to the
existing code, we lost information which is actually helpful.
To still keep the helpful information about the depth tracking, a new comment is
added before load_segments().
Could you explain why this is a separate/extra change?
Nevertheless, are you looking for something like below in the changelog?
With the 'host_mem_enc_active' and the comment around it removed,
the information about depth tracking no longer exists. Expand the
comment around load_segments() to mention that due to depth tracking
no function call can be made after load_segments().
next prev parent reply other threads:[~2025-03-19 9:57 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-12 11:34 [RFC PATCH 0/5] TDX host: kexec/kdump support Kai Huang
2025-03-12 11:34 ` [RFC PATCH 1/5] x86/kexec: Do unconditional WBINVD for bare-metal in stop_this_cpu() Kai Huang
2025-03-13 18:40 ` Edgecombe, Rick P
2025-03-14 10:03 ` Huang, Kai
2025-03-14 15:11 ` Tom Lendacky
2025-03-14 16:28 ` Edgecombe, Rick P
2025-03-14 18:18 ` Tom Lendacky
2025-03-14 18:57 ` Edgecombe, Rick P
2025-03-17 10:11 ` Huang, Kai
2025-03-18 3:41 ` Edgecombe, Rick P
2025-03-20 0:03 ` Huang, Kai
2025-03-17 12:52 ` kirill.shutemov
2025-03-17 21:59 ` Edgecombe, Rick P
2025-03-19 16:41 ` Dave Hansen
2025-03-19 17:03 ` Edgecombe, Rick P
2025-03-19 21:42 ` Huang, Kai
2025-03-12 11:34 ` [RFC PATCH 2/5] x86/kexec: Do unconditional WBINVD for bare-metal in relocate_kernel() Kai Huang
2025-03-13 23:17 ` Edgecombe, Rick P
2025-03-14 9:44 ` Huang, Kai
2025-03-18 3:54 ` Edgecombe, Rick P
2025-03-19 9:57 ` Huang, Kai [this message]
2025-03-19 16:20 ` Edgecombe, Rick P
2025-03-12 11:34 ` [RFC PATCH 3/5] x86/kexec: Disable kexec/kdump on platforms with TDX partial write erratum Kai Huang
2025-03-12 23:27 ` Edgecombe, Rick P
2025-03-13 0:57 ` Huang, Kai
2025-03-13 17:18 ` Edgecombe, Rick P
2025-03-13 22:32 ` Huang, Kai
2025-03-13 22:47 ` Edgecombe, Rick P
2025-03-13 23:57 ` Huang, Kai
2025-03-14 19:03 ` Edgecombe, Rick P
2025-03-17 1:19 ` Huang, Kai
2025-03-17 23:53 ` Edgecombe, Rick P
2025-03-12 11:34 ` [RFC PATCH 4/5] x86/virt/tdx: Remove the !KEXEC_CORE dependency Kai Huang
2025-03-12 11:34 ` [RFC PATCH 5/5] x86/virt/tdx: Update the kexec section in the TDX documentation Kai Huang
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=a0e5d74162354028b80912ab4fcdd0b35692090b.camel@intel.com \
--to=kai.huang@intel.com \
--cc=ashish.kalra@amd.com \
--cc=bhe@redhat.com \
--cc=bp@alien8.de \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@intel.com \
--cc=david.kaplan@amd.com \
--cc=dwmw@amazon.co.uk \
--cc=dyoung@redhat.com \
--cc=hpa@zytor.com \
--cc=isaku.yamahata@intel.com \
--cc=kirill.shutemov@linux.intel.com \
--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
all inboxes | Powered by JetHome®