Hi,
On 18/01/2023 10:22, Wei Chen wrote:
Although it is unlikely that vendors using the Armv8-R IP will do so, it
is indeed an option. In the ID register, there are also related bits in
ID_AA64MMFR0_EL1 (MSA_frac) to indicate this.
---
xen/arch/arm/Kconfig | 8 ++++++++
xen/arch/arm/platforms/Kconfig | 16 +++++++++++++---
2 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index ace7178c9a..c6b6b612d1 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -145,6 +145,14 @@ config TEE
This option enables generic TEE mediators support. It allows
guests
to access real TEE via one of TEE mediators implemented in
XEN.
+config XEN_START_ADDRESS
+ hex "Xen start address: keep default to use platform defined
address"
+ default 0
+ depends on ARM_V8R
It is still pretty unclear to me what would be the difference between
HAS_MPU and ARM_V8R.
If we don't want to support non-MPU supported Armv8-R, I think they are
the
same. IMO, non-MPU supported Armv8-R is meaningless to Xen.
OOI, why do you think this is meaningless?
If there is Armv8-R board without EL2 MPU, how can we protect Xen?
So what you call EL2 MPU is an MPU that is following the Arm
specification. In theory, you could have a proprietary mechanism for that.
So the question is whether a system not following the Arm specification
is allowed.
Cheers,
--
Julien Grall
