Re: [PATCH 4/6] KVM: arm64: Correctly handle end of VA space TLBI invalidation

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

Pre-existing issues:
- [High] Missing sign-extension in `decode_range_tlbi()` breaks Stage-1 range TLB invalidations (e.g., `TLBI RVAE1`) for TTBR1 addresses.
--

--- Patch [4]: [PATCH 4/6] KVM: arm64: Correctly handle end of VA space TLBI invalidation ---
commit 33057eee0c17792f671722b92173b4f67ff0fde6
Author: Marc Zyngier <[email protected]>

KVM: arm64: Correctly handle end of VA space TLBI invalidation

This patch corrects the overlap check for TLB invalidations by modifying the
comparison logic to be inclusive rather than exclusive. This fixes an issue
where the invalidation would fail if the range ended exactly at the boundary of
the TTBR1 VA space due to address rollover.

> diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
> index 711c0d0ff8339..69a4652f39336 100644
> --- a/arch/arm64/kvm/nested.c
> +++ b/arch/arm64/kvm/nested.c

[ ... ]

> @@ -1060,28 +1064,19 @@ static void invalidate_vncr_va(struct kvm *kvm,
>  	lockdep_assert_held_write(&kvm->mmu_lock);
>  
>  	kvm_for_each_vncr_tlb(i, vcpu, vt, kvm) {
[ ... ]
>  		switch (scope->type) {
>  		case TLBI_ALL:
>  			break;
>  
>  		case TLBI_VA:
> -			if (va_end <= scope->va ||
> -			    va_start >= (scope->va + scope->size))
> +			if (!vncr_tlb_intersects(vt, vt->gva, scope->va, scope->size))

[Severity: High]
This is a pre-existing issue, but does scope->va fail to match TTBR1 addresses
because it is not properly sign-extended?

Looking at compute_s1_tlbi_range() which populates scope->va using
decode_range_tlbi(val, &scope->size, &scope->asid), the base address is
extracted in arch/arm64/include/asm/kvm_nested.h:

	base = (val & GENMASK(36, 0)) << shift;

Because this shifts the bits without sign-extending them to 64 bits, TTBR1
addresses are zero-extended. When vncr_tlb_intersects() compares this positive
scope_start against a correctly sign-extended, negative vt->gva (mapped to
tlb_start), the unsigned comparison (tlb_start > scope_end) evaluates to true.

Could this cause Stage-1 range TLB invalidations (like TLBI RVAE1) to silently
fail for kernel space addresses, leaving stale translations in the nested
guest's TLB?

>  				continue;
>  			if (vt->wr.nG && vt->wr.asid != scope->asid)
>  				continue;
>  			break;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=4