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