All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	linux-arm-kernel@lists.infradead.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Oliver Upton <oupton@kernel.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] arm64: Clear VTCR_EL2 in __init_el2_stage2()
Date: Tue, 17 Mar 2026 09:15:56 +0000	[thread overview]
Message-ID: <86pl526ckz.wl-maz@kernel.org> (raw)
In-Reply-To: <3dc3f358-7f4a-4950-b8f7-f3b3c284166b@arm.com>

On Tue, 17 Mar 2026 02:46:44 +0000,
Anshuman Khandual <anshuman.khandual@arm.com> wrote:
> 
> On 13/03/26 3:29 PM, Mark Rutland wrote:
> > On Fri, Mar 13, 2026 at 05:38:57AM +0000, Anshuman Khandual wrote:
> >> Clear VTCR_EL2 along with VTTBR_EL2 register in __init_el2_stage2(), which
> >> ensures that MMU stage-2 translation remain disabled.
> > 
> > As Marc noted, that's not true -- whether stage 2 is enabled is governed
> > entirely by HCR_EL2.VM.
> > > The only reason to initialize VTCR_EL2 here would be if some field in
> > VTCR_EL2 applies when stage 2 is *disabled*.
> 
> Understood. Something similar to VTTBR_EL2.VMID field which
> gets into tagged TLB entries for EL0/EL1 translation regime
> even when stage-2 is not enabled via HCR_EL2_VM.
> 
> But wondering if VTTBR_EL2.VMID gets cleaned up should not
> it also be followed by a "tlbi vmalls12e1 --> dsb --> isb"
> sequence to clear existing stale TLB entries ?

Why? We already have a TLBI VMALLE1 whenever a CPU boots. That's all
we need, and not some random invalidation that serves no purpose as
long as S2 is *off*. When we are about to turn S2 on, we have all the
required invalidation already.

> 
> > 
> >> Although clearing out VTTBR_EL2 probably should have been sufficient
> >> but adding VTCR_EL2 improves overall safety.
> > 
> > It's unhelpful to send patches like this with unclear or non-existent
> > rationale, and vague statements about what the patch might do. Was there
> 
> The commit message could have been more detailed and explicit
> about its rationale. Although the intent here was to ensure
> improved safety during S2 MMU context initialization.
> 
> > some specific reason to send this? e.g.
> > 
> > * Did you have any specific reason to believe that setting some field in
> >   VTCR_EL2 was necessary? e.g. is there some misleading documentation,
> >   or comment elsewhere in the kernel?
> > 
> > * Are you trying to fix some problem you've encountered, but haven't
> >   managed to debug?
> > 
> > * Was this purely from inspection?
> 
> This was from code inspection while navigating S2 MMU context
> initialization and management.

I think you should start by improving your understanding of how S2
works *before* sending random patches.

Thanks,

	M.

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


  reply	other threads:[~2026-03-17  9:16 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-13  5:38 [PATCH] arm64: Clear VTCR_EL2 in __init_el2_stage2() Anshuman Khandual
2026-03-13  7:25 ` Marc Zyngier
2026-03-13  7:54   ` Anshuman Khandual
2026-03-13  8:07     ` Marc Zyngier
2026-03-13  8:11     ` Marc Zyngier
2026-03-13  8:39       ` Anshuman Khandual
2026-03-13  9:06         ` Marc Zyngier
2026-03-13  9:59 ` Mark Rutland
2026-03-17  2:46   ` Anshuman Khandual
2026-03-17  9:15     ` Marc Zyngier [this message]
2026-03-17 10:16     ` Mark Rutland

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=86pl526ckz.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=anshuman.khandual@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=oupton@kernel.org \
    --cc=will@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.