Re: [PATCH v4 0/5] initialize SCTRL2_ELx

[Dave Martin <Dave.Martin@arm.com>]

Hi,

On Wed, Sep 03, 2025 at 01:08:44PM +0100, Yeoreum Yun wrote:

[...]

> > > > Have you tested all the code paths, or are there some things that have
> > > > not been tested?
> > >
> > > I've tested for pKVM, nested and nhve and crash path
> > > (I do my best what can I do for modified path).
> >
> > Was that just confirming that the kernel boots / does not crash?
> 
> Not only that, since the my last mistake, I've check it with debugger
> too -- set the SCTLR2_ELx as I expected.
> 
> >
> > What about CPU suspend/resume and hotplug?
> 
> Of course It's done both enter/exit idle and hotplug with related kselftest test.

Were you able to step through these paths, too?

> > My concern is that most of the defined SCTLR2_ELx bits won't affect
> > kernel execution unless the corresponding hardware features are
> > actively being used -- so while we know that the patches don't break
> > the kernel, this may not prove that SCTLR2_ELx is really being
> > initialised / saved / restored / reset correctly.
> 
> That's why I've confirmed with debugger whether the SCTLR2_ELx value
> sets as I expected... personally I've done as much as I can for
> test related for SCTLR2_ELx.

OK

> > > > Since this code is not useful by itself, it may make sense to delay
> > > > merging it until we have patches for a feature that depends on SCTLR2.
> > >
> > > Whatever I pass this detiermination for maintainer.
> >
> > Sure, that's just my opinion.
> >
> > Either way, this doesn't stop anyone from building support for specific
> > features on top of this series before it gets merged.


Looking again through this series, I realised that the requirements for
this feature are not documented in booting.rst.

Does the following patch look good to you?  If so, feel free to append
it to the series (with your Reviewed-by, if you're happy with the
changes).

It's probably worth double-checking the bit numbers etc.  I wrote this
some weeks ago and then forgot about it.

--8<--

From 0f0adc70ef6c00a3f198c1f0e105b6e47f8cab3b Mon Sep 17 00:00:00 2001
From: Dave Martin <Dave.Martin@arm.com>
Date: Mon, 8 Sep 2025 11:36:21 +0100
Subject: [PATCH] docs: arm64: Document booting requirements for FEAT_SCTLR2

Support for FEAT_SCTLR2 imposes some requirments on the configuration
of traps at exception levels above the level at which the kernel is
booted.

Document them.

For now, don't document requirements on the initial state of SCTLR2_ELx
at the kernel boot exception level.  The general wording under "System
registers" appiles.  (SCTLR_ELx is similarly undocumented.)

Signed-off-by: Dave Martin <Dave.Martin@arm.com>
---

Based on v6.17-rc1

 Documentation/arch/arm64/booting.rst | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/arch/arm64/booting.rst b/Documentation/arch/arm64/booting.rst
index 2f666a7c303c..e8fe1b2023a9 100644
--- a/Documentation/arch/arm64/booting.rst
+++ b/Documentation/arch/arm64/booting.rst
@@ -545,6 +545,16 @@ Before jumping into the kernel, the following conditions must be met:
 
    - MDCR_EL3.TPM (bit 6) must be initialized to 0b0
 
+  For CPUs with the SCTLR2_ELx registers (FEAT_SCTLR2):
+
+  - If EL3 is present:
+
+    - SCR_EL3.SCTLR2En (bit 44) must be initialised to 0b1.
+
+  - If the kernel is entered at EL1 and EL2 is present:
+
+    - HCRX_EL2.SCTLR2En (bit 15) must be initialised to 0b1.
+
 The requirements described above for CPU mode, caches, MMUs, architected
 timers, coherency and system registers apply to all CPUs.  All CPUs must
 enter the kernel in the same exception level.  Where the values documented
-- 
2.34.1