[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