[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: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Penny Zheng <Penny.Zheng@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- From: Ayan Kumar Halder <ayankuma@xxxxxxx>
- Date: Thu, 29 Jun 2023 15:44:21 +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=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=cE+fUOLsQb5yMN6+QmJ+ZXjlAG77kHKXhfg7+dgWk0M=; b=EoiuuQelawpTQrw7KRtrYlxQ3yO57IBMsRk30EptYEmhAE2HaGzk0EAC8cxbfpDGji/Nrwh7IF79uIwOYicfZ5IzF9fQdhaWK7CtxarW658WtmbPK82e8AQB3oR0Mia7YZiCxuM9nmMQPYv5lfVY87yNxCRL3ZoTRF3EH78K5s4PGqufwEunTrVByIN+dGlh9lOIbKp+smeQ8fNZkiNK0NTSNFeJPXOKC2dsiEBcbQnc5i9j8QNC3vELZLndmn/baJy19wuZjHfG0Bn84RNQsqGqtFUqU8PHPYpXWHHwSbYsSGcauVDkCcyi9uxH606kO/owQGA6wmwH4dXE0d7N9Q==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=amQez3fQOVBStty5c/TtJPUta0V2S0adQm/6nu7FA8ZjMqcs7Z/Ol6axcz0i+bIIHGxcl9GWcsFVPdUujNcrdph1quGRhw8LLhnPzOnM2yOcxxb7kPaOiEeJeR5KTk/lF7gzpUzRE7a60lLix7UdmDXio1DVUnvJkoP4FgynmnEMmqs2UZz5MlDTlcXeTa0V7CiEFhn8FvHljWfv3Fzd68cuXuzyWS6CBw0e64Uaq/JwFMBBkhk82UOcyB4Ef39VYhpAuuiZFmXEziXi6iU/aKR2Ksb9Yo5y07L65wGc7CpuCDOAS79/Yb5ZHG74F1xlfGQZrVo8eVnC5Dku52TKBQ==
- 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>, Wei Chen <wei.chen@xxxxxxx>
- Delivery-date: Thu, 29 Jun 2023 14:44:44 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
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 ?
- Ayan
The logic is correct, but it is an opencoding of the _p() macro for
turning an arbitrary integer into a pointer.
~Andrew
|
