[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [PATCH v2 3/3] xen/arm: fix mask calculation in pdx_init_mask
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. + * + * 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 + * are left uncompressed. + */ u64 __init pdx_init_mask(u64 base_addr) { - return fill_mask(base_addr - 1); + return fill_mask(max(base_addr, (u64)1 << (MAX_ORDER + PAGE_SHIFT)) - 1); } u64 __init pdx_region_mask(u64 base, u64 len) @@ -80,6 +84,8 @@ void __init pfn_pdx_hole_setup(unsigned long mask) * This guarantees that page-pointer arithmetic remains valid within * contiguous aligned ranges of 2^MAX_ORDER pages. Among others, our * buddy allocator relies on this assumption. + * + * If the logic changes here, we might have to update init_pdx too. */ for ( j = MAX_ORDER-1; ; ) { -- 2.17.1 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |