This series introduces initial support for the SCTLR2_ELx registers in Linux.
The feature is optional starting from ARMv8.8/ARMv9.3,
and becomes mandatory from ARMv8.9/ARMv9.4.

Currently, Linux has no strict need to modify SCTLR2_ELx--
at least assuming that firmware initializes
these registers to reasonable defaults.

However, several upcoming architectural features will require configuring
control bits in these registers.
Notable examples include FEAT_PAuth_LR and FEAT_CPA2.

Patch History
==============
from v3 to v4:
  - integrate set_sctlr2_elx() and __set_sctlr2_elx() to set_sctlr2_elx()
    without isb()
  - fix the wrong register setting in set_sctlr2_elx().
  - add initialise SCTLR2_EL2 at HVC_SOFT_RESTART.
  - https://lore.kernel.org/all/20250813120118.3953541-1-yeoreum.yun@arm.com/

from v2 to v3:
  - rewrite commit messages.
  - fix missing SCTLR2_EL2 synchonization at boot.
  - merging the __kvm_host_psci_cpu_entry() changes into patch #1
  - https://lore.kernel.org/all/20250811163340.1561893-1-yeoreum.yun@arm.com/

from v1 to v2:
  - rebase to v6.17-rc1
  - https://lore.kernel.org/all/20250804121724.3681531-1-yeoreum.yun@arm.com/

Yeoreum Yun (5):
  arm64: make SCTLR2_EL1 accessible
  arm64: initialise SCTLR2_ELx register at boot time
  arm64: save/restore SCTLR2_EL1 when cpu_suspend()/resume()
  arm64: initialise SCTLR2_EL1 at cpu_soft_restart()
  arm64: make the per-task SCTLR2_EL1

 arch/arm64/include/asm/assembler.h   | 15 +++++++++++++++
 arch/arm64/include/asm/el2_setup.h   | 17 +++++++++++++++--
 arch/arm64/include/asm/processor.h   |  3 +++
 arch/arm64/include/asm/suspend.h     |  2 +-
 arch/arm64/include/asm/sysreg.h      |  5 +++++
 arch/arm64/kernel/cpu-reset.S        |  4 ++++
 arch/arm64/kernel/head.S             |  5 +++++
 arch/arm64/kernel/hyp-stub.S         | 10 ++++++++++
 arch/arm64/kernel/process.c          |  9 +++++++++
 arch/arm64/kvm/hyp/nvhe/hyp-init.S   |  3 +++
 arch/arm64/kvm/hyp/nvhe/psci-relay.c |  3 +++
 arch/arm64/mm/proc.S                 | 24 ++++++++++++++++--------
 12 files changed, 89 insertions(+), 11 deletions(-)


base-commit: 8f5ae30d69d7543eee0d70083daf4de8fe15d585
--
LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}

Gentle ping in case of forgotten.

On Thu, Aug 21, 2025 at 06:24:03PM +0100, Yeoreum Yun wrote:
> This series introduces initial support for the SCTLR2_ELx registers in Linux.
> The feature is optional starting from ARMv8.8/ARMv9.3,
> and becomes mandatory from ARMv8.9/ARMv9.4.
>
> Currently, Linux has no strict need to modify SCTLR2_ELx--
> at least assuming that firmware initializes
> these registers to reasonable defaults.
>
> However, several upcoming architectural features will require configuring
> control bits in these registers.
> Notable examples include FEAT_PAuth_LR and FEAT_CPA2.
>
> Patch History
> ==============
> from v3 to v4:
>   - integrate set_sctlr2_elx() and __set_sctlr2_elx() to set_sctlr2_elx()
>     without isb()
>   - fix the wrong register setting in set_sctlr2_elx().
>   - add initialise SCTLR2_EL2 at HVC_SOFT_RESTART.
>   - https://lore.kernel.org/all/20250813120118.3953541-1-yeoreum.yun@arm.com/
>
> from v2 to v3:
>   - rewrite commit messages.
>   - fix missing SCTLR2_EL2 synchonization at boot.
>   - merging the __kvm_host_psci_cpu_entry() changes into patch #1
>   - https://lore.kernel.org/all/20250811163340.1561893-1-yeoreum.yun@arm.com/
>
> from v1 to v2:
>   - rebase to v6.17-rc1
>   - https://lore.kernel.org/all/20250804121724.3681531-1-yeoreum.yun@arm.com/
>
> Yeoreum Yun (5):
>   arm64: make SCTLR2_EL1 accessible
>   arm64: initialise SCTLR2_ELx register at boot time
>   arm64: save/restore SCTLR2_EL1 when cpu_suspend()/resume()
>   arm64: initialise SCTLR2_EL1 at cpu_soft_restart()
>   arm64: make the per-task SCTLR2_EL1
>
>  arch/arm64/include/asm/assembler.h   | 15 +++++++++++++++
>  arch/arm64/include/asm/el2_setup.h   | 17 +++++++++++++++--
>  arch/arm64/include/asm/processor.h   |  3 +++
>  arch/arm64/include/asm/suspend.h     |  2 +-
>  arch/arm64/include/asm/sysreg.h      |  5 +++++
>  arch/arm64/kernel/cpu-reset.S        |  4 ++++
>  arch/arm64/kernel/head.S             |  5 +++++
>  arch/arm64/kernel/hyp-stub.S         | 10 ++++++++++
>  arch/arm64/kernel/process.c          |  9 +++++++++
>  arch/arm64/kvm/hyp/nvhe/hyp-init.S   |  3 +++
>  arch/arm64/kvm/hyp/nvhe/psci-relay.c |  3 +++
>  arch/arm64/mm/proc.S                 | 24 ++++++++++++++++--------
>  12 files changed, 89 insertions(+), 11 deletions(-)
>
>
> base-commit: 8f5ae30d69d7543eee0d70083daf4de8fe15d585
> --
> LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}
>

