Linux KVM/arm64 development list
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Marc Zyngier" <maz@kernel.org>
Cc: "Oliver Upton" <oupton@kernel.org>,
	kvm@vger.kernel.org, kvmarm@lists.linux.dev,
	"Marc Zyngier" <maz@kernel.org>
Subject: Re: [PATCH 4/6] KVM: arm64: Correctly handle end of VA space TLBI invalidation
Date: Sat, 01 Aug 2026 13:03:37 +0000	[thread overview]
Message-ID: <20260801130337.EB2BA1F00AC4@smtp.kernel.org> (raw)
In-Reply-To: <20260801124818.366274-5-maz@kernel.org>

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 <maz@kernel.org>

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/20260801124818.366274-1-maz@kernel.org?part=4

  reply	other threads:[~2026-08-01 13:03 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-01 12:48 [PATCH 0/6] KVM: arm64: VNCR TLB invalidation fixes Marc Zyngier
2026-08-01 12:48 ` [PATCH 1/6] KVM: arm64: Remove VM-wide VNCR mapping counter Marc Zyngier
2026-08-01 13:08   ` sashiko-bot
2026-08-01 13:19     ` Marc Zyngier
2026-08-01 12:48 ` [PATCH 2/6] KVM: arm64: Handle negative S1 walk levels in VNCR TLB size evaluation Marc Zyngier
2026-08-01 13:02   ` sashiko-bot
2026-08-01 13:20     ` Marc Zyngier
2026-08-01 12:48 ` [PATCH 3/6] KVM: arm64: Consider SCTLR_EL2.M when mapping the L1 VNCR page Marc Zyngier
2026-08-01 13:10   ` sashiko-bot
2026-08-01 12:48 ` [PATCH 4/6] KVM: arm64: Correctly handle end of VA space TLBI invalidation Marc Zyngier
2026-08-01 13:03   ` sashiko-bot [this message]
2026-08-01 13:40     ` Marc Zyngier
2026-08-01 12:48 ` [PATCH 5/6] KVM: arm64: Couple VNCR fixmap clearing and CPU number invalidation Marc Zyngier
2026-08-01 13:02   ` sashiko-bot
2026-08-01 14:51     ` Marc Zyngier
2026-08-01 12:48 ` [PATCH 6/6] KVM: arm64: Add VNCR TLB tracking again Marc Zyngier
2026-08-01 13:04   ` sashiko-bot
2026-08-01 17:01     ` Marc Zyngier

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=20260801130337.EB2BA1F00AC4@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=maz@kernel.org \
    --cc=oupton@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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