From: "Huang, Ying" <ying.huang@intel.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: nigel@nigel.suspend2.net,
Kexec Mailing List <kexec@lists.infradead.org>,
linux-kernel@vger.kernel.org, Pavel Machek <pavel@ucw.cz>,
Andrew Morton <akpm@linux-foundation.org>,
linux-pm@lists.linux-foundation.org,
Jeremy Maitin-Shepard <jbms@cmu.edu>
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
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
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
next prev parent reply other threads:[~2007-09-21 8:46 UTC|newest]
Thread overview: 167+ 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 5:34 ` Huang, Ying
2007-09-20 10:09 ` Pavel Machek
2007-09-20 10:09 ` Pavel Machek
2007-09-20 10:09 ` Pavel Machek
2007-09-21 0:24 ` Nigel Cunningham
2007-09-21 0:24 ` Nigel Cunningham
2007-09-21 0:24 ` Nigel Cunningham
2007-09-21 1:06 ` Andrew Morton
2007-09-21 1:06 ` Andrew Morton
2007-09-21 1:06 ` Andrew Morton
2007-09-21 1:19 ` Nigel Cunningham
2007-09-21 1:19 ` Nigel Cunningham
2007-09-21 1:19 ` Nigel Cunningham
2007-09-21 1:41 ` Andrew Morton
2007-09-21 1:41 ` Andrew Morton
2007-09-21 1:41 ` Andrew Morton
2007-09-21 1:57 ` Nigel Cunningham
2007-09-21 1:57 ` Nigel Cunningham
2007-09-21 2:18 ` Huang, Ying
2007-09-21 2:18 ` Huang, Ying
2007-09-21 2:18 ` Huang, Ying
2007-09-21 2:25 ` Nigel Cunningham
2007-09-21 2:25 ` Nigel Cunningham
2007-09-21 2:25 ` Nigel Cunningham
2007-09-21 2:45 ` Huang, Ying
2007-09-21 2:45 ` Huang, Ying
2007-09-21 2:45 ` Huang, Ying
2007-09-21 2:58 ` Nigel Cunningham
2007-09-21 2:58 ` Nigel Cunningham
2007-09-21 2:58 ` Nigel Cunningham
2007-09-21 4:46 ` Eric W. Biederman
2007-09-21 4:46 ` Eric W. Biederman
2007-09-21 9:45 ` Pavel Machek
2007-09-21 9:45 ` Pavel Machek
2007-09-21 9:45 ` Pavel Machek
2007-09-26 20:30 ` Joseph Fannin
2007-09-26 20:30 ` Joseph Fannin
2007-09-26 20:52 ` Nigel Cunningham
2007-09-26 20:52 ` Nigel Cunningham
2007-09-26 20:52 ` Nigel Cunningham
2007-09-27 6:33 ` Huang, Ying
2007-09-27 6:33 ` Huang, Ying
2007-09-27 6:35 ` Nigel Cunningham
2007-09-27 6:35 ` Nigel Cunningham
2007-09-27 6:35 ` Nigel Cunningham
2007-09-27 6:33 ` Huang, Ying
2007-09-26 20:30 ` Joseph Fannin
2007-09-21 4:46 ` Eric W. Biederman
2007-09-22 22:02 ` Alon Bar-Lev
2007-09-22 22:02 ` Alon Bar-Lev
2007-09-22 22:02 ` Alon Bar-Lev
2007-09-21 3:33 ` Eric W. Biederman
2007-09-21 3:33 ` Eric W. Biederman
2007-09-21 12:09 ` [linux-pm] " Rafael J. Wysocki
2007-09-21 12:09 ` Rafael J. Wysocki
2007-09-21 13:14 ` huang ying
2007-09-21 13:14 ` [linux-pm] " huang ying
2007-09-21 13:14 ` huang ying
2007-09-21 14:31 ` Rafael J. Wysocki
2007-09-21 14:31 ` [linux-pm] " Rafael J. Wysocki
2007-09-21 14:31 ` Rafael J. Wysocki
2007-09-21 14:45 ` Alan Stern
2007-09-21 15:27 ` Rafael J. Wysocki
2007-09-21 15:02 ` huang ying
2007-09-21 15:02 ` [linux-pm] " huang ying
2007-09-21 15:02 ` huang ying
2007-09-21 15:50 ` Rafael J. Wysocki
2007-09-21 15:50 ` [linux-pm] " Rafael J. Wysocki
2007-09-21 15:50 ` Rafael J. Wysocki
2007-09-21 18:11 ` Jeremy Maitin-Shepard
2007-09-21 18:11 ` Jeremy Maitin-Shepard
2007-09-21 19:00 ` Rafael J. Wysocki
2007-09-21 19:00 ` Rafael J. Wysocki
2007-09-21 19:00 ` Rafael J. Wysocki
2007-09-21 19:45 ` [linux-pm] " Alan Stern
2007-09-21 19:45 ` Alan Stern
2007-09-21 20:15 ` Rafael J. Wysocki
2007-09-21 20:15 ` Rafael J. Wysocki
2007-09-21 20:26 ` Jeremy Maitin-Shepard
2007-09-21 20:26 ` Jeremy Maitin-Shepard
2007-09-21 20:53 ` Rafael J. Wysocki
2007-09-21 20:53 ` [linux-pm] " Rafael J. Wysocki
2007-09-21 20:53 ` Rafael J. Wysocki
2007-09-21 21:08 ` Jeremy Maitin-Shepard
2007-09-21 21:08 ` [linux-pm] " Jeremy Maitin-Shepard
2007-09-21 21:08 ` Jeremy Maitin-Shepard
2007-09-21 21:25 ` Rafael J. Wysocki
2007-09-21 21:25 ` Rafael J. Wysocki
2007-09-21 21:16 ` Jeremy Maitin-Shepard
2007-09-21 21:16 ` Jeremy Maitin-Shepard
2007-09-21 23:19 ` Kyle Moffett
2007-09-21 23:19 ` Kyle Moffett
2007-09-21 23:47 ` Nigel Cunningham
2007-09-21 23:47 ` Nigel Cunningham
2007-09-22 10:40 ` Rafael J. Wysocki
2007-09-22 10:40 ` [linux-pm] " Rafael J. Wysocki
2007-09-22 10:40 ` Rafael J. Wysocki
2007-10-11 20:54 ` Pavel Machek
2007-10-11 20:54 ` Pavel Machek
2007-10-24 20:38 ` Rafael J. Wysocki
2007-10-24 20:38 ` [linux-pm] " Rafael J. Wysocki
2007-10-24 20:38 ` Rafael J. Wysocki
2007-10-11 20:54 ` Pavel Machek
2007-09-21 23:47 ` Nigel Cunningham
2007-09-22 10:34 ` [linux-pm] " Rafael J. Wysocki
2007-09-22 10:34 ` Rafael J. Wysocki
2007-09-22 18:00 ` Kyle Moffett
2007-09-22 18:00 ` Kyle Moffett
2007-09-22 21:51 ` Rafael J. Wysocki
2007-09-22 21:51 ` Rafael J. Wysocki
2007-09-26 20:52 ` Joseph Fannin
2007-09-26 20:52 ` [linux-pm] " Joseph Fannin
2007-09-26 20:52 ` Joseph Fannin
2007-09-22 21:51 ` Rafael J. Wysocki
2007-09-22 18:00 ` Kyle Moffett
2007-09-22 10:34 ` Rafael J. Wysocki
2007-09-21 23:19 ` Kyle Moffett
2007-09-21 21:16 ` Jeremy Maitin-Shepard
2007-09-21 21:25 ` Rafael J. Wysocki
2007-09-21 20:26 ` Jeremy Maitin-Shepard
2007-09-21 20:15 ` Rafael J. Wysocki
2007-09-21 19:45 ` Alan Stern
2007-09-21 18:11 ` Jeremy Maitin-Shepard
2007-09-21 12:09 ` Rafael J. Wysocki
2007-09-21 3:33 ` Eric W. Biederman
2007-09-21 4:16 ` Andrew Morton
2007-09-21 4:16 ` Andrew Morton
2007-09-21 4:16 ` Andrew Morton
2007-09-21 1:57 ` Nigel Cunningham
2007-09-21 11:56 ` Rafael J. Wysocki
2007-09-21 11:56 ` Rafael J. Wysocki
2007-09-21 11:58 ` Nigel Cunningham
2007-09-21 11:58 ` Nigel Cunningham
2007-09-21 11:58 ` Nigel Cunningham
2007-09-21 12:18 ` Rafael J. Wysocki
2007-09-21 12:18 ` Rafael J. Wysocki
2007-09-21 12:15 ` Nigel Cunningham
2007-09-21 12:15 ` Nigel Cunningham
2007-09-21 12:15 ` Nigel Cunningham
2007-09-21 12:18 ` Rafael J. Wysocki
2007-09-21 13:25 ` huang ying
2007-09-21 13:25 ` huang ying
2007-09-21 13:25 ` huang ying
2007-09-21 11:56 ` Rafael J. Wysocki
2007-09-24 17:37 ` Thomas Meyer
2007-09-24 17:37 ` Thomas Meyer
2007-09-24 17:37 ` Thomas Meyer
2007-09-21 9:49 ` Pavel Machek
2007-09-21 9:49 ` Pavel Machek
2007-09-21 12:10 ` [linux-pm] " Rafael J. Wysocki
2007-09-21 12:10 ` Rafael J. Wysocki
2007-09-21 12:10 ` Rafael J. Wysocki
2007-09-21 9:49 ` Pavel Machek
2007-09-21 2:55 ` Eric W. Biederman
2007-09-21 2:55 ` Eric W. Biederman
2007-09-21 7:27 ` Huang, Ying
2007-09-21 7:27 ` Huang, Ying
2007-09-21 7:27 ` Huang, Ying
2007-09-21 2:55 ` Eric W. Biederman
2007-09-21 4:01 ` Eric W. Biederman
2007-09-21 4:01 ` Eric W. Biederman
2007-09-21 4:01 ` Eric W. Biederman
2007-09-21 8:42 ` Huang, Ying
2007-09-21 8:42 ` Huang, Ying [this message]
2007-09-21 8:42 ` Huang, Ying
-- strict thread matches above, loose matches on Subject: below --
2007-09-20 5:34 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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.