|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 1/6] xen: correct xenheap_bits after "xen: support RAM at addresses 0 and 4096"
On 10/10/2013 15:43, "Ian Campbell" <ian.campbell@xxxxxxxxxx> 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@xxxxxxxxxx>
> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
> Cc: Keir Fraser <keir@xxxxxxx>
> Cc: Tim Deegan <tim@xxxxxxx>
Acked-by: Keir Fraser <keir@xxxxxxx>
> ---
> 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)
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |