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

Re: [PATCH v3 6/6] arm/mpu: Enable read/write to protection regions for arm32


  • To: Luca Fancellu <Luca.Fancellu@xxxxxxx>, Ayan Kumar Halder <ayan.kumar.halder@xxxxxxx>
  • From: Ayan Kumar Halder <ayankuma@xxxxxxx>
  • Date: Thu, 12 Jun 2025 11:37:45 +0100
  • 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=rfgt0faCwlqfNukCYZw3rOVHqafZfoASff2CONnzUiw=; b=viziyE1cea1yiKdsUB821jaNK8wJMtGMjfj/xM3B29WLEgnidA31daNjkpuHlzxIc2MuaKvQL7mehhiKKWDTzMo+hzFIXeRIDFo9JGlb66MUBc0FJomOHKMZ0tRmrqLJGJq2TKYQa+hOsYtLh9H6Z5wiYpqmJINOymqfywlxH0eDxsZkIToS+n1NSmxUzpS3awWZnsS1wRLOc65iZqt2rKcPdyr3Ok7EHYnbTnGbqhoDCBXSx8cFe5vJht8GdKRLQExKEarOF9HZ0CucOhRlWDKszjW7i3+ujos7YdPl03rFk8BDAZLTMvAgYO10xPxqhIG5BD6+ma3e1pmTgdwpKg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=xk9qSUh9utTIlMZ4a0NE95gf4ma2eZkfuyVzWSKhfQ1zPCzN/fGO3Cheg9IVA01XDDl0OrUxp+JBOYXjAn4Tlv4EDmY2oiOjhP6KkV8pEc3S9szDwuUdBE4fiJ/qi8oHVDlGg02itedZYSJwY0K9H3ee57IL+xFkKEDY0QKhxAZWzD4gbmdXOEn4ag3PwQL5EUevF4wvHOtz9ZIPPkpAZNtPsPO0p1JSRTQxXp17CHwzyfkqmdXf5Y5LBa2ijE/oQ05zEBpxq5iMe8XPmT+ISGMGm4VAaL2aoS49pmyVbH1lSOBzFfbwXmy++olKEPJ4I50GmxoAUimSFEmn4mimew==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.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: Thu, 12 Jun 2025 10:38:02 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>


On 12/06/2025 10:35, Luca Fancellu wrote:
Hi Ayan,
Hi Luca,

On 11 Jun 2025, at 15:35, Ayan Kumar Halder <ayan.kumar.halder@xxxxxxx> wrote:

Define prepare_selector(), read_protection_region() and
write_protection_region() for arm32. Also, define
GENERATE_{READ/WRITE}_PR_REG_OTHERS to access MPU regions from 32 to 255.

Enable pr_{get/set}_{base/limit}(), region_is_valid() for arm32.
Enable pr_of_addr() for arm32.

Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@xxxxxxx>
---
Based on your v2 
(https://patchwork.kernel.org/project/xen-devel/patch/20250606164854.1551148-4-ayan.kumar.halder@xxxxxxx/)
 I was imaging something like this:

diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c
index 74e96ca57137..5d324b2d4ca5 100644
--- a/xen/arch/arm/mpu/mm.c
+++ b/xen/arch/arm/mpu/mm.c
@@ -87,20 +87,28 @@ static void __init __maybe_unused build_assertions(void)
   */
  static void prepare_selector(uint8_t *sel)
  {
-#ifdef CONFIG_ARM_64
      uint8_t cur_sel = *sel;
+#ifdef CONFIG_ARM_64
      /*
-     * {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.
+     * {read,write}_protection_region works using the Arm64 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;
+#else
+    /* Arm32 MPU can use direct access for 0-31 */
+    if ( cur_sel > 31 )
+        cur_sel = 0;
+#endif
      if ( READ_SYSREG(PRSELR_EL2) != cur_sel )
      {
          WRITE_SYSREG(cur_sel, PRSELR_EL2);
          isb();
      }
+
+#ifdef CONFIG_ARM_64
      *sel = *sel & 0xFU;
  #endif
  }
@@ -144,6 +152,12 @@ void read_protection_region(pr_t *pr_read, uint8_t sel)
          GENERATE_READ_PR_REG_CASE(29, pr_read);
          GENERATE_READ_PR_REG_CASE(30, pr_read);
          GENERATE_READ_PR_REG_CASE(31, pr_read);
+        case 32 ... 255:
+        {
+            pr->prbar.bits = READ_SYSREG(PRBAR_EL2);
+            pr->prlar.bits = READ_SYSREG(PRLAR_EL2);
+            break;
+        }
  #endif
      default:
          BUG(); /* Can't happen */
@@ -190,6 +204,12 @@ void write_protection_region(const pr_t *pr_write, uint8_t 
sel)
          GENERATE_WRITE_PR_REG_CASE(29, pr_write);
          GENERATE_WRITE_PR_REG_CASE(30, pr_write);
          GENERATE_WRITE_PR_REG_CASE(31, pr_write);
+        case 32 ... 255:
+        {
+            WRITE_SYSREG(pr->prbar.bits & ~MPU_REGION_RES0, PRBAR_EL2);
+            WRITE_SYSREG(pr->prlar.bits & ~MPU_REGION_RES0, PRLAR_EL2);
+            break;
+        }
  #endif
      default:
          BUG(); /* Can't happen */


Is it using too ifdefs in your opinion that would benefit the split you do in 
v3?

Yes. However, I understand that this is subjective. I need your and Michal/Julien to have an opinion here whether to go with the split (which means some amount of code duplication) or introduce if-defs. I will be happy to proceed as per your opinions.

- Ayan






 


Rackspace

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