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
