From: Marc Zyngier <maz@kernel.org>
To: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Oliver Upton <oupton@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] arm64: Clear VTCR_EL2 in __init_el2_stage2()
Date: Fri, 13 Mar 2026 08:07:51 +0000 [thread overview]
Message-ID: <87pl58cfu0.wl-maz@kernel.org> (raw)
In-Reply-To: <edcb9acf-359f-45db-9574-10337c0928fd@arm.com>
On Fri, 13 Mar 2026 07:54:04 +0000,
Anshuman Khandual <anshuman.khandual@arm.com> wrote:
>
> On 13/03/26 12:55 PM, Marc Zyngier wrote:
> > On Fri, 13 Mar 2026 05:38:57 +0000,
> > Anshuman Khandual <anshuman.khandual@arm.com> wrote:
> >>
> >> Clear VTCR_EL2 along with VTTBR_EL2 register in __init_el2_stage2(), which
> >> ensures that MMU stage-2 translation remain disabled. Although clearing out
> >> VTTBR_EL2 probably should have been sufficient but adding VTCR_EL2 improves
> >> overall safety.
> >
> > This serves no purpose whatsoever. Even the write to VTTBR_EL2 is
> > pointless, and writing 0 is no better than writing *any* other value.
> > > The only thing that matters at this stage is HCR_EL2.VM, which
> > actually controls stage-2 translation (contrary to your above
> > assertion). This of course is not captured by this macro.
> >
> > So what are you *really* trying to achieve?
>
> To keep VTTBR_EL2 and VTCR_EL2 cleared (and prepared) if and when
> HCR_EL2_VM gets enabled.
How does that prepare anything? Zero is not even a valid value for
VTCR_EL2!
> But it can be argued that these registers
> need not have to be cleared now and can just be initialised before
> setting up HCR_EL2_VM itself. In which case should we drop
> __init_el2_stage2() entirely ?
I really like how you argue one thing and its opposite in two adjacent
sentences.
"If it ain't broke, don't fix it".
M.
--
Jazz isn't dead. It just smells funny.
next prev parent reply other threads:[~2026-03-13 8:08 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 [this message]
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
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=87pl58cfu0.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.