[PATCH] automation: Add Arm64 MPU build job

[PATCH] automation: Add Arm64 MPU build job

[Michal Orzel]

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(+)

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
-- 
2.25.1

Re: [PATCH] automation: Add Arm64 MPU build job

[Jan Beulich]

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

Re: [PATCH] automation: Add Arm64 MPU build job

[Orzel, Michal]

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

Re: [PATCH] automation: Add Arm64 MPU build job

[Jan Beulich]

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

Re: [PATCH] automation: Add Arm64 MPU build job

[Orzel, Michal]

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

Re: [PATCH] automation: Add Arm64 MPU build job

[Jan Beulich]

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

Re: [PATCH] automation: Add Arm64 MPU build job

[Orzel, Michal]

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

Re: [PATCH] automation: Add Arm64 MPU build job

[Jan Beulich]

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 ...

Re: [PATCH] automation: Add Arm64 MPU build job

[Anthony PERARD]

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,

-- 

Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech