Kernel KVM virtualization development
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Joey Gouly <joey.gouly@arm.com>
Cc: kvmarm@lists.linux.dev, kvm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Steffen Eiden <seiden@linux.ibm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Oliver Upton <oupton@kernel.org>,
	Zenghui Yu <yuzenghui@huawei.com>,
	Hyunwoo Kim <imv4bel@gmail.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH 3/6] KVM: arm64: Consider SCTLR_EL2.M when mapping the L1 VNCR page
Date: Tue, 04 Aug 2026 16:16:02 +0100	[thread overview]
Message-ID: <86ik5pc3wt.wl-maz@kernel.org> (raw)
In-Reply-To: <anHIhHS6INKZLnrZ@e143914.arm.com>

On Tue, 04 Aug 2026 12:09:56 +0100,
Joey Gouly <joey.gouly@arm.com> wrote:
> 
> Another thing I forgot..
> 
> On Sat, Aug 01, 2026 at 01:48:15PM +0100, Marc Zyngier wrote:
> > We record a VNCR TLB even when SCTLR_EL2.M is 0 in order to make
> > our life easier. But this is not something that the architecture
> > anticipate.
> > 
> > As a consequence, a hypervisor is free to set VNCR_EL2 to
> > some PA when SCTLR_EL2.M==0, use it to run a guest which indirectly
> > accesses the VNCR page, then eventually set SCTLR_EL2.M==1 with
> > the same VA. Yes, this is odd, but apparently legal.
> > 
> > A common trick in HW is to invalidate the TLBs on SCTLR_ELx.M being
> > flipped. But doing this is a not a good idea for us (we'd need to
> > trap SCTLR accesses), and wouldn't scale as we nest deeper.
> > 
> > Instead, use the fact that the S1 MMU being off at the point of
> > translation is cached in our TLB, and simply ignore it if it
> > doesn't match the current MMU state.
> > 
> > Fixes: 2a359e072596f ("KVM: arm64: nv: Handle mapping of VNCR_EL2 at EL2")
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > Cc: stable@vger.kernel.org
> > ---
> >  arch/arm64/include/asm/kvm_nested.h | 7 +++++++
> >  arch/arm64/kvm/at.c                 | 2 --
> >  arch/arm64/kvm/nested.c             | 3 +++
> >  3 files changed, 10 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/arm64/include/asm/kvm_nested.h b/arch/arm64/include/asm/kvm_nested.h
> > index 012d711034d17..cc48817a5bf7a 100644
> > --- a/arch/arm64/include/asm/kvm_nested.h
> > +++ b/arch/arm64/include/asm/kvm_nested.h
> > @@ -388,6 +388,8 @@ struct s1_walk_result {
> >  	bool	failed;
> >  };
> >  
> > +#define S1_MMU_DISABLED		(-127)
> > +
> >  static inline void fail_s1_walk(struct s1_walk_result *wr, u8 fst, bool s1ptw)
> >  {
> >  	wr->fst		= fst;
> > @@ -396,6 +398,11 @@ static inline void fail_s1_walk(struct s1_walk_result *wr, u8 fst, bool s1ptw)
> >  	wr->failed	= true;
> >  }
> >  
> > +static inline bool s1_mmu_disabled(struct s1_walk_result *wr)
> > +{
> > +	return wr->level == S1_MMU_DISABLED;
> > +}
> > +
> >  int __kvm_translate_va(struct kvm_vcpu *vcpu, struct s1_walk_info *wi,
> >  		       struct s1_walk_result *wr, u64 va);
> >  int __kvm_find_s1_desc_level(struct kvm_vcpu *vcpu, u64 va, u64 ipa,
> > diff --git a/arch/arm64/kvm/at.c b/arch/arm64/kvm/at.c
> > index 640f2dc00a8ba..0926426b87989 100644
> > --- a/arch/arm64/kvm/at.c
> > +++ b/arch/arm64/kvm/at.c
> > @@ -11,8 +11,6 @@
> >  #include <asm/kvm_mmu.h>
> >  #include <asm/lsui.h>
> >  
> > -#define S1_MMU_DISABLED		(-127)
> > -
> >  static int get_ia_size(struct s1_walk_info *wi)
> >  {
> >  	return 64 - wi->txsz;
> > diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
> > index 035cda256e2a5..d7dba02dc84fe 100644
> > --- a/arch/arm64/kvm/nested.c
> > +++ b/arch/arm64/kvm/nested.c
> > @@ -1578,6 +1578,9 @@ static void kvm_map_l1_vncr(struct kvm_vcpu *vcpu)
> >  	if (!vt->valid)
> >  		return;
> >  
> > +	if (!(vcpu_read_sys_reg(vcpu, SCTLR_EL2) & SCTLR_ELx_M) != s1_mmu_disabled(&vt->wr))
> > +		return;
> 
> Another thing, should we set valid=false? (Haven't really looked into
> what that implies..)

No. The TLB itself is still valid. We just haven't hit it. Which is
why we don't map the page in the fixmap, and wait until we take the
fault. When (and if) it happens, we can invalidate it, rewalk, and
establish the new TLB.

At this stage, this doesn't bring much. But if one day we need to
cache multiple translations, we will want this exact flow.

HTH,

	M.

-- 
Without deviation from the norm, progress is not possible.

  reply	other threads:[~2026-08-04 15:16 UTC|newest]

Thread overview: 26+ 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-04  2:45   ` Yao Yuan
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-04 11:03   ` Joey Gouly
2026-08-04 15:16     ` Marc Zyngier
2026-08-04 11:09   ` Joey Gouly
2026-08-04 15:16     ` Marc Zyngier [this message]
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-04  3:46   ` Yao Yuan
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-04  3:34   ` Yao Yuan
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
2026-08-04  3:09   ` Yao Yuan

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=86ik5pc3wt.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=imv4bel@gmail.com \
    --cc=joey.gouly@arm.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=oupton@kernel.org \
    --cc=seiden@linux.ibm.com \
    --cc=stable@vger.kernel.org \
    --cc=suzuki.poulose@arm.com \
    --cc=yuzenghui@huawei.com \
    /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