From: Dave Martin <Dave.Martin@arm.com>
To: Yeoreum Yun <yeoreum.yun@arm.com>
Cc: catalin.marinas@arm.com, will@kernel.org, broonie@kernel.org,
oliver.upton@linux.dev, anshuman.khandual@arm.com,
robh@kernel.org, james.morse@arm.com, mark.rutland@arm.com,
joey.gouly@arm.com, ahmed.genidi@arm.com, kevin.brodsky@arm.com,
scott@os.amperecomputing.com, mbenes@suse.cz,
james.clark@linaro.org, frederic@kernel.org, rafael@kernel.org,
pavel@kernel.org, ryan.roberts@arm.com, suzuki.poulose@arm.com,
maz@kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
kvmarm@lists.linux.dev
Subject: Re: [PATCH v4 2/5] arm64: initialise SCTLR2_ELx register at boot time
Date: Tue, 2 Sep 2025 11:39:53 +0100 [thread overview]
Message-ID: <aLbJeQf9LKXFTxzS@e133380.arm.com> (raw)
In-Reply-To: <aLXmCJOuxCHVXEYx@e129823.arm.com>
Hi,
On Mon, Sep 01, 2025 at 07:29:28PM +0100, Yeoreum Yun wrote:
> Hi Dave,
>
> > On Thu, Aug 21, 2025 at 06:24:05PM +0100, Yeoreum Yun wrote:
> > > The value of the SCTLR2_ELx register is UNKNOWN after reset.
> > > If the firmware initializes these registers properly, no additional
> > > initialization is required.
> > > However, in cases where they are not initialized correctly,
> > > initialize the SCTLR2_ELx registers during CPU/vCPU boot
> > > to prevent unexpected system behavior caused by invalid values.
> > >
> > > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> > > ---
> >
> > [...]
> >
> > > diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
> > > index 23be85d93348..c25c2aed5125 100644
> > > --- a/arch/arm64/include/asm/assembler.h
> > > +++ b/arch/arm64/include/asm/assembler.h
> > > @@ -738,6 +738,21 @@ alternative_endif
[...]
> > > +/* Set SCTLR2_ELx to the @reg value. */
> > > +.macro set_sctlr2_elx, el, reg, tmp
> > > + mrs_s \tmp, SYS_ID_AA64MMFR3_EL1
> > > + ubfx \tmp, \tmp, #ID_AA64MMFR3_EL1_SCTLRX_SHIFT, #4
> > > + cbz \tmp, .Lskip_sctlr2_\@
> > > + .if \el == 2
> > > + msr_s SYS_SCTLR2_EL2, \reg
> > > + .elseif \el == 12
> > > + msr_s SYS_SCTLR2_EL12, \reg
> > > + .else
> > > + msr_s SYS_SCTLR2_EL1, \reg
> > > + .endif
> > > +.Lskip_sctlr2_\@:
> > > +.endm
[...]
> > If might be a good idea to migrate other macros that use an "el"
> > argument to do something similar -- although that probably doesn't
> > belong in this series.
> >
> > The assembler seems to have no ".elseifc" directive, so you'll need
> > separate nested .ifc blocks:
> >
> > .ifc \el,2
> > msr_s SYS_SCTLR2_EL2, \reg
> > .else
> > .ifc \el,12
> > msr_s SYS_SCTLR2_EL12, \reg
> > .else
> > .ifc \el,1
> > msr_s SYS_SCTLR2_EL1, \reg
> > .else
> > .error "Bad EL \"\el\" in set_sctlr2_elx"
> > .endif
> > .endif
> > .endif
> >
> > (Note, I've not tested this approach. If you can think of a better
> > way, please feel free to suggest.)
>
> Thanks for your suggestion. Let me test and check about this idea could
> be applied in other macro too :D
> (But as you mention, I'll apply this for SCTLR2 in other patchset).
Ack, let me know how it goes.
It is probably not worth doing this if the changes become complicated,
though.
[...]
> > > diff --git a/arch/arm64/kernel/hyp-stub.S b/arch/arm64/kernel/hyp-stub.S
> > > index 36e2d26b54f5..ac12f1b4f8e2 100644
> > > --- a/arch/arm64/kernel/hyp-stub.S
> > > +++ b/arch/arm64/kernel/hyp-stub.S
> > > @@ -144,7 +144,17 @@ SYM_CODE_START_LOCAL(__finalise_el2)
> > >
> > > .Lskip_indirection:
> > > .Lskip_tcr2:
> > > + mrs_s x1, SYS_ID_AA64MMFR3_EL1
> > > + ubfx x1, x1, #ID_AA64MMFR3_EL1_SCTLRX_SHIFT, #4
> > > + cbz x1, .Lskip_sctlr2
> > > + mrs_s x1, SYS_SCTLR2_EL12
> > > + msr_s SYS_SCTLR2_EL1, x1
> > >
> > > + // clean SCTLR2_EL1
> > > + mov_q x1, INIT_SCTLR2_EL1
> > > + msr_s SYS_SCTLR2_EL12, x1
> >
> > I'm still not sure why we need to do this. The code doesn't seem to
> > clean up by the EL1 value of any other register -- or have I missed
> > something?
> >
> > We have already switched to EL2, via the HVC call that jumped to
> > __finalise_el2. We won't run at EL1 again unless KVM starts a guest --
> > but in that case, it's KVM's responsibility to set up the EL1 registers
> > before handing control to the guest.
> >
> > In any case, is SCTLR2_EL1 ever set to anything except INIT_SCTLR2_EL1
> > before we get here?
>
> Regardless of VHE and nVHE, between init_kernel_el() and finalise_el2()
> the kernel modifies SCTLR_EL1/SCTLR2_EL1 (since el level in this period
> is EL1).
> and at the end of finalise_el2(), kernel switches to el2 and
> if VHE, it writes the SCTLR_EL1/SCTLR2_EL1 to SCTLR_EL2/SCTLR2_EL2 and
> initialize the SCTLR_EL1/SCTLR2_EL1.
>
> Although there is no code to modify SCTLR2_EL1 between this period,
> as SCTLR1_ELx, I initialize the SCTLR2_EL1 as init value for the future
> usage.
I think that we don't need to ensure that all sysregs are cleanly
initialised; only those that can affect execution in some way need to
be initialised.
Once we are running at EL2 with VHE, we don't switch back to EL1, so
the _EL1 control registers don't affect execution any more.
If we did have to clean up the _EL1 registers, then this code would
need to clean up all the other regs too, but I can't see clean-up for
anything other than SCTLR2_EL1 here. Is there some cleanup code
elsewhere that I have missed?
Cheers
---Dave
next prev parent reply other threads:[~2025-09-02 10:40 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-21 17:24 [PATCH v4 0/5] initialize SCTRL2_ELx Yeoreum Yun
2025-08-21 17:24 ` [PATCH v4 1/5] arm64: make SCTLR2_EL1 accessible Yeoreum Yun
2025-08-21 17:24 ` [PATCH v4 2/5] arm64: initialise SCTLR2_ELx register at boot time Yeoreum Yun
2025-09-01 15:13 ` Dave Martin
2025-09-01 18:29 ` Yeoreum Yun
2025-09-02 10:39 ` Dave Martin [this message]
2025-09-02 11:05 ` Yeoreum Yun
2025-09-03 10:43 ` Dave Martin
2025-09-03 10:59 ` Yeoreum Yun
2025-09-17 14:28 ` Yeoreum Yun
2025-08-21 17:24 ` [PATCH v4 3/5] arm64: save/restore SCTLR2_EL1 when cpu_suspend()/resume() Yeoreum Yun
2025-08-21 17:24 ` [PATCH v4 4/5] arm64: initialise SCTLR2_EL1 at cpu_soft_restart() Yeoreum Yun
2025-09-01 15:13 ` Dave Martin
2025-09-01 18:33 ` Yeoreum Yun
2025-08-21 17:24 ` [PATCH v4 5/5] arm64: make the per-task SCTLR2_EL1 Yeoreum Yun
2025-09-01 10:08 ` [PATCH v4 0/5] initialize SCTRL2_ELx Yeoreum Yun
2025-09-01 15:18 ` Dave Martin
2025-09-01 18:17 ` Yeoreum Yun
2025-09-03 10:52 ` Dave Martin
2025-09-03 12:08 ` Yeoreum Yun
2025-09-08 11:02 ` Dave Martin
2025-09-08 11:22 ` Yeoreum Yun
2025-09-08 12:49 ` Dave Martin
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=aLbJeQf9LKXFTxzS@e133380.arm.com \
--to=dave.martin@arm.com \
--cc=ahmed.genidi@arm.com \
--cc=anshuman.khandual@arm.com \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=frederic@kernel.org \
--cc=james.clark@linaro.org \
--cc=james.morse@arm.com \
--cc=joey.gouly@arm.com \
--cc=kevin.brodsky@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=mbenes@suse.cz \
--cc=oliver.upton@linux.dev \
--cc=pavel@kernel.org \
--cc=rafael@kernel.org \
--cc=robh@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=scott@os.amperecomputing.com \
--cc=suzuki.poulose@arm.com \
--cc=will@kernel.org \
--cc=yeoreum.yun@arm.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 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.