From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from cantor2.suse.de ([195.135.220.15] helo=mx2.suse.de) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1WUtnp-0002LW-CA for kexec@lists.infradead.org; Tue, 01 Apr 2014 08:12:14 +0000 Date: Tue, 1 Apr 2014 10:11:26 +0200 From: Petr Tesarik Subject: Re: [PATCH 2/2] makedumpfile: Use max_pfn from mem_map array Message-ID: <20140401101126.767549bc@hananiah.suse.cz> In-Reply-To: <0910DD04CBD6DE4193FCF86B9C00BE971FBB75@BPXM01GP.gisp.nec.co.jp> References: <20140325171420.6b558576@holzheu> <20140326.105507.429853525.d.hatayama@jp.fujitsu.com> <20140326185426.5e2e5fc4@holzheu> <0910DD04CBD6DE4193FCF86B9C00BE971FA0EC@BPXM01GP.gisp.nec.co.jp> <20140327145441.4c956989@holzheu> <20140328120047.24a056ea@hananiah.suse.cz> <20140328174622.2896296e@holzheu> <20140328175303.2ed0232a@holzheu> <0910DD04CBD6DE4193FCF86B9C00BE971FB6BA@BPXM01GP.gisp.nec.co.jp> <20140331123742.21beb21a@hananiah.suse.cz> <0910DD04CBD6DE4193FCF86B9C00BE971FBB75@BPXM01GP.gisp.nec.co.jp> Mime-Version: 1.0 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "kexec" Errors-To: kexec-bounces+dwmw2=twosheds.infradead.org@lists.infradead.org To: Atsushi Kumagai Cc: "d.hatayama@jp.fujitsu.com" , "holzheu@linux.vnet.ibm.com" , "kexec@lists.infradead.org" On Tue, 1 Apr 2014 05:06:33 +0000 Atsushi Kumagai wrote: > [...] > >> > >> In the first place, we shouldn't truncate max_mapnr > >> based on dom0's mem_section since there are some domU's > >> memories on Xen dumps. Now, I think a better way for Xen > >> is just leaving max_mapnr as it is. > >> > >> Do you agree with my view ? > > > >Definitely! For Xen, info->max_mapnr gives the maximum machine PFN > >(ie. it corresponds to total memory installed in the machine). > > > >The data in mem_section describes Dom0 kernel memory map (and gets > >initialized from info->dom0_mapnr). It may be substantially smaller > >than info->max_mapnr... > > Thanks for your confirming. > > >A "clean" solution would be to change info->max_mapnr so that it always > >gives the maximum physical PFN, but that doesn't fly very well in > >practice, because memory bitmaps and other stuff must still be sized > >according to the number of machine PFNs, so I would have to add special > >cases all around the place... > > I don't know how to capture a dump on Xen well, so do you have any idea > how to produce the difference between actual memory regions and the ELF > header like the s390 case ? I don't quite see what would be the Xen equivalent. Like I said in a previous mail, memory regions under Xen are sized by Dom0's max_pfn, so it makes no sense to set this value back from the memory regions. > If it isn't possible, we don't need to change info->max_mapnr since the > value calculated from the ELF header must be correct. Ah, if we're talking about the ELF headers, then the extents are determined by kexec-tools using information passed on by the Xen hypervisor on boot. If the available memory is reduced using Xen's mem= or availmem= command line parameter, then these headers are correct. AFAIK there is no mechanism to change the amount of RAM used by the hypervisor at run-time. In short, I agree that the adjustment should be simply skipped for Xen, exactly as you proposed in your patch: + if (!is_xen_memory()) { + for (i = 0; i < info->num_mem_map; i++) { + if (info->mem_map_data[i].mem_map == NOT_MEMMAP_ADDR) + continue; + max_pfn = MAX(max_pfn, info->mem_map_data[i].pfn_end); + } + info->max_mapnr = MIN(info->max_mapnr, max_pfn); + } Petr T _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec