| Message ID | 20250403081916.6834-1-michal.orzel@amd.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | automation: Add Arm64 MPU build job | expand |
On 03.04.2025 10:19, Michal Orzel wrote: > Just like for RISCV and PPC, the earlier we enable the CI build the > better. What about Arm32? Jan
On 03/04/2025 10:43, Jan Beulich wrote: > > > On 03.04.2025 10:19, Michal Orzel wrote: >> Just like for RISCV and PPC, the earlier we enable the CI build the >> better. > > What about Arm32? The series to enable compilation of Arm32 with MPU is still under review on the ML. ~Michal
On 03.04.2025 10:44, Orzel, Michal wrote: > On 03/04/2025 10:43, Jan Beulich wrote: >> On 03.04.2025 10:19, Michal Orzel wrote: >>> Just like for RISCV and PPC, the earlier we enable the CI build the >>> better. >> >> What about Arm32? > The series to enable compilation of Arm32 with MPU is still under review on the ML. Oh. Is MPU in Kconfig then missing a dependency on 64BIT? Jan
On 03/04/2025 10:58, Jan Beulich wrote: > > > On 03.04.2025 10:44, Orzel, Michal wrote: >> On 03/04/2025 10:43, Jan Beulich wrote: >>> On 03.04.2025 10:19, Michal Orzel wrote: >>>> Just like for RISCV and PPC, the earlier we enable the CI build the >>>> better. >>> >>> What about Arm32? >> The series to enable compilation of Arm32 with MPU is still under review on the ML. > > Oh. Is MPU in Kconfig then missing a dependency on 64BIT? Well, yes you're right although when I think about it, it's been like that (for both 64 and 32) since the introduction of CONFIG_MPU by commit (in October last year): 0388a5979b21 ("xen/arm: mpu: Introduce choice between MMU and MPU") If you're saying that all the Kconfig combinations + targets like allyes/allno need to build successfully also for new ports (MPU on Arm is kind of like a new port), then I agree (I did not think about it and clearly others too seeing the MPU patch above) although I'd prefer to avoid sending a patch adding dependency just to be removed in 1-2 weeks. But I can do whatever you think needs to be done. ~Michal
On 03.04.2025 11:17, Orzel, Michal wrote: > On 03/04/2025 10:58, Jan Beulich wrote: >> On 03.04.2025 10:44, Orzel, Michal wrote: >>> On 03/04/2025 10:43, Jan Beulich wrote: >>>> On 03.04.2025 10:19, Michal Orzel wrote: >>>>> Just like for RISCV and PPC, the earlier we enable the CI build the >>>>> better. >>>> >>>> What about Arm32? >>> The series to enable compilation of Arm32 with MPU is still under review on the ML. >> >> Oh. Is MPU in Kconfig then missing a dependency on 64BIT? > Well, yes you're right although when I think about it, it's been like that (for > both 64 and 32) since the introduction of CONFIG_MPU by commit (in October last > year): > 0388a5979b21 ("xen/arm: mpu: Introduce choice between MMU and MPU") > > If you're saying that all the Kconfig combinations + targets like allyes/allno > need to build successfully also for new ports (MPU on Arm is kind of like a new > port), then I agree (I did not think about it and clearly others too seeing the > MPU patch above) although I'd prefer to avoid sending a patch adding dependency > just to be removed in 1-2 weeks. But I can do whatever you think needs to be done. I'm far from insisting on a change here; you're a maintainer of that code while I am not. Yet I indeed think Kconfig needs to have the dependencies right, or else randconfig CI jobs may randomly fail. Jan
On 03/04/2025 11:28, Jan Beulich wrote: > > > On 03.04.2025 11:17, Orzel, Michal wrote: >> On 03/04/2025 10:58, Jan Beulich wrote: >>> On 03.04.2025 10:44, Orzel, Michal wrote: >>>> On 03/04/2025 10:43, Jan Beulich wrote: >>>>> On 03.04.2025 10:19, Michal Orzel wrote: >>>>>> Just like for RISCV and PPC, the earlier we enable the CI build the >>>>>> better. >>>>> >>>>> What about Arm32? >>>> The series to enable compilation of Arm32 with MPU is still under review on the ML. >>> >>> Oh. Is MPU in Kconfig then missing a dependency on 64BIT? >> Well, yes you're right although when I think about it, it's been like that (for >> both 64 and 32) since the introduction of CONFIG_MPU by commit (in October last >> year): >> 0388a5979b21 ("xen/arm: mpu: Introduce choice between MMU and MPU") >> >> If you're saying that all the Kconfig combinations + targets like allyes/allno >> need to build successfully also for new ports (MPU on Arm is kind of like a new >> port), then I agree (I did not think about it and clearly others too seeing the >> MPU patch above) although I'd prefer to avoid sending a patch adding dependency >> just to be removed in 1-2 weeks. But I can do whatever you think needs to be done. > > I'm far from insisting on a change here; you're a maintainer of that code while > I am not. Yet I indeed think Kconfig needs to have the dependencies right, or > else randconfig CI jobs may randomly fail. Sure, thanks for showing understanding. A different question (also to other people who knows this stuff). MPU requires to specify Xen start address using CONFIG_XEN_START_ADDRESS that is set to invalid default value to catch user attention. Provided that randconfig can select UNSUPPORTED and MPU, we should somehow set CONFIG_XEN_START_ADDRESS to e.g. 0 to be able to build successfully. Is this where we need to add EXTRA_FIXED_RANDCONFIG to existing arm64 and arm32 randconfig jobs? ~Michal
On 03.04.2025 11:35, Orzel, Michal wrote: > > > On 03/04/2025 11:28, Jan Beulich wrote: >> >> >> On 03.04.2025 11:17, Orzel, Michal wrote: >>> On 03/04/2025 10:58, Jan Beulich wrote: >>>> On 03.04.2025 10:44, Orzel, Michal wrote: >>>>> On 03/04/2025 10:43, Jan Beulich wrote: >>>>>> On 03.04.2025 10:19, Michal Orzel wrote: >>>>>>> Just like for RISCV and PPC, the earlier we enable the CI build the >>>>>>> better. >>>>>> >>>>>> What about Arm32? >>>>> The series to enable compilation of Arm32 with MPU is still under review on the ML. >>>> >>>> Oh. Is MPU in Kconfig then missing a dependency on 64BIT? >>> Well, yes you're right although when I think about it, it's been like that (for >>> both 64 and 32) since the introduction of CONFIG_MPU by commit (in October last >>> year): >>> 0388a5979b21 ("xen/arm: mpu: Introduce choice between MMU and MPU") >>> >>> If you're saying that all the Kconfig combinations + targets like allyes/allno >>> need to build successfully also for new ports (MPU on Arm is kind of like a new >>> port), then I agree (I did not think about it and clearly others too seeing the >>> MPU patch above) although I'd prefer to avoid sending a patch adding dependency >>> just to be removed in 1-2 weeks. But I can do whatever you think needs to be done. >> >> I'm far from insisting on a change here; you're a maintainer of that code while >> I am not. Yet I indeed think Kconfig needs to have the dependencies right, or >> else randconfig CI jobs may randomly fail. > Sure, thanks for showing understanding. > > A different question (also to other people who knows this stuff). > MPU requires to specify Xen start address using CONFIG_XEN_START_ADDRESS that is > set to invalid default value to catch user attention. Provided that randconfig > can select UNSUPPORTED and MPU, we should somehow set CONFIG_XEN_START_ADDRESS > to e.g. 0 to be able to build successfully. Is this where we need to add > EXTRA_FIXED_RANDCONFIG to existing arm64 and arm32 randconfig jobs? In principle some override like this will be needed, I think, yet that undermines the randomness of the build. From what I can tell the sole constraint on XEN_START_ADDRESS is that it needs to be page aligned (for whatever reason; I didn't think there was the concept of "pages" without an MMU [1]). Arbitrary values satisfying this constraint ought to be selectable by random configurations. Which would then - hopefully - also trigger the case where XEN_START_ADDRESS is e.g. so large that Xen can't fit in the remaining address space anymore. Plus perhaps any other constraints presently not enforced. How to deal with all of this, i.e. how to leave as much flexibility as possible to randconfig, I simply don't know. Extending the Cc list in the hope for someone to provide some insight. Jan [1] Perhaps PAGE_SIZE there is purely a software construct, used as allocation granularity. Yet then it's not clear why XEN_START_ADDRESS would need to be PAGE_SIZE-aligned. Maybe that's merely simplifying some code ...
On Thu, Apr 03, 2025 at 12:00:39PM +0200, Jan Beulich wrote: > On 03.04.2025 11:35, Orzel, Michal wrote: > > A different question (also to other people who knows this stuff). > > MPU requires to specify Xen start address using CONFIG_XEN_START_ADDRESS that is > > set to invalid default value to catch user attention. Provided that randconfig > > can select UNSUPPORTED and MPU, we should somehow set CONFIG_XEN_START_ADDRESS > > to e.g. 0 to be able to build successfully. Is this where we need to add > > EXTRA_FIXED_RANDCONFIG to existing arm64 and arm32 randconfig jobs? > > In principle some override like this will be needed, I think, yet that undermines > the randomness of the build. From what I can tell the sole constraint on > XEN_START_ADDRESS is that it needs to be page aligned (for whatever reason; I > didn't think there was the concept of "pages" without an MMU [1]). Arbitrary > values satisfying this constraint ought to be selectable by random configurations. > Which would then - hopefully - also trigger the case where XEN_START_ADDRESS is > e.g. so large that Xen can't fit in the remaining address space anymore. Plus > perhaps any other constraints presently not enforced. > > How to deal with all of this, i.e. how to leave as much flexibility as possible > to randconfig, I simply don't know. Extending the Cc list in the hope for someone > to provide some insight. It doesn't looks like kconfig have support for randomizing hex values. So you'll have to provide a value for XEN_START_ADDRESS that actually respect the contrain written in prose, since the default doesn't. Ah, the prompt of that config value is way to long and contain explanation that ought to be in the help message instead. So I guess the default value is the choose default value option, so probably fine for randconfig. Cheers,
diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml index 2513908b059b..8cb770d6ff27 100644 --- a/automation/gitlab-ci/build.yaml +++ b/automation/gitlab-ci/build.yaml @@ -476,6 +476,16 @@ alpine-3.18-gcc-debug-arm64-earlyprintk: CONFIG_EARLY_UART_CHOICE_PL011=y CONFIG_EARLY_UART_BASE_ADDRESS=0x9000000 +alpine-3.18-gcc-debug-arm64-mpu: + extends: .gcc-arm64-build-debug + variables: + CONTAINER: alpine:3.18-arm64v8 + HYPERVISOR_ONLY: y + EXTRA_XEN_CONFIG: | + CONFIG_XEN_START_ADDRESS=0x0 + CONFIG_MPU=y + CONFIG_UNSUPPORTED=y + # Yocto test jobs yocto-qemuarm64: extends: .yocto-test-arm64
Just like for RISCV and PPC, the earlier we enable the CI build the better. Signed-off-by: Michal Orzel <michal.orzel@amd.com> --- automation/gitlab-ci/build.yaml | 10 ++++++++++ 1 file changed, 10 insertions(+)