public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Paul Bolle <pebolle@tiscali.nl>
To: Juergen Gross <jgross@suse.com>
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com
Subject: Re: [PATCH 13/13] xen: allow more than 512 GB of RAM for 64 bit pv-domains
Date: Wed, 18 Feb 2015 10:21:32 +0100	[thread overview]
Message-ID: <1424251292.7082.72.camel@x220> (raw)
In-Reply-To: <1424242326-26611-14-git-send-email-jgross@suse.com>

On Wed, 2015-02-18 at 07:52 +0100, Juergen Gross wrote:
> 64 bit pv-domains under Xen are limited to 512 GB of RAM today. The
> main reason has been the 3 level p2m tree, which was replaced by the
> virtual mapped linear p2m list. Parallel to the p2m list which is
> being used by the kernel itself there is a 3 level mfn tree for usage
> by the Xen tools and eventually for crash dump analysis. For this tree
> the linear p2m list can serve as a replacement, too. As the kernel
> can't know whether the tools are capable of dealing with the p2m list
> instead of the mfn tree, the limit of 512 GB can't be dropped in all
> cases.
> 
> This patch replaces the hard limit by a kernel parameter which tells
> the kernel to obey the 512 GB limit or not. The default is selected by
> a configuration parameter which specifies whether the 512 GB limit
> should be active per default for dom0 (only crash dump analysis is
> affected) and/or for domUs (additionally domain save/restore/migration
> are affected).
> 
> Memory above the domain limit is returned to the hypervisor instead of
> being identity mapped, which was wrong anyways.
> 
> The kernel configuration parameter to specify the maximum size of a
> domain can be deleted, as it is not relevant any more.
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
>  Documentation/kernel-parameters.txt |  7 ++++
>  arch/x86/include/asm/xen/page.h     |  4 ---
>  arch/x86/xen/Kconfig                | 31 +++++++++++-----
>  arch/x86/xen/p2m.c                  | 10 +++---
>  arch/x86/xen/setup.c                | 72 ++++++++++++++++++++++++++++++-------
>  5 files changed, 93 insertions(+), 31 deletions(-)

[...]

> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -23,14 +23,29 @@ config XEN_PVHVM
>  	def_bool y
>  	depends on XEN && PCI && X86_LOCAL_APIC
>  
> -config XEN_MAX_DOMAIN_MEMORY
> -       int
> -       default 500 if X86_64
> -       default 64 if X86_32
> -       depends on XEN
> -       help
> -         This only affects the sizing of some bss arrays, the unused
> -         portions of which are freed.
> +if X86_64

Not
    && XEN
?

> +choice
> +	prompt "Support pv-domains larger than 512GB"
> +	default XEN_512GB_NONE
> +	help
> +	  Support paravirtualized domains with more than 512GB of RAM.
> +
> +	  The Xen tools and crash dump analysis tools might not support
> +	  pv-domains with more than 512 GB of RAM. This option controls the
> +	  default setting of the kernel to use only up to 512 GB or more.
> +	  It is always possible to change the default via specifying the
> +	  boot parameter "xen_512gb_limit".
> +
> +	config XEN_512GB_NONE
> +		bool "neither dom0 nor domUs can be larger than 512GB"
> +	config XEN_512GB_DOM0
> +		bool "dom0 can be larger than 512GB, domUs not"
> +	config XEN_512GB_DOMU
> +		bool "domUs can be larger than 512GB, dom0 not"
> +	config XEN_512GB_ALL
> +		bool "dom0 and domUs can be larger than 512GB"
> +endchoice

So there are actually two independent limits, configured through a
choice with four entries. Would using just two separate Kconfig symbols
(XEN_512GB_DOM0 and XEN_512GB_DOMU) without a choice wrapper also work?
Because ...

> +endif
>  
>  config XEN_SAVE_RESTORE
>         bool

