[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Luca Fancellu <Luca.Fancellu@xxxxxxx>
  • From: "Orzel, Michal" <michal.orzel@xxxxxxx>
  • Date: Mon, 11 May 2026 13:17:40 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=arm.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0)
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=29pvWVDMjHINi8k+yed9tHwgmlIcnunz/kvSVVpKoYA=; b=TODtB48ttjFCY8uzbxjHqlKhysHHdKIl69/acUeIQNMANnuOaEeFXrW2jUsKaK3T7Y01CkSglBQETdQqbVyp4pG+OAUN75FETAl8IeUZHZ0NkGibKfYa0CVAYyM80ASWdY09lknd7+A42NPfBDnhLvGNvPt+TEia+I+aGRV9/aiJHEsUL88nHn/f3+Fi9XhFv1P+4gDCKuftPf/fj8czf9zYOCKPRmn7PP6XT4IymJ2xDE5YJ4OVV25OsWTM+InDydtWUpDHul+EGXPdgUqc3YeU/pPCmUvkuTjVzq9LxBRu3RY39IF+fBKaxPnxV1jR2y9xfxMB8/pnbsgBNArRYQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=EQIioPTVrIdw9CROqzdvXUaUroyEm/q+Fzv6PkMMeQLhhJsndLVcHUo5EBnqr8EcIDNfRLVESHMuIm9uTUn8GmgzAEQzhBZguUWAZM005Nnd7IwjhhUtU9x7N1w6UbsNTVg6lYbBJHD7oM/iA+ZdogkjALKCd4WJ088m9SjnCVYUE5jhsX016aZN2Gsg0ZczsgqpPoIb2pu9j5dPpSpWIoEtH5k0/OUYUnkOZTmtL/IndPpXKuHM0DH8zTTc1DC26gQGkuks/OguebxxZeklqmd7WL/j5zpn/wTeQpctI6YR/lKGkohqoNF1YDUR9B9Nj57zWDCIsX+nMykqT0t92A==
  • Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Harry Ramsey <Harry.Ramsey@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <Bertrand.Marquis@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Delivery-date: Mon, 11 May 2026 11:18:11 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>


On 11-May-26 13:07, Luca Fancellu wrote:
> 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)
I think the confusion is that you are mixing the meaning of none (i.e. I don't
want it) with not set. In case of TEE and SCI, none means you I don't want TEE
or SCI, please disable them. Now, how would this look like for MPU. I don't want
PMSA or VMSA? This does not make any sense because it's something impossible.

~Michal




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.