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

[Brendan Jackman <jackmanb@google.com>]

On Wed Oct 1, 2025 at 8:59 PM UTC, Dave Hansen wrote:
> On 9/24/25 07:59, Brendan Jackman wrote:
>> Why is this the scope of the first series? The objective here is to
>> reach a MVP of ASI that people can actually run, as soon as possible.
>
> I had to ask ChatGPT what you meant by MVP. Minimum Viable Product?

Yeah exactly, sorry I am leaking corporate jargon.

> So this series just creates a new address space and then ensures that
> sensitive data is not mapped there? To me, that's a proof-of-concept,
> not a bit of valuable functionality that can be merged upstream.
>
> I'm curious how far the first bit of functionality that would be useful
> to end users is from the end of this series.

I think this series is about half way there. With 2 main series:

1. The bit to get the pagetables set up (this series)

2. The bit to switch in and out of the address space

We already have something that delivers security value. It would only
perform well for a certain set of usecases, but there are users for whom
its still a win - it's already strictly cheaper than IBPB-on-VMExit.

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

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?

[0] https://lore.kernel.org/all/20250812173109.295750-1-jackmanb@google.com/