From patchwork Thu Nov 7 12:21:15 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Andrew Cooper X-Patchwork-Id: 13866330 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 lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E0B37D43352 for ; Thu, 7 Nov 2024 12:21:38 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.831765.1247133 (Exim 4.92) (envelope-from ) id 1t91Vu-0003Uv-G6; Thu, 07 Nov 2024 12:21:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 831765.1247133; Thu, 07 Nov 2024 12:21:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1t91Vu-0003Un-DG; Thu, 07 Nov 2024 12:21:26 +0000 Received: by outflank-mailman (input) for mailman id 831765; Thu, 07 Nov 2024 12:21:25 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1t91Vt-0003Uc-Ik for xen-devel@lists.xenproject.org; Thu, 07 Nov 2024 12:21:25 +0000 Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [2a00:1450:4864:20::52c]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id cc80d798-9d02-11ef-a0c6-8be0dac302b0; Thu, 07 Nov 2024 13:21:21 +0100 (CET) Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-5cebcf96fabso1057163a12.3 for ; Thu, 07 Nov 2024 04:21:21 -0800 (PST) Received: from andrewcoop.eng.citrite.net ([185.25.67.249]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5cf03b5c91esm727688a12.4.2024.11.07.04.21.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Nov 2024 04:21:20 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: cc80d798-9d02-11ef-a0c6-8be0dac302b0 X-Custom-Connection: eyJyZW1vdGVpcCI6IjJhMDA6MTQ1MDo0ODY0OjIwOjo1MmMiLCJoZWxvIjoibWFpbC1lZDEteDUyYy5nb29nbGUuY29tIn0= X-Custom-Transaction: eyJpZCI6ImNjODBkNzk4LTlkMDItMTFlZi1hMGM2LThiZTBkYWMzMDJiMCIsInRzIjoxNzMwOTgyMDgxLjk3MjE4NSwic2VuZGVyIjoiYW5kcmV3LmNvb3BlckBjbG91ZC5jb20iLCJyZWNpcGllbnQiOiJ4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcifQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1730982081; x=1731586881; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=SDbTb7NjSJYn3X1Dh4L5KXZIiaqRtXYAT6o5D6+07ZU=; b=agqa3JUTy2fl+mpj6JAbJDy6oCVvngy5hXNVD3oNvvYw0Dj5/T+RoEIu1onw6X2l0N XDMfXYgbItG/QgG2u5xA3M9d6bJuT4vbqioXzl/I0Cz0U4yCwUTkdkG/Dw2pE5fTIG2D QojCzhveo0ceeSc5D7TIKYOvaO4zH+Sdm8X7M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730982081; x=1731586881; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=SDbTb7NjSJYn3X1Dh4L5KXZIiaqRtXYAT6o5D6+07ZU=; b=KDlPEuO5NauW9d7pwGLfJ88OOreiFGrZtnVmNeZm4l83EPjOhZjULwAYuVaqw4Vi/Y dPuVM0CFzzJVUQMsX1TgKm/dmRrmbOlumLJlVrfB2w5d9WWxgxNFFD8U2+DgBQXteAET 9vN2GznH0AP3XropOmIWGrdFtJyAbJdigcrg+Oa7KjBHdunalf74mJIG7KjtOktz7r/R QQq/xIaqkixLzpBOpL1dx7va5bSoGVmo3U7LCy/ZNBMu/FMpMlpWyI1LdKXaC5PoBoTf XJD5H9IB6LeRz1piM13vJ73Qo5NDXFGYTVtjvEDhDNeix1hfhB3MyDhAkLOoN6apzjRF K6Iw== X-Gm-Message-State: AOJu0YwBIf1dX9Ai/7nKcHtrH8poN1I2+wIleBtXYQrPSp3BnvwmKmNk q1u5EsvG2Yi8VQL9jKGre0E/JfdRGj+JVJFj6utLxfP8fFMXxKovwB6wF3iIQ5Nrv9yGLh4oTFQ N X-Google-Smtp-Source: AGHT+IGpF/m3x2o12SaRg3fy6eGoryDpECSFOmUQ7NWXQw1gZ34JFuB/Ho2T7Tux41gXWEKqiTfODQ== X-Received: by 2002:a05:6402:5242:b0:5ce:f7c2:65fe with SMTP id 4fb4d7f45d1cf-5cf05a5976emr1020372a12.28.1730982080836; Thu, 07 Nov 2024 04:21:20 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?utf-8?q?Roger_Pau_Monn=C3=A9?= Subject: [PATCH 1/3] x86/ucode: Don't use microcode_update_cpu() in early_microcode_load() Date: Thu, 7 Nov 2024 12:21:15 +0000 Message-Id: <20241107122117.4073266-2-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20241107122117.4073266-1-andrew.cooper3@citrix.com> References: <20241107122117.4073266-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 There are two callers of microcode_update_cpu(), and because one passes NULL and one doesn't, there are effectively two disjoint pieces of logic wrapped in a single function. early_microcode_load()'s use skips all the microcode_cache handling, and is just a simple patch application. This skips a redundant collect_cpu_info() call (performed in early_microcode_init(), marginally earlier), and avoids holding microcode_mutex when we're not interacting with microcode_cache at all. No functional change. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich --- CC: Jan Beulich CC: Roger Pau Monné --- xen/arch/x86/cpu/microcode/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/x86/cpu/microcode/core.c b/xen/arch/x86/cpu/microcode/core.c index 11cd878d1f2e..d9406ec3fd34 100644 --- a/xen/arch/x86/cpu/microcode/core.c +++ b/xen/arch/x86/cpu/microcode/core.c @@ -900,7 +900,7 @@ static int __init early_microcode_load(struct boot_info *bi) */ early_mod_idx = idx; - rc = microcode_update_cpu(patch, 0); + rc = ucode_ops.apply_microcode(patch, 0); unmap: bootstrap_unmap(); From patchwork Thu Nov 7 12:21:16 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Andrew Cooper X-Patchwork-Id: 13866332 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 lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 54477D4335A for ; Thu, 7 Nov 2024 12:21:40 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.831768.1247155 (Exim 4.92) (envelope-from ) id 1t91Vw-0003sB-CB; Thu, 07 Nov 2024 12:21:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 831768.1247155; Thu, 07 Nov 2024 12:21:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1t91Vw-0003qf-3o; Thu, 07 Nov 2024 12:21:28 +0000 Received: by outflank-mailman (input) for mailman id 831768; Thu, 07 Nov 2024 12:21:27 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1t91Vv-0003Uj-8q for xen-devel@lists.xenproject.org; Thu, 07 Nov 2024 12:21:27 +0000 Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [2a00:1450:4864:20::530]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id cd731a90-9d02-11ef-99a3-01e77a169b0f; Thu, 07 Nov 2024 13:21:23 +0100 (CET) Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-5ceccffadfdso1144762a12.2 for ; Thu, 07 Nov 2024 04:21:23 -0800 (PST) Received: from andrewcoop.eng.citrite.net ([185.25.67.249]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5cf03b5c91esm727688a12.4.2024.11.07.04.21.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Nov 2024 04:21:21 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: cd731a90-9d02-11ef-99a3-01e77a169b0f X-Custom-Connection: eyJyZW1vdGVpcCI6IjJhMDA6MTQ1MDo0ODY0OjIwOjo1MzAiLCJoZWxvIjoibWFpbC1lZDEteDUzMC5nb29nbGUuY29tIn0= X-Custom-Transaction: eyJpZCI6ImNkNzMxYTkwLTlkMDItMTFlZi05OWEzLTAxZTc3YTE2OWIwZiIsInRzIjoxNzMwOTgyMDgzLjU4MjU3NCwic2VuZGVyIjoiYW5kcmV3LmNvb3BlckBjbG91ZC5jb20iLCJyZWNpcGllbnQiOiJ4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcifQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1730982082; x=1731586882; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=VVZQOpTTpM2S/e3rLNR3YwvXv7wCxv2Z+w11Kz7Jc/g=; b=qolGz+oYeKF3B686Z2usJizG+p3SXjQ71i8I4nNSUiXWJwXJ6Ssx18Fw8xhtfolLgJ po4n1hzwotK1YZPlbsAKoF/zmWgWNhIUhIXEQGcMYtTuCIYExisNPmq9hyFR3agWyQuZ KPkGlxel/x264BqDTUii+1Fm3QpVbJfvIjDQc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730982082; x=1731586882; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=VVZQOpTTpM2S/e3rLNR3YwvXv7wCxv2Z+w11Kz7Jc/g=; b=FCHSz5lITD/FPObe2PqRxIKxqPlvrykEQ6+sKMKjNO4Qzen0v6DdKhXz6wH/LFFmHh kPTbDDo/k13irK8ayP2VNzgb64NAcMSp9pa58eKuzz4dL4aAXmhGR89ccj+d91bcyjQ6 +3N4peuFeBWsZBw9kXjamOWUMrnhP2ZdTV/WoEwO6vqPeUW5TuYPKxUe7rTFiyhlPlUN 7mqzJHtlgqfj9Y/+YqUa6gdocBMr0lQ6z8FRlHKhP2U6nxqoRbPCd+qGZvxX1a5bCue3 hiBsou28H5Zn+CZP3zdoX9EoaIrn9Q7DC2LtZWfIduiPa/bJBq7UuQb5ywu2tqMfxRO6 A0Pw== X-Gm-Message-State: AOJu0Yxv0NfWqd7+O3DLLuEV2O0JVX/zm+jLX2g6/nf34l/kNkKaE30m /vv7ndbeDqSrZsE3fDErwXYhKDxoFEEoWY87cPgHiTWxUYfVcJe2BKk6X6IKhim7evAe0tCAF0H A X-Google-Smtp-Source: AGHT+IGWMic17q7tsN1mJCztBO+K8U9AP6DY+ZFvHixitFldko5Xa+0H3e44iwcr5m94BjL2g1uPeA== X-Received: by 2002:a05:6402:5242:b0:5ce:f7c2:65fe with SMTP id 4fb4d7f45d1cf-5cf05a5976emr1020450a12.28.1730982082259; Thu, 07 Nov 2024 04:21:22 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?utf-8?q?Roger_Pau_Monn=C3=A9?= Subject: [PATCH 2/3] x86/ucode: Fold microcode_update_cpu() and fix error handling Date: Thu, 7 Nov 2024 12:21:16 +0000 Message-Id: <20241107122117.4073266-3-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20241107122117.4073266-1-andrew.cooper3@citrix.com> References: <20241107122117.4073266-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Fold microcode_update_cpu() into its single remaining caller and simplify the logic by removing the patch != NULL path with microcode_mutex held. Explain why we bother grabbing the microcode revision even if we can't load microcode. Furthermore, delete the -EIO path. An error updating microcode on AP boot or S3 resume is certainly bad, but freeing the cache is about the worst possible action we can take in response; it prevents subsequent APs from taking an update they might have accepted. This avoids a double collect_cpu_info() call on each AP. Signed-off-by: Andrew Cooper Acked-by: Jan Beulich --- CC: Jan Beulich CC: Roger Pau Monné --- xen/arch/x86/cpu/microcode/core.c | 49 +++++++++---------------------- 1 file changed, 14 insertions(+), 35 deletions(-) diff --git a/xen/arch/x86/cpu/microcode/core.c b/xen/arch/x86/cpu/microcode/core.c index d9406ec3fd34..fd4b08b45388 100644 --- a/xen/arch/x86/cpu/microcode/core.c +++ b/xen/arch/x86/cpu/microcode/core.c @@ -263,40 +263,6 @@ static bool cf_check wait_cpu_callout(unsigned int nr) return atomic_read(&cpu_out) >= nr; } -/* - * Load a microcode update to current CPU. - * - * If no patch is provided, the cached patch will be loaded. Microcode update - * during APs bringup and CPU resuming falls into this case. - */ -static int microcode_update_cpu(const struct microcode_patch *patch, - unsigned int flags) -{ - int err; - - alternative_vcall(ucode_ops.collect_cpu_info); - - spin_lock(µcode_mutex); - if ( patch ) - err = alternative_call(ucode_ops.apply_microcode, patch, flags); - else if ( microcode_cache ) - { - err = alternative_call(ucode_ops.apply_microcode, microcode_cache, - flags); - if ( err == -EIO ) - { - microcode_free_patch(microcode_cache); - microcode_cache = NULL; - } - } - else - /* No patch to update */ - err = -ENOENT; - spin_unlock(µcode_mutex); - - return err; -} - static bool wait_for_state(typeof(loading_state) state) { typeof(loading_state) cur_state; @@ -702,13 +668,26 @@ int microcode_update(XEN_GUEST_HANDLE(const_void) buf, /* Load a cached update to current cpu */ int microcode_update_one(void) { + int rc; + + /* + * This path is used for APs and S3 resume. Read the microcode revision + * if possible, even if we can't load microcode. + */ if ( ucode_ops.collect_cpu_info ) alternative_vcall(ucode_ops.collect_cpu_info); if ( !ucode_ops.apply_microcode ) return -EOPNOTSUPP; - return microcode_update_cpu(NULL, 0); + spin_lock(µcode_mutex); + if ( microcode_cache ) + rc = alternative_call(ucode_ops.apply_microcode, microcode_cache, 0); + else + rc = -ENOENT; + spin_unlock(µcode_mutex); + + return rc; } /* From patchwork Thu Nov 7 12:21:17 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Andrew Cooper X-Patchwork-Id: 13866331 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 lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 50076D43359 for ; Thu, 7 Nov 2024 12:21:40 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.831766.1247143 (Exim 4.92) (envelope-from ) id 1t91Vv-0003jv-My; Thu, 07 Nov 2024 12:21:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 831766.1247143; Thu, 07 Nov 2024 12:21:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1t91Vv-0003jo-JX; Thu, 07 Nov 2024 12:21:27 +0000 Received: by outflank-mailman (input) for mailman id 831766; Thu, 07 Nov 2024 12:21:26 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1t91Vu-0003Uc-8N for xen-devel@lists.xenproject.org; Thu, 07 Nov 2024 12:21:26 +0000 Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [2a00:1450:4864:20::62e]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id cdc17699-9d02-11ef-a0c6-8be0dac302b0; Thu, 07 Nov 2024 13:21:24 +0100 (CET) Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-a9ee097a478so39568066b.2 for ; Thu, 07 Nov 2024 04:21:24 -0800 (PST) Received: from andrewcoop.eng.citrite.net ([185.25.67.249]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5cf03b5c91esm727688a12.4.2024.11.07.04.21.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Nov 2024 04:21:22 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: cdc17699-9d02-11ef-a0c6-8be0dac302b0 X-Custom-Connection: eyJyZW1vdGVpcCI6IjJhMDA6MTQ1MDo0ODY0OjIwOjo2MmUiLCJoZWxvIjoibWFpbC1lajEteDYyZS5nb29nbGUuY29tIn0= X-Custom-Transaction: eyJpZCI6ImNkYzE3Njk5LTlkMDItMTFlZi1hMGM2LThiZTBkYWMzMDJiMCIsInRzIjoxNzMwOTgyMDg0LjA4NzUzOSwic2VuZGVyIjoiYW5kcmV3LmNvb3BlckBjbG91ZC5jb20iLCJyZWNpcGllbnQiOiJ4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcifQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1730982083; x=1731586883; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=dhkaHQoFIRa55JOrJcaTnvyo182cpXRAkClX9uwWjpI=; b=sO82k5t5Q6dEIqdNrAUES0PJxkdj5oCkKdoq+GZElFsTYIjdjyXjW+6ONieJ12Qcuh gFc7xGMRhhRh7dzqKC+z4wsj94V7xUlY/8hOkSfMhXMlBCq2Q/ygWST+1LRS5YXR1Qmh c1MmweaBw8GZRH94LOhcHkjy9PMFSlX8Bx9Rs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730982083; x=1731586883; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=dhkaHQoFIRa55JOrJcaTnvyo182cpXRAkClX9uwWjpI=; b=pm4GiG+qeObyx5U0QNQ28ePF8BlR6D03pCta05ItCreKSikHPzejjzcPY+iQ2gZb2l F/SQ5aZPRb0u5KYLAUGJrPEtvHnx7fwZjaTFul/m9QDbDsWlcxmxlYVX5dAzrM4Edp2m PrvOiErm+Hh27Y/P/TZBtj527cGTXIbG+lq4nXVlsQU6HrD/DETwdWITLQ1wUC2szVZh 5KA4lfjpRrKuN+40a0Y+hi+O3ptWnkhnMS8S2VmHO63bZYMcLLNa9j+mZUaHqvuPgS/q RnpfQIpzvK+iIsDQaltI9ip6AAhfP7SMa0sFCkBLY+LqGRBK7jqbkbCzCJz8zYSCyM7V bTxQ== X-Gm-Message-State: AOJu0YxkCgBkyc3lXBb/5UjXE/D06Yr/SII6nY9nZsz+gQmWAIDVtAdm p49xaukRrSlTsm3DZR2PHiWDH9xKy49YJYqt8zHKsPNTZBjSCtVkgTkznhHQ8gkXC5nQ4XtpDqZ l X-Google-Smtp-Source: AGHT+IFYCiJbEL/d67ECmyal5RqaBxk7eAqjmISW2oKfrekMRSrrUF/GI3CDJgtpBs1SzNPvU+rF9Q== X-Received: by 2002:a05:6402:d05:b0:5c9:5745:de9a with SMTP id 4fb4d7f45d1cf-5ceb926152emr19520279a12.9.1730982082892; Thu, 07 Nov 2024 04:21:22 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?utf-8?q?Roger_Pau_Monn=C3=A9?= Subject: [PATCH 3/3] x86/ucode: Remove the collect_cpu_info() call from parse_blob() Date: Thu, 7 Nov 2024 12:21:17 +0000 Message-Id: <20241107122117.4073266-4-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20241107122117.4073266-1-andrew.cooper3@citrix.com> References: <20241107122117.4073266-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 With the tangle of logic starting to come under control, it is now plain to see that parse_blob()'s side effect of re-gathering the signature/revision is pointless. The cpu_request_microcode() hooks need the signature only. The BSP gathers this in early_microcode_init(), the APs and S3 in microcode_update_cpu(). For good measure, the apply_microcode() hooks also keep the revision correct as load attempts are made. This finally gets us down to a single call per CPU on boot / S3 resume, and no calls during late-load hypercalls. No functional change. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné Slightly RFC. Just before posting, I've realised that cpu_request_microcode() does actually use the current CPU revision, and it's buggy, and it's the cause of `xen-ucode --force` not working as expected. I'm tempted to do another series cleaning that up in isolation, such that this patch becomes true in this form. --- xen/arch/x86/cpu/microcode/core.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/xen/arch/x86/cpu/microcode/core.c b/xen/arch/x86/cpu/microcode/core.c index fd4b08b45388..5897ec54032a 100644 --- a/xen/arch/x86/cpu/microcode/core.c +++ b/xen/arch/x86/cpu/microcode/core.c @@ -189,8 +189,6 @@ static struct patch_with_flags nmi_patch = */ static struct microcode_patch *parse_blob(const char *buf, size_t len) { - alternative_vcall(ucode_ops.collect_cpu_info); - return alternative_call(ucode_ops.cpu_request_microcode, buf, len, true); } From patchwork Fri Nov 8 12:12:41 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Andrew Cooper X-Patchwork-Id: 13868104 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 lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 49045D5C0C0 for ; Fri, 8 Nov 2024 12:13:08 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.832528.1247813 (Exim 4.92) (envelope-from ) id 1t9NrA-0006Nj-Jr; Fri, 08 Nov 2024 12:12:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 832528.1247813; Fri, 08 Nov 2024 12:12:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1t9NrA-0006Nc-Ft; Fri, 08 Nov 2024 12:12:52 +0000 Received: by outflank-mailman (input) for mailman id 832528; Fri, 08 Nov 2024 12:12:51 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1t9Nr9-0006NV-1l for xen-devel@lists.xenproject.org; Fri, 08 Nov 2024 12:12:51 +0000 Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [2a00:1450:4864:20::636]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c33ca85f-9dca-11ef-a0c6-8be0dac302b0; Fri, 08 Nov 2024 13:12:45 +0100 (CET) Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-a9ed7d8c86cso363153966b.2 for ; Fri, 08 Nov 2024 04:12:45 -0800 (PST) Received: from andrewcoop.eng.citrite.net ([185.25.67.249]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a9ee0a4a988sm223954466b.59.2024.11.08.04.12.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Nov 2024 04:12:43 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c33ca85f-9dca-11ef-a0c6-8be0dac302b0 X-Custom-Connection: eyJyZW1vdGVpcCI6IjJhMDA6MTQ1MDo0ODY0OjIwOjo2MzYiLCJoZWxvIjoibWFpbC1lajEteDYzNi5nb29nbGUuY29tIn0= X-Custom-Transaction: eyJpZCI6ImMzM2NhODVmLTlkY2EtMTFlZi1hMGM2LThiZTBkYWMzMDJiMCIsInRzIjoxNzMxMDY3OTY1Ljc5MTU1Nywic2VuZGVyIjoiYW5kcmV3LmNvb3BlckBjbG91ZC5jb20iLCJyZWNpcGllbnQiOiJ4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcifQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1731067964; x=1731672764; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=KPl05uDpcIVvTaOJ217rmBk+BiHJABBBSah5zq7hgxc=; b=A7qjLE6SQ96KJUb3LiKRSDXKg8NWJPwF99rUxlK7R4y8ky4nZj0AuGl/Xr0EY/G2k7 lm9NfaDc0doJspSP4atNE+NzbfKuKxd54V7vIwWsPj3tuKYtnnBsU9eMGysCthhAlfH1 BlioawicSgDGyS48GuW8klodhSrMs4q+7/ofc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731067964; x=1731672764; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=KPl05uDpcIVvTaOJ217rmBk+BiHJABBBSah5zq7hgxc=; b=XzFHcoD0Mbh37p3upRy4ZY+95rxOzVvTuW0EW96AjU5GZcPepJLBulLCjVXDSdRJgT 3QJyIeUORF/gOZ6Y/wfiqBdGQZN4MpFM1g0V8S14yAMCYum8dC/5fxR7bMhnQZtRuGIY qfRJ+BBselCI3KSI7/5W1nOkfiN9YDFpNcdI0jWbxQGC2x9NlunXgr7IA4dzd+nNO7u3 yYl/b4LX0Kc+16b3miZtjnsjIrNEr//5QZoHMISqUSYXXBVsGcB2SEoSBCqOFKLG7VU/ cQkyihd/0o1Vds0Iyg7/jPi4pFJWQVL9HTKIXNDEHdT/9Au4M56N8PTMDlCcucu7ooZH fQjw== X-Gm-Message-State: AOJu0Yx5wxkXuO+mERVRIcpIrmMMjs7KkGRIAGUOTzAPZTtN8H33yvjU LgXrJQKUlmJkgL7sM9Glxl20EZYYibO2owLEs9pvRme6f4wibw/i16k8hYsJcNVPehsBybf4efW + X-Google-Smtp-Source: AGHT+IHX6d+y0TiDZ7gHyA8K7KonB6rhXBRUeR4cYlqIfXUzM8h/tZnjrWXc3aI4Z4KIgwpBsOu/QA== X-Received: by 2002:a17:907:6d0c:b0:a9e:447b:6f76 with SMTP id a640c23a62f3a-a9eeff38602mr232465866b.31.1731067964142; Fri, 08 Nov 2024 04:12:44 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?utf-8?q?Roger_Pau_Monn=C3=A9?= Subject: [PATCH 4/3] x86/ucode: Fix cache handling in microcode_update_helper() Date: Fri, 8 Nov 2024 12:12:41 +0000 Message-Id: <20241108121241.243945-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20241107122117.4073266-1-andrew.cooper3@citrix.com> References: <20241107122117.4073266-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 microcode_update_cache() now has a single caller, but inlining it shows how unnecessarily complicated the logic really is. Outside of error paths, there is always one microcode patch to free. Its either result of parse_blob(), or it's the old cached value. In order to fix this, have a local patch pointer (mostly to avoid the unnecessary verbosity of patch_with_flags.patch), and always free it at the end. The only error path needing care is the IS_ERR(patch) path, which is easy enough to handle. Also, widen the scope of result. We only need to call compare_patch() once, and the answer is still good later when updating the cache. In order to update the cache, simply SWAP() the patch and the cache pointers, allowing the singular xfree() at the end to cover both cases. This also removes all callers microcode_free_patch() which fixes the need to cast away const to allow it to compile. No functional change. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné This is in prepartion to totally overhaul compare_patch(). There's now only a single caller. --- xen/arch/x86/cpu/microcode/core.c | 66 +++++++++++-------------------- 1 file changed, 24 insertions(+), 42 deletions(-) diff --git a/xen/arch/x86/cpu/microcode/core.c b/xen/arch/x86/cpu/microcode/core.c index 5897ec54032a..0cc5daa251e2 100644 --- a/xen/arch/x86/cpu/microcode/core.c +++ b/xen/arch/x86/cpu/microcode/core.c @@ -86,7 +86,7 @@ struct patch_with_flags { static bool ucode_in_nmi = true; /* Protected by microcode_mutex */ -static const struct microcode_patch *microcode_cache; +static struct microcode_patch *microcode_cache; /* * opt_mod_idx and opt_scan have subtle semantics. @@ -192,33 +192,6 @@ static struct microcode_patch *parse_blob(const char *buf, size_t len) return alternative_call(ucode_ops.cpu_request_microcode, buf, len, true); } -static void microcode_free_patch(const struct microcode_patch *patch) -{ - xfree((struct microcode_patch *)patch); -} - -/* Return true if cache gets updated. Otherwise, return false */ -static bool microcode_update_cache(const struct microcode_patch *patch) -{ - ASSERT(spin_is_locked(µcode_mutex)); - - if ( !microcode_cache ) - microcode_cache = patch; - else if ( alternative_call(ucode_ops.compare_patch, - patch, microcode_cache) == NEW_UCODE ) - { - microcode_free_patch(microcode_cache); - microcode_cache = patch; - } - else - { - microcode_free_patch(patch); - return false; - } - - return true; -} - /* Returns true if ucode should be loaded on a given cpu */ static bool is_cpu_primary(unsigned int cpu) { @@ -496,6 +469,8 @@ struct ucode_buf { static long cf_check microcode_update_helper(void *data) { + struct microcode_patch *patch = NULL; + enum microcode_match_result result; int ret; struct ucode_buf *buffer = data; unsigned int cpu, updated; @@ -524,17 +499,20 @@ static long cf_check microcode_update_helper(void *data) goto put; } - patch_with_flags.patch = parse_blob(buffer->buffer, buffer->len); + patch = parse_blob(buffer->buffer, buffer->len); patch_with_flags.flags = buffer->flags; + xfree(buffer); - if ( IS_ERR(patch_with_flags.patch) ) + + if ( IS_ERR(patch) ) { - ret = PTR_ERR(patch_with_flags.patch); + ret = PTR_ERR(patch); + patch = NULL; printk(XENLOG_WARNING "Parsing microcode blob error %d\n", ret); goto put; } - if ( !patch_with_flags.patch ) + if ( !patch ) { printk(XENLOG_WARNING "microcode: couldn't find any matching ucode in " "the provided blob!\n"); @@ -549,10 +527,7 @@ static long cf_check microcode_update_helper(void *data) spin_lock(µcode_mutex); if ( microcode_cache ) { - enum microcode_match_result result; - - result = alternative_call(ucode_ops.compare_patch, - patch_with_flags.patch, microcode_cache); + result = alternative_call(ucode_ops.compare_patch, patch, microcode_cache); if ( result != NEW_UCODE && !(ucode_force && (result == OLD_UCODE || result == SAME_UCODE)) ) @@ -561,12 +536,13 @@ static long cf_check microcode_update_helper(void *data) printk(XENLOG_WARNING "microcode: couldn't find any newer%s revision in the provided blob!\n", ucode_force ? " (or a valid)" : ""); - microcode_free_patch(patch_with_flags.patch); ret = -EEXIST; goto put; } } + else + result = NEW_UCODE; spin_unlock(µcode_mutex); cpumask_clear(&cpu_callin_map); @@ -593,14 +569,18 @@ static long cf_check microcode_update_helper(void *data) * this requirement can be relaxed in the future. Right now, this is * conservative and good. */ + patch_with_flags.patch = patch; ret = stop_machine_run(do_microcode_update, &patch_with_flags, NR_CPUS); updated = atomic_read(&cpu_updated); if ( updated > 0 ) { - spin_lock(µcode_mutex); - microcode_update_cache(patch_with_flags.patch); - spin_unlock(µcode_mutex); + if ( result == NEW_UCODE ) + { + spin_lock(µcode_mutex); + SWAP(patch, microcode_cache); + spin_unlock(µcode_mutex); + } /* * Refresh the raw CPU policy, in case the features have changed. @@ -615,8 +595,6 @@ static long cf_check microcode_update_helper(void *data) if ( ctxt_switch_masking ) alternative_vcall(ctxt_switch_masking, current); } - else - microcode_free_patch(patch_with_flags.patch); if ( updated && updated != nr_cores ) printk(XENLOG_ERR "ERROR: Updating microcode succeeded on %u cores and failed\n" @@ -627,6 +605,10 @@ static long cf_check microcode_update_helper(void *data) put: put_cpu_maps(); + + /* The parsed blob or old cached value, whichever we're not keeping. */ + xfree(patch); + return ret; }