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
prev parent 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