[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: Luca Fancellu <luca.fancellu@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • From: "Orzel, Michal" <michal.orzel@xxxxxxx>
  • Date: Wed, 16 Apr 2025 12:50:42 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none
  • 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=heQNtd111nig9aTk/NYEc+rG0PoT6+pO/VFw1vMtPoI=; b=dYixT+dW3NvmS9U/rZ4IgRpyflc2kk6Wjg68ghXgbERIsw/efEUZKj0xbPnRUf7x5uCvVgM48QUU5vOQJAzwjJ/400G3ZUSWLI0kd2MLYRVcZQZGjCetcec27W/oPjr3eHmlMIFZBLDavAzf0kugykmdiBD9rUQxwjtMoyOzwI+TfHg3K7BkVbFypl1hM19TZpnEf0+aeFE2RvYMSVhvool68fzQybTwwCmmnGim703wpQ2eiYNt7UdFcDZWFIaoGtr4Ne0LP1gfaFHjyi9KhQ6KCg+CMUMNSyowl1U8r4snWte5SUzJyNVba1DZWt+sjjYeTRUI3OiO53RbUIQrqw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=OiZxqZKx8rp0k5IvShL4lwVGd8dhyljAUdIcfDN1mIIUrqcIX9mYU+21n6GqsR4vyVI04U8h5H66fiUmyp4WgM6j/7K+xt1VWhlNRLHBdJrllLDM1rHScHW9TmhM+1Ns/jGllgSplKhF+5tPC62dpKYp09SA5c2Cy/8dQxjz0ot5I4eZQicdMw8r/TOOquACeVeaP6ZRDnb2ZuMZP/LW2bI5Cydv1EEE4TCaT1yAAsP3XNXsl2bYY1Rxl4UVYilSgqdZ2q4Z8bgp1Cam9BaYjsrxKTPVoGlYr+X+43OetraEWZeABYNGZndWokENWovC8zzkZPX9q9aCiOcDwzuZyw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com;
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
  • Delivery-date: Wed, 16 Apr 2025 10:50:57 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>


On 11/04/2025 16:56, Luca Fancellu wrote:
> Introduce few utility function to manipulate and handle the
> pr_t type.
> 
> Signed-off-by: Luca Fancellu <luca.fancellu@xxxxxxx>
> ---
>  xen/arch/arm/include/asm/mpu.h | 40 ++++++++++++++++++++++++++++++++++
>  1 file changed, 40 insertions(+)
> 
> diff --git a/xen/arch/arm/include/asm/mpu.h b/xen/arch/arm/include/asm/mpu.h
> index 59ff22c804c1..6971507457fb 100644
> --- a/xen/arch/arm/include/asm/mpu.h
> +++ b/xen/arch/arm/include/asm/mpu.h
> @@ -20,6 +20,46 @@
>  #define NUM_MPU_REGIONS_MASK    (NUM_MPU_REGIONS - 1)
>  #define MAX_MPU_REGIONS         NUM_MPU_REGIONS_MASK
>  
> +#ifndef __ASSEMBLY__
> +
> +/* Set base address of MPU protection region(pr_t). */
What's the use of (pr_t) in this comment? pr_t is a data type. If at all, it
would want to be ...region @pr but I think you can skip it.

> +static inline void pr_set_base(pr_t *pr, paddr_t base)
> +{
> +    pr->prbar.reg.base = (base >> MPU_REGION_SHIFT);
Looking at pr_t definition, base/limit is 46 bits wide. However the spec says
that last 4bits are reserved (i.e. you should not write to them) unless FEAT_LPA
is implemented. What's our plan here?

> +}
> +
> +/* 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.


~Michal




 


Rackspace

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