From: Wei-Lin Chang <weilin.chang@arm.com>
To: linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
linux-kernel@vger.kernel.org
Cc: Marc Zyngier <maz@kernel.org>, Oliver Upton <oupton@kernel.org>,
Joey Gouly <joey.gouly@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Wei-Lin Chang <weilin.chang@arm.com>
Subject: [PATCH 0/1] KVM: arm64: nv: Implement nested stage-2 reverse map
Date: Sat, 11 Apr 2026 13:50:23 +0100 [thread overview]
Message-ID: <20260411125024.3735989-1-weilin.chang@arm.com> (raw)
Hi,
This is v2 of optimizing the shadow s2 mmu unmapping during MMU
notifiers. Thanks to Sashiko, who helped point out the many problems [1]
in v1.
* Changes from v1 [2]:
- Rebased on to a newer kvmarm/next, where user_mem_abort() underwent
a significant refactor.
- Added a flag VALID_ENTRY (bit 63) to each non-polluted reverse map
entry, so that if nested IPA == 0, we still insert a non-zero entry
to the maple tree.
- Added usage of the maple tree lock while using the tree. Previously
I though I could piggyback on kvm->mmu_lock, but this doesn't work
for 2 reasons:
1. The maple tree advanced API (mas_*) expects the maple tree lock
to be held.
2. At stage-2 fault time, kvm->mmu_lock is only taken for read.
Therefore even if 1. does not matter, parallel accesses to the
maple tree could still happen.
- Changed from using GFP_KERNEL_ACCOUNT to (GFP_NOWAIT | __GFP_ACCOUNT)
in maple tree operations. This is done because GFP_KERNEL_ACCOUNT
can sleep, and we are holding kvm->mmu_lock while doing the
operations.
- Made the code able to tolerate reverse map creation failure. In v1
if a maple tree operation fails, the error is reported back to the
caller which in the end fails the vCPU run. It shouldn't be this way
as the reverse map is an optimization and it shouldn't fail the
normal operation as we can fallback to a full unmap.
- Added a boolean nested_revmap_broken in struct kvm_s2_mmu. If
reverse map creation fails, the reverse map becomes unreliable. Keep
this failure information with nested_revmap_broken so that we can
fallback when we need to unmap.
- Removed patch 2,3,4 for now. After we start using the maple tree
lock, and keeping track of the reverse map failure state in
nested_revmap_broken, the s2 mmu look up acceleration in v1 patch 2
becomes very complicated, as the canonical maple tree used to speed
up s2 mmu look up can also encounter allocation failures which we
also need to keep track of and fallback. In the mean time the
consistency between the trees is not easy to reason about when
errors happen. Additionally, the extra lock of the canonical maple
tree also needs to be considered and care must be taken to not
introduce lock order inversion.
Given the above I believe it is best to leave the reverse map
improvements out for now, so as to not use too much time thinking
about optimization before the initial version of the reverse map is
even good.
Thanks!
[1]: https://sashiko.dev/#/patchset/20260330100633.2817076-1-weilin.chang%40arm.com
[2]: https://lore.kernel.org/kvmarm/20260330100633.2817076-1-weilin.chang@arm.com/
Wei-Lin Chang (1):
KVM: arm64: nv: Avoid full shadow s2 unmap
arch/arm64/include/asm/kvm_host.h | 4 +
arch/arm64/include/asm/kvm_nested.h | 4 +
arch/arm64/kvm/mmu.c | 30 ++++--
arch/arm64/kvm/nested.c | 147 +++++++++++++++++++++++++++-
4 files changed, 177 insertions(+), 8 deletions(-)
--
2.43.0
next reply other threads:[~2026-04-11 12:51 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-11 12:50 Wei-Lin Chang [this message]
2026-04-11 12:50 ` [PATCH 1/1] KVM: arm64: nv: Avoid full shadow s2 unmap Wei-Lin Chang
2026-04-11 14:00 ` [PATCH v2 0/1] KVM: arm64: nv: Implement nested stage-2 reverse map 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=20260411125024.3735989-1-weilin.chang@arm.com \
--to=weilin.chang@arm.com \
--cc=catalin.marinas@arm.com \
--cc=joey.gouly@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=oupton@kernel.org \
--cc=suzuki.poulose@arm.com \
--cc=will@kernel.org \
--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