On 27/01/2026 10:14, Orzel, Michal wrote:
For MPU system, we could have the following memory translation regime:
- PMSAv8-64 at both EL1/EL0 and EL2
- VMSAv8-64 at EL1/EL0 and PMSAv8-64 at EL2
The default option will be the second, unless the platform could not support,
which could be checked against MSA_frac bit in Memory Model Feature Register 0(
ID_AA64MMFR0_EL1).
What's the reasoning behind it? Why do we prefer VMSA at EL1 rather than PMSA?
AFAICT PMSA is a default and VMSA is optional, so logically PMSA should be
preffered. We should also make it configurable I think, so that a user has a
choice.
Can we introduce this as a device tree parameter since we may want to
run multiple guests with one guest to use PMSA such as Zephyr and Linux
to use VMSA?
- BUG_ON("unimplemented");
+ uint64_t vtcr_el2 = 0, vstcr_el2 = 0;
+ bool p2m_vmsa = true;
+
+ /* PA size */
+ const unsigned int pa_range_info[] = { 32, 36, 40, 42, 44, 48, 52, 0, /*
Invalid */ };
80 chars exceeded.
Do we still need 0 here to denote invalid value?
It is possible for the architecture to be expanded with new features
which increase the potential PA range (requiring additional support).
Additionally for consistency this is how it is defined in MMU. Is there
another reason why we should remove it?
+ vtcr_el2 |= VTCR_VS;
+
+ p2m_vmid_allocator_init();
+
+ WRITE_SYSREG(vtcr_el2, VTCR_EL2);
Where do we set NSA bit?
On ARMv8-R EL0, EL1 and EL2 all run in the secure state so we do not set
that bit in this context.
Regarding the other comments, I plan on reworking/cleaning up the patch
to address them and make the code/intents clearer.
Thanks,
Harry Ramsey
