[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0de32bbc-66e9-4875-af87-7a2fa2e03e39@intel.com>
Date: Mon, 6 Jan 2025 08:50:27 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Borislav Petkov <bp@...en8.de>, Rik van Riel <riel@...riel.com>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org, kernel-team@...a.com,
dave.hansen@...ux.intel.com, luto@...nel.org, peterz@...radead.org,
tglx@...utronix.de, mingo@...hat.com, hpa@...or.com,
akpm@...ux-foundation.org, nadav.amit@...il.com, zhengqi.arch@...edance.com,
linux-mm@...ck.org
Subject: Re: [PATCH 05/12] x86/mm: add INVLPGB support code
On 1/2/25 04:42, Borislav Petkov wrote:
>> +#define INVLPGB_VA BIT(0)
>> +#define INVLPGB_PCID BIT(1)
>> +#define INVLPGB_ASID BIT(2)
>> +#define INVLPGB_INCLUDE_GLOBAL BIT(3)
>> +#define INVLPGB_FINAL_ONLY BIT(4)
>> +#define INVLPGB_INCLUDE_NESTED BIT(5)
> Please add only the defines which are actually being used. Ditto for the
> functions.
There's some precedent for defining them all up front, like we did for
invpcid_flush_*().
For INVPCID, there are four variants and two of them got used up front.
But I get that it's a balancing act between having untested code that
might bitrot and introducing helpers at a time when someone (Rik) is
very likely to get all the variants coded up correctly.
Rik, how many of these end up being used by the end of the series?
Powered by blists - more mailing lists