[...]
 
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index 84a6473..16d94de 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -32,6 +32,8 @@
>  #include "p2m.h"
>  #include "mmu.h"
>  
> +#define GB(x) ((uint64_t)(x) * 1024 * 1024 * 1024)
> +
>  /* Amount of extra memory space we add to the e820 ranges */
>  struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata;
>  
> @@ -85,6 +87,27 @@ static struct {
>   */
>  #define EXTRA_MEM_RATIO		(10)
>  
> +static bool xen_dom0_512gb_limit __initdata =
> +	IS_ENABLED(CONFIG_XEN_512GB_NONE) || IS_ENABLED(CONFIG_XEN_512GB_DOMU);

... then this could be something like:
    static bool xen_dom0_512gb_limit __initdata = !IS_ENABLED(CONFIG_XEN_512GB_DOM0);

> +static bool xen_domu_512gb_limit __initdata =
> +	IS_ENABLED(CONFIG_XEN_512GB_NONE) || IS_ENABLED(CONFIG_XEN_512GB_DOM0);
> +

and this likewise:
    static bool xen_domu_512gb_limit __initdata = !IS_ENABLED(CONFIG_XEN_512GB_DOMU);

Correct?

> +static int __init xen_parse_512gb(char *arg)
> +{
> +	bool val = false;
> +
> +	if (!arg)
> +		val = true;
> +	else if (strtobool(arg, &val))
> +		return 1;
> +
> +	xen_dom0_512gb_limit = val;
> +	xen_domu_512gb_limit = val;
> +
> +	return 0;
> +}
> +early_param("xen_512gb_limit", xen_parse_512gb);
> +
>  static void __init xen_add_extra_mem(phys_addr_t start, phys_addr_t size)
>  {
>  	int i;

So one can configure these two limits separately, but the kernel
parameter is used for both. Any particular reason?

Thanks,


Paul Bolle


  reply	other threads:[~2015-02-18  9:21 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-18  6:51 [PATCH 00/13] xen: support pv-domains larger than 512GB Juergen Gross
2015-02-18  6:51 ` [PATCH 01/13] xen: sync with xen header Juergen Gross
2015-02-18  6:51 ` [PATCH 02/13] xen: anchor linear p2m list in shared info structure Juergen Gross
2015-02-18 10:32   ` [Xen-devel] " David Vrabel
2015-02-18 10:42     ` Juergen Gross
2015-02-18 10:50       ` Andrew Cooper
2015-02-18 10:54         ` David Vrabel
2015-02-18 10:57           ` Andrew Cooper
2015-02-18 10:57           ` Juergen Gross
2015-02-18 10:56         ` Juergen Gross
2015-02-18 10:51       ` David Vrabel
2015-02-18  6:51 ` [PATCH 03/13] xen: eliminate scalability issues from initial mapping setup Juergen Gross
2015-02-18  6:51 ` [PATCH 04/13] xen: move static e820 map to global scope Juergen Gross
2015-02-19 17:27   ` [Xen-devel] " David Vrabel
2015-02-18  6:51 ` [PATCH 05/13] xen: simplify xen_set_identity_and_remap() by using global variables Juergen Gross
2015-02-19 18:10   ` [Xen-devel] " David Vrabel
2015-02-24  6:15     ` Juergen Gross
2015-02-18  6:51 ` [PATCH 06/13] xen: detect pre-allocated memory interfering with e820 map Juergen Gross
2015-02-19 18:07   ` [Xen-devel] " David Vrabel
2015-02-24  6:27     ` Juergen Gross
2015-02-25 14:24       ` David Vrabel
2015-02-25 16:00         ` Juergen Gross
2015-03-30 10:00           ` Juergen Gross
2015-02-18  6:52 ` [PATCH 07/13] xen: find unused contiguous memory area Juergen Gross
2015-02-19 17:31   ` [Xen-devel] " David Vrabel
2015-02-18  6:52 ` [PATCH 08/13] xen: add service function to copy physical memory areas Juergen Gross
2015-02-19 17:35   ` [Xen-devel] " David Vrabel
2015-02-24  6:34     ` Juergen Gross
2015-02-18  6:52 ` [PATCH 09/13] xen: check for kernel memory conflicting with memory layout Juergen Gross
2015-02-19 17:36   ` [Xen-devel] " David Vrabel
2015-02-24  6:45     ` Juergen Gross
2015-02-18  6:52 ` [PATCH 10/13] xen: check pre-allocated page tables for conflict with memory map Juergen Gross
2015-02-19 17:37   ` [Xen-devel] " David Vrabel
2015-02-24  6:45     ` Juergen Gross
2015-02-18  6:52 ` [PATCH 11/13] xen: move initrd away from e820 non-ram area Juergen Gross
2015-02-19 17:42   ` [Xen-devel] " David Vrabel
2015-02-18  6:52 ` [PATCH 12/13] xen: if p2m list located in to be remapped region delay remapping Juergen Gross
2015-02-19 17:44   ` [Xen-devel] " David Vrabel
2015-02-24  7:01     ` Juergen Gross
2015-02-18  6:52 ` [PATCH 13/13] xen: allow more than 512 GB of RAM for 64 bit pv-domains Juergen Gross
2015-02-18  9:21   ` Paul Bolle [this message]
2015-02-18  9:37     ` Juergen Gross
2015-02-18  9:49       ` [Xen-devel] " Jan Beulich
     [not found]       ` <54E46E3C0200007800060F98@suse.com>
2015-02-18  9:59         ` Juergen Gross
2015-02-18 10:35       ` Paul Bolle
2015-02-18 11:18   ` [Xen-devel] " David Vrabel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1424251292.7082.72.camel@x220 \
    --to=pebolle@tiscali.nl \
    --cc=boris.ostrovsky@oracle.com \
    --cc=david.vrabel@citrix.com \
    --cc=jgross@suse.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox