From mboxrd@z Thu Jan 1 00:00:00 1970 From: Magnus Damm Subject: Re: [PATCH 00/04] Kexec / Kdump: Release 20061122 (xen-unstable-12502) Date: Wed, 29 Nov 2006 17:17:42 +0900 Message-ID: <1164788262.30816.41.camel@localhost> References: Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: Ian Pratt , Kazuo Moriwaka , xen-devel@lists.xensource.com, Ian Campbell , Akio Takebe , Magnus Damm , Isaku Yamahata , Horms List-Id: xen-devel@lists.xenproject.org On Wed, 2006-11-29 at 07:54 +0000, Keir Fraser wrote: > On 29/11/06 4:30 am, "Magnus Damm" wrote: > > In user space the kexec-tool then builds an elf header which points > > out where the notes are located in machine address space (using > > /proc/iomem). This header is then passed on to the secondary crash > > kernel which (for some reason) compacts all per-cpu PT_NOTE program > > headers into one which will be present in the final vmcore image. At > > this compacting stage we need to have data present for _all_ cpus, and > > the data for cpus that are not present should contain just zeros. > > How does kexec discover how many cpus is 'all cpus'? The kexec tool creates (at load time) one PT_NOTE program header per note exported through /proc/iomem. The number of PT_NOTE program headers is the same as the NR_CPUS constant in the hypervisor. The seconday kernel is not aware of how many cpus that was used by the first kernel, it only expects to find valid data pointed out by the PT_NOTE program headers. Valid data in this case is either ELF note formatted data or zeroed memory which happens to be valid end-of-notes ELF note data as well. So giving the secondary kernel a pointer to heap does not work very well. =) / magnus