arm64_addrenv: Add support for 4 level MMU translations

[pussuw]

Summary

The original code made the incorrect assumption that the amount of
translation levels is 3, but this is incorrect. The amount of levels is 4
and the amount of levels that are utilized / in use is set dynamically
from the amount of VA bits in use.

Impact

Support for 4 level translations in ARM64 address environments

Testing

QEMU + iMX93 with kernel mode

[nuttxpr]

[Experimental Bot, please feedback here]

Squash The Commits: This PR contains 2 Commits. Please Squash the Multiple Commits into a Single Commit.

While the provided information gives a general idea about the PR, it lacks details to assess if it fully meets the NuttX requirements. Here's a breakdown:

Strengths:

• Summary: Clearly states the problem (incorrect assumption about translation levels) and the solution (dynamically setting levels based on VA bits).
• Impact: Clearly mentions the added support for 4-level translations in ARM64.
• Testing: Specifies the testing environment (QEMU + iMX93 with kernel mode).

Areas for Improvement:

• Summary:
  • Functional part: Needs more specifics. Which part of the codebase handles address translation? (e.g., MMU driver, virtual memory subsystem, etc.)
  • NuttX Issue/PR references: Are there any related issues or PRs this change addresses? If so, include their links.
• Impact:
  • User impact: Will users need to make any configuration changes or be aware of this modification?
  • Build impact: Does this change affect the build process in any way? New dependencies, configuration options, etc.?
  • Hardware impact: Specifies ARM64, but are there specific architectures or boards affected?
  • Documentation impact: Does this change necessitate documentation updates?
  • Security, compatibility: While you might not anticipate impacts in these areas, it's still a good practice to explicitly state "NO" with a brief explanation (e.g., "NO - This is a bug fix within the internal address translation logic and has no direct impact on security or compatibility").
• Testing:
  • Build Host(s): Provide more specifics about your build host environment. OS version, compiler version are crucial for reproducibility.
  • Testing logs: The logs are placeholder comments. You need to include the actual logs from your testing both before and after the change. This is crucial for reviewers to understand the issue and verify the fix.

Recommendation:

Provide the missing details to make the PR review smoother and ensure it aligns with the NuttX requirements.

[acassis]

Hey bot @nuttxpr (and @lupyuen @pussuw ) the suggestion to squash the commits in this case doesn't make sense, having separated commits for different logic changes is better to understand the modifications. Squash only should be used when it is some fix for something missing in the previous commit or some small modification in the previous previous commits