Re: [PATCH v5 2/3] arm/mpu: Introduce `v8r_el1_msa` device tree property for domains

[Luca Fancellu <Luca.Fancellu@xxxxxxx>]

Hi Michal,

>> 
>>>>>> +
>>>>>> +static inline bool v8r_el1_msa_domain_sanitise_config(
>>>>>> +    const struct xen_domctl_createdomain *config)
>>>>> Why can't this function be common? I can see 3 definitions (Arm64 MPU, 
>>>>> Arm32
>>>>> MPU, MMU) but they do not have anything that would prevent from 
>>>>> generalizing
>>>>> them in a single function.
>>>> 
>>>> I can do a common one I think, just to be aligned, should the common one 
>>>> behaves as the current implementation?
>>>> 
>>>> Arm64/32 MMU: Only v8r_el1_msa == XEN_DOMCTL_CONFIG_ARM_V8R_EL1_MSA_NONE 
>>>> allowed
>>>> Arm64: Only v8r_el1_msa == 
>>>> XEN_DOMCTL_CONFIG_ARM_V8R_EL1_MSA_{NONE,PMSA,VMSA}  allowed
>>>> Arm32: Only v8r_el1_msa == XEN_DOMCTL_CONFIG_ARM_V8R_EL1_MSA_{NONE,PMSA}  
>>>> allowed
>>> What's the reason for allowing NONE for MPU here? None denotes property not
>>> specified but at this point it should be set to a default.
>> 
>> We treat NONE as PMSA on Armv8-R, so either NONE and PMSA are valid and lead 
>> to PMSA at EL1
> NONE denotes property not set i.e. set a default. IMO at the place where we 
> set
> a default, NONE should be switched to PMSA. This is a cleaner solution than
> giving two options the same meaning. Sanitization could then verify that 
> indeed
> the default setting took place.

Ok so this is a bit different from how all other *_NONE are handled currently 
(TEE and SCI).

So on MPU Arm32/64 now we will stop the domain creation if NONE is passed, is 
that the behaviour
you are expecting for DOMCTL v8r_el1_msa? (Ideally we should not get this 
because we will switch
during DT parse)

Cheers,
Luca