[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <320802FA-6BD0-4E3E-8812-0B8D5FB5F464@alien8.de>
Date: Sat, 26 Apr 2025 14:22:56 +0300
From: Borislav Petkov <bp@...en8.de>
To: "Kaplan, David" <David.Kaplan@....com>
CC: Thomas Gleixner <tglx@...utronix.de>, Peter Zijlstra <peterz@...radead.org>,
Josh Poimboeuf <jpoimboe@...nel.org>,
Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>,
Ingo Molnar <mingo@...hat.com>, Dave Hansen <dave.hansen@...ux.intel.com>,
"x86@...nel.org" <x86@...nel.org>, "H . Peter Anvin" <hpa@...or.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v5 03/16] x86/bugs: Restructure MMIO mitigation
On April 25, 2025 4:28:14 PM GMT+03:00, "Kaplan, David" <David.Kaplan@....com> wrote:
>It was the intent to imply that. If you look at patch 1, 2, and 4 then if verw_mitigation_selected is ever set to true, it means that some mitigation is going to force X86_FEATURE_CLEAR_CPU_BUF.
Aaaand the other shoe dropped...
>Maybe the solution here is to clarify the comment above verw_mitigation_selected that it is set if any of those 4 bugs are going to enable X86_FEATURE_CLEAR_CPU_BUF. So it implies that specific VERW-based mitigation.
>
>Or perhaps I could even rename the variable to be 'clear_cpu_buf_selected'?
Right, I think both should be the optimal thing as it would make it crystal clear.
>I think clarifying what verw_mitigation_selected means is better. When that becomes clear, I think that the existing comments make sense.
>
Ok, all clear.
But you don't have to resend an updated set - I'll fix that up while applying.
Thx.
--
Sent from a small device: formatting sucks and brevity is inevitable.
Powered by blists - more mailing lists