From: Mostafa Saleh <smostafa@google.com>
To: linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev,
linux-arm-kernel@lists.infradead.org
Cc: maz@kernel.org, oupton@kernel.org, seiden@linux.ibm.com,
joey.gouly@arm.com, suzuki.poulose@arm.com,
yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org,
vdonnefort@google.com, tabba@google.com,
Mostafa Saleh <smostafa@google.com>
Subject: [RFC PATCH 2/2] KVM: arm64: Support BBM level 3
Date: Fri, 17 Jul 2026 13:09:00 +0000 [thread overview]
Message-ID: <20260717130901.2239134-3-smostafa@google.com> (raw)
In-Reply-To: <20260717130901.2239134-1-smostafa@google.com>
If the system supports hardware Break-Before-Make (BBM) level 3, use it
to replace stage-2 PTEs directly instead of falling back to the software
break-before-make sequence.
1) Get a reference count on the containing table for the new PTE.
2) Atomically update the PTE with the new valid descriptor.
3) Invalidate the TLB for the old PTE.
4) Drop the reference count holding the old PTE.
One interesting case, as BBML3 will update the PTE atomically, it
can only know it raced with another core at the point of the cmpxchg
failing, unlike the SW implementation which locks the PTE first.
And as we must issue CMOs to the new mapped page before the update,
that means with BBML3 racing cores will issue redundant CMOs,
to improve this:
- We only use BBML3 if the old PTE was live.
- To reduce the window of the race, an early check is added before
the CMO to exit early, but that does not eliminate the race.
Signed-off-by: Mostafa Saleh <smostafa@google.com>
---
arch/arm64/kvm/hyp/pgtable.c | 53 +++++++++++++++++++++++++++++++-----
1 file changed, 46 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
index 127b7f9541b1..69d52308236f 100644
--- a/arch/arm64/kvm/hyp/pgtable.c
+++ b/arch/arm64/kvm/hyp/pgtable.c
@@ -838,7 +838,8 @@ static void stage2_clean_old_pte(const struct kvm_pgtable_visit_ctx *ctx,
/**
* stage2_try_break_pte() - Invalidates a pte according to the
* 'break-before-make' requirements of the
- * architecture.
+ * architecture, if BMML3 is supported it
+ * will be used, otherwise fallback to SW.
*
* @ctx: context of the visited pte.
* @mmu: stage-2 mmu
@@ -854,6 +855,18 @@ static bool stage2_try_break_pte(const struct kvm_pgtable_visit_ctx *ctx,
{
kvm_pte_t locked_pte;
+ if (system_supports_bbml3() && kvm_pte_valid(ctx->old)) {
+ kvm_pte_t curr_pte = READ_ONCE(*ctx->ptep);
+
+ /*
+ * All handled in stage2_make_pte(). However exit early if we already
+ * lost the race to avoid extra CMOs.
+ */
+ if (curr_pte != ctx->old)
+ return false;
+ return true;
+ }
+
if (stage2_pte_is_locked(ctx->old)) {
/*
* Should never occur if this walker has exclusive access to the
@@ -873,16 +886,35 @@ static bool stage2_try_break_pte(const struct kvm_pgtable_visit_ctx *ctx,
return true;
}
-static void stage2_make_pte(const struct kvm_pgtable_visit_ctx *ctx, kvm_pte_t new)
+/* Must be paired with stage2_try_break_pte() */
+static bool stage2_make_pte(const struct kvm_pgtable_visit_ctx *ctx, struct kvm_s2_mmu *mmu,
+ kvm_pte_t new)
{
struct kvm_pgtable_mm_ops *mm_ops = ctx->mm_ops;
- WARN_ON(!stage2_pte_is_locked(*ctx->ptep));
-
if (stage2_pte_is_counted(new))
mm_ops->get_page(ctx->ptep);
+ if (system_supports_bbml3() && kvm_pte_valid(ctx->old)) {
+ /*
+ * Barrier is required because stage2_try_set_pte() uses
+ * WRITE_ONCE for non-shared walks, lacking release semantics
+ * used in the software BBM case.
+ */
+ smp_wmb();
+ if (!stage2_try_set_pte(ctx, new)) {
+ if (stage2_pte_is_counted(new))
+ mm_ops->put_page(ctx->ptep);
+ return false;
+ }
+
+ stage2_clean_old_pte(ctx, mmu);
+ return true;
+ }
+
+ WARN_ON(!stage2_pte_is_locked(*ctx->ptep));
smp_store_release(ctx->ptep, new);
+ return true;
}
static bool stage2_unmap_defer_tlb_flush(struct kvm_pgtable *pgt)
@@ -1014,7 +1046,8 @@ static int stage2_map_walker_try_leaf(const struct kvm_pgtable_visit_ctx *ctx,
stage2_pte_executable(new))
mm_ops->icache_inval_pou(kvm_pte_follow(new, mm_ops), granule);
- stage2_make_pte(ctx, new);
+ if (!stage2_make_pte(ctx, data->mmu, new))
+ return -EAGAIN;
return 0;
}
@@ -1069,7 +1102,10 @@ static int stage2_map_walk_leaf(const struct kvm_pgtable_visit_ctx *ctx,
* will be mapped lazily.
*/
new = kvm_init_table_pte(childp, mm_ops);
- stage2_make_pte(ctx, new);
+ if (!stage2_make_pte(ctx, data->mmu, new)) {
+ mm_ops->put_page(childp);
+ return -EAGAIN;
+ }
return 0;
}
@@ -1557,7 +1593,10 @@ static int stage2_split_walker(const struct kvm_pgtable_visit_ctx *ctx,
* writes the PTE using smp_store_release().
*/
new = kvm_init_table_pte(childp, mm_ops);
- stage2_make_pte(ctx, new);
+ if (!stage2_make_pte(ctx, mmu, new)) {
+ kvm_pgtable_stage2_free_unlinked(mm_ops, childp, level);
+ return -EAGAIN;
+ }
return 0;
}
--
2.55.0.229.g6434b31f56-goog
next prev parent reply other threads:[~2026-07-17 13:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-17 13:08 [RFC PATCH 0/2] KVM: arm64: Support BBM level 3 Mostafa Saleh
2026-07-17 13:08 ` [RFC PATCH 1/2] KVM: arm64: Add stage2_clean_old_pte() Mostafa Saleh
2026-07-17 13:09 ` Mostafa Saleh [this message]
2026-07-17 13:28 ` [RFC PATCH 2/2] KVM: arm64: Support BBM level 3 sashiko-bot
2026-07-17 14:15 ` Mostafa Saleh
2026-07-17 20:56 ` Oliver Upton
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=20260717130901.2239134-3-smostafa@google.com \
--to=smostafa@google.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=seiden@linux.ibm.com \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.com \
--cc=vdonnefort@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.