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

Re: [PATCH v3 28/52] xen/mpu: plump virt/maddr conversion in MPU system


  • To: Julien Grall <julien@xxxxxxx>, Ayan Kumar Halder <ayankuma@xxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Penny Zheng <penny.zheng@xxxxxxx>
  • Date: Fri, 30 Jun 2023 10:40:06 +0800
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 40.67.248.234) smtp.rcpttodomain=xen.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=none (message not signed); arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; 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=2YrygJb6IOptJjQ6c2+oTKLOXDU6DZyk0uzvVtZLK6g=; b=DNgmpL8Eye7CWdT6kAmEgiY32+MOvDia9w9wpM0UNE15FpMuOVSw2PQfcKFUYZTUkjTQ1lcGNhBhCIDY0xJTFhMYKUhFhW+6YwHC+1e7MWr5zzllwQIe4knOtWYhhCT/65Bs89czLX9nlFYkMDMhiOLK3n3G3njefEYkTRwGCatnM8+nm5+D088/06DzUh3sW/iJp8MqSGqNv9WLl/IcZ6vl/MsIIkZv6VkngpxCXigkXGbYPuIb4hVVoBeMCtNA1FRIP8tqo3Ih66gHollaNDHi6vfJDE/9GiuRMGBd8hE95cV5VeVKKrAsKV8i0PqVrt/3FblAY2RMFhXe2xHbzQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=njES2J6R1r+G7vso5A5PfOh/MJj1Mq1ECM0c9b9Hlx07tXIe0Q+ZkLsZMyevOhnwVp0rtTLpTHPsDv46M0VMiuLy1F9edQfeJ3+PyO2TEAXSxp9rsJgHwF7cLJKQOp8VSy3sA4eQyQ0grqFzMOGug2I4bP7Mg/ctk+TcPdw0qC8m090HPHVWmPwBALDBO2rspFsnuuhsgWAE6YYla1pPp7LYOp/psOQoIK1myEY6+nB7QJC6F1SrM/Ic18OEF4NMmryH/PdZegMdol6HmJ8wsxeW2Zy+X6LXJz3JvlN0BnWJ+7C050g3ISEppfNaJMRr2pREACTEbgYB5mp1lhpBEQ==
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Wei Chen <wei.chen@xxxxxxx>
  • Delivery-date: Fri, 30 Jun 2023 02:40:45 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true

Hi,

On 2023/6/29 23:14, Julien Grall wrote:
Hi,

On 29/06/2023 15:44, Ayan Kumar Halder wrote:

On 29/06/2023 15:23, Andrew Cooper wrote:
On 29/06/2023 3:20 pm, Ayan Kumar Halder wrote:
On 26/06/2023 04:34, Penny Zheng wrote:
diff --git a/xen/arch/arm/include/asm/mm.h
b/xen/arch/arm/include/asm/mm.h
index eb520b49e3..ea4847c12b 100644
--- a/xen/arch/arm/include/asm/mm.h
+++ b/xen/arch/arm/include/asm/mm.h
@@ -292,6 +301,12 @@ static inline void *maddr_to_virt(paddr_t ma)
                        ((ma & ma_top_mask) >> pfn_pdx_hole_shift)));
   }
   #endif
+#else /* CONFIG_HAS_MPU */
+static inline void *maddr_to_virt(paddr_t ma)
+{
+    return (void *)(unsigned long)ma;
Why do you need "(unsigned long)ma" ? Both "unsigned long" and
"paddr_t" are u64.
For when paddr_t really isn't u64.

Sorry, I am missing something

 From https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/arm/include/asm/types.h;h=fb6618ef247fe8e3abe472e50b4877e11cc8a96c;hb=refs/heads/staging

In CONFIG_ARM_64

typedef unsigned long u64;

typedef u64 paddr_t;

So, why do we need to typecast "paddr_t" to "unsigned long" as they are the same ?
We may decide to restrict paddr_t to 32-bit in the future on Arm64.

Also, when CONFIG_PHYS_ADDR_T_32=n, paddr_t is 64-bit on 32-bit Xen. So casting directly to (void *) is not possible. Although, this is not a problem here because for the MPU on 32-bit, you would select CONFIG_PHYS_ADDR_T_32.

On a side note, I agree with Andrew that we should switch to _p().

Sure. I'll switch to _p().


Cheers,




 


Rackspace

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