Re: [PATCH 00/21] mm: ASI direct map management

[Brendan Jackman <jackmanb@google.com>]

On Thu Oct 2, 2025 at 5:01 PM UTC, Dave Hansen wrote:
> 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.

OK thanks, after our IRC chat I understand this now. So in the case of
pkeys I guess the internal gunk didn't "do anything" per se but it was a
clear improvement in the code in its own right. So I'll look for a way
to split out the preparatory stuff to be more like that. And then I'll
try to get a single patchset that goes from "no ASI" to "ASI that does
_something_ useful". I think it's inevitable that this will still be
rather on the large side but I'll do my best.

>> 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

And yep, I'll take a look at this too. Thanks very much for taking a
look and for all of the valuable pointers.