[RFC PATCH v2 0/2] KVM: arm64: Add support for BBM level 3

[RFC PATCH v2 0/2] KVM: arm64: Add support for BBM level 3

[Mostafa Saleh]

This patch series adds support for BBM level 3 to KVM pgtable, it
depends on [1]

Changes from v1:
https://lore.kernel.org/all/20260717130901.2239134-1-smostafa@google.com/
- Limit BBML3 to systems with FWB and DIC and remove race check.

Motivation
==========
I have been looking into this for the context of:
- Page table sharing between the host CPU stage-2 and the SMMUv3 for
  protected KVM.
- Use the pagtable code to populate SMMUv3 stage-2 shadowed
  page table [2]

However, BBM level 3 is still useful for CPU only operations as it
avoids intermediately breaking translation.

Design
======
Some of the conditions that BBM level 3 will be useful in (RWHZWS):
1) A change to a PTE memory type, shareability, cacheability or OA
2) Changing from block to table
3) Changing from table to block

At the moment in the hyp page table code:
- For #1) stage2_map_walker_try_leaf(): Replaces a leaf with another
  one which does not match the same OA/perms/attrs.

- For #2) Switch block to table is used from:
  - kvm_pgtable_stage2_split(): Explicitly splitting a block (used
    for dirty logging), where a block is replaced by a table with
    the same attributes.
  - stage2_map_walk_leaf(): Updating a mapping that is partially
    part of an existing block.

- #3) Does not exist in the code at the moment as coalescing is not
  supported.

The first patch is a preparation to be able to clean up the old pte
for BBML3, the second patch adds the main logic.

Initially, I encapsulated the full logic of BBM in one function,
which was not readable, due to different ordering and dealing with
CMO, TLBI.

Instead, I kept the logic into 2 functions, where BBML3 is added in
the make step.

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
avoid this, we limit the use of BBML3 to systems with FWB and DIC.

Testing
=======
This was tested:
- C1-Pro cores, unfortunately the version I have does not run
  upstream, I backported the patches to Android kernel (6.18).

- mainline(7.2-rc3) kernel on a Qualcomm X1 with a hacked cpufeature
  as it does not support BBM, I did not see conflict aborts or TLB
  corruption.

I tested with VHE and protected (hvhe) modes, running VMs
(and protected), and running some selftests, that might exercise and
stress this path tools/testing/selftests/kvm:
- demand_paging_test
- memslot_perf_test
- memslot_modification_stress_test
- dirty_log_test

Future work
===========
Some other changes that would be useful:
- Eagerly install table on block split, we can now replace a block
  with a fully populated table atomically when we unmap a partial
  part of the block.

- Use BBML3 in the hypervisor stage-1 with nvhe/protected mode to
  improve preformance and reduce memory usage as now it is forced
  to use leaf mappings.

There is more to support page table sharing (such as dealing with
TLB invalidation, coherency...), I submitted a talk to LPC to discuss
this further.

[1] https://lore.kernel.org/all/20260723044034.2983651-1-linu.cherian@arm.com/
[2] https://lore.kernel.org/linux-iommu/20260715115906.2664882-1-smostafa@google.com/

Mostafa Saleh (2):
  KVM: arm64: Add stage2_clean_old_pte()
  KVM: arm64: Support BBM level 3

 arch/arm64/kvm/hyp/pgtable.c | 123 +++++++++++++++++++++++++----------
 1 file changed, 87 insertions(+), 36 deletions(-)

-- 
2.55.0.229.g6434b31f56-goog

[RFC PATCH v2 1/2] KVM: arm64: Add stage2_clean_old_pte()

[Mostafa Saleh]

At the moment, the pgtable code rely on BBM in SW which looks like:
Break: stage2_try_break_pte()
	1) Break PTE and lock it
	2) TLBI
	3) Put the ref on the old PTE

Make: stage2_make_pte()
	1) Get a ref on the new PTE
	2) Install the new PTE

With BBML3, the sequence will look as
	1) Get ref on the new PTE
	2) Install new PTE
	3) TLBI
	4) Put the ref on the old PTE

Which requires moving step #2 #3 from the break function to the make
function, although it is possible to do that for SW BBM also, that
means the stage2_try_break_pte() did not fully break the PTE as it
is referenced in TLBs, although that works it seems fragile.

Instead, move this logic to a new function stage2_clean_old_pte()
so that can be called from BBML3.

Signed-off-by: Mostafa Saleh <smostafa@google.com>
---
 arch/arm64/kvm/hyp/pgtable.c | 67 ++++++++++++++++++++----------------
 1 file changed, 37 insertions(+), 30 deletions(-)

diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
index b74dd5ce1efd..d670da8882a5 100644
--- a/arch/arm64/kvm/hyp/pgtable.c
+++ b/arch/arm64/kvm/hyp/pgtable.c
@@ -810,39 +810,10 @@ static bool stage2_try_set_pte(const struct kvm_pgtable_visit_ctx *ctx, kvm_pte_
 	return cmpxchg(ctx->ptep, ctx->old, new) == ctx->old;
 }
 
-/**
- * stage2_try_break_pte() - Invalidates a pte according to the
- *			    'break-before-make' requirements of the
- *			    architecture.
- *
- * @ctx: context of the visited pte.
- * @mmu: stage-2 mmu
- *
- * Returns: true if the pte was successfully broken.
- *
- * If the removed pte was valid, performs the necessary serialization and TLB
- * invalidation for the old value. For counted ptes, drops the reference count
- * on the containing table page.
- */
-static bool stage2_try_break_pte(const struct kvm_pgtable_visit_ctx *ctx,
+static void stage2_clean_old_pte(const struct kvm_pgtable_visit_ctx *ctx,
 				 struct kvm_s2_mmu *mmu)
 {
 	struct kvm_pgtable_mm_ops *mm_ops = ctx->mm_ops;
-	kvm_pte_t locked_pte;
-
-	if (stage2_pte_is_locked(ctx->old)) {
-		/*
-		 * Should never occur if this walker has exclusive access to the
-		 * page tables.
-		 */
-		WARN_ON(!kvm_pgtable_walk_shared(ctx));
-		return false;
-	}
-
-	locked_pte = FIELD_PREP(KVM_INVALID_PTE_TYPE_MASK,
-				KVM_INVALID_PTE_TYPE_LOCKED);
-	if (!stage2_try_set_pte(ctx, locked_pte))
-		return false;
 
 	if (!kvm_pgtable_walk_skip_bbm_tlbi(ctx)) {
 		/*
@@ -862,6 +833,42 @@ static bool stage2_try_break_pte(const struct kvm_pgtable_visit_ctx *ctx,
 
 	if (stage2_pte_is_counted(ctx->old))
 		mm_ops->put_page(ctx->ptep);
+}
+
+/**
+ * stage2_try_break_pte() - Invalidates a pte according to the
+ *			    'break-before-make' requirements of the
+ *			    architecture.
+ *
+ * @ctx: context of the visited pte.
+ * @mmu: stage-2 mmu
+ *
+ * Returns: true if the pte was successfully broken.
+ *
+ * If the removed pte was valid, performs the necessary serialization and TLB
+ * invalidation for the old value. For counted ptes, drops the reference count
+ * on the containing table page.
+ */
+static bool stage2_try_break_pte(const struct kvm_pgtable_visit_ctx *ctx,
+				 struct kvm_s2_mmu *mmu)
+{
+	kvm_pte_t locked_pte;
+
+	if (stage2_pte_is_locked(ctx->old)) {
+		/*
+		 * Should never occur if this walker has exclusive access to the
+		 * page tables.
+		 */
+		WARN_ON(!kvm_pgtable_walk_shared(ctx));
+		return false;
+	}
+
+	locked_pte = FIELD_PREP(KVM_INVALID_PTE_TYPE_MASK,
+				KVM_INVALID_PTE_TYPE_LOCKED);
+	if (!stage2_try_set_pte(ctx, locked_pte))
+		return false;
+
+	stage2_clean_old_pte(ctx, mmu);
 
 	return true;
 }
-- 
2.55.0.229.g6434b31f56-goog

[RFC PATCH v2 2/2] KVM: arm64: Support BBM level 3

[Mostafa Saleh]

If the system supports hardware Break-Before-Make (BBM) level 3, use it
to replace stage-2 PTEs directly. Otherwise, fall back to the software
BBM sequence.

For BBML3 the sequence is:
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 avoid this, limit BBML3 support for systems with DIC and FWB,
which does not require CMOs.

Signed-off-by: Mostafa Saleh <smostafa@google.com>
---
 arch/arm64/kvm/hyp/pgtable.c | 58 +++++++++++++++++++++++++++++++-----
 1 file changed, 51 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
index d670da8882a5..4644b596f020 100644
--- a/arch/arm64/kvm/hyp/pgtable.c
+++ b/arch/arm64/kvm/hyp/pgtable.c
@@ -835,10 +835,24 @@ static void stage2_clean_old_pte(const struct kvm_pgtable_visit_ctx *ctx,
 		mm_ops->put_page(ctx->ptep);
 }
 
+/*
+ * We assume that KVM will never change the OA of an active translation.
+ * If the host needs to move the backing PFN, it should do an explicit
+ * unmap to issue the required TLBI.
+ */
+static bool stage2_use_bbml3(void)
+{
+	return system_supports_bbml3() &&
+	       cpus_have_final_cap(ARM64_HAS_STAGE2_FWB) &&
+	       cpus_have_final_cap(ARM64_HAS_CACHE_DIC);
+}
+
 /**
  * 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, meaning that this function
+ *			    won't break the PTE.
  *
  * @ctx: context of the visited pte.
  * @mmu: stage-2 mmu
@@ -854,6 +868,10 @@ static bool stage2_try_break_pte(const struct kvm_pgtable_visit_ctx *ctx,
 {
 	kvm_pte_t locked_pte;
 
+	/* All handled in stage2_make_pte() */
+	if (stage2_use_bbml3() && kvm_pte_valid(ctx->old))
+		return true;
+
 	if (stage2_pte_is_locked(ctx->old)) {
 		/*
 		 * Should never occur if this walker has exclusive access to the
@@ -873,16 +891,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)
+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 (stage2_use_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)) {
+			/* Raced with another core. */
+			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 +1051,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 +1107,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;
 }
@@ -1560,7 +1601,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

Re: [RFC PATCH v2 2/2] KVM: arm64: Support BBM level 3

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Missing DSB between MTE tag stores and the stage-2 PTE update.
--

--- Patch [2]: [RFC PATCH v2 2/2] KVM: arm64: Support BBM level 3 ---
commit be481f0e17bfc16626c7f5b1b8b652be3ec92909
Author: Mostafa Saleh <smostafa@google.com>

KVM: arm64: Support BBM level 3

If the system supports hardware Break-Before-Make (BBM) level 3, use it
to replace stage-2 PTEs directly. Otherwise, fall back to the software
BBM sequence.

> diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
> index 127b7f9541b16..5e16ed7e9b909 100644
> --- a/arch/arm64/kvm/hyp/pgtable.c
> +++ b/arch/arm64/kvm/hyp/pgtable.c

[ ... ]

> @@ -873,16 +891,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)
> +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 (stage2_use_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)) {
> +			/* Raced with another core. */
> +			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;
>  }

[Severity: High]
This is a pre-existing issue, but does this sequence lack a required
synchronization barrier for MTE tag stores?

When KVM maps a page with MTE enabled, it clears the tags using STGM:

arch/arm64/kvm/mmu.c:kvm_s2_fault_map() {
        ...
        if (!perm_fault_granule && !s2vi->map_non_cacheable && kvm_has_mte(kvm))
                sanitise_mte_tags(kvm, pfn, mapping_size);
        ...
}

The PTE is then updated here in stage2_make_pte(), which uses either
smp_wmb() + cmpxchg() (mapping to DMB ISHST + CASAL) for BBML3, or
smp_store_release() (mapping to STLR) for the software BBM case. Neither
of these provides the architecturally mandated DSB semantics required
after MTE tag stores.

Without a DSB between sanitise_mte_tags() and the stage-2 PTE update, is
it possible for the hardware page table walker to observe the new PTE
before the explicit tag stores are globally visible? Could this result in
the guest observing uninitialized MTE tags, leading to memory permission
corruption or spurious tag check faults?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260723182140.4025575-1-smostafa@google.com?part=2

Re: [RFC PATCH v2 2/2] KVM: arm64: Support BBM level 3

[Mostafa Saleh]

On Thu, Jul 23, 2026 at 06:43:45PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> 
> Pre-existing issues:
> - [High] Missing DSB between MTE tag stores and the stage-2 PTE update.
> --
> 
> --- Patch [2]: [RFC PATCH v2 2/2] KVM: arm64: Support BBM level 3 ---
> commit be481f0e17bfc16626c7f5b1b8b652be3ec92909
> Author: Mostafa Saleh <smostafa@google.com>
> 
> KVM: arm64: Support BBM level 3
> 
> If the system supports hardware Break-Before-Make (BBM) level 3, use it
> to replace stage-2 PTEs directly. Otherwise, fall back to the software
> BBM sequence.
> 
> > diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
> > index 127b7f9541b16..5e16ed7e9b909 100644
> > --- a/arch/arm64/kvm/hyp/pgtable.c
> > +++ b/arch/arm64/kvm/hyp/pgtable.c
> 
> [ ... ]
> 
> > @@ -873,16 +891,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)
> > +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 (stage2_use_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)) {
> > +			/* Raced with another core. */
> > +			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;
> >  }
> 
> [Severity: High]
> This is a pre-existing issue, but does this sequence lack a required
> synchronization barrier for MTE tag stores?
> 
> When KVM maps a page with MTE enabled, it clears the tags using STGM:
> 
> arch/arm64/kvm/mmu.c:kvm_s2_fault_map() {
>         ...
>         if (!perm_fault_granule && !s2vi->map_non_cacheable && kvm_has_mte(kvm))
>                 sanitise_mte_tags(kvm, pfn, mapping_size);
>         ...
> }
> 
> The PTE is then updated here in stage2_make_pte(), which uses either
> smp_wmb() + cmpxchg() (mapping to DMB ISHST + CASAL) for BBML3, or
> smp_store_release() (mapping to STLR) for the software BBM case. Neither
> of these provides the architecturally mandated DSB semantics required
> after MTE tag stores.
> 
> Without a DSB between sanitise_mte_tags() and the stage-2 PTE update, is
> it possible for the hardware page table walker to observe the new PTE
> before the explicit tag stores are globally visible? Could this result in
> the guest observing uninitialized MTE tags, leading to memory permission
> corruption or spurious tag check faults?

