From nobody Mon Feb 9 14:50:36 2026 Delivered-To: importer@patchew.org Received-SPF: none (zoho.com: 192.237.175.120 is neither permitted nor denied by domain of lists.xenproject.org) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; spf=none (zoho.com: 192.237.175.120 is neither permitted nor denied by domain of lists.xenproject.org) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=fail(p=none dis=none) header.from=intel.com ARC-Seal: i=1; a=rsa-sha256; t=1558945746; cv=none; d=zoho.com; s=zohoarc; b=ZABpgc+UrvUUAahNxUjiSnDHcSkjCrhn/EU8/YChaCOQ3xLeXWoBrKznQt6JNmI/JizNB32uEmtiTJKNCw9WPF8a2S9XrbF1wQrbXJ/XuHfeH3548L2Y2Krai6QrJD7dt5Pbcydqw6Y+GF1ddZ+k5ZSQy4mYLLx9gN036h0Oga0= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1558945746; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To:ARC-Authentication-Results; bh=m4ZA1lF8jPgiJbzpm8hv19hoqhOE1Qld7UMbQWBVx+8=; b=j/P6JSnWC5yylMDN7dOsHt2YJbWmPKFcN7gEySOoXVFuatFmqBJYhAVphupNbVvWVf7Zbhox5piUZKdEO4OxRXJuje2uvLPNjLt/iHpq+7w8tNsyG8RTDQdB55uunH2WkQpVsznFeTxtY5yE6Xw0bpz4XUrocmXW0xtS1MOnRTY= ARC-Authentication-Results: i=1; mx.zoho.com; spf=none (zoho.com: 192.237.175.120 is neither permitted nor denied by domain of lists.xenproject.org) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=fail header.from= (p=none dis=none) header.from= Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1558945746735468.02029682469595; Mon, 27 May 2019 01:29:06 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1hVAyy-0004LQ-Ky; Mon, 27 May 2019 08:27:48 +0000 Received: from us1-rack-dfw2.inumbo.com ([104.130.134.6]) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1hVAyx-0004K7-Da for xen-devel@lists.xenproject.org; Mon, 27 May 2019 08:27:47 +0000 Received: from mga12.intel.com (unknown [192.55.52.136]) by us1-rack-dfw2.inumbo.com (Halon) with ESMTPS id 4deb591e-8059-11e9-8980-bc764e045a96; Mon, 27 May 2019 08:27:46 +0000 (UTC) Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 May 2019 01:27:45 -0700 Received: from gao-cwp.sh.intel.com ([10.239.159.26]) by orsmga005.jf.intel.com with ESMTP; 27 May 2019 01:27:44 -0700 X-Inumbo-ID: 4deb591e-8059-11e9-8980-bc764e045a96 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False X-ExtLoop1: 1 From: Chao Gao To: xen-devel@lists.xenproject.org Date: Mon, 27 May 2019 16:31:30 +0800 Message-Id: <1558945891-3015-10-git-send-email-chao.gao@intel.com> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1558945891-3015-1-git-send-email-chao.gao@intel.com> References: <1558945891-3015-1-git-send-email-chao.gao@intel.com> Subject: [Xen-devel] [PATCH v7 09/10] microcode: remove microcode_update_lock X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Sergey Dyasli , Ashok Raj , Wei Liu , Andrew Cooper , Jan Beulich , Chao Gao , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" microcode_update_lock is to prevent logic threads of a same core from updating microcode at the same time. But due to using a global lock, it also prevented parallel microcode updating on different cores. Remove this lock in order to update microcode in parallel. It is safe because we have already ensured serialization of sibling threads at the caller side. 1.For late microcode update, do_microcode_update() ensures that only one sibiling thread of a core can update microcode. 2.For microcode update during system startup or CPU-hotplug, microcode_mutex() guarantees update serialization of logical threads. 3.get/put_cpu_bitmaps() prevents the concurrency of CPU-hotplug and late microcode update. Note that printk in apply_microcode() and svm_host_osvm_init() (for AMD only) are still processed sequentially. Signed-off-by: Chao Gao Reviewed-by: Jan Beulich --- Changes in v7: - reworked. Remove complex lock logics introduced in v5 and v6. The microc= ode patch to be applied is passed as an argument without any global variable. = Thus no lock is added to serialize potential readers/writers. Callers of apply_microcode() will guarantee the correctness: the patch poninted by the arguments won't be changed by others. Changes in v6: - introduce early_ucode_update_lock to serialize early ucode update. Changes in v5: - newly add --- xen/arch/x86/microcode_amd.c | 8 +------- xen/arch/x86/microcode_intel.c | 8 +------- 2 files changed, 2 insertions(+), 14 deletions(-) diff --git a/xen/arch/x86/microcode_amd.c b/xen/arch/x86/microcode_amd.c index c819028..b64a58d 100644 --- a/xen/arch/x86/microcode_amd.c +++ b/xen/arch/x86/microcode_amd.c @@ -74,9 +74,6 @@ struct mpbhdr { uint8_t data[]; }; =20 -/* serialize access to the physical write */ -static DEFINE_SPINLOCK(microcode_update_lock); - /* See comment in start_update() for cases when this routine fails */ static int collect_cpu_info(struct cpu_signature *csig) { @@ -251,7 +248,6 @@ static enum microcode_match_result compare_patch( =20 static int apply_microcode(const struct microcode_patch *patch) { - unsigned long flags; uint32_t rev; int hw_err; unsigned int cpu =3D smp_processor_id(); @@ -263,15 +259,13 @@ static int apply_microcode(const struct microcode_pat= ch *patch) =20 hdr =3D patch->mc_amd->mpb; =20 - spin_lock_irqsave(µcode_update_lock, flags); + BUG_ON(local_irq_is_enabled()); =20 hw_err =3D wrmsr_safe(MSR_AMD_PATCHLOADER, (unsigned long)hdr); =20 /* get patch id after patching */ rdmsrl(MSR_AMD_PATCHLEVEL, rev); =20 - spin_unlock_irqrestore(µcode_update_lock, flags); - /* * Some processors leave the ucode blob mapping as UC after the update. * Flush the mapping to regain normal cacheability. diff --git a/xen/arch/x86/microcode_intel.c b/xen/arch/x86/microcode_intel.c index bfb48ce..94a1561 100644 --- a/xen/arch/x86/microcode_intel.c +++ b/xen/arch/x86/microcode_intel.c @@ -93,9 +93,6 @@ struct extended_sigtable { =20 #define exttable_size(et) ((et)->count * EXT_SIGNATURE_SIZE + EXT_HEADER_S= IZE) =20 -/* serialize access to the physical write to MSR 0x79 */ -static DEFINE_SPINLOCK(microcode_update_lock); - static int collect_cpu_info(struct cpu_signature *csig) { unsigned int cpu_num =3D smp_processor_id(); @@ -295,7 +292,6 @@ static struct microcode_patch *allow_microcode_patch( =20 static int apply_microcode(const struct microcode_patch *patch) { - unsigned long flags; uint64_t msr_content; unsigned int val[2]; unsigned int cpu_num =3D raw_smp_processor_id(); @@ -307,8 +303,7 @@ static int apply_microcode(const struct microcode_patch= *patch) =20 mc_intel =3D patch->mc_intel; =20 - /* serialize access to the physical write to MSR 0x79 */ - spin_lock_irqsave(µcode_update_lock, flags); + BUG_ON(local_irq_is_enabled()); =20 /* * Writeback and invalidate caches before updating microcode to avoid @@ -327,7 +322,6 @@ static int apply_microcode(const struct microcode_patch= *patch) rdmsrl(MSR_IA32_UCODE_REV, msr_content); val[1] =3D (uint32_t)(msr_content >> 32); =20 - spin_unlock_irqrestore(µcode_update_lock, flags); if ( val[1] !=3D mc_intel->hdr.rev ) { printk(KERN_ERR "microcode: CPU%d update from revision " --=20 1.8.3.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel