[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54E4751F.4090005@citrix.com>
Date: Wed, 18 Feb 2015 11:18:55 +0000
From: David Vrabel <david.vrabel@...rix.com>
To: Juergen Gross <jgross@...e.com>, <linux-kernel@...r.kernel.org>,
<xen-devel@...ts.xensource.com>, <konrad.wilk@...cle.com>,
<david.vrabel@...rix.com>, <boris.ostrovsky@...cle.com>
Subject: Re: [Xen-devel] [PATCH 13/13] xen: allow more than 512 GB of RAM
for 64 bit pv-domains
On 18/02/15 06:52, Juergen Gross wrote:
>
> +if X86_64
> +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
> +endif
This configuration option doesn't look useful to me. Can we get rid of
it with runtime checking. e.g.,
If dom0, enable >512G.
If domU, enable >512G if requested by command line option /or/ toolstack
indicates that it supports the linear p2m.
And
If max_pfn < 512G, populate 3-level p2m /unless/ toolstack indicates it
supports the linear p2m.
People using crash analysis tools that need the 3-level p2m can clamp
dom0 memory with the Xen command line option. FWIW, the tool we use
doesn't need this.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists