From: Tom Lendacky <thomas.lendacky@amd.com>
To: Kai Huang <kai.huang@intel.com>, linux-kernel@vger.kernel.org
Cc: x86@kernel.org, dave.hansen@intel.com, bp@alien8.de,
kirill.shutemov@linux.intel.com, tglx@linutronix.de,
mingo@redhat.com, hpa@zytor.com, luto@kernel.org,
peterz@infradead.org, rick.p.edgecombe@intel.com,
ashish.kalra@amd.com, chao.gao@intel.com, bhe@redhat.com,
nik.borisov@suse.com, pbonzini@redhat.com, seanjc@google.com
Subject: Re: [PATCH v3 1/5] x86/kexec: do unconditional WBINVD for bare-metal in stop_this_cpu()
Date: Wed, 10 Apr 2024 11:08:11 -0500 [thread overview]
Message-ID: <e94d208e-964f-cfc0-60a4-fe70db52bec1@amd.com> (raw)
In-Reply-To: <33b985a8f4346f4bcf0944eaf37193a906b11af3.1712493366.git.kai.huang@intel.com>
On 4/7/24 07:44, Kai Huang wrote:
> diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
> index b8441147eb5e..5ba8a9c1e47a 100644
> --- a/arch/x86/kernel/process.c
> +++ b/arch/x86/kernel/process.c
> @@ -813,18 +813,16 @@ void __noreturn stop_this_cpu(void *dummy)
> mcheck_cpu_clear(c);
>
> /*
> - * Use wbinvd on processors that support SME. This provides support
> - * for performing a successful kexec when going from SME inactive
> - * to SME active (or vice-versa). The cache must be cleared so that
> - * if there are entries with the same physical address, both with and
> - * without the encryption bit, they don't race each other when flushed
> - * and potentially end up with the wrong entry being committed to
> - * memory.
> + * The kernel could leave caches in incoherent state on SME/TDX
> + * capable platforms. Flush cache to avoid silent memory
> + * corruption for these platforms.
> *
> - * Test the CPUID bit directly because the machine might've cleared
> - * X86_FEATURE_SME due to cmdline options.
> + * stop_this_cpu() is not a fast path, just do unconditional
> + * WBINVD for simplicity. But only do WBINVD for bare-metal
> + * as TDX guests and SEV-ES/SEV-SNP guests will get unexpected
> + * (and unnecessary) #VE and may unable to handle.
In addition to Kirill's comment on #VE...
This last part of the comment reads a bit odd since you say
unconditional and then say only do WBINVD for bare-metal. Maybe
something like this makes it a bit clearer?:
For TDX and SEV-ES/SEV-SNP guests, a WBINVD may cause an exception (#VE
or #VC). However, all exception handling has been torn down at this
point, so this would cause the guest to crash. Since memory within these
types of guests is coherent only issue the WBINVD on bare-metal.
And you can expand the comment block out to at least 80 characters to
make it more compact.
Thanks,
Tom
> */
> - if (c->extended_cpuid_level >= 0x8000001f && (cpuid_eax(0x8000001f) & BIT(0)))
> + if (!boot_cpu_has(X86_FEATURE_HYPERVISOR))
> native_wbinvd();
>
> /*
next prev parent reply other threads:[~2024-04-10 16:08 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-07 12:44 [PATCH v3 0/5] TDX host: kexec() support Kai Huang
2024-04-07 12:44 ` [PATCH v3 1/5] x86/kexec: do unconditional WBINVD for bare-metal in stop_this_cpu() Kai Huang
2024-04-10 14:12 ` Kirill A. Shutemov
2024-04-10 21:54 ` Huang, Kai
2024-04-11 13:31 ` Kirill A. Shutemov
2024-04-11 13:53 ` Huang, Kai
2024-04-15 17:59 ` Borislav Petkov
2024-04-15 21:43 ` Huang, Kai
2024-04-10 16:08 ` Tom Lendacky [this message]
2024-04-10 16:14 ` Tom Lendacky
2024-04-10 22:26 ` Huang, Kai
2024-04-11 14:13 ` Tom Lendacky
2024-04-11 21:55 ` Huang, Kai
2024-04-07 12:44 ` [PATCH v3 2/5] x86/kexec: do unconditional WBINVD for bare-metal in relocate_kernel() Kai Huang
2024-04-10 14:15 ` Kirill A. Shutemov
2024-04-10 16:21 ` Tom Lendacky
2024-04-10 22:55 ` Huang, Kai
2024-04-11 14:25 ` Tom Lendacky
2024-04-11 21:59 ` Huang, Kai
2024-04-07 12:44 ` [PATCH v3 3/5] x86/kexec: Reset TDX private memory on platforms with TDX erratum Kai Huang
2024-04-07 12:44 ` [PATCH v3 4/5] x86/virt/tdx: Remove the !KEXEC_CORE dependency Kai Huang
2024-04-07 12:44 ` [PATCH v3 5/5] x86/virt/tdx: Add TDX memory reset notifier to reset other private pages 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=e94d208e-964f-cfc0-60a4-fe70db52bec1@amd.com \
--to=thomas.lendacky@amd.com \
--cc=ashish.kalra@amd.com \
--cc=bhe@redhat.com \
--cc=bp@alien8.de \
--cc=chao.gao@intel.com \
--cc=dave.hansen@intel.com \
--cc=hpa@zytor.com \
--cc=kai.huang@intel.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=nik.borisov@suse.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=rick.p.edgecombe@intel.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--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