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 11:35:08 +0100	[thread overview]
Message-ID: <1424255708.29983.5.camel@x220> (raw)
In-Reply-To: <54E45D6D.3050900@suse.com>

On Wed, 2015-02-18 at 10:37 +0100, Juergen Gross wrote:
> On 02/18/2015 10:21 AM, Paul Bolle wrote:
> > On Wed, 2015-02-18 at 07:52 +0100, Juergen Gross wrote:
> >> +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?
> 
> Yes.
> 
> > Because ...
> >
> >> +endif

[...]

> >> @@ -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?
> 
> Yes.
> 
> That's a matter of taste, I think.

Well, my suggestion does look simpler. Anyhow, I'll be glad to let the
maintainers decide.

> >
> >> +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?
> 
> Yes. A kernel is running only either as Dom0 or as domU at a given time.
> Having two parameters here would be nonsense, as only one could apply.

I see.

> And being able to configure both limits separately does make sense,
> of course.

Thanks,


Paul Bolle


  parent reply	other threads:[~2015-02-18 10:35 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
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 [this message]
2015-02-18 11:18   ` 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=1424255708.29983.5.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