--
Sincerely,
Yeoreum Yun

Hi,

On Thu, Aug 21, 2025 at 06:24:03PM +0100, Yeoreum Yun wrote:
> This series introduces initial support for the SCTLR2_ELx registers in Linux.
> The feature is optional starting from ARMv8.8/ARMv9.3,
> and becomes mandatory from ARMv8.9/ARMv9.4.
> 
> Currently, Linux has no strict need to modify SCTLR2_ELx--
> at least assuming that firmware initializes
> these registers to reasonable defaults.
> 
> However, several upcoming architectural features will require configuring
> control bits in these registers.
> Notable examples include FEAT_PAuth_LR and FEAT_CPA2.

This looks OK to me now, except for one or two minor issues (see
replies to the patches).

I think we will need a way of testing all the code paths before this
should be merged, though.

Have you tested all the code paths, or are there some things that have
not been tested?


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.

Cheers
---Dave

Hi Dave,

> On Thu, Aug 21, 2025 at 06:24:03PM +0100, Yeoreum Yun wrote:
> > This series introduces initial support for the SCTLR2_ELx registers in Linux.
> > The feature is optional starting from ARMv8.8/ARMv9.3,
> > and becomes mandatory from ARMv8.9/ARMv9.4.
> >
> > Currently, Linux has no strict need to modify SCTLR2_ELx--
> > at least assuming that firmware initializes
> > these registers to reasonable defaults.
> >
> > However, several upcoming architectural features will require configuring
> > control bits in these registers.
> > Notable examples include FEAT_PAuth_LR and FEAT_CPA2.
>
> This looks OK to me now, except for one or two minor issues (see
> replies to the patches).
>
> I think we will need a way of testing all the code paths before this
> should be merged, though.
>
> 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).

>
>
> 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.

>
> Cheers
> ---Dave

--
Sincerely,
Yeoreum Yun

Hi,

On Mon, Sep 01, 2025 at 07:17:56PM +0100, Yeoreum Yun wrote:
> Hi Dave,
> 
> > On Thu, Aug 21, 2025 at 06:24:03PM +0100, Yeoreum Yun wrote:
> > > This series introduces initial support for the SCTLR2_ELx registers in Linux.
> > > The feature is optional starting from ARMv8.8/ARMv9.3,
> > > and becomes mandatory from ARMv8.9/ARMv9.4.
> > >
> > > Currently, Linux has no strict need to modify SCTLR2_ELx--
> > > at least assuming that firmware initializes
> > > these registers to reasonable defaults.
> > >
> > > However, several upcoming architectural features will require configuring
> > > control bits in these registers.
> > > Notable examples include FEAT_PAuth_LR and FEAT_CPA2.
> >
> > This looks OK to me now, except for one or two minor issues (see
> > replies to the patches).
> >
> > I think we will need a way of testing all the code paths before this
> > should be merged, though.
> >
> > 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?

What about CPU suspend/resume and hotplug?

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.

> > 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.

Cheers
---Dave

Hi Dave,

[...]
> > > > This series introduces initial support for the SCTLR2_ELx registers in Linux.
> > > > The feature is optional starting from ARMv8.8/ARMv9.3,
> > > > and becomes mandatory from ARMv8.9/ARMv9.4.
> > > >
> > > > Currently, Linux has no strict need to modify SCTLR2_ELx--
> > > > at least assuming that firmware initializes
> > > > these registers to reasonable defaults.
> > > >
> > > > However, several upcoming architectural features will require configuring
> > > > control bits in these registers.
> > > > Notable examples include FEAT_PAuth_LR and FEAT_CPA2.
> > >
> > > This looks OK to me now, except for one or two minor issues (see
> > > replies to the patches).
> > >
> > > I think we will need a way of testing all the code paths before this
> > > should be merged, though.
> > >
> > > 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.

>
> 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.
>
> > > 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.

Okay.

Thanks!

--
Sincerely,
Yeoreum Yun

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

Hi,

> [...]
>
> > > > > 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?

Yes. with debugger and some trick with:
  asm volatile("b ." ::: "memory");

checking a cpu idle (by not loading any work) without any load and
checking cpu-hotplug with kselftest's cpu-on-off-test.sh.

So, by hitting the "b .", I've stepped in and confirm the SCTLR2_ELx set
as it intended.

>
> > > 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.

I've missed this and Thanks for your efforts.
The bits you documented have no problem as far as I checked.
Let me include this too in next series.

(I'm still checking your suggestion to use .ifc. as soon as finish
this. I'll repost it according to your suggestion)


Thanks!

[...]

--
Sincerely,
Yeoreum Yun

Hi,

On Mon, Sep 08, 2025 at 12:22:34PM +0100, Yeoreum Yun wrote:
> Hi,
> 
> > [...]
> >
> > > > > > 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?
> 
> Yes. with debugger and some trick with:
>   asm volatile("b ." ::: "memory");
> 
> checking a cpu idle (by not loading any work) without any load and
> checking cpu-hotplug with kselftest's cpu-on-off-test.sh.
> 
> So, by hitting the "b .", I've stepped in and confirm the SCTLR2_ELx set
> as it intended.

OK, that sounds reasonable comprehensive.

[...]

> > 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.
> 
> I've missed this and Thanks for your efforts.
> The bits you documented have no problem as far as I checked.
> Let me include this too in next series.
> 
> (I'm still checking your suggestion to use .ifc. as soon as finish
> this. I'll repost it according to your suggestion)
> 
> 
> Thanks!

OK, I'll take another look when you repost.

Cheers
---Dave