From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: [PATCH 13/13] xen: allow more than 512 GB of RAM for 64 bit pv-domains Date: Tue, 24 Feb 2015 08:28:40 +0100 Message-ID: <54EC2828.4080207@suse.com> References: <1424242326-26611-1-git-send-email-jgross@suse.com> <1424242326-26611-14-git-send-email-jgross@suse.com> <54E4751F.4090005@citrix.com> <54E47CD2.5000702@suse.com> <54E622B4.7080701@cantab.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <54E622B4.7080701@cantab.net> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: David Vrabel , xen-devel@lists.xen.org Cc: "keir@xen.org" , "Ian.Campbell@citrix.com" , Andrew Cooper , Tim Deegan , Jan Beulich , Ian Jackson List-Id: xen-devel@lists.xenproject.org On 02/19/2015 06:51 PM, David Vrabel wrote: > On 18/02/2015 11:51, Juergen Gross wrote: >> On 02/18/2015 12:18 PM, David Vrabel wrote: >>> 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. >> >> How is the toolstack supposed to indicate this? > > I don't know. A bit in the shared info perhaps? Okay, I'd be fine with this. CC'ed the hypervisor maintainers to enable them to object early. :-) > >> I'd be more than happy to get rid of that option. For Dom0 you seem to >> have changed your mind (you rejected enabling >512GB as default last >> year). > > Since for dom0 it's only crash analysis that might be impacted, removing > the option is fine. Anyone using such a tool probably know what they're > doing. Fine, I'll remove it. > >> Doing some more tests I found the command line option is problematic: >> The option seems to be evaluated only after it is needed (I did the >> first tests using the config option). Can we get rid of the option >> even for domU? Or do I have to pre-scan the command line for the option? > > I don't what people to be able to inadvertantly create domUs that cannot > be saved/migrated. Can you think of another mechanism? No, I hoped you'd have an idea. I'll try to parse the command line options a little bit earlier. > >>> And >>> >>> If max_pfn < 512G, populate 3-level p2m /unless/ toolstack indicates it >>> supports the linear p2m. >> >> What about Dom0? > > This bit is for dom0 and domU. Okay, but which toolstack would set the indicator for dom0? The hypervisor? Would it set this bit in any case, or depending on a command line option? Juergen