Ian Campbell
2013-Oct-03 10:06 UTC
[PATCH] xen: correct xenheap_bits after "xen: support RAM at addresses 0 and 4096"
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
Jan Beulich
2013-Oct-04 09:47 UTC
Re: [PATCH] xen: correct xenheap_bits after "xen: support RAM at addresses 0 and 4096"
>>> 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