[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Arm: AArch32: Need suggestions to support 32 bit physical addresses
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Ayan Kumar Halder <ayankuma@xxxxxxx>
- Date: Wed, 30 Nov 2022 11:27:54 +0000
- 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=5xrXrsj/7NgSQSbDpJMBlak7v0PWein6jZNCxYllDEY=; b=cfyaQliPkid6I2soaI+bsDh0ataN0j/ece79x+maTOWM4RWsiwRwPUC0aMcALZsIH0sLy7UInQi9KEbdzBupBgv5fc/tIsdKOXqdtk17SuSVHDhn8JqzLUp3VhjDpyJbL7fpEOOH4iIAsIcEAPGW+KyWb4SwVBhztWGhidTDpHsWQxJRmi8YHLjQQ8LyywuruNGNNdhg/MztOXOCGrkSAVH2iZAno7Kud2PuDkjsHxfn6Uk4bYLwrI7gsYGFizvu5oPKulVvc4XleqgY4oxmCL0R2n2iFKtNMXAuhV7QQUhuviB7hiOUT/4qT8eHxkx6hxhMt4J4mtTey1Kyl9yXGQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=leRHd6ivGq+Y8YSu2PL7E826dMf9xZYlIq/DxgWwgbD+blGAHB/gGNbT3Tr4jFjAWLrk5jyJsr9oEWKAZ2Ns19qsxCElsILiGkc9dO7DgPdIjjOIjkcKlQzZnyGTUJW3ADYd9oOJ/TBMZhr9IUvSJtucsFLhTpu6QobVLWpQDNMPcn47fIhKu6/7YTDQlqxBS0tXRIDSi9ds+e2lZKVjGi6s3T+/l0rcS5oGzz9x1StVBWbcZ3jTEEl4zEV9sYrkjJyg6K7UkMFlMhLCOmuo/U2hW0cVtNjjaRw5/dcGn3bfRhSCFr5ervNpnTZyxhm/SE14egWxubBBgCLHky7yJg==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com;
- Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, "Stabellini, Stefano" <stefano.stabellini@xxxxxxx>, bertrand Marquis <Bertrand.Marquis@xxxxxxx>, Andre Przywara <andre.przywara@xxxxxxx>, "Volodymyr_Babchuk@xxxxxxxx" <Volodymyr_Babchuk@xxxxxxxx>, Rahul Singh <rahul.singh@xxxxxxx>, Vladimir Murzin <vladimir.murzin@xxxxxxx>, Julien Grall <julien@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Wed, 30 Nov 2022 11:28:09 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 30/11/2022 07:09, Jan Beulich wrote:
On 29.11.2022 19:18, Ayan Kumar Halder wrote:
On 29/11/2022 15:52, Julien Grall wrote:
On 29/11/2022 16:23, Ayan Kumar Halder wrote:
On 29/11/2022 14:52, Julien Grall wrote:
On 29/11/2022 14:57, Ayan Kumar Halder wrote:
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -2245,7 +2245,9 @@ void __init xenheap_max_mfn(unsigned long mfn)
{
ASSERT(!first_node_initialised);
ASSERT(!xenheap_bits);
+#ifndef CONFIG_AARCH32_V8R
BUILD_BUG_ON(PADDR_BITS >= BITS_PER_LONG);
+#endif
BUILD_BUG_ON() are used to indicate that the code would fall over the
check pass. I can't find the justification for this change in the
commit message.
I had a look at the following commit which introduced this, but I
couldn't get the explaination for this.
commit 88e3ed61642bb393458acc7a9bd2f96edc337190
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date: Tue Sep 1 14:02:57 2015 +0200
@Jan :- Do you know why BUILD_BUG_ON() was introduced ?
You've cut too much context - the next line explains this all by itself,
I think:
xenheap_bits = min(flsl(mfn + 1) - 1 + PAGE_SHIFT, PADDR_BITS);
Clearly addresses used for the Xen heap need to be representable in an
unsigned long (which we assume to be the same size as void *).
But I'm afraid there's further context missing for your question: Why
would that construct be a problem in your case? Is it just that you'd
need it to be > rather than the >= that's used presently?
In my case (for Cortex-R52 build) :-
PADDR_BITS = 32
BITS_PER_LONG = 32
Thus, "BUILD_BUG_ON(PADDR_BITS >= BITS_PER_LONG)" gets triggered.
I think the physical adresses are representable using "unsigned long".
Yes, using "BUILD_BUG_ON(PADDR_BITS > BITS_PER_LONG)" looks correct to me.
If so, why
do you add an #ifdef rather than dealing with the (apparent) off-by-1?
(I say "apparent" because I haven't checked whether the >= is really
depended upon anywhere.)
The only callers of xenheap_max_mfn() are from xen/arch/x86/setup.c as
follows :-
1. xenheap_max_mfn(PFN_DOWN(highmem_start - 1));
2. xenheap_max_mfn(limit);
Looking at "min(flsl(mfn + 1) - 1 + PAGE_SHIFT, PADDR_BITS);", I do not
understand the reason for "... -1" (ie subtracting by 1).
Do you know the reason ?
- Ayan
Jan
|
