[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH v2 3/3] xen/arm: fix mask calculation in pdx_init_mask
- To: Stefano Stabellini <sstabellini@xxxxxxxxxx>
- From: Julien Grall <julien.grall@xxxxxxx>
- Date: Mon, 13 May 2019 10:50:36 +0100
- Cc: Stefano Stabellini <stefanos@xxxxxxxxxx>, wei.liu2@xxxxxxxxxx, konrad.wilk@xxxxxxxxxx, George.Dunlap@xxxxxxxxxxxxx, andrew.cooper3@xxxxxxxxxx, ian.jackson@xxxxxxxxxxxxx, tim@xxxxxxx, JBeulich@xxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Mon, 13 May 2019 09:50:51 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
Hi Stefano,
On 5/8/19 11:47 PM, Stefano Stabellini wrote:
The mask calculation in pdx_init_mask is wrong when the first bank
starts at address 0x0. The reason is that pdx_init_mask will do '0 - 1'
causing an underflow. As a result, the mask becomes 0xffffffffffffffff
which is the biggest possible mask and ends up causing a significant
memory waste in the frametable size computation.
For instance, on platforms that have a low memory bank starting at 0x0
and a high memory bank, the frametable will end up covering all the
holes in between.
The purpose of the mask is to be passed as a parameter to
pfn_pdx_hole_setup, which based on the mask parameter calculates
pfn_pdx_hole_shift, pfn_pdx_bottom_mask, etc. which are actually the
important masks for frametable initialization later on.
pfn_pdx_hole_setup never compresses addresses below MAX_ORDER bits (1GB
on ARM). Thus, it is safe to initialize mask passing 1ULL << (MAX_ORDER
+ PAGE_SHIFT) as start address to pdx_init_mask.
Signed-off-by: Stefano Stabellini <stefanos@xxxxxxxxxx>
CC: JBeulich@xxxxxxxx
CC: andrew.cooper3@xxxxxxxxxx
CC: George.Dunlap@xxxxxxxxxxxxx
CC: ian.jackson@xxxxxxxxxxxxx
CC: konrad.wilk@xxxxxxxxxx
CC: tim@xxxxxxx
CC: wei.liu2@xxxxxxxxxx
---
Changes in v2:
- update commit message
- add in-code comments regarding update sites
- improve in-code comments
- move the mask initialization changes to pdx_init_mask
---
xen/arch/arm/setup.c | 9 ++++++++-
xen/common/pdx.c | 8 +++++++-
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index ccb0f181ea..afaafe7b84 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -482,7 +482,14 @@ static void __init init_pdx(void)
{
paddr_t bank_start, bank_size, bank_end;
- u64 mask = pdx_init_mask(bootinfo.mem.bank[0].start);
+ /*
+ * Pass 0x0 to pdx_init_mask to get a mask initialized with the
+ * first to 1<<MAX_ORDER pages of RAM left uncompressed.
What matter is Arm doesn't have any specific restriction on the
compression, but the common code may have. So how about something:
"Arm does not have any restriction on the bits to compress. Pass 0 to
let the common code to further restrict".
+ *
+ * If the logic changes in pfn_pdx_hole_setup we might have to
+ * update this function too.
+ */ > + u64 mask = pdx_init_mask(0x0);
int bank;
for ( bank = 0 ; bank < bootinfo.mem.nr_banks; bank++ )
diff --git a/xen/common/pdx.c b/xen/common/pdx.c
index bb7e437049..268d6f7ec3 100644
--- a/xen/common/pdx.c
+++ b/xen/common/pdx.c
@@ -50,9 +50,13 @@ static u64 __init fill_mask(u64 mask)
return mask;
}
+/*
+ * We always map the first 1<<MAX_ORDER pages of RAM, hence, they
I thought I already pointed out in the previous version. At least on
Arm, we never map the first 1 << MAX_ORDER of RAM. Instead what you want
to say is that we don't compress the first N bits of the address.
+ * are left uncompressed.
+ */
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|