From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mx1.redhat.com ([209.132.183.28]) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1W0Xmu-0000uR-2e for kexec@lists.infradead.org; Tue, 07 Jan 2014 14:37:48 +0000 Date: Tue, 7 Jan 2014 09:37:23 -0500 From: Vivek Goyal Subject: Re: kexec: reuse 1st kernel as kexec/kdump kernel? Message-ID: <20140107143723.GB1524@redhat.com> References: <20140107023405.GC3967@dhcp-16-126.nay.redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20140107023405.GC3967@dhcp-16-126.nay.redhat.com> 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: Dave Young Cc: hpa@zytor.com, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, ebiederm@xmission.com On Tue, Jan 07, 2014 at 10:34:06AM +0800, Dave Young wrote: > Hi, all > > I have a question in mind: can we copy and prepare kexec kernel while > normal booting? > > Just like below wild idea: > > Kernel uncompress itself (assume kernel is relocatable) > -> copy the kernel image somewhere for backup > -> reserver crashkernel memory > -> copy the backuped kernel image/initrd image to reserved memory > -> copy the purgatory which can be embedded in elf section? > -> prepare the e820 memory ranges which is for kdump kernel > > So userspace only need to call kexec reboot, kexec_load is not necessary. > The initrd for kdump should be different, but we can add some different logic > which will be only for kdump and it can be skipped in normal boot. > > Is it doable? What's the advantage of doing all this? Why are you trying to skip load step. Thanks Vivek _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751609AbaAGOh6 (ORCPT ); Tue, 7 Jan 2014 09:37:58 -0500 Received: from mx1.redhat.com ([209.132.183.28]:1758 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750821AbaAGOht (ORCPT ); Tue, 7 Jan 2014 09:37:49 -0500 Date: Tue, 7 Jan 2014 09:37:23 -0500 From: Vivek Goyal To: Dave Young Cc: kexec@lists.infradead.org, linux-kernel@vger.kernel.org, ebiederm@xmission.com, hpa@zytor.com Subject: Re: kexec: reuse 1st kernel as kexec/kdump kernel? Message-ID: <20140107143723.GB1524@redhat.com> References: <20140107023405.GC3967@dhcp-16-126.nay.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140107023405.GC3967@dhcp-16-126.nay.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 07, 2014 at 10:34:06AM +0800, Dave Young wrote: > Hi, all > > I have a question in mind: can we copy and prepare kexec kernel while > normal booting? > > Just like below wild idea: > > Kernel uncompress itself (assume kernel is relocatable) > -> copy the kernel image somewhere for backup > -> reserver crashkernel memory > -> copy the backuped kernel image/initrd image to reserved memory > -> copy the purgatory which can be embedded in elf section? > -> prepare the e820 memory ranges which is for kdump kernel > > So userspace only need to call kexec reboot, kexec_load is not necessary. > The initrd for kdump should be different, but we can add some different logic > which will be only for kdump and it can be skipped in normal boot. > > Is it doable? What's the advantage of doing all this? Why are you trying to skip load step. Thanks Vivek