Hi,

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

[...]

quoted

quoted

quoted

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.

quoted

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?

quoted

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

quoted

quoted

quoted

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