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

Re: [PATCH v3 4/6] arm/mpu: Move the functions to arm64 specific files


  • To: Ayan Kumar Halder <ayan.kumar.halder@xxxxxxx>
  • From: Luca Fancellu <Luca.Fancellu@xxxxxxx>
  • Date: Fri, 13 Jun 2025 15:08:09 +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=MXDymSsTrYYTlYE//xY6tmXz2/gWgkiBxyI9GOerb88=; b=J1+XqTOng4L3KRpBnZQfo9dM8Bl8FAzebJ/IXByVeLBVDepIAh9f94G9JvodfAfG6sW6EfdDJZNLFsa6k03pssu3s6U4OaGEsGdMpI4gsLrQxR8eLvUyII9a51OA0eUeH7Bf4+VBwORQM7/I2ZH+ysE7/RkqSAoaStcfx1j0Q/CIhka9SwkcTj4vAyMKIz7AlF29ar3jVQ7D8IGexUFE0yFcJI2viTc14UEMOQD3eCxZ2oOoGk/HXAtfLwfejtp2/WFPv4ZE1NcbdijLJZsbjNsgi9r5TF3KYKdxqOTe+AmyJAf+wC8eImxcksJAo8LUwYRxGcB4ksVn1LWQTd5Txw==
  • 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=MXDymSsTrYYTlYE//xY6tmXz2/gWgkiBxyI9GOerb88=; b=WTelt3pm9EB5iPjSLZFnRuiRDSz6VlKeYi71PtV9Bv6l3ExQHLvhZbVsnA50sHsclr3jcjU2L/PnYsjKYk9DTrTmDMJBe5z/DPax3lcJKa2misOCNUM5+LmC94vFKfqlH5ds6VjibAwlr28Ax+C0TcBb7HETiqKQ2qvCvUk9SYTCHq97nQd7woih0XpJcnOFc9B3F/TPFN4zUefJiy7Db9VZuoj23cQAvk8AKYPYd6JrbY4MGgdENOHI2kZCHt8QYwjeXekysNKUUx9QwahEJAT1gRr7wp8tflz1bitL2awBwVDyGyB0UQ91kU93Kw43w4WB5nwnbOO1qORJ3RfNLQ==
  • Arc-seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=OF4i9MAsgaCYC2/eZAbczf6dVK30FDUNo9s/AdquJ9c+T2sX2DiiITpRh226gDTT2iTBbCcip02nhY2+1rBWAmJLUNBjDHGluVcHp7JO9TYi6wW8em4vReUc6HnJ2aXdG0M9HDAu7UJ6YCzxuimRof4J/EjmAMp3YypQhf+ebhORRA8EAcw50uYubIVzMli5pfqGswb/2meCbBemJZRwdGsG1oOOeifmzXD7PS+GYGgLECMa+2Ozft1GIrnOTeeJMVjMcLFUKkzKA+8noPg6Pchxai/QrKxMgLJhI7p9lXdOBSIY3QkkD6smQ7zxqTrqdZnzT6SISSUUUej/v8j3FA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=uOwMtrCie1qwU6yNwvyUgPxfvhaXeceoQu6Wgt2OXq8tIng1bphKknxlQ1M6lAJS9AFao37R+G1yW3EFxX+EdMzt0k6KswU1GcMu5hVAiLHVxQDVyy2slnz7o8hDvtC5YVwsMCTIYLFbvwfE/qRAmi2hj/VPUP4H70Wow636b55V/gl+YaCcN/h1oSBg1fZBniSEiTbmMIcUSeGs4nH/bWULcBfu0D8KcPMej7KnOBcbnmLup+7xN0negayKlGtt9t6jE/ZnbdIvyEmmzsQuWAyvZQbcZm+sVsSQ4t26xdOpMocVPd3xiKLugysU+Dg4JgaBIb29AEECmMuov5t2aQ==
  • 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>, Michal Orzel <michal.orzel@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
  • Delivery-date: Fri, 13 Jun 2025 15:08:58 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Thread-index: AQHb2t5pdnmvyzn4J0yiDihJhBlJArQBNBGA
  • Thread-topic: [PATCH v3 4/6] arm/mpu: Move the functions to arm64 specific files

Hi Ayan,

> On 11 Jun 2025, at 15:35, Ayan Kumar Halder <ayan.kumar.halder@xxxxxxx> wrote:
> 
> prepare_selector(), read_protection_region() and write_protection_region()
> differ significantly between arm32 and arm64. Thus, move these functions
> to their specific folders.

   ^— NIT: “to sub-arch specific folder”? What do you think?

> 
> GENERATE_{WRITE/READ}_PR_REG_CASE are duplicated for arm32 and arm64 so
> as to improve the code readability.

It reads a bit hard in this way, what about:

“Also the macro GENERATE_{WRITE/READ}_PR_REG_CASE are moved, in order to
keep them in the same file of their usage and improve readability"

