public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Huang, Ying" <ying.huang@intel.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Pavel Machek <pavel@ucw.cz>,
	nigel@nigel.suspend2.net,
	Andrew Morton <akpm@linux-foundation.org>,
	Jeremy Maitin-Shepard <jbms@cmu.edu>,
	linux-kernel@vger.kernel.org,
	linux-pm@lists.linux-foundation.org,
	Kexec Mailing List <kexec@lists.infradead.org>
Subject: Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
Date: Fri, 21 Sep 2007 16:42:34 +0800	[thread overview]
Message-ID: <1190364154.21818.182.camel@caritas-dev.intel.com> (raw)
In-Reply-To: <m1y7f0k6p4.fsf@ebiederm.dsl.xmission.com>

On Thu, 2007-09-20 at 22:01 -0600, Eric W. Biederman wrote:
> "Huang, Ying" <ying.huang@intel.com> writes:
> 
> > Index: linux-2.6.23-rc6/include/linux/kexec.h
> > ===================================================================
> > --- linux-2.6.23-rc6.orig/include/linux/kexec.h 2007-09-20 11:24:25.000000000
> > +0800
> > +++ linux-2.6.23-rc6/include/linux/kexec.h 2007-09-20 11:26:03.000000000 +0800
> > @@ -83,6 +83,7 @@
> >  
> >  	unsigned long start;
> >  	struct page *control_code_page;
> > +	struct page *swap_page;
> >  
> >  	unsigned long nr_segments;
> >  	struct kexec_segment segment[KEXEC_SEGMENT_MAX];
> > @@ -194,4 +195,12 @@
> >  static inline void crash_kexec(struct pt_regs *regs) { }
> >  static inline int kexec_should_crash(struct task_struct *p) { return 0; }
> >  #endif /* CONFIG_KEXEC */
> > +
> > +#ifdef CONFIG_KEXEC_JUMP
> > +extern int machine_kexec_jump(struct kimage *image);
> > +extern unsigned long kexec_jump_back_entry;
> > +extern int kexec_jump(void);
> > +#else /* !CONFIG_KEXEC_JUMP */
> > +static inline int kexec_jump(void) { return 0; }
> > +#endif /* CONFIG_KEXEC_JUMP */
> >  #endif /* LINUX_KEXEC_H */
> 
> Please the kexec_jump code just be triggered off of a flag in
> struct kimage.  We just need to define an extra flag to sys_kexec_load
> say KEXEC_RETURNS.  Ideally in the long term we would not have to
> do anything except to accept the flag.  Adding a flag makes
> a nice feature test if you want to see if your kernel supports
> the extended version of kexec.
> 
> Until we get the hibernation methods sorted out storing the flag in
> struct kimage and making the methods that we call conditional feels
> like a more maintainable interface.  Especially since we have to
> know at kexec image load time what we are going to do with the
> kexec image.

You mean we use KEXEC_RETURNS when do sys_kexec_load, then use ordinary
reboot command LINUX_REBOOT_CMD_KEXEC, which call kexec_jump conditional
based on KEXEC_RETURNS? This is reasonable. I will change it.

> > +#ifdef CONFIG_KEXEC_JUMP
> > +unsigned long kexec_jump_back_entry;
> > +
> > +int kexec_jump(void)
> > +{
> > +	int error;
> > +
> > +	if (!kexec_image)
> > +		return -EINVAL;
> 
> I understand where you are coming from with this implementation of
> kexec_jump but it looks like this is one of the big parts of this
> patch that have not reached their final form.
> 
> The line above is racy with sys_kexec_load.

Yes. I should use xchg(&kexec_image, NULL) as that of other kexec
related functions.

> > +	pm_prepare_console();
> > +	suspend_console();
> > +	error = device_suspend(PMSG_FREEZE);
> > +	if (error)
> > +		goto Resume_console;
> 
> This as everyone knows needs to be device_shutdown or a better hibernation
> replacement.

Yes.

> > +	error = disable_nonboot_cpus();
> > +	if (error)
> > +		goto Resume_devices;
> 
> Can't we just catch the noboot cpu's in a mutex.
> disable_nonboot_cpus is actually impossible to implement 100% reliably
> with current hardware.  But something smp_call_function so we trap them
> at a specific location and then the equivalent when we come back should
> be simple.  I guess the tricky part is bringing the cpus back up again.
> 
> Using the broken by design version of cpu hotplug really annoys me here.

I think this is not very simple. Given that we may jump back from the
kernel with SMP turned off, or from bootloader directly. But CPU hotplug
is another topic, I think it should be solved in another patch.

> > +	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)
> > +		goto Enable_irqs;
> 
> This of course should go away when we have the proper methods.
Yes.
> > +	save_processor_state();
> This line might even be reasonable.
> > +	error = machine_kexec_jump(kexec_image);
> > +	restore_processor_state();
> >
> > +	/* NOTE:  device_power_up() is just a resume() for devices
> > +	 * that suspended with irqs off ... no overall powerup.
> > +	 */
> > +	device_power_up();
> Yep this can go away.
Yes.
> > + Enable_irqs:
> > +	local_irq_enable();
> > +	enable_nonboot_cpus();
> 
> I haven't looked at the cpu start up code yet to see if it
> is generally implementable.  I would think so, but I guess
> we need to be careful with our data structures.
> 
> > + Resume_devices:
> > +	device_resume();
> This of course should change.
Yes.
> > + Resume_console:
> > +	resume_console();
> > +	pm_restore_console();
> 
> Odd.  I'm a little surprised that the console is the last
> thing we restore.  But it does make sense to treat it specially.
> 
> > +	return error;
> > +}
> > +#endif /* CONFIG_KEXEC_JUMP */

