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

[Mostafa Saleh <smostafa@google.com>]

On Fri, Jul 17, 2026 at 01:28:57PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Critical] Replacing a block mapping with an empty table mapping using BBML3 violates architectural requirements and causes TLB conflict aborts.
> --
> 
> --- Patch [2]: [RFC PATCH 2/2] KVM: arm64: Support BBM level 3 ---
> commit ea79cffc563af3beac80c1a139cbab5674ecb7f0
> Author: Mostafa Saleh <smostafa@google.com>
> 
> KVM: arm64: Support BBM level 3
> 
> This patch introduces support for hardware Break-Before-Make (BBM) level 3
> to replace stage-2 PTEs directly instead of using the software sequence.
> It atomically updates the PTE and relies on hardware features to handle
> the transition.
> 
> > --- a/arch/arm64/kvm/hyp/pgtable.c
> > +++ b/arch/arm64/kvm/hyp/pgtable.c
> 
> [ ... ]
> 
> > @@ -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;
> >  }
> 
> [Severity: Critical]
> Does using BBML3 to replace a block mapping with an empty table mapping risk
> a TLB conflict abort?
> 
> In stage2_map_walk_leaf(), the code allocates a zeroed page for the new
> table and installs it. With BBML3, stage2_make_pte() atomically overwrites
> the valid block PTE with the new empty table PTE, bypassing the software
> break step.
> 
> Because the new table is unpopulated, if another CPU takes a stage-2 fault
> on this range before the TLBI completes, it can populate a 4KB page in the
> new table. That CPU will then cache the new 4KB mapping while still holding
> the old 2MB block mapping in its TLB. The overlapping entries will trigger
> a fatal TLB Conflict Abort, panicking the host.
> 
> Would it be necessary to either fall back to the software break-before-make
> sequence when splitting a block, or ensure the new table is populated with
> equivalent translations before the atomic swap?

The point of BBML3 is not to get conflict aborts, so I do not believe
that can happen.

Thanks,
Mostafa


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