From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH 00/04] Kexec / Kdump: Release 20061122 (xen-unstable-12502) Date: Wed, 29 Nov 2006 11:42:37 +0000 Message-ID: <1164800557.2647.9.camel@localhost.localdomain> References: <1164788262.30816.41.camel@localhost> <1164792929.3336.228.camel@localhost.localdomain> 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: Magnus Damm Cc: Ian Pratt , Kazuo Moriwaka , xen-devel@lists.xensource.com, Akio Takebe , Isaku Yamahata , Magnus Damm , Horms List-Id: xen-devel@lists.xenproject.org On Wed, 2006-11-29 at 20:13 +0900, Magnus Damm wrote: > On 11/29/06, Ian Campbell wrote: > > On Wed, 2006-11-29 at 17:17 +0900, Magnus Damm wrote: > > > > > > 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 guest kernel creates entries in /proc/iomem by calling > > kexec_get_cpu(cpu) until it returns EINVAL. This currently happens when > > cpu>NR_CPUS. > > > > I think this function should return EINVAL for cpu>num_present_cpus() > > instead. Xen doesn't currently do PCPU hotplug and this wouldn't be the > > only thing that would need fixing if it ever does (percpu data would be > > another one I think ;-)). > > > > This would cause the tools to create notes only for CPUs which really > > exist. That would make the loop in machine_crash_kexec() unnecessary. > > I feel that using bss instead of per-cpu data is more robust and will > make future cpu hotplug support a breeze to implement - at least in > the case of kexec. Using bss also makes the loop in > machine_crash_kexec() unnecessary. > > Using num_present_cpus() will of course work as well, but I'd like to > avoid adding code that likely needs to be rewritten in the near > future.. But you know the future better than I do, so what do you > think? =) I don't think anyone is planning PCPU hotplug anytime soon (I've not even heard rumours about the distant future ;-)). I do think that using the existing infrastructure is the right way to go though rather than open coding a different per cpu mechanism to solve a problem which doesn't currently exist. If someone implements PCPU hotplug they will no doubt need to update the per cpu infrastructure and if kdump is using it then it can be taken into consideration at that time. Cheers, Ian.