[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 3/7] arm/mpu: Introduce utility functions for the pr_t type
- To: "Orzel, Michal" <michal.orzel@xxxxxxx>
- From: Luca Fancellu <Luca.Fancellu@xxxxxxx>
- Date: Wed, 16 Apr 2025 12:57:35 +0000
- Accept-language: en-GB, en-US
- Arc-authentication-results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=amd.com smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com])
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
- Arc-message-signature: i=2; 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=Zlic03bdKAfZiXVrtZdvQfjP9TL89lldZN01Byh2sZM=; b=mWHyG/aUTm977Kv1IUEbqumhaV3Hod613aIzuLLnahW0wKVYWzauR9TrudXFScks6CQGOehSH5giL11lC6Q9p6X7BuKYOaEecWIpIt+oVuViRWBQgtYTOtU9ikU/4hPvVpmgz9t0cygaVEs8c5HY5FQMv86qj7DEbsaymfrbqwfm5vGTwNiKpftkYf4bER/DvcMXEgCnL50G2xw9E0hANSKAIhuC7tFvRMolEob7QONRn3141nK9AtG39L/3F14V6qJMUGT5hDg697bZOX+boufXiYufQYJCP3MLn6ZwAZMgJ34fb1QA/q2MfZkxRscjBWlaUnOPdGygrGlVn9WVaA==
- 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=Zlic03bdKAfZiXVrtZdvQfjP9TL89lldZN01Byh2sZM=; b=hDcXKlmFt9glRKz0LQ3uW8iYE1gymfa7CTabf5+H+9S9s95KAEBOvdpZ1R1UMjFCPFEQiYA5SEOYOyarqsT7tPEXWa4B94gP4pgbV7QquTSNpmPqSAo7yuvAUxchc+Znk5xSH3svFN59fezNWaagc2aer6/UIDu2RneTH8Qs2kWlJ+aDh7VCu9V9hHrTjYuUrPO2RNeXDFMz4q8nM3g1XZLFDaLn0/YS729UJ7z9IhT5e8YMyCLxTjQgmN5C+qRCMS5qBzY9sgoVQ9YzXgpuFB+NE4mrKR/yas8hPVPjmu84DvFdQq+frxYZmFKyBsnHi34uFkPp2hWva2LyzaPVRg==
- Arc-seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=dEM4OWeWUQaDERtC6S1qdpNPkYNPNKga2JjFJ2ePlDA8KDLwz04NzT5XRvMqK9lAdhslR2PSOKr8eWdK7Xjw3pyeuIgf7XwvEoE6Vjh6kSrua0kPM5I2xez0dUS4/fqKCRHunCFYHDfrbxZ/0zETfuElv+EdqqkCNUHWY5h9E8gIkgvA6eUI1KUDRtmohTL/T5O5ST8aC3nlTVL88S77bOYCE5/0LkykjNFV6Y6DAlrB5GSg8J7B3AFysMHO1yp81sQZ5iMoYtrW8ODRy+nlUuCg+I0EQwAPcXr04OTwHFLwt48jZQ8s+MYNS5jdzsX3U0/nePJvv11TOwnqxcxUvQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=D1zt+omKOUpvJtSQmdrXif/ETND62s4GgZRXG2v3uUS05E98R1GWl3rSRu1X21av2I+MioO3Uj7qQlAeiwvdVR699nK1oH9FdeO/uA76pZwox+cnbOdY3KNzl6G8lqhcro2zSPD7wdIlVirxA5IOY2BF3xaYurFRzaTyxp4Ah+w11sIDL2W+7DST4+xm0tsBLv6j7dyT/FLrQOUbbgMbqU0WC9IGmTbUsM2WeIAMOsb3pFoZeN1diwl6Zidexxv84gNlVkDlqUhcyRdvvOp4TDr4A6LsKBCN65VxU3u4fmKWiKetLsNqtdds4qkb5uGszQTk+QC5Ox0ky3BzRXhzew==
- Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
- Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <Bertrand.Marquis@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
- Delivery-date: Wed, 16 Apr 2025 12:58:15 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Nodisclaimer: true
- Thread-index: AQHbqvIP34UccZOkWUuu+Y+Ap2U3MrOmJOcAgAAb/QCAAAMjAIAABC8A
- Thread-topic: [PATCH v3 3/7] arm/mpu: Introduce utility functions for the pr_t type
Hi Michal,
>>
>>>
>>>> +}
>>>> +
>>>> +/* Set limit address of MPU protection region(pr_t). */
>>>> +static inline void pr_set_limit(pr_t *pr, paddr_t limit)
>>>> +{
>>>> + pr->prlar.reg.limit = ((limit - 1) >> MPU_REGION_SHIFT);
>>> Why -1? AFAIR these registers take inclusive addresses, so is it because you
>>> want caller to pass limit as exclusive and you convert it to inclusive? I
>>> think
>>> it's quite error prone.
>>
>> Yes it’s meant to be used with exclusive range, shall we document it or use
>> Inclusive range instead?
> What's the expected behavior of callers? Are we going to set up protection
> region based on regular start+size pair (like with MMU) or start+end? If the
> latter for some reason (with size there are less issues), then end usually is
> inclusive and you would not need conversion.
I think we have a mix because for example destroy_xen_mappings and
modify_xen_mappings
are start and end, map_pages_to_xen instead is kind of start+size?
I moved the -1 inside pr_set_limit because it was open-coded in all the places,
for example when
referencing linker symbols or output of mfn_to_maddr(mfn_add(smfn, nr_mfn)),
for this reason I
thought: let’s call this one with exclusive ranges and modify internally for
inclusive.
|
