[<prev] [next>] [day] [month] [year] [list]
Message-ID: <2a53cf1c48b44ea4b12debeed7521d50@baidu.com>
Date: Sat, 16 Aug 2025 00:15:20 +0000
From: "Li,Rongqing" <lirongqing@...du.com>
To: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
CC: "tglx@...utronix.de" <tglx@...utronix.de>, "bp@...en8.de" <bp@...en8.de>,
"peterz@...radead.org" <peterz@...radead.org>, "jpoimboe@...nel.org"
<jpoimboe@...nel.org>, "mingo@...hat.com" <mingo@...hat.com>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>, "x86@...nel.org"
<x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>, "david.kaplan@....com"
<david.kaplan@....com>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>
Subject: RE: Re: [????] Re: [PATCH] x86/bugs: Fix GDS mitigation check for
CPUs without ARCH_CAP_GDS_CTRL
>
> How is that a problem? That is how it was originally implemented.
>
> Infact, the following checks are required for the correct behavior:
You are right, I will resend this patch
Thanks
-Li
>
> if (mcu_ctrl & GDS_MITG_LOCKED) {
> if (gds_mitigation == GDS_MITIGATION_OFF)
> pr_warn("Mitigation locked. Disable failed.\n");
> ...
> gds_mitigation = GDS_MITIGATION_FULL_LOCKED;
> }
>
> If the GDS microcode mitigation is locked before the kernel boot, MSR write for
> OFF will not take effect anyways. And you report OFF when the mitigation is
> locked to ON. While also triggering below WARN_ON_ONCE():
>
> update_gds_msr()
> {
> ...
> /*
> * Check to make sure that the WRMSR value was not ignored.
> Writes to
> * GDS_MITG_DIS will be ignored if this processor is locked but the
> boot
> * processor was not.
> */
> rdmsrq(MSR_IA32_MCU_OPT_CTRL, mcu_ctrl_after);
> WARN_ON_ONCE(mcu_ctrl != mcu_ctrl_after);
Powered by blists - more mailing lists