[PATCH 0/4] KVM: arm64: Reduce overhead of full S2 teardown

Oliver Upton oupton at kernel.org
Tue Sep 15 16:19:18 PDT 2026


Hey,

On Mon, Sep 14, 2026 at 09:14:24AM +0100, Marc Zyngier wrote:
> > Another vCPU can therefore still use that shadow S2. The write lock
> > excludes software page-table updates, not hardware table walks.
> > The following interleaving is allowed:
> > 
> >   vCPU B / hardware walker        vCPU A
> >   ------------------------        ----------------------------
> >   Holds an old reference to T
> >                                   Clears parent, skips TLBI
> >                                   Drops T's last reference
> >                                   T is reused by the allocator
> >   Accesses T via the old reference
> >                                   Performs final VMID-wide TLBI
> >
> > The final flush barriers cannot retroactively protect a table that
> > has already been freed and reused.
> 
> T is a shadow page-table page on the host. How can vcpu B hold a
> reference on that page? It isn't even in the same address space.
> 
> Now, I can see that B could have a VA that *translate through* T, and
> that's rather annoying.
> 
> I'll have a think.

One option that may be worth considering is reusing the KVM_REQ_NESTED_S2_UNMAP
request for emulating VMALLS12E1*. All vCPUs that share the S2 MMU would
be forced to take EL1&0 out of context until the unmap operation
completes, at the expense of an unnecessary kick to vCPUs in a different
MMU context.

A bit hacky but seems more straightforward than wiring up some batching
mechanism for freeing table pages.

Thanks,
Oliver



More information about the linux-arm-kernel mailing list