From: Usama Arif <usama.arif@bytedance.com>
To: David Woodhouse <dwmw2@infradead.org>,
Tom Lendacky <thomas.lendacky@amd.com>,
tglx@linutronix.de, kim.phillips@amd.com, brgerst@gmail.com,
"Rapan, Sabin" <sabrapan@amazon.com>
Cc: piotrgorski@cachyos.org, oleksandr@natalenko.name,
arjan@linux.intel.com, mingo@redhat.com, bp@alien8.de,
dave.hansen@linux.intel.com, hpa@zytor.com, x86@kernel.org,
pbonzini@redhat.com, paulmck@kernel.org,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
rcu@vger.kernel.org, mimoja@mimoja.de, hewenliang4@huawei.com,
seanjc@google.com, pmenzel@molgen.mpg.de,
fam.zheng@bytedance.com, punit.agrawal@bytedance.com,
simon.evans@bytedance.com, liangma@liangbit.com
Subject: Re: [External] Re: [PATCH v13 00/11] Parallel CPU bringup for x86_64
Date: Tue, 7 Mar 2023 21:00:47 +0000 [thread overview]
Message-ID: <cb82069c-cd81-1799-91c7-dea79916ab1a@bytedance.com> (raw)
In-Reply-To: <269ed38b5eed9c3a259c183d59d4f1eb5128f132.camel@infradead.org>
> diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
> index 9d956571ecc1..d194c4ffeef8 100644
> --- a/arch/x86/kernel/smpboot.c
> +++ b/arch/x86/kernel/smpboot.c
> @@ -1510,6 +1510,71 @@ void __init smp_prepare_cpus_common(void)
> set_cpu_sibling_map(0);
> }
>
> +
> +/*
> + * We can do 64-bit AP bringup in parallel if the CPU reports its APIC
> + * ID in CPUID (either leaf 0x0B if we need the full APIC ID in X2APIC
> + * mode, or leaf 0x01 if 8 bits are sufficient). Otherwise it's too
> + * hard. And not for SEV-ES guests because they can't use CPUID that
> + * early.
> + */
> +static bool __init prepare_parallel_bringup(void)
> +{
> + if (IS_ENABLED(CONFIG_X86_32) || boot_cpu_data.cpuid_level < 1)
> + return false;
> +
> + if (x2apic_mode) {
> + unsigned int eax, ebx, ecx, edx;
> +
> + if (boot_cpu_data.cpuid_level < 0xb)
> + return false;
> +
> + /*
> + * To support parallel bringup in x2apic mode, the AP will need
> + * to obtain its APIC ID from CPUID 0x0B, since CPUID 0x01 has
> + * only 8 bits. Check that it is present and seems correct.
> + */
> + cpuid_count(0xb, 0, &eax, &ebx, &ecx, &edx);
> +
> + /*
> + * AMD says that if executed with an umimplemented level in
> + * ECX, then it will return all zeroes in EAX. Intel says it
> + * will return zeroes in both EAX and EBX. Checking only EAX
> + * should be sufficient.
> + */
> + if (!eax) {
> + pr_info("Disabling parallel bringup because CPUID 0xb looks untrustworthy\n");
> + return false;
> + }
> +
> + if (IS_ENABLED(AMD_MEM_ENCRYPT) && static_branch_unlikely(&sev_es_enable_key)) {
> + pr_debug("Using SEV-ES CPUID 0xb for parallel CPU startup\n");
> + smpboot_control = STARTUP_APICID_SEV_ES;
> + } else if (cc_platform_has(CC_ATTR_GUEST_STATE_ENCRYPT)) {
> + /*
> + * Other forms of memory encryption need to implement a way of
> + * finding the APs' APIC IDs that early.
> + */
> + return false;
> + } else {
> + pr_debug("Using CPUID 0xb for parallel CPU startup\n");
> + smpboot_control = STARTUP_APICID_CPUID_0B;
I believe TDX guests with x2apic mode will end up here and enable
parallel smp if Sean was correct in this
(https://lore.kernel.org/all/Y91PoIfc2jdRv0WG@google.com/). i.e. "TDX
guest state is also encrypted, but TDX doesn't return true
CC_ATTR_GUEST_STATE_ENCRYPT.".
So I believe the above else if
(cc_platform_has(CC_ATTR_GUEST_STATE_ENCRYPT)) is not useful as thats
set for just SEV-ES guests? which is covered in the if part.
Thanks,
Usama
> + }
> + } else {
> + if (cc_platform_has(CC_ATTR_GUEST_STATE_ENCRYPT))
> + return false;
> +
> + /* Without X2APIC, what's in CPUID 0x01 should suffice. */
> + pr_debug("Using CPUID 0x1 for parallel CPU startup\n");
> + smpboot_control = STARTUP_APICID_CPUID_01;
> + }
> +
> + cpuhp_setup_state_nocalls(CPUHP_BP_PARALLEL_DYN, "x86/cpu:kick",
> + native_cpu_kick, NULL);
> +
> + return true;
> +}
> +
> /*
> * Prepare for SMP bootup.
prev parent reply other threads:[~2023-03-07 21:01 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-02 11:12 Usama Arif
2023-03-02 11:12 ` [PATCH v13 01/11] x86/apic/x2apic: Allow CPU cluster_mask to be populated in parallel Usama Arif
2023-03-02 11:12 ` [PATCH v13 02/11] cpu/hotplug: Move idle_thread_get() to <linux/smpboot.h> Usama Arif
2023-03-02 11:12 ` [PATCH v13 03/11] cpu/hotplug: Add dynamic parallel bringup states before CPUHP_BRINGUP_CPU Usama Arif
2023-03-02 11:12 ` [PATCH v13 04/11] x86/smpboot: Reference count on smpboot_setup_warm_reset_vector() Usama Arif
2023-03-02 11:12 ` [PATCH v13 05/11] x86/smpboot: Split up native_cpu_up into separate phases and document them Usama Arif
2023-03-02 11:12 ` [PATCH v13 06/11] x86/smpboot: Remove initial_stack on 64-bit Usama Arif
2023-03-02 11:12 ` [PATCH v13 07/11] x86/smpboot: Remove early_gdt_descr " Usama Arif
2023-03-02 11:12 ` [PATCH v13 08/11] x86/smpboot: Remove initial_gs Usama Arif
2023-03-02 11:12 ` [PATCH v13 09/11] x86/smpboot: Support parallel startup of secondary CPUs Usama Arif
2023-03-02 11:12 ` [PATCH v13 10/11] x86/smpboot: Send INIT/SIPI/SIPI to secondary CPUs in parallel Usama Arif
2023-03-02 11:12 ` [PATCH v13 11/11] x86/smpboot: Serialize topology updates for secondary bringup Usama Arif
2023-03-07 14:42 ` [PATCH v13 00/11] Parallel CPU bringup for x86_64 David Woodhouse
2023-03-07 16:45 ` Tom Lendacky
2023-03-07 19:18 ` David Woodhouse
2023-03-07 20:06 ` Tom Lendacky
2023-03-07 22:22 ` Tom Lendacky
2023-03-07 22:27 ` David Woodhouse
2023-03-07 22:55 ` Tom Lendacky
2023-03-08 9:04 ` David Woodhouse
2023-03-08 11:27 ` [External] " Usama Arif
2023-03-08 12:15 ` David Laight
2023-03-08 12:19 ` David Woodhouse
2023-03-08 14:10 ` [External] " Usama Arif
2023-03-08 14:40 ` Tom Lendacky
2023-03-07 23:35 ` Sean Christopherson
2023-03-08 7:38 ` David Woodhouse
2023-03-07 21:00 ` Usama Arif [this message]
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=cb82069c-cd81-1799-91c7-dea79916ab1a@bytedance.com \
--to=usama.arif@bytedance.com \
--cc=arjan@linux.intel.com \
--cc=bp@alien8.de \
--cc=brgerst@gmail.com \
--cc=dave.hansen@linux.intel.com \
--cc=dwmw2@infradead.org \
--cc=fam.zheng@bytedance.com \
--cc=hewenliang4@huawei.com \
--cc=hpa@zytor.com \
--cc=kim.phillips@amd.com \
--cc=kvm@vger.kernel.org \
--cc=liangma@liangbit.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mimoja@mimoja.de \
--cc=mingo@redhat.com \
--cc=oleksandr@natalenko.name \
--cc=paulmck@kernel.org \
--cc=pbonzini@redhat.com \
--cc=piotrgorski@cachyos.org \
--cc=pmenzel@molgen.mpg.de \
--cc=punit.agrawal@bytedance.com \
--cc=rcu@vger.kernel.org \
--cc=sabrapan@amazon.com \
--cc=seanjc@google.com \
--cc=simon.evans@bytedance.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®