[PATCH] xen: correct xenheap_bits after "xen: support RAM at addresses 0 and 4096"

[PATCH] xen: correct xenheap_bits after "xen: support RAM at addresses 0 and 4096"

[Ian Campbell]

This is incorrect after commit 1aac966e24e which shuffled the zones up by one.
I've observed failures on arm64 systems with RAM at 0x8,00000000-0x8,7fffffff
since xenheap_bits ends up as 35 instead of 36 (which is the zone with all the
RAM).

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Keir Fraser <keir@xen.org>
Cc: jbeulich@suse.com
Cc: Tim Deegan <tim@xen.org>
---
I suppose that MEMZONE_XEN is not really useful when !CONFIG_SEPARATE_XENHEAP
so in principal 1aac966e24e could be make conditional, but in reality
MEMZONE_XEN is at least referenced when !CONFIG_SEPARATE_XENHEAP so at least
some other cleanup would be needed. This fix seems simpler/clearer.
---
 xen/common/page_alloc.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index fb8187b..4c17fbd 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -1364,7 +1364,7 @@ static unsigned int __read_mostly xenheap_bits;
 
 void __init xenheap_max_mfn(unsigned long mfn)
 {
-    xenheap_bits = fls(mfn) + PAGE_SHIFT - 1;
+    xenheap_bits = fls(mfn) + PAGE_SHIFT;
 }
 
 void init_xenheap_pages(paddr_t ps, paddr_t pe)
-- 
1.7.10.4

Re: [PATCH] xen: correct xenheap_bits after "xen: support RAM at addresses 0 and 4096"

[Jan Beulich]

>>> On 03.10.13 at 12:06, Ian Campbell <ian.campbell@citrix.com> wrote:
> This is incorrect after commit 1aac966e24e which shuffled the zones up by 
> one.
> I've observed failures on arm64 systems with RAM at 0x8,00000000-0x8,7fffffff
> since xenheap_bits ends up as 35 instead of 36 (which is the zone with all 
> the
> RAM).
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Keir Fraser <keir@xen.org>

Reviewed-by: Jan Beulich <jbeulich@suse.com>

> Cc: Tim Deegan <tim@xen.org>
> ---
> I suppose that MEMZONE_XEN is not really useful when 
> !CONFIG_SEPARATE_XENHEAP
> so in principal 1aac966e24e could be make conditional, but in reality
> MEMZONE_XEN is at least referenced when !CONFIG_SEPARATE_XENHEAP so at least
> some other cleanup would be needed. This fix seems simpler/clearer.
> ---
>  xen/common/page_alloc.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
> index fb8187b..4c17fbd 100644
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -1364,7 +1364,7 @@ static unsigned int __read_mostly xenheap_bits;
>  
>  void __init xenheap_max_mfn(unsigned long mfn)
>  {
> -    xenheap_bits = fls(mfn) + PAGE_SHIFT - 1;
> +    xenheap_bits = fls(mfn) + PAGE_SHIFT;
>  }
>  
>  void init_xenheap_pages(paddr_t ps, paddr_t pe)
> -- 
> 1.7.10.4