From nobody Thu Dec 18 04:29:44 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0D7DBCDB47E for ; Fri, 13 Oct 2023 09:39:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231407AbjJMJjM (ORCPT ); Fri, 13 Oct 2023 05:39:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52916 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231284AbjJMJiR (ORCPT ); Fri, 13 Oct 2023 05:38:17 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5985EBE; Fri, 13 Oct 2023 02:38:15 -0700 (PDT) Date: Fri, 13 Oct 2023 09:38:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1697189893; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rCTCPgo8jeqYDUyGPCO49XEL+tzO99RT05N9qxWKWRc=; b=mm5BdMEVZPLvrOLrHF03QnQw5cfeUH3j/SaZoXapSbD4RDOOarP3e7DxQakQMpKzllDbw2 Y1BRiOkPiiRqpmwr3OAmns2GEwg7dsGzdNuDgnNX3FxB7zRV22948SbPG0Pli/5dFdGigV hKrNoQwX/J6Nf7f3/qgLwCCisG9RS6oRYGng6/Vh7ezfgIJz3khBPoosEclrPcJ1E1wSC0 uey8bGa4oCOpfAy3pMFkzWkdxWszb9qzozpKWRE5vrwRxhk5iDNNJxs3kfZg47F6T5bDHn Dcq+XmAvO4ebYJbeI5+b0bWvPUnOFA/J/WgTlNmkUyQgWV/ws81JdCGsb9HL7A== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1697189893; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rCTCPgo8jeqYDUyGPCO49XEL+tzO99RT05N9qxWKWRc=; b=DvcCmy6XUtOkXfbQxEn+2tr3mWOOVAf6mBm3vFU2LUg0vNGSxIVAIi5nH14Hyy3dMSEZF3 xlYIScSP+qSbZsBw== From: "tip-bot2 for Thomas Gleixner" Sender: tip-bot2@linutronix.de Reply-to: linux-kernel@vger.kernel.org To: linux-tip-commits@vger.kernel.org Subject: [tip: x86/core] x86/apic: Fake primary thread mask for XEN/PV Cc: Juergen Gross , Thomas Gleixner , Sohil Mehta , Michael Kelley , "Peter Zijlstra (Intel)" , Zhang Rui , x86@kernel.org, linux-kernel@vger.kernel.org In-Reply-To: <20230814085112.210011520@linutronix.de> References: <20230814085112.210011520@linutronix.de> MIME-Version: 1.0 Message-ID: <169718989311.3135.5099682715244955511.tip-bot2@tip-bot2> Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The following commit has been merged into the x86/core branch of tip: Commit-ID: 965e05ff8af98c44f9937366715c512000373164 Gitweb: https://git.kernel.org/tip/965e05ff8af98c44f9937366715c51200= 0373164 Author: Thomas Gleixner AuthorDate: Mon, 14 Aug 2023 10:18:28 +02:00 Committer: Thomas Gleixner CommitterDate: Tue, 10 Oct 2023 14:38:17 +02:00 x86/apic: Fake primary thread mask for XEN/PV The SMT control mechanism got added as speculation attack vector mitigation. The implemented logic relies on the primary thread mask to be set up properly. This turns out to be an issue with XEN/PV guests because their CPU hotplug mechanics do not enumerate APICs and therefore the mask is never correctly populated. This went unnoticed so far because by chance XEN/PV ends up with smp_num_siblings =3D=3D 2. So cpu_smt_control stays at its default value CPU_SMT_ENABLED and the primary thread mask is never evaluated in the context of CPU hotplug. This stopped "working" with the upcoming overhaul of the topology evaluation which legitimately provides a fake topology for XEN/PV. That sets smp_num_siblings to 1, which causes the core CPU hot-plug core to refuse to bring up the APs. This happens because cpu_smt_control is set to CPU_SMT_NOT_SUPPORTED which causes cpu_bootable() to evaluate the unpopulated primary thread mask with the conclusion that all non-boot CPUs are not valid to be plugged. The core code has already been made more robust against this kind of fail, but the primary thread mask really wants to be populated to avoid other issues all over the place. Just fake the mask by pretending that all XEN/PV vCPUs are primary threads, which is consistent because all of XEN/PVs topology is fake or non-existent. Fixes: 6a4d2657e048 ("x86/smp: Provide topology_is_primary_thread()") Fixes: f54d4434c281 ("x86/apic: Provide cpu_primary_thread mask") Reported-by: Juergen Gross Signed-off-by: Thomas Gleixner Tested-by: Juergen Gross Tested-by: Sohil Mehta Tested-by: Michael Kelley Tested-by: Peter Zijlstra (Intel) Tested-by: Zhang Rui Acked-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20230814085112.210011520@linutronix.de --- arch/x86/kernel/apic/apic.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c index 760adac..3cdf484 100644 --- a/arch/x86/kernel/apic/apic.c +++ b/arch/x86/kernel/apic/apic.c @@ -36,6 +36,8 @@ #include #include =20 +#include + #include #include #include @@ -2344,6 +2346,15 @@ static int __init smp_init_primary_thread_mask(void) { unsigned int cpu; =20 + /* + * XEN/PV provides either none or useless topology information. + * Pretend that all vCPUs are primary threads. + */ + if (xen_pv_domain()) { + cpumask_copy(&__cpu_primary_thread_mask, cpu_possible_mask); + return 0; + } + for (cpu =3D 0; cpu < nr_logical_cpuids; cpu++) cpu_mark_primary_thread(cpu, cpuid_to_apicid[cpu]); return 0;