Best Regards,
Huang Ying

      reply	other threads:[~2007-09-21  8:41 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-20  5:34 [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump Huang, Ying
2007-09-20 10:09 ` Pavel Machek
2007-09-21  0:24   ` Nigel Cunningham
2007-09-21  1:06     ` Andrew Morton
2007-09-21  1:19       ` Nigel Cunningham
2007-09-21  1:41         ` Andrew Morton
2007-09-21  1:57           ` Nigel Cunningham
2007-09-21  2:18             ` Huang, Ying
2007-09-21  2:25               ` Nigel Cunningham
2007-09-21  2:45                 ` Huang, Ying
2007-09-21  2:58                   ` Nigel Cunningham
2007-09-21  4:46                     ` Eric W. Biederman
2007-09-21  9:45                       ` Pavel Machek
2007-09-26 20:30                         ` Joseph Fannin
2007-09-26 20:52                           ` Nigel Cunningham
2007-09-27  6:33                           ` Huang, Ying
2007-09-27  6:35                             ` Nigel Cunningham
2007-09-22 22:02                   ` Alon Bar-Lev
2007-09-21  3:33             ` Eric W. Biederman
2007-09-21 12:09               ` [linux-pm] " Rafael J. Wysocki
2007-09-21 13:14                 ` huang ying
2007-09-21 14:31                   ` Rafael J. Wysocki
2007-09-21 15:02                     ` huang ying
2007-09-21 15:50                       ` Rafael J. Wysocki
2007-09-21 18:11                     ` Jeremy Maitin-Shepard
2007-09-21 19:00                       ` Rafael J. Wysocki
2007-09-21 19:45                         ` Alan Stern
2007-09-21 20:15                           ` Rafael J. Wysocki
2007-09-21 20:26                             ` Jeremy Maitin-Shepard
2007-09-21 20:53                               ` Rafael J. Wysocki
2007-09-21 21:08                                 ` Jeremy Maitin-Shepard
2007-09-21 21:25                                   ` Rafael J. Wysocki
2007-09-21 21:16                                     ` Jeremy Maitin-Shepard
2007-09-21 23:19                                       ` Kyle Moffett
2007-09-21 23:47                                         ` Nigel Cunningham
2007-09-22 10:40                                           ` Rafael J. Wysocki
2007-10-11 20:54                                             ` Pavel Machek
2007-10-24 20:38                                               ` Rafael J. Wysocki
2007-09-22 10:34                                         ` Rafael J. Wysocki
2007-09-22 18:00                                           ` Kyle Moffett
2007-09-22 21:51                                             ` Rafael J. Wysocki
2007-09-26 20:52                                               ` Joseph Fannin
2007-09-21  4:16             ` Andrew Morton
2007-09-21 11:56           ` Rafael J. Wysocki
2007-09-21 11:58             ` Nigel Cunningham
2007-09-21 12:18               ` Rafael J. Wysocki
2007-09-21 12:15                 ` Nigel Cunningham
2007-09-21 13:25             ` huang ying
2007-09-24 17:37       ` Thomas Meyer
2007-09-21  9:49     ` Pavel Machek
2007-09-21 12:10       ` [linux-pm] " Rafael J. Wysocki
2007-09-21  2:55 ` Eric W. Biederman
2007-09-21  7:27   ` Huang, Ying
2007-09-21  4:01 ` Eric W. Biederman
2007-09-21  8:42   ` Huang, Ying [this message]

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=1190364154.21818.182.camel@caritas-dev.intel.com \
    --to=ying.huang@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=jbms@cmu.edu \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=nigel@nigel.suspend2.net \
    --cc=pavel@ucw.cz \
    /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