Message-ID: <6a97031d-33d4-4710-ab5a-7d8947936038@intel.com>
Date: Thu, 2 Oct 2025 10:01:44 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Brendan Jackman <jackmanb@...gle.com>, 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>
Cc: peterz@...radead.org, bp@...en8.de, 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 00/21] mm: ASI direct map management

On 10/2/25 04:23, Brendan Jackman wrote:
...
> [Well, I'm assuming there that we include the actual security flushes in
> series 2, maybe that would be more like "2b"...]
> 
> To get to the more interesting cases where it's faster than the current
> default, I think is not that far away for KVM usecases. I think the
> branch I posted in my [Discuss] thread[0] gets competitive with existing
> KVM usecases well before it devolves into the really hacky prototype
> stuff.
> 
> To get to the actual goal, where ASI can become the global default (i.e.
> it's still fast when you sandbox native tasks as well as KVM guests), is
> further since we need to figure out the details on something like what I
> called the "ephmap" in [0].
> 
> There are competing tensions here - we would prefer not to merge code
> that "doesn't do anything", but on the other hand I don't think anyone
> wants to find themselves receiving [PATCH v34 19/40] next July... so
> I've tried to strike a balance here. Something like:
> 
> 1. Develop a consensus that "we probably want ASI and it's worth trying"
> 
> 2. Start working towards it in-tree, by breaking it down into smaller
>    chunks.

Just to be clear: we don't merge code that doesn't do anything
functional. The bar for inclusion is that it has to do something
practical and useful for end users. It can't be purely infrastructure or
preparatory.

Protection keys is a good example. It was a big, gnarly series that
could be roughly divided into two pieces: one that did all the page
table gunk, and all the new ABI bits around exposing pkeys to apps. But
we found a way to do all the page table gunk with no new ABI and that
also gave security folks something they wanted: execute_only_pkey().

So we merged all the page table and internal gunk first, and then the
new ABI a release or two later.

But the important part was that it had _some_ functionality from day one
when it was merged. It wasn't purely infrastructure.

> Do you think it would help if I started also maintaining an asi-next
> branch with the next few things all queued up and benchmarked, so we can
> get a look at the "goal state" while also keeping an eye on the here and
> now? Or do you have other suggestions for the strategy here?

Yes, I think that would be useful.

For instance, imagine you'd had that series sitting around:
6.16-asi-next. Then, all of a sudden you see the vmscape series[1] show
up. Ideally, you'd take your 6.16-asi-next branch and show us how much
simpler and faster it is to mitigate vmscape with ASI instead of the
IBPB silliness that we ended up with.

Basically, use your asi-next branch to bludgeon us each time we _should_
have been using it.

It's also not too late. You could still go back and do that analysis for
vmscape. It's fresh enough in our minds to matter.

1.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=223ba8ee0a3986718c874b66ed24e7f87f6b8124

Powered by blists - more mailing lists