Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp1429728rwb; Tue, 29 Nov 2022 13:31:29 -0800 (PST) X-Google-Smtp-Source: AA0mqf63lGZxq9Y0WvVwfWdRDp+ZNqd1DTJRcGTMurG8Nvol3wFCViEzLkHwYJ6QuyRfRHYoRuZf X-Received: by 2002:a17:906:3952:b0:7b9:2a28:f6ff with SMTP id g18-20020a170906395200b007b92a28f6ffmr31034399eje.61.1669757488799; Tue, 29 Nov 2022 13:31:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669757488; cv=none; d=google.com; s=arc-20160816; b=JMGCg3Xzn2ZNWxVzklsZmMp/UQb5iTSsQa27AdInVfZClr0zl5blTFQgl+jM0ZOwaD /vwHwNd+tm7Wr3rRzBOch3pFtnsv29T3U+9HbcIZJ1tAF6b1opoOsHrqOujXuLUBC6yV DFjozzeZJRIKj+eCcjFfWp8uXI4S3/FKeCHAhaOa8pok2WdfqI2KH7ppSILh75E/qtvM sHA7X6OCVtHfSLtW3GVkx9GsbTPS/0Bb4r7cg3AtDidl5QnSoiSkWLePOjN9sjuvKwcH ihZ/WgXcfJlutDaFcDTl77b3hECv34zQ4S4+Zi28ShKr9dijyAbblQ/h4osKx1zqOPlK Ouxw== 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=voBW/s8OoYt5E6o5tabDbOkYItpw5zwBtuN4AXb7uUk=; b=0pYRdu2Ix6wfKasQxhpunyt+57uhg0W4z2Ptmhbq0IIWbCpLchsEsGmgRg4vsvN0j4 bo2x1/mvoYXXCi5wB7OYvtOVcMh6hggqHzrNzsm+kvQPZInnw7SsmsLXKgrmCs1Ldlxm vLivnIBf9hn3KHTLUbOhu+WzMBbpbptbnPTV9h9FL0gUO8+NSOSTzOcFAGhSnZ6sxcmj UaoVRG+sG9qluAyozS7M/p6t5hh2oRhfUNi9KjR+qLld7U1/jXKErRTEhY/QY7bm5Ths DVUzBtrCfyS0oLKIs6HndvUoVN1P7GxM6DOd/c5enD8EXLeB8szwLYJylWuszSsijNL8 s/GQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=TY4QdO1T; 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 l17-20020a056402255100b00461c5846e1asi14014927edb.371.2022.11.29.13.31.05; Tue, 29 Nov 2022 13:31:28 -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=TY4QdO1T; 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 S235796AbiK2VJW (ORCPT + 84 others); Tue, 29 Nov 2022 16:09:22 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36310 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236084AbiK2VJG (ORCPT ); Tue, 29 Nov 2022 16:09:06 -0500 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7919F55A0 for ; Tue, 29 Nov 2022 13:09:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1669756144; x=1701292144; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=CQp4qbII0DlxhRkqqCYEfCUWHdc6N9otPMAR1s7O/AM=; b=TY4QdO1TM6rxlpJvouVXEdRgnA/UyPI1zFZCbd17oChagrx9LnKEI4+E lJIvy7TrR0GpwxiMolddOJnTQ+Dhd/haAHRvG0jpqldFvtkLXZDSvSy4H LsrHNPpaRAFVN1Tn2Gud0+N+VGI9zxxLUVNrfuT1mwhSbIqFWb5/QwZe5 BKD2OmNKM7IoTVcu4fH+k2+rUb6NknL0tPZkpnfRb7wRABSnZ/aLVM/oj Y2SH1cmJBGNIa8HqwzTXDEjUt99mT6shePwY+4IeX9hDAOcOWD3tVG7DJ SMX9T3Ri7/XUfo+wUquFOL/40HjsFNsQjLPonNbfF/KbT3+YD/LF4MMfo w==; X-IronPort-AV: E=McAfee;i="6500,9779,10546"; a="317083131" X-IronPort-AV: E=Sophos;i="5.96,204,1665471600"; d="scan'208";a="317083131" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Nov 2022 13:09:04 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10546"; a="646066205" X-IronPort-AV: E=Sophos;i="5.96,204,1665471600"; d="scan'208";a="646066205" Received: from araj-ucode.jf.intel.com ([10.23.0.19]) by fmsmga007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Nov 2022 13:09:03 -0800 From: Ashok Raj To: Borislav Petkov Cc: X86-kernel , LKML Mailing List , Ashok Raj , Dave Hansen , Tony Luck , alison.schofield@intel.com, reinette.chatre@intel.com Subject: [Patch V1 2/7] x86/microcode/intel: Remove retries on early microcode load Date: Tue, 29 Nov 2022 13:08:27 -0800 Message-Id: <20221129210832.107850-3-ashok.raj@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20221129210832.107850-1-ashok.raj@intel.com> References: <20221129210832.107850-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 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 loading can fail. This happens today when handling mixed steppings. But it can also happen for other reasons such as corrupted image, Security Version Number (SVN) preventing anti-rollback, dependencies on BIOS loaded microcode image for some capabilities. When the microcode loading fails, the kernel will quietly hang at boot. This has been observed by end users (Links below) who had to revert their microcode packages in order to boot again. The hang is due to an infinite retry loop. The retries were in place to support systems with mixed steppings. Now that mixed steppings are no longer supported, there is only one microcode image at a time. Any retries will simply reattempt to apply the same image over and over without making progress. Some possible past bugs that could be due to this bug are below. There is no direct evidence that these end user issues were caused by this retry loop. However, the early boot hangs along with reverting the microcode update workaround provide strong circumstantial evidence to support the theory that they are linked. Remove the retry loop and only attempt to apply microcode once. Link: https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/1911959 Link: https://forums.linuxmint.com/viewtopic.php?p=1827032#1827032 Link: https://askubuntu.com/questions/1291486/boot-crash-after-latest-update-of-intel-microcode-nov-11-2020 Fixes: 06b8534cb728 ("x86/microcode: Rework microcode loading") Cc: stable@vger.kernel.org Signed-off-by: Ashok Raj --- arch/x86/kernel/cpu/microcode/intel.c | 9 +-------- 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/arch/x86/kernel/cpu/microcode/intel.c b/arch/x86/kernel/cpu/microcode/intel.c index 4f93875f57b4..d68b084a17e7 100644 --- a/arch/x86/kernel/cpu/microcode/intel.c +++ b/arch/x86/kernel/cpu/microcode/intel.c @@ -495,7 +495,6 @@ void load_ucode_intel_ap(void) else iup = &intel_ucode_patch; -reget: if (!*iup) { patch = __load_ucode_intel(&uci); if (!patch) @@ -505,13 +504,7 @@ void load_ucode_intel_ap(void) } uci.mc = *iup; - - if (apply_microcode_early(&uci, true)) { - /* Mixed-silicon system? Try to refetch the proper patch: */ - *iup = NULL; - - goto reget; - } + apply_microcode_early(&uci, true); } static struct microcode_intel *find_patch(struct ucode_cpu_info *uci) -- 2.34.1