From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1756077AbcK3GWB (ORCPT <rfc822;w@1wt.eu>);
        Wed, 30 Nov 2016 01:22:01 -0500
Received: from mail-wm0-f65.google.com ([74.125.82.65]:33545 "EHLO
        mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751529AbcK3GVx (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 30 Nov 2016 01:21:53 -0500
Date: Wed, 30 Nov 2016 07:21:48 +0100
From: Ingo Molnar <mingo@kernel.org>
To: Alex Thorlton <athorlton@sgi.com>
Cc: linux-kernel@vger.kernel.org, Russ Anderson <rja@sgi.com>,
        David Vrabel <david.vrabel@citrix.com>, Ingo Molnar <mingo@redhat.com>,
        Juergen Gross <jgross@suse.com>, Thomas Gleixner <tglx@linutronix.de>,
        "H. Peter Anvin" <hpa@zytor.com>, Denys Vlasenko <dvlasenk@redhat.com>,
        Boris Ostrovsky <boris.ostrovsky@oracle.com>, x86@kernel.org,
        xen-devel@lists.xenproject.org
Subject: Re: [PATCH 1/2] x86: Make E820_X_MAX unconditionally larger than
 E820MAX
Message-ID: <20161130062148.GA11684@gmail.com>
References: <1479168677-23633-1-git-send-email-athorlton@sgi.com>
 <1480476287-232878-1-git-send-email-athorlton@sgi.com>
 <1480476287-232878-2-git-send-email-athorlton@sgi.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1480476287-232878-2-git-send-email-athorlton@sgi.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


* Alex Thorlton <athorlton@sgi.com> wrote:

> It's really not necessary to limit E820_X_MAX to 128 in the non-EFI
> case.  This commit drops E820_X_MAX's dependency on CONFIG_EFI, so that
> E820_X_MAX is always at least slightly larger than E820MAX.
> 
> The real motivation behind this is actually to prevent some issues in
> the Xen kernel, where the XENMEM_machine_memory_map hypercall can
> produce an e820 map larger than 128 entries, even on systems where the
> original e820 table was quite a bit smaller than that, depending on how
> many IOAPICs are installed on the system.
> 
> Signed-off-by: Alex Thorlton <athorlton@sgi.com>
> Suggested-by: Ingo Molnar <mingo@redhat.com>
> Cc: Russ Anderson <rja@sgi.com>
> Cc: David Vrabel <david.vrabel@citrix.com>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Juergen Gross <jgross@suse.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: Denys Vlasenko <dvlasenk@redhat.com>
> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Cc: x86@kernel.org
> Cc: xen-devel@lists.xenproject.org
> ---
>  arch/x86/include/asm/e820.h | 10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/include/asm/e820.h b/arch/x86/include/asm/e820.h
> index 476b574..aa00d33 100644
> --- a/arch/x86/include/asm/e820.h
> +++ b/arch/x86/include/asm/e820.h
> @@ -1,13 +1,15 @@
>  #ifndef _ASM_X86_E820_H
>  #define _ASM_X86_E820_H
>  
> -#ifdef CONFIG_EFI
> +/*
> + * We need to make sure that E820_X_MAX is defined
> + * before we include uapi/asm/e820.h
> + */
>  #include <linux/numa.h>
>  #define E820_X_MAX (E820MAX + 3 * MAX_NUMNODES)

What we need an explanation for in the comment is what does this stand for (what 
does the 'X' mean?), and what is the magic 3*MAX_NUMNODES about?

Thanks,

	Ingo