From: Marc Zyngier <maz@kernel.org>
To: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
Steffen Eiden <seiden@linux.ibm.com>,
Joey Gouly <joey.gouly@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Oliver Upton <oupton@kernel.org>,
Zenghui Yu <yuzenghui@huawei.com>,
Fuad Tabba <fuad.tabba@linux.dev>,
Shen Yongchao <grayhat@foxmail.com>,
Karl Mehltretter <kmehltretter@gmail.com>,
Wei-Lin Chang <weilin.chang@arm.com>,
stable@vger.kernel.org
Subject: Re: [PATCH v3 2/2] KVM: arm64: nv: Delay freeing of shadow S2 structures until VM destruction
Date: Sat, 22 Aug 2026 09:12:32 +0100 [thread overview]
Message-ID: <86v7924lqn.wl-maz@kernel.org> (raw)
In-Reply-To: <aoiQuVs5jzB5La4i@gremlin>
On Fri, 21 Aug 2026 19:15:45 +0100,
"Lorenzo Stoakes (ARM)" <ljs@kernel.org> wrote:
>
> On Fri, Aug 21, 2026 at 05:18:29PM +0100, Marc Zyngier wrote:
> > We free the shadow S2 structures from kvm_arch_flush_shadow_all(), which
> > is a Bad Idea(tm). Freeing the page tables is fair game (this is what
> > this callback is for), but freeing the container that could still be
> > referenced by another part of the system is not great.
>
> Yes.
>
> >
> > Instead, grow separate destructors that gets called when we tear the VM
> > down for good. From there, we can nuke both the individual MMUs as well
> > as the global array that points to them, safe in the knowledge that the
> > vcpus themselves have been destroyed already.
> >
> > Fixes: 4f128f8e1aaac ("KVM: arm64: nv: Support multiple nested Stage-2 mmu structures")
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
>
> LGTM so:
>
> Reviewed-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Thanks.
> A couple thoughts/questions below.
[...]
> > @@ -1310,16 +1319,12 @@ void kvm_nested_s2_flush(struct kvm *kvm)
> >
> > void kvm_arch_flush_shadow_all(struct kvm *kvm)
> > {
> > - for (int i = kvm->arch.nested_mmus_size - 1; i >= 0; i--) {
> > + for (int i = 0; i < kvm->arch.nested_mmus_size; i++) {
>
> Hmm why this was in reverse before? :) I guess some product of the
> kvfree() bit or maybe something else?
We allocate s2_mmus in S2_MMU_PER_VCPU chunks. Which means that it
complicates the freeing of the these structures, as they can only be
freed once all S2 PTs of that chunk have been freed. We have three
options:
- scan forward, and use complicated logic to work out that you have
freed the last PTs of a chunk, freeing with a negative offset from
the current point in the loop. Works, but hard to reason about in
fewer than 3 seconds.
- scan backward, use simpler logic to ensure you have reached the
beginning of a chunk, nuke it.
- have two loops, one for the PTs, one for the MMUs. That's what we
end-up with due to the different garbage collection phases.
Cheers,
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2026-08-22 8:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-21 16:18 [PATCH v3 0/2] KVM: arm64: nv: Shadow S2 life-cycle fixes Marc Zyngier
2026-08-21 16:18 ` [PATCH v3 1/2] KVM: arm64: nv: Fix life cycle of the nested_mmus array Marc Zyngier
2026-08-21 16:18 ` [PATCH v3 2/2] KVM: arm64: nv: Delay freeing of shadow S2 structures until VM destruction Marc Zyngier
2026-08-21 18:15 ` Lorenzo Stoakes (ARM)
2026-08-22 8:12 ` Marc Zyngier [this message]
2026-08-24 11:18 ` Lorenzo Stoakes (ARM)
2026-08-23 14:11 ` Wei-Lin Chang
2026-08-24 11:07 ` Lorenzo Stoakes (ARM)
2026-08-24 11:09 ` Lorenzo Stoakes (ARM)
2026-08-23 14:07 ` [PATCH v3 0/2] KVM: arm64: nv: Shadow S2 life-cycle fixes Wei-Lin Chang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86v7924lqn.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=fuad.tabba@linux.dev \
--cc=grayhat@foxmail.com \
--cc=joey.gouly@arm.com \
--cc=kmehltretter@gmail.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=ljs@kernel.org \
--cc=oupton@kernel.org \
--cc=seiden@linux.ibm.com \
--cc=stable@vger.kernel.org \
--cc=suzuki.poulose@arm.com \
--cc=weilin.chang@arm.com \
--cc=yuzenghui@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox