From: Julien Grall <julien.grall@arm.com>
To: Stefano Stabellini <sstabellini@kernel.org>,
xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com,
JBeulich@suse.com
Cc: Stefano Stabellini <stefanos@xilinx.com>,
wei.liu2@citrix.com, konrad.wilk@oracle.com,
George.Dunlap@eu.citrix.com, ian.jackson@eu.citrix.com,
tim@xen.org
Subject: Re: [Xen-devel] [PATCH v4 2/2] xen/arm: fix mask calculation in pdx_init_mask
Date: Thu, 20 Jun 2019 14:20:16 +0100 [thread overview]
Message-ID: <e3ff3109-73e5-eb87-b8ad-51c697e0d9a3@arm.com> (raw)
In-Reply-To: <20190617185017.32661-2-sstabellini@kernel.org>
Hi,
On 6/17/19 7:50 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@xilinx.com>
Reviewed-by: Julien Grall <julien.grall@arm.com>
Ideally, I would like an ack from Andrew or Jan.
> CC: JBeulich@suse.com
> CC: andrew.cooper3@citrix.com
> CC: George.Dunlap@eu.citrix.com
> CC: ian.jackson@eu.citrix.com
> CC: konrad.wilk@oracle.com
> CC: tim@xen.org
> CC: wei.liu2@citrix.com
> ---
>
> Changes in v4:
> - use uint64_t
> - single line comment code style
>
> Changes in v3:
> - improve in-code comments
>
> Unchanged in v3:
> - (u64)1
>
> 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 | 7 ++++++-
> 2 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index b03e7ac330..b0af90e5bf 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -483,7 +483,14 @@ static void __init init_pdx(void)
> {
> paddr_t bank_start, bank_size, bank_end;
>
> - uint64_t mask = pdx_init_mask(bootinfo.mem.bank[0].start);
> + /*
> + * Arm does not have any restrictions on the bits to compress. Pass 0 to
> + * let the common code further restrict the mask.
> + *
> + * If the logic changes in pfn_pdx_hole_setup we might have to
> + * update this function too.
> + */
> + uint64_t 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 8356f03ce8..9990b94f73 100644
> --- a/xen/common/pdx.c
> +++ b/xen/common/pdx.c
> @@ -50,9 +50,11 @@ static u64 __init fill_mask(u64 mask)
> return mask;
> }
>
> +/* We don't compress the first MAX_ORDER bit of the addresses. */
> uint64_t __init pdx_init_mask(uint64_t base_addr)
> {
> - return fill_mask(base_addr - 1);
> + return fill_mask(max(base_addr,
> + (uint64_t)1 << (MAX_ORDER + PAGE_SHIFT)) - 1);
> }
>
> u64 __init pdx_region_mask(u64 base, u64 len)
> @@ -80,6 +82,9 @@ 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 the ARM specific
> + * init_pdx too.
> */
> for ( j = MAX_ORDER-1; ; )
> {
>
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2019-06-20 13:20 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-17 18:50 [Xen-devel] [PATCH v4 0/2] fix mask calculation in pdx_init_mask Stefano Stabellini
2019-06-17 18:50 ` [Xen-devel] [PATCH v4 1/2] xen: switch pdx_init_mask to return uint64_t Stefano Stabellini
2019-06-18 10:23 ` Jan Beulich
2019-06-20 13:15 ` Julien Grall
2019-06-21 6:17 ` Jan Beulich
2019-06-17 18:50 ` [Xen-devel] [PATCH v4 2/2] xen/arm: fix mask calculation in pdx_init_mask Stefano Stabellini
2019-06-20 13:20 ` Julien Grall [this message]
2019-06-21 6:21 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e3ff3109-73e5-eb87-b8ad-51c697e0d9a3@arm.com \
--to=julien.grall@arm.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=konrad.wilk@oracle.com \
--cc=sstabellini@kernel.org \
--cc=stefanos@xilinx.com \
--cc=tim@xen.org \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).