Hi,
On 14/08/17 15:23, Julien Grall wrote:
> alloc_boot_pages will panic if it is not possible to allocate. So the
> check in the caller is pointless.
More than that I don't see why "0" couldn't be a valid MFN. At least the
code in alloc_boot_pages() doesn't treat it specially, so it doesn't
signal an error condition in the first place.
> Signed-off-by: Julien Grall
Reviewed-by: Andre Przywara
Cheers,
Andre.
> ---
>
> Cc: Jan Beulich
> Cc: Andrew Cooper
> ---
> xen/arch/x86/numa.c | 8
> 1 file changed, 8 deletions(-)
>
> diff --git a/xen/arch/x86/numa.c b/xen/arch/x86/numa.c
> index d45196fafc..ffeba6e180 100644
> --- a/xen/arch/x86/numa.c
> +++ b/xen/arch/x86/numa.c
> @@ -101,14 +101,6 @@ static int __init allocate_cachealigned_memnodemap(void)
> unsigned long size = PFN_UP(memnodemapsize * sizeof(*memnodemap));
> unsigned long mfn = alloc_boot_pages(size, 1);
>
> -if ( !mfn )
> -{
> -printk(KERN_ERR
> - "NUMA: Unable to allocate Memory to Node hash map\n");
> -memnodemapsize = 0;
> -return -1;
> -}
> -
> memnodemap = mfn_to_virt(mfn);
> mfn <<= PAGE_SHIFT;
> size <<= PAGE_SHIFT;
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel