From nobody Sun Sep 14 12:34:51 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 C5999C38142 for ; Sat, 21 Jan 2023 21:35:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229895AbjAUVfh (ORCPT ); Sat, 21 Jan 2023 16:35:37 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34866 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229861AbjAUVf0 (ORCPT ); Sat, 21 Jan 2023 16:35:26 -0500 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A359E23C5A for ; Sat, 21 Jan 2023 13:35:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1674336925; x=1705872925; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=12y1YL1Y5qoTxYyqexFumwpishfssucSyiNGL/AKPlc=; b=deYoGTeW1fwQHBc/ySetJ/irV8ODII2Vmoc9eZ4r3bJ7eY+azMTuNV8w YXAQYNOlqu/sKLinhmSHzocdVsX1CGHJnCFzocy30pHgYdwuiZ2M7/kyF I0/jIyRcnM1tULq3h+OG7e+KyZl9rv9A25GhT9J4nRMMhWt0mrHGcGUOC mLwpmhmJVuQP3f9VBWWRwd00EfZvBEpLc1wUWe1243DFDDhcH0nWTojS4 8KbI9pb8eAOEk+8NcvsmGynXRFG3RZD4AC24xqI8YIie1o8fq+070jFEi +HmP5m/ESK/1A8uMISciiz1TMlWgwdOrM35VmittSzW/htTvbdE0eTb5l w==; X-IronPort-AV: E=McAfee;i="6500,9779,10597"; a="412066337" X-IronPort-AV: E=Sophos;i="5.97,235,1669104000"; d="scan'208";a="412066337" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Jan 2023 13:35:22 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10597"; a="784946318" X-IronPort-AV: E=Sophos;i="5.97,235,1669104000"; d="scan'208";a="784946318" Received: from araj-ucode.jf.intel.com ([10.23.0.19]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Jan 2023 13:35:21 -0800 From: Ashok Raj To: Thomas Gleixner , Borislav Petkov Cc: Ashok Raj , LKML , x86 , Ingo Molnar , Tony Luck , Dave Hansen , Alison Schofield , Reinette Chatre , Tom Lendacky , Stefan Talpalaru , David Woodhouse , Benjamin Herrenschmidt , Jonathan Corbet , "Rafael J . Wysocki" , Peter Zilstra , Andy Lutomirski , Andrew Cooper , Boris Ostrovsky , Martin Pohlack Subject: [Part 2 v2[cleanup] 4/4] x86/microcode: Do not call apply_microde() on sibling threads Date: Sat, 21 Jan 2023 13:35:12 -0800 Message-Id: <20230121213512.251578-5-ashok.raj@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230121213512.251578-1-ashok.raj@intel.com> References: <87y1pygiyf.ffs@tglx> <20230121213512.251578-1-ashok.raj@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Microcode updates are applied at the core, and both threads of HT siblings will notice the update. During late-load, after the primary has updated the microcode, it also reflects that in the per-cpu structure (cpuinfo_x86) holding the current revision. Since the sibling hasn't had a chance to update the per-cpu revision, the current code calls apply_microcode() just as a way to verify and also update the per-cpu revision number. But in the odd case when primary returned with an error, the secondary will try to perform a patchload and the primary has already been released to the system. This could be problematic. Replace apply_microcode() with a call to collect_cpu_info() and let that call also update the per-cpu structure instead of returning the previously cached values. Suggested-by: Thomas Gleixner Signed-off-by: Ashok Raj Cc: LKML Cc: x86 Cc: Ingo Molnar Cc: Tony Luck Cc: Dave Hansen Cc: Alison Schofield Cc: Reinette Chatre Cc: Thomas Gleixner (Intel) Cc: Tom Lendacky Cc: Stefan Talpalaru Cc: David Woodhouse Cc: Benjamin Herrenschmidt Cc: Jonathan Corbet Cc: Rafael J. Wysocki Cc: Peter Zilstra (Intel) Cc: Andy Lutomirski Cc: Andrew Cooper Cc: Boris Ostrovsky Cc: Martin Pohlack --- arch/x86/kernel/cpu/microcode/core.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/x86/kernel/cpu/microcode/core.c b/arch/x86/kernel/cpu/mic= rocode/core.c index 6ade3d59c404..089636b1643f 100644 --- a/arch/x86/kernel/cpu/microcode/core.c +++ b/arch/x86/kernel/cpu/microcode/core.c @@ -386,6 +386,7 @@ static int __wait_for_cpus(atomic_t *t, long long timeo= ut) */ static int __reload_late(void *info) { + struct ucode_cpu_info *uci =3D ucode_cpu_info + cpu; int cpu =3D smp_processor_id(); enum ucode_state err; int ret =3D 0; @@ -422,12 +423,11 @@ static int __reload_late(void *info) =20 /* * At least one thread has completed update on each core. - * For others, simply call the update to make sure the - * per-cpu cpuinfo can be updated with right microcode - * revision. + * For siblings, collect the cpuinfo and update the + * per-cpu cpuinfo with the current microcode revision. */ if (cpumask_first(topology_sibling_cpumask(cpu)) !=3D cpu) - err =3D microcode_ops->apply_microcode(cpu); + microcode_ops->collect_cpu_info(cpu, &uci->cpu_sig); =20 return ret; } --=20 2.34.1