I do not know much about MTE, but AFAIU, STLR wouldn’t order against
page table walks. So there is a window between the STGM and the DSB at
the end of the map where another core can observe a valid PTE and not
a the new tag. My guess we need a DSB at the end of
sanitise_mte_tags()

Thanks,
Mostafa

> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260723182140.4025575-1-smostafa@google.com?part=2

Re: [RFC PATCH v2 0/2] KVM: arm64: Add support for BBM level 3

[Linu Cherian]

Hi,

On Thu, Jul 23, 2026 at 06:21:38PM +0000, Mostafa Saleh wrote:
> This patch series adds support for BBM level 3 to KVM pgtable, it
> depends on [1]
> 
> Changes from v1:
> https://lore.kernel.org/all/20260717130901.2239134-1-smostafa@google.com/
> - Limit BBML3 to systems with FWB and DIC and remove race check.
> 
> Motivation
> ==========
> I have been looking into this for the context of:
> - Page table sharing between the host CPU stage-2 and the SMMUv3 for
>   protected KVM.
> - Use the pagtable code to populate SMMUv3 stage-2 shadowed
>   page table [2]
> 
> However, BBM level 3 is still useful for CPU only operations as it
> avoids intermediately breaking translation.
> 
> Design
> ======
> Some of the conditions that BBM level 3 will be useful in (RWHZWS):
> 1) A change to a PTE memory type, shareability, cacheability or OA

