Received: by 2002:a05:6358:a55:b0:ec:fcf4:3ecf with SMTP id 21csp4520365rwb; Sat, 21 Jan 2023 13:50:00 -0800 (PST) X-Google-Smtp-Source: AMrXdXss9Y9j9rkllHFzWRRw1E/bRXZqmszacnAFFi/5edRzui0Sdl7KYYgzowzOkJezEvknkpUx X-Received: by 2002:a05:6a20:9e0e:b0:b2:46c0:81a9 with SMTP id ms14-20020a056a209e0e00b000b246c081a9mr20436440pzb.30.1674337800149; Sat, 21 Jan 2023 13:50:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1674337800; cv=none; d=google.com; s=arc-20160816; b=NTWwTqDvJxx0cGX87HGOYfeNG2sqUSk8zyEQ91G/37W1Tm9P0RL5wNa0NyrqdZsa+0 K7EgLCK4WhTKYgjfKbYj/3xERsBeAuoKxelEyNQiZ4hRyOvmrYadNHd9iIQaIguGnVDf 1WhHjBeyX3ad75cDtbihZttaHzFA+8+L5yzpsbWon6fHCqWbi2Ck1IqJFj10j8gCSNOA YoSz5BtI2lqFm52e9ngwfTQyT4eH/jcMBrPr2ozR30ZhyrPodL8yHTKfwZhLFxNh10ut U8fLVR9S4j4iYRLp+9IiFJRZBfLBoG9PwKO0L5+B65UX+vQ1oI93cs5QI3na7bXeGl2M 8/dg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=bJ1ASeQXdZE18Fimd0iBtKCvRtzXpOe0YehcuBe38mM=; b=tY9ecu2dbvyYyV6xugqZGON9LH6AmWU4GlXQsSjPmeKlxbJJRwUotQ8drUC5ddJGrQ Cs52IHbN658ReFNeeMb3+XSczvv3SXD6qrGEhloYvzUhNatSUmzY2QuayCIttxwRc9/U Y4EMiMh+nJ3/y5rHHZSKVezcWeeS607BW8INdBe68YZMDfeNOiikUORKegT9oR31qpSW 0ll8ub1SVv5KyW6xykH5sqiLJccvgpVbrff/bn0ITKTpcJimAHooFXXcxqEej7gH/bDJ tjdQmK2ndlnTRmHttAq/umnYdmtShWRubzRnPHcQ/usZXUIoLVPcge3gELui6ZJQIrIE xmxw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=deYoGTeW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id r139-20020a632b91000000b004ce425ce690si18182988pgr.661.2023.01.21.13.49.54; Sat, 21 Jan 2023 13:50:00 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=deYoGTeW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229917AbjAUVfg (ORCPT + 50 others); Sat, 21 Jan 2023 16:35:36 -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: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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/microcode/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 timeout) */ static int __reload_late(void *info) { + struct ucode_cpu_info *uci = ucode_cpu_info + cpu; int cpu = smp_processor_id(); enum ucode_state err; int ret = 0; @@ -422,12 +423,11 @@ static int __reload_late(void *info) /* * 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)) != cpu) - err = microcode_ops->apply_microcode(cpu); + microcode_ops->collect_cpu_info(cpu, &uci->cpu_sig); return ret; } -- 2.34.1