| Message ID | 20241028124547.1371867-4-ayan.kumar.halder@amd.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Enable early bootup of AArch64 MPU systems | expand |
Hi Ayan, > On 28 Oct 2024, at 12:45, Ayan Kumar Halder <ayan.kumar.halder@amd.com> wrote: > > From: Wei Chen <wei.chen@arm.com> > > On Armv8-A, Xen has a fixed virtual start address (link address too) for all > Armv8-A platforms. In an MMU based system, Xen can map its loaded address to > this virtual start address. So, on Armv8-A platforms, the Xen start address does > not need to be configurable. But on Armv8-R platforms, there is no MMU to map > loaded address to a fixed virtual address and different platforms will have very > different address space layout. So Xen cannot use a fixed physical address on > MPU based system and need to have it configurable. > > So, we introduce a Kconfig option for users to set the start address. The start > address needs to be aligned to 4KB. We have a check for this alignment. > > MPU allows us to define regions which are 64 bits aligned. This restriction > comes from the bitfields of PRBAR, PRLAR (the lower 6 bits are 0 extended to > provide the base and limit address of a region). This means that the start > address of Xen needs to be at least 64 bits aligned (as it will correspond to > the start address of memory protection region). > > As for now Xen on MPU tries to use the same memory alignment restrictions as it > has been for MMU. We have added a build assertion to ensure that the page size > is 4KB. Unlike MMU where the starting virtual address is 2MB, Xen on MPU needs > the start address to be 4KB (ie page size) aligned. > > In case if the user forgets to set the start address, then 0xffffffff is used > as default. This is to trigger the error (on alignment check) and thereby prompt > user to set the start address. > > Also updated config.h so that it includes mpu/layout.h when CONFIG_MPU is > defined. > > Signed-off-by: Wei Chen <wei.chen@arm.com> > Signed-off-by: Jiamei.Xie <jiamei.xie@arm.com> > Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com> > — Looks good to me Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Hi Ayan, On 28/10/2024 12:45, Ayan Kumar Halder wrote: > From: Wei Chen <wei.chen@arm.com> > > On Armv8-A, Xen has a fixed virtual start address (link address too) for all > Armv8-A platforms. In an MMU based system, Xen can map its loaded address to > this virtual start address. So, on Armv8-A platforms, the Xen start address does > not need to be configurable. But on Armv8-R platforms, there is no MMU to map > loaded address to a fixed virtual address and different platforms will have very > different address space layout. So Xen cannot use a fixed physical address on > MPU based system and need to have it configurable. > > So, we introduce a Kconfig option for users to set the start address. The start > address needs to be aligned to 4KB. We have a check for this alignment. > > MPU allows us to define regions which are 64 bits aligned. This restriction > comes from the bitfields of PRBAR, PRLAR (the lower 6 bits are 0 extended to > provide the base and limit address of a region). This means that the start > address of Xen needs to be at least 64 bits aligned (as it will correspond to > the start address of memory protection region). > > As for now Xen on MPU tries to use the same memory alignment restrictions as it > has been for MMU. We have added a build assertion to ensure that the page size > is 4KB. Unlike MMU where the starting virtual address is 2MB, Xen on MPU needs > the start address to be 4KB (ie page size) aligned. > > In case if the user forgets to set the start address, then 0xffffffff is used > as default. This is to trigger the error (on alignment check) and thereby prompt > user to set the start address. > > Also updated config.h so that it includes mpu/layout.h when CONFIG_MPU is > defined. > > Signed-off-by: Wei Chen <wei.chen@arm.com> > Signed-off-by: Jiamei.Xie <jiamei.xie@arm.com> > Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com> Reviewed-by: Julien Grall <jgrall@amazon.com> Cheers,
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index ed92eb67cb..15b2e4a227 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -23,6 +23,16 @@ config ARCH_DEFCONFIG default "arch/arm/configs/arm32_defconfig" if ARM_32 default "arch/arm/configs/arm64_defconfig" if ARM_64 +config XEN_START_ADDRESS + hex "Xen start address: keep default to use platform defined address" + default 0xFFFFFFFF + depends on MPU + help + Used to set customized address at which which Xen will be linked on MPU + systems. Must be aligned to 4KB. + 0xFFFFFFFF is used as default value to indicate that user has not + customized this address. + menu "Architecture Features" choice diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile index 72161ff22e..6491c5350b 100644 --- a/xen/arch/arm/arm64/Makefile +++ b/xen/arch/arm/arm64/Makefile @@ -1,5 +1,6 @@ obj-y += lib/ obj-$(CONFIG_MMU) += mmu/ +obj-$(CONFIG_MPU) += mpu/ obj-y += cache.o obj-y += cpufeature.o diff --git a/xen/arch/arm/arm64/mpu/Makefile b/xen/arch/arm/arm64/mpu/Makefile new file mode 100644 index 0000000000..b18cec4836 --- /dev/null +++ b/xen/arch/arm/arm64/mpu/Makefile @@ -0,0 +1 @@ +obj-y += mm.o diff --git a/xen/arch/arm/arm64/mpu/mm.c b/xen/arch/arm/arm64/mpu/mm.c new file mode 100644 index 0000000000..0b8748e575 --- /dev/null +++ b/xen/arch/arm/arm64/mpu/mm.c @@ -0,0 +1,15 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#include <xen/lib.h> +#include <xen/init.h> +#include <xen/sizes.h> + +static void __init __maybe_unused build_assertions(void) +{ + /* + * Unlike MMU, MPU does not use pages for translation. However, we continue + * to use PAGE_SIZE to denote 4KB. This is so that the existing memory + * management based on pages, continue to work for now. + */ + BUILD_BUG_ON(PAGE_SIZE != SZ_4K); +} diff --git a/xen/arch/arm/include/asm/config.h b/xen/arch/arm/include/asm/config.h index a2e22b659d..0a51142efd 100644 --- a/xen/arch/arm/include/asm/config.h +++ b/xen/arch/arm/include/asm/config.h @@ -69,8 +69,10 @@ #include <xen/const.h> #include <xen/page-size.h> -#ifdef CONFIG_MMU +#if defined(CONFIG_MMU) #include <asm/mmu/layout.h> +#elif defined(CONFIG_MPU) +#include <asm/mpu/layout.h> #else # error "Unknown memory management layout" #endif diff --git a/xen/arch/arm/include/asm/mpu/layout.h b/xen/arch/arm/include/asm/mpu/layout.h new file mode 100644 index 0000000000..d6d397f4c2 --- /dev/null +++ b/xen/arch/arm/include/asm/mpu/layout.h @@ -0,0 +1,33 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#ifndef __ARM_MPU_LAYOUT_H__ +#define __ARM_MPU_LAYOUT_H__ + +#define XEN_START_ADDRESS CONFIG_XEN_START_ADDRESS + +/* + * All MPU platforms need to provide a XEN_START_ADDRESS for linker. This + * address indicates where Xen image will be loaded and run from. This + * address must be aligned to a PAGE_SIZE. + */ +#if (XEN_START_ADDRESS % PAGE_SIZE) != 0 +#error "XEN_START_ADDRESS must be aligned to 4KB" +#endif + +/* + * For MPU, XEN's virtual start address is same as the physical address. + * The reason being MPU treats VA == PA. IOW, it cannot map the physical + * address to a different fixed virtual address. So, the virtual start + * address is determined by the physical address at which Xen is loaded. + */ +#define XEN_VIRT_START _AT(paddr_t, XEN_START_ADDRESS) + +#endif /* __ARM_MPU_LAYOUT_H__ */ +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S index 5b9abc9a2d..d1e579e8a8 100644 --- a/xen/arch/arm/xen.lds.S +++ b/xen/arch/arm/xen.lds.S @@ -213,6 +213,13 @@ SECTIONS * match the context. */ ASSERT(_start == XEN_VIRT_START, "_start != XEN_VIRT_START") +#ifdef CONFIG_MPU +/* + * On MPU based platforms, the starting address is to be provided by user. + * One need to check that it is 4KB aligned. + */ +ASSERT(IS_ALIGNED(_start, 4096), "starting address should be aligned to 4KB") +#endif /* * We require that Xen is loaded at a page boundary, so this ensures that any