[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DE509XAYNMVR.2UH3ZEC7HIU69@google.com>
Date: Mon, 10 Nov 2025 12:15:45 +0000
From: Brendan Jackman <jackmanb@...gle.com>
To: Borislav Petkov <bp@...en8.de>, Brendan Jackman <jackmanb@...gle.com>
Cc: Andy Lutomirski <luto@...nel.org>, Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
"Liam R. Howlett" <Liam.Howlett@...cle.com>, Suren Baghdasaryan <surenb@...gle.com>,
Michal Hocko <mhocko@...e.com>, Johannes Weiner <hannes@...xchg.org>, Zi Yan <ziy@...dia.com>,
Axel Rasmussen <axelrasmussen@...gle.com>, Yuanchu Xie <yuanchu@...gle.com>,
Roman Gushchin <roman.gushchin@...ux.dev>, <peterz@...radead.org>,
<dave.hansen@...ux.intel.com>, <mingo@...hat.com>, <tglx@...utronix.de>,
<akpm@...ux-foundation.org>, <david@...hat.com>, <derkling@...gle.com>,
<junaids@...gle.com>, <linux-kernel@...r.kernel.org>, <linux-mm@...ck.org>,
<reijiw@...gle.com>, <rientjes@...gle.com>, <rppt@...nel.org>,
<vbabka@...e.cz>, <x86@...nel.org>, Yosry Ahmed <yosry.ahmed@...ux.dev>
Subject: Re: [PATCH 02/21] x86/mm/asi: add X86_FEATURE_ASI and asi=
On Mon Nov 10, 2025 at 11:26 AM UTC, Borislav Petkov wrote:
> On Sun, Oct 26, 2025 at 10:24:35PM +0000, Brendan Jackman wrote:
>> Hm yeah, I actually also thought I had some direct feedback from one of
>> the x86 maintainers saying not to expose it here. I can no longer find
>> that feedback on Lore so I think I must be misremembering, the flag
>> was already hidden back in [0].
>>
>> [0] https://lore.kernel.org/linux-mm/20240712-asi-rfc-24-v1-5-144b319a40d8@google.com/
>>
>> If that feedback indeed doesn't exist
>
> Just ignore everything whoever might've told you or not - we override all
> previous statements! :-P
>
> From Documentation/arch/x86/cpuinfo.rst
>
> "So, the current use of /proc/cpuinfo is to show features which the
> kernel has *enabled* and *supports*. As in: the CPUID feature flag is
> there, there's an additional setup which the kernel has done while
> booting and the functionality is ready to use. A perfect example for
> that is "user_shstk" where additional code enablement is present in the
> kernel to support shadow stack for user programs."
>
> So it is all written down now and is the law! :-P
>
>> then personally I'd lean towards exposing it right away, I don't see that
>> much downside in terms of ABI, since ASI kinda "doesn't do anything", from
>> a SW point of view it's just a very weird and complicated NOP. It's hard for
>> me to see how userspace could grow a functional dependency on this flag.
>> Whereas for general monitoring it's handy.
>
> The point is: once all the ASI code lands, we should show it in cpuinfo. As
> in: "this kernel supports ASI" and not "there's asi in cpuinfo but well,
> that's not the whole deal."
>
> Makes sense?
Sure, sounds good to me.
Powered by blists - more mailing lists