> 
> Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@xxxxxxx>
> ---
> Changes from -
> 
> v1..v2 - New patch introduced in v3.
> 
> xen/arch/arm/mpu/Makefile       |   1 +
> xen/arch/arm/mpu/arm64/Makefile |   1 +
> xen/arch/arm/mpu/arm64/mm.c     | 130 ++++++++++++++++++++++++++++++++
> xen/arch/arm/mpu/mm.c           | 117 ----------------------------
> 4 files changed, 132 insertions(+), 117 deletions(-)
> create mode 100644 xen/arch/arm/mpu/arm64/Makefile
> create mode 100644 xen/arch/arm/mpu/arm64/mm.c
> 
> diff --git a/xen/arch/arm/mpu/Makefile b/xen/arch/arm/mpu/Makefile
> index 9359d79332..4963c8b550 100644
> --- a/xen/arch/arm/mpu/Makefile
> +++ b/xen/arch/arm/mpu/Makefile
> @@ -1,4 +1,5 @@
> obj-$(CONFIG_ARM_32) += arm32/
> +obj-$(CONFIG_ARM_64) += arm64/
> obj-y += mm.o
> obj-y += p2m.o
> obj-y += setup.init.o
> diff --git a/xen/arch/arm/mpu/arm64/Makefile b/xen/arch/arm/mpu/arm64/Makefile
> new file mode 100644
> index 0000000000..b18cec4836
> --- /dev/null
> +++ b/xen/arch/arm/mpu/arm64/Makefile
> @@ -0,0 +1 @@
> +obj-y += mm.o
> diff --git a/xen/arch/arm/mpu/arm64/mm.c b/xen/arch/arm/mpu/arm64/mm.c
> new file mode 100644
> index 0000000000..a978c1fc6e
> --- /dev/null
> +++ b/xen/arch/arm/mpu/arm64/mm.c
> @@ -0,0 +1,130 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +
> +#include <xen/bug.h>
> +#include <xen/types.h>
> +#include <asm/mpu.h>
> +#include <asm/sysregs.h>
> +#include <asm/system.h>
> +
> +/*
> + * The following are needed for the cases: GENERATE_WRITE_PR_REG_CASE
> + * and GENERATE_READ_PR_REG_CASE with num==0
> + */
> +#define PRBAR0_EL2 PRBAR_EL2
> +#define PRLAR0_EL2 PRLAR_EL2
> +
> +#define PRBAR_EL2_(n)   PRBAR##n##_EL2
> +#define PRLAR_EL2_(n)   PRLAR##n##_EL2
> +
> +#define GENERATE_WRITE_PR_REG_CASE(num, pr)                                 \
> +    case num:                                                               \
> +    {                                                                       \
> +        WRITE_SYSREG(pr->prbar.bits & ~MPU_REGION_RES0, PRBAR_EL2_(num));   \
> +        WRITE_SYSREG(pr->prlar.bits & ~MPU_REGION_RES0, PRLAR_EL2_(num));   \
> +        break;                                                              \
> +    }
> +
> +#define GENERATE_READ_PR_REG_CASE(num, pr)                      \
> +    case num:                                                   \
> +    {                                                           \
> +        pr->prbar.bits = READ_SYSREG(PRBAR_EL2_(num));          \
> +        pr->prlar.bits = READ_SYSREG(PRLAR_EL2_(num));          \
> +        break;                                                  \
> +    }
> +
> +/*
> + * Armv8-R supports direct access and indirect access to the MPU regions 
> through
> + * registers:
> + *  - indirect access involves changing the MPU region selector, issuing an 
> isb
> + *    barrier and accessing the selected region through specific registers
> + *  - direct access involves accessing specific registers that point to
> + *    specific MPU regions, without changing the selector, avoiding the use 
> of
> + *    a barrier.
> + * For Arm64 the PR{B,L}AR_ELx (for n=0) and PR{B,L}AR<n>_ELx (for n=1..15) 
> are
> + * used for the direct access to the regions selected by
> + * PRSELR_EL2.REGION<7:4>:n, so 16 regions can be directly accessed when the
> + * selector is a multiple of 16, giving access to all the supported memory
> + * regions.
> + */
> +static void prepare_selector(uint8_t *sel)
> +{
> +    uint8_t cur_sel = *sel;
> +
> +    /*
> +     * {read,write}_protection_region works using the direct access to the 
> 0..15
> +     * regions, so in order to save the isb() overhead, change the PRSELR_EL2
> +     * only when needed, so when the upper 4 bits of the selector will 
> change.
> +     */
> +    cur_sel &= 0xF0U;
> +    if ( READ_SYSREG(PRSELR_EL2) != cur_sel )
> +    {
> +        WRITE_SYSREG(cur_sel, PRSELR_EL2);
> +        isb();
> +    }
> +    *sel = *sel & 0xFU;

This one is different in the original file (*sel &= 0xFU;)

The rest looks good to me!
With the above fixed:

Reviewed-by: Luca Fancellu <luca.fancellu@xxxxxxx>

Cheers,
Luca


 


Rackspace

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