Linux KVM/arm64 development list
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: sashiko-reviews@lists.linux.dev
Cc: kvmarm@lists.linux.dev, "Oliver Upton" <oupton@kernel.org>,
	kvm@vger.kernel.org
Subject: Re: [PATCH 2/6] KVM: arm64: Handle negative S1 walk levels in VNCR TLB size evaluation
Date: Sat, 01 Aug 2026 14:20:29 +0100	[thread overview]
Message-ID: <87qzkiou3m.wl-maz@kernel.org> (raw)
In-Reply-To: <20260801130236.376BD1F00AC4@smtp.kernel.org>

On Sat, 01 Aug 2026 14:02:35 +0100,
sashiko-bot@kernel.org wrote:
> 
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> 
> Pre-existing issues:
> - [High] Stage-1 huge block mappings (e.g., 4TB, 64GB) are incorrectly truncated to 1GB due to a 32-bit return type and a hardcoded fallback, leading to under-invalidation of the VNCR software cache.
> --
> 
> --- Patch [2]: [PATCH 2/6] KVM: arm64: Handle negative S1 walk levels in VNCR TLB size evaluation ---
> commit 55a3817e6985fb11462e68c9b396c2d3ee056461
> Author: Marc Zyngier <maz@kernel.org>
> 
> KVM: arm64: Handle negative S1 walk levels in VNCR TLB size evaluation
> 
> This patch fixes a bug where negative Stage-1 mapping levels (used to indicate
> S1_MMU_DISABLED) were mishandled by pgshift_level_to_ttl(), leading to an
> invalidation size of 0. It introduces __ttl_to_size() and ensures ttl_to_size()
> always falls back to SZ_1G when no valid TTL size is found.
> 
> Link: https://lore.kernel.org/r/ameGoxbn2wzBq2kL@v4bel
> 
> > diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
> > index 983ba0adaf4e6..b026d160f253d 100644
> > --- a/arch/arm64/kvm/nested.c
> > +++ b/arch/arm64/kvm/nested.c
> 
> [ ... ]
> 
> > @@ -506,7 +506,7 @@ int kvm_walk_nested_s2(struct kvm_vcpu *vcpu, phys_addr_t gipa,
> >  	return ret;
> >  }
> >  
> > -static unsigned int ttl_to_size(u8 ttl)
> > +static unsigned int __ttl_to_size(u8 ttl)
> 
> [Severity: High]
> This is a pre-existing issue, but does this unsigned int return type cause
> huge block mapping sizes to be incorrectly truncated?
> 
> Since __ttl_to_size() and ttl_to_size() return a 32-bit unsigned int, they
> cannot represent sizes 4GB or larger (like 4TB for 64K granule Level 1, or
> 64GB for 16K granule Level 1).

Which is adequate since we don't support these sizes.

> 
> > @@ -562,10 +562,22 @@ static unsigned int ttl_to_size(u8 ttl)
> >  	return max_size;
> >  }
> >  
> > -static u8 pgshift_level_to_ttl(u16 shift, u8 level)
> > +static unsigned int ttl_to_size(u8 ttl)
> > +{
> > +	return __ttl_to_size(ttl) ?: SZ_1G;
> > +}
> 
> If a nested L1 guest maps its VNCR page in such a huge block using 52-bit
> VAs and later issues a TLBI with a VA far from the VNCR page VA, KVM will
> calculate a severely undersized invalidation window. Because the true size
> overflows unsigned int (or evaluates to 0), the fallback restricts it to 1GB.
> 
> This could leave KVM using a stale IPA, potentially corrupting nested guest
> state by writing into unmapped or reassigned guest physical memory.
> 
> Should these size calculation functions be returning an unsigned long or u64
> instead?

No, we don't support LVA/LVA2 for nested guests.

	M.

-- 
Jazz isn't dead. It just smells funny.

  reply	other threads:[~2026-08-01 13:16 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 [this message]
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
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=87qzkiou3m.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --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