public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Huang, Ying" <ying.huang@intel.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: nigel@nigel.suspend2.net, "Rafael J. Wysocki" <rjw@sisk.pl>,
	Jeremy Maitin-Shepard <jbms@cmu.edu>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org,
	linux-pm@lists.linux-foundation.org
Subject: Re: [PATCH 2/2] Kexec jump: Kexec jump
Date: Fri, 13 Jul 2007 21:03:31 +0000	[thread overview]
Message-ID: <1184360611.1069.23.camel@caritas-dev.intel.com> (raw)
In-Reply-To: <20070712094207.GG1866@elf.ucw.cz>

On Thu, 2007-07-12 at 11:42 +0200, Pavel Machek wrote:
> > This patch provide the kexec based implementation of hibernation image
> > operation. Now, only jumping between original kernel and kexeced
> > kernel is supported, real image write/read/check will be provided in
> > next patches.
> 
> I'd prefer this not to use hibernation hooks... existing dumping
> infrastructure should be good enough to write resume image, no?
> 
> BTW... is this able to do kdump, then return back to the old kernel?
> That seems to be similar functionality to hibernation, and I was told
> it would be very welcome.

Yes. Just because there are so much similarity between them, many people
think they can be merged.

> > +static int kexec_suspend(void)
> > +{
> > +	int error;
> > +
> > +	local_irq_disable();
> > +	/* At this point, device_suspend() has been called, but *not*
> > +	 * device_power_down(). We *must* device_power_down() now.
> > +	 * Otherwise, drivers for some devices (e.g. interrupt controllers)
> > +	 * become desynchronized with the actual state of the hardware
> > +	 * at resume time, and evil weirdness ensues.
> > +	 */
> > +	error = device_power_down(PMSG_FREEZE);
> > +	if (error) {
> > +		printk(KERN_ERR "Some devices failed to power down, aborting suspend\n");
> > +		goto Enable_irqs;
> > +	}
> > +
> > +	save_processor_state();
> > +	error = kexec_jump(KEXEC_JUMP_TYPE_EXEC);
> > +	restore_processor_state();
> > +
> > +	/* NOTE:  device_power_up() is just a resume() for devices
> > +	 * that suspended with irqs off ... no overall powerup.
> > +	 */
> > +	device_power_up();
> > + Enable_irqs:
> > +	in_suspend = 0;
> > +	local_irq_enable();
> > +	return error;
> > +}
> ...
> > +static int kexec_resume(void)
> > +{
> > +	int error = 0;
> > +
> > +	local_irq_disable();
> > +	/* NOTE:  device_power_down() is just a suspend() with irqs off;
> > +	 * it has no special "power things down" semantics
> > +	 */
> > +	if (device_power_down(PMSG_PRETHAW))
> > +		printk(KERN_ERR "Some devices failed to power down, very bad\n");
> > +	/* We'll ignore saved state, but this gets preempt count (etc) right */
> > +	save_processor_state();
> > +	kexec_restore_backup();
> > +	error = kexec_jump(KEXEC_JUMP_TYPE_JUMP);
> > +	swsusp_free();
> > +	restore_processor_state();
> > +	touch_softlockup_watchdog();
> > +	device_power_up();
> > +	local_irq_enable();
> > +	return error;
> > +}
> 
> This seems like mostly generic stuff for going between two kernels,
> no? I'd prefer it not be hooked into hibernation infrastructure.

Yes. In fact, with device_suspend(...), disable_nonboot_cpus() and
enable_nonboot_cpus(), device_resume(...) around the above two
functions, the jumping between normal kernel and kexeced kernel can work
too. Maybe it is more approriate not to hook the kexec into current
hibernation. It seems that there are no much code shared between them
except device/CPU state quiescent/save/restore.

Best Regards,
Huang Ying

  reply	other threads:[~2007-07-13 13:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-11 15:30 [PATCH 2/2] Kexec jump: Kexec jump Huang, Ying
2007-07-12  9:42 ` Pavel Machek
2007-07-13 21:03   ` Huang, Ying [this message]
2007-07-12 19:58 ` Rafael J. Wysocki
2007-07-13 17:20   ` Huang, Ying

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1184360611.1069.23.camel@caritas-dev.intel.com \
    --to=ying.huang@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=jbms@cmu.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=nigel@nigel.suspend2.net \
    --cc=pavel@ucw.cz \
    --cc=rjw@sisk.pl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox