arm64: Allows thread to independent control the switch of sctlr

[W-M-R]

Note: Please adhere to Contributing Guidelines.

Summary

    The method is the same as the method of saving the current DAIF state of the thread
    It will pave the way for the future implementation of hwasan's memory management
    Allows each thread to independently control the mte switch function

Impact

Update this section, where applicable, on how change affects users,
build process, hardware, documentation, security, compatibility, etc.

Testing

Update this section with details on how did you verify the change,
what Host was used for build (OS, CPU, compiler, ..), what Target was
used for verification (arch, board:config, ..), etc. Providing build
and runtime logs from before and after change is highly appreciated.

[nuttxpr]

[Experimental Bot, please feedback here]

This PR does not fully meet the NuttX requirements. While it provides a summary of what the change does, it lacks crucial information.

Here's a breakdown of what's missing:

Summary:

• Missing "Why": The summary explains the how but not the why. Why is per-thread MTE control necessary? What problem does it solve? Is there a bug being fixed? Is this a performance optimization?
• Missing Scope: What specific files/modules are affected? Saying "the method is the same as..." isn't descriptive enough. Name the specific functions or files modified.
• Missing Issue References: Are there any related NuttX or NuttX-apps issues that prompted this change? If so, link them.

Impact:

• Completely Empty: This section is critical. The maintainer needs to understand the ramifications of merging this change. Address all the points (user impact, build impact, hardware impact, documentation, security, compatibility). Even if the answer is "NO", explicitly state it. For example: "Impact on user: NO"
• Security implications are especially important here given that this relates to MTE (Memory Tagging Extension), a security feature. What are the potential security benefits or drawbacks of this change?

Testing:

• Completely Empty: This section is also crucial. Without evidence of testing, the PR is unlikely to be merged. Provide specific details:
  • Build Host: e.g., "Linux (Ubuntu 22.04), x86_64, GCC 11.2.0"
  • Target: e.g., "qemu-rv64:nsh"
  • Logs: Include actual logs showing the behavior before and after the change. Demonstrate that the change works as intended and doesn't introduce regressions. If the logs are too long, consider providing a link to a gist or pastebin.

In short, the PR needs significant improvements before it can be considered for merging. It needs to be more thorough and provide the necessary information for reviewers to evaluate the change effectively. Follow the template more closely and fill in all the required sections.

[W-M-R]

This approach causes the code size of "nuttx/arch/arm64/src/common/arm64_vector_table.S： arm64_enter_exception“ to be larger than the 128 bytes required by the vector table. Can this problem be solved by changing the macro to a function?

I passed the test by turning off "CONFIG_ARCH_FPU"

[anchao]

Suggested change

	str \xreg0, [sp, #8 * REG_SCTLR_EL1]
	str \xreg0, [sp, #8 * REG_SCTLR_EL1]

[xiaoxiang781216]

This approach causes the code size of "nuttx/arch/arm64/src/common/arm64_vector_table.S： arm64_enter_exception“ to be larger than the 128 bytes required by the vector table. Can this problem be solved by changing the macro to a function? ! I passed the test by turning off "CONFIG_ARCH_FPU"

let's try to reduce the code size first.

[xiaoxiang781216]

This approach causes the code size of "nuttx/arch/arm64/src/common/arm64_vector_table.S： arm64_enter_exception“ to be larger than the 128 bytes required by the vector table. Can this problem be solved by changing the macro to a function? ! I passed the test by turning off "CONFIG_ARCH_FPU"

let's try to reduce the code size first.

@W-M-R some optimization can be done:

1. Skip save and restore x0 since it's always zero
2. Remove the duplication loading tpidrro_el0 at line 92
3. Remove line 93 by using add with immediate value:
   https://developer.arm.com/documentation/ddi0596/2021-03/Base-Instructions/ADDS--immediate---Add--immediate---setting-flags-#:~:text=Add%20(immediate)%2C%20setting%20flags,the%20alias%20CMN%20(immediate).