[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 13:12:45 +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=5SPq0io0Fd7Ioym5XIdVQiUiX7DqiYIwbUOd6mrI6Yc=; b=OT7YZjR3nhgh8f+dC+T7lYLh6UfbV9SEWzEs1wbubuuBi9yG9Rx20fQqoLRAy1Eh7umRYdFqpnOxk2NyY69q84DMw9KmI0K/fre2xou8D8WZeoHeEN25gU+fBq/8AYY01IjV+MGW1JnHE8AO9jj/9y2bEX7dvGj937PIvo6SkK2NQtuMz/AMhOz6xCugEcE8AoCLCkCsWemBvKlnqfaoV00znztuRjF3vCFKbggJQmxFwHRpX5dnZnfcih0J4Tr6sURWZssUJN74nRgn/7gr/+I+oLLddDynwOZMqdN1m1xvx3L5AL6FQxIS0X+x8rrZCpGSIMXxKw/9xN6bPXikfA==
- 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=5SPq0io0Fd7Ioym5XIdVQiUiX7DqiYIwbUOd6mrI6Yc=; b=pRAyaUCqEFoBT88+r4d8NlWfVTvwoFJndC4w3xiCh0059oZoZEDiTDBXtunYAkSno+MCKBERUPnb20KIVCZYqiyFp4W13PxGc1iUTXqSlbbv0W9ySaqzk/ZF8DjzGGTca++a/vecNK0+O9RlsaHBInLqu3ykFP+0gUvU5OxujU09FQXlKRd22AUoA4eJjxyRV38EsnJS8Yn3eWCfZIketraPp6HcO05X6YLxYZP9L6L50J2J/rtLK8pCI+nWd1dYhSK6vXGNSTwuG1j9Rj85WSRGORtMqzObe9tBBX2yQQKwbBVoempohsX8VMwBYPwj0keYMllD+72m7wDVMtHSKQ==
- Arc-seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=I4QoZhF2c0RIj6ebj5G/LxsuhgKUdxD5c00ojTK/St+Eh6DcEyQEot7bjke/J4zCWjw0hrMRyLfQycyU9gH5nDEw+WeFDSF/fssUSVY/+538qyXEe77on15/deNPAPA7fyQ+G9eyYap2Bbbo3EU/9APZyWidKP0avDKtIVGlgybmg3r7fMVj6jM+07wJeNeAlg0oDQ8fygrDT8TvdCkPC7jptsDH/q1/t6liZo2369HO18/gxGpc7gLjaMIhPBglIHYS3t8Q9evLFuQp7hDvno0shdXLYIn3SS74SR1v5GRfiimwzrbj/tXdxDZDaj9iX3RUs5XfQ1rrYz8WHX3D9w==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=G4QBrauIgcC+zWhg22Ief+od9nmJAyuOjeJjU+xXJeZKkjR+qOfhvILNQ3Xrkfs7Au2LUQnVPARpsBwgz+W9SojI6hB+q1ZuD9oCN8OXUayF0NiphK3KlYolgtvSPPTorA6klWLroTz+edr1GiuwSkaVeqc0orCQxcD4gJ7IO96m4NejVD+7FxQyUdtcT4KNxm6qnsec6BFGwGI7vPxJLw3gOf9p/pnladaQJI/rvsZ/3Vpg4HWCnpEA6jRTDID21ZPKo12KW3/++q8WVGfZg3EIf8T61yD0z25rrXqDdoIfmZOfqfzHAcHycZGDXXhRoKnXgNY+buMFgDhY5zaqsw==
- 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 13:13:27 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Nodisclaimer: true
- Thread-index: AQHbqvIP34UccZOkWUuu+Y+Ap2U3MrOmJOcAgAAb/QCAAAMjAIAABC8AgAADsYCAAACNgA==
- Thread-topic: [PATCH v3 3/7] arm/mpu: Introduce utility functions for the pr_t type
> On 16 Apr 2025, at 14:10, Orzel, Michal <Michal.Orzel@xxxxxxx> wrote:
>
>
>
> On 16/04/2025 14:57, Luca Fancellu wrote:
>> 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.
> Hmm, yes. Indeed we have a mix of places where end is inclusive or exclusive.
> I
> think we can stick with exclusive address being passed to this helper unless
> others have a different opinion. I know we tried to convert some places to
> start+size but I don't remember the future plans.
Ok, I'll document on top of the helper that @limit needs to be exclusive just
to be sure it will be used
in this way.
|