Could you please clarify how BBM level 3 is helping this particular scenario ?
This is supposed to be a case where break before make is required.

Thanks,
Linu Cherian.
 

Re: [RFC PATCH v2 0/2] KVM: arm64: Add support for BBM level 3

[Mostafa Saleh]

Hi Linu,

On Thu, Jul 30, 2026 at 08:52:37AM +0530, Linu Cherian wrote:
> Hi,
> 
> On Thu, Jul 23, 2026 at 06:21:38PM +0000, Mostafa Saleh wrote:
> > This patch series adds support for BBM level 3 to KVM pgtable, it
> > depends on [1]
> > 
> > Changes from v1:
> > https://lore.kernel.org/all/20260717130901.2239134-1-smostafa@google.com/
> > - Limit BBML3 to systems with FWB and DIC and remove race check.
> > 
> > Motivation
> > ==========
> > I have been looking into this for the context of:
> > - Page table sharing between the host CPU stage-2 and the SMMUv3 for
> >   protected KVM.
> > - Use the pagtable code to populate SMMUv3 stage-2 shadowed
> >   page table [2]
> > 
> > However, BBM level 3 is still useful for CPU only operations as it
> > avoids intermediately breaking translation.
> > 
> > Design
> > ======
> > Some of the conditions that BBM level 3 will be useful in (RWHZWS):
> > 1) A change to a PTE memory type, shareability, cacheability or OA
> 
> Could you please clarify how BBM level 3 is helping this particular scenario ?
> This is supposed to be a case where break before make is required.

Right, I initially misinterpreted the rule.
However, AFAIK, KVM does not rely on those, I added a comment based
on Oliver feedback in the last version.

I will update the cover letter. But looking again, may be we also need
an extra check to enforce that in the run time and fallback to SW BBM
as I'd be concerned about some of the KVM call chains as
user_mem_abort().

Thanks,
Mostafa

> 
> Thanks,
> Linu Cherian.
>