[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <24713e0d-779f-4084-ba5c-7375d4b05955@linux.intel.com>
Date: Fri, 19 Apr 2024 11:03:28 -0700
From: Daniel Sneddon <daniel.sneddon@...ux.intel.com>
To: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>,
linux-kernel@...r.kernel.org
Cc: x86@...nel.org, dan.j.williams@...el.com, bernie.keany@...el.com,
charishma1.gairuboyina@...el.com, chang.seok.bae@...el.com,
Josh Poimboeuf <jpoimboe@...nel.org>, antonio.gomez.iglesias@...ux.intel.com
Subject: Re: [PATCH 15/14] x86/gds: Lock GDS mitigation when keylocker feature
is present
On 4/19/24 10:47, Pawan Gupta wrote:
> + u64 gds_lock = 0;
>
> switch (gds_mitigation) {
> case GDS_MITIGATION_OFF:
> @@ -769,6 +769,8 @@ void update_gds_msr(void)
> * the same state. Make sure the mitigation is enabled on all
> * CPUs.
> */
> + gds_lock = GDS_MITG_LOCKED;
Can't we just drop the new gds_lock var and set mcu_ctrl |= GDS_MITG_LOCKED here?
> + fallthrough;
> case GDS_MITIGATION_FULL:
> rdmsrl(MSR_IA32_MCU_OPT_CTRL, mcu_ctrl);
> mcu_ctrl &= ~GDS_MITG_DIS;
> @@ -779,6 +781,7 @@ void update_gds_msr(void)
> return;
> }
>
> + mcu_ctrl |= gds_lock;
> wrmsrl(MSR_IA32_MCU_OPT_CTRL, mcu_ctrl);
Powered by blists - more mailing lists