Re: [PATCH v4 6/6] xen/arm: mpu: Implement a dummy enable_secondary_cpu_mm

[Luca Fancellu <Luca.Fancellu@xxxxxxx>]

Hi Jan,

> On 29 Oct 2024, at 08:08, Jan Beulich <jbeulich@xxxxxxxx> wrote:
> 
> On 28.10.2024 18:38, Ayan Kumar Halder wrote:
>> On 28/10/2024 15:01, Jan Beulich wrote:
>>> On 28.10.2024 15:39, Ayan Kumar Halder wrote:
>>>> On 28/10/2024 12:55, Jan Beulich wrote:
>>>>> On 28.10.2024 13:45, Ayan Kumar Halder wrote:
>>>>>> --- a/xen/arch/Kconfig
>>>>>> +++ b/xen/arch/Kconfig
>>>>>> @@ -6,11 +6,13 @@ config PHYS_ADDR_T_32
>>>>>> 
>>>>>>   config NR_CPUS
>>>>>>          int "Maximum number of CPUs"
>>>>>> +        range 1 1 if ARM && MPU
>>>>>>          range 1 16383
>>>>>>          default "256" if X86
>>>>>>          default "8" if ARM && RCAR3
>>>>>>          default "4" if ARM && QEMU
>>>>>>          default "4" if ARM && MPSOC
>>>>>> +        default "1" if ARM && MPU
>>>>>>          default "128" if ARM
>>>>>>          help
>>>>>>            Controls the build-time size of various arrays and bitmaps
>>>>> I'm afraid I can't easily tell whether MPU can be used together with any 
>>>>> of
>>>>> RCAR3, QEMU, or MPSOC. If it can, the new default line would need to move
>>>>> up, as it's the first one that has a match on its condition which is being
>>>>> used.
>>>> MPU cannot be used with any of the existing platforms.
>>> That is - qemu can't emulate such an environment, i.e. even QEMU and MPU
>>> don't go together?
>> 
>> Qemu has support for Aarch32 MPU at EL2 and EL1 (ie R52). As far as I am 
>> aware, there is no support for Aarch64 MPU in Qemu (ie R82).
>> 
>> Even for R52, I could not get the upstream Qemu working (emulating some 
>> Arm reference platform).
>> 
>> I could get the Xilinx fork of Qemu (https://github.com/Xilinx/qemu) 
>> working which emulates AMD's SoC using R52.
>> 
>> However, this should not impact the current patch. There is no Qemu in 
>> xen/arch/arm/platforms/*.
> 
> Aiui that's not relevant. There is a QEMU item in 
> xen/arch/arm/platforms/Kconfig.
> I continue to fail to see why that couldn't be selected together with MPU. 
> Yet if
> it can be, you'd end up with a default of 4, not 1, if it actually _is_ 
> selected.
> Alternatively QEMU (and maybe also RCAR3 and MPSOC) need to be mutually 
> exclusive
> with MPU. Hmm, looks like that's already the case, by patch 2 suppressing the
> "Platform Support" prompt. While that looks fragile to me, I'm sorry for the
> noise then.

Are you suggesting to move "default "1" if ARM && MPU” right after “default 
"256" if X86”?

Cheers,
Luca