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 <julien.gr...@arm.com>
Reviewed-by: Andre Przywara <andre.przyw...@arm.com>
Cheers,
Andre.
> ---
>
> Cc: Jan Beulich <jbeul...@suse.com>
> Cc: Andrew Cooper <andrew.coop...@citrix.com>
> ---
> 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
