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
next prev 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