From: "Huang, Ying" <ying.huang@intel.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Pavel Machek <pavel@ucw.cz>,
nigel@nigel.suspend2.net, "Rafael J. Wysocki" <rjw@sisk.pl>,
Andrew Morton <akpm@linux-foundation.org>,
Vivek Goyal <vgoyal@redhat.com>,
linux-kernel@vger.kernel.org,
linux-pm@lists.linux-foundation.org,
Kexec Mailing List <kexec@lists.infradead.org>
Subject: Re: [PATCH -mm] kexec jump -v9
Date: Thu, 15 May 2008 09:42:19 +0800 [thread overview]
Message-ID: <1210815739.23707.74.camel@caritas-dev.intel.com> (raw)
In-Reply-To: <m13aok1pt1.fsf@frodo.ebiederm.org>
On Wed, 2008-05-14 at 15:30 -0700, Eric W. Biederman wrote:
[...]
> >
> > + if (image->preserve_context) {
> > + KJUMP_MAGIC(control_page) = KJUMP_MAGIC_NUMBER;
> > + if (kexec_jump_save_cpu(control_page)) {
> > + image->start = KJUMP_ENTRY(control_page);
> > + return;
>
> Tricky, and I expect unnecessary.
> We should be able to just have relocate_new_kernel return?
OK, I will check this. Maybe we can move CPU state saving code into
relocate_new_kernel.
[...]
> > -static void kernel_kexec(void)
> > +static int kernel_kexec(void)
> > {
> > + int ret = -ENOSYS;
> > #ifdef CONFIG_KEXEC
> > - struct kimage *image;
> > - image = xchg(&kexec_image, NULL);
> > - if (!image)
> > - return;
> > - kernel_restart_prepare(NULL);
> > - printk(KERN_EMERG "Starting new kernel\n");
> > - machine_shutdown();
> > - machine_kexec(image);
> > + if (xchg(&kexec_lock, 1))
> > + return -EBUSY;
> > + if (!kexec_image) {
> > + ret = -EINVAL;
> > + goto unlock;
> > + }
> > + if (!kexec_image->preserve_context) {
> > + kernel_restart_prepare(NULL);
> > + printk(KERN_EMERG "Starting new kernel\n");
> > + machine_shutdown();
> > + }
> > + ret = kexec_jump(kexec_image);
> > +unlock:
> > + xchg(&kexec_lock, 0);
> > #endif
>
> Ugh. No. Not sharing the shutdown methods with reboot and
> the normal kexec path looks like a recipe for failure to me.
>
> This looks like where we really need to have the conversation.
> What methods do we use to shutdown the system.
>
> My take on the situation is this. For proper handling we
> need driver device_detach and device_reattach methods.
>
> With the following semantics. The device_detach methods
> will disable DMA and place the hardware in a sane state
> from which the device driver can reclaim and reinitialize it,
> but the hardware will not be touched.
>
> device_reattach reattaches the driver to the hardware.
Yes. Current device PM callback is not suitable for hibernation (kexec
based or original). I think we can collaborate with Rafael J. Wysocki on
the new device drivers hibernation callbacks.
> So looking at this patch I see two very productive directions
> we can go.
> 1) A patch that just fixes up the kexec infrastructure code
> so it implements the swap page and provides the kernel
> reentry point. And doesn't handle the upper layer
> user interface portion.
>
> 2) A patch that renames device_shutdown to device_detach.
> And starts implementing the driver hooks needed from
> a resumable kexec.
OK. I can separate the patch into two patches.
Best Regards,
Huang Ying
next prev parent reply other threads:[~2008-05-15 1:37 UTC|newest]
Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-06 3:13 [PATCH -mm] kexec jump -v9 Huang, Ying
2008-03-11 21:10 ` Vivek Goyal
2008-03-11 21:59 ` Nigel Cunningham
2008-03-11 23:55 ` Eric W. Biederman
2008-03-12 0:09 ` david
2008-03-12 2:14 ` Huang, Ying
2008-03-12 18:53 ` Vivek Goyal
2008-03-13 0:01 ` Eric W. Biederman
2008-03-11 22:18 ` Rafael J. Wysocki
2008-03-12 2:02 ` Eric W. Biederman
2008-03-12 2:26 ` Huang, Ying
2008-03-11 23:24 ` Pavel Machek
2008-03-11 23:49 ` Rafael J. Wysocki
2008-03-12 1:55 ` Huang, Ying
2008-03-12 15:01 ` [linux-pm] " Alan Stern
2008-03-12 21:53 ` Rafael J. Wysocki
2008-03-13 0:33 ` Eric W. Biederman
2008-03-13 17:03 ` Rafael J. Wysocki
2008-03-13 23:07 ` Eric W. Biederman
2008-03-14 1:31 ` Rafael J. Wysocki
[not found] ` <m1prtsug2e.fsf@ebiederm.dsl.xmission.com>
2008-03-18 23:52 ` Pavel Machek
2008-03-19 0:08 ` Rafael J. Wysocki
2008-03-19 2:33 ` Alan Stern
[not found] ` <m1ve3jtmxk.fsf@ebiederm.dsl.xmission.com>
2008-03-19 15:01 ` Alan Stern
2008-03-19 19:28 ` Rafael J. Wysocki
2008-03-20 10:40 ` Pavel Machek
2008-03-20 22:45 ` Rafael J. Wysocki
2008-03-20 23:01 ` Alan Stern
2008-03-20 23:22 ` Pavel Machek
2008-03-20 23:40 ` Rafael J. Wysocki
2008-03-21 0:36 ` Rafael J. Wysocki
2008-03-21 0:52 ` Alan Stern
2008-03-21 22:05 ` Nigel Cunningham
2008-03-22 16:21 ` Pavel Machek
2008-03-22 17:45 ` Rafael J. Wysocki
2008-03-22 20:49 ` Alan Stern
2008-03-22 21:29 ` Rafael J. Wysocki
2008-05-14 22:38 ` Eric W. Biederman
2008-05-14 23:47 ` Rafael J. Wysocki
2008-05-15 20:55 ` Eric W. Biederman
2008-05-15 21:20 ` Rafael J. Wysocki
2008-05-14 20:41 ` Maxim Levitsky
2008-05-14 23:34 ` Eric W. Biederman
2008-03-12 8:57 ` Pavel Machek
2008-03-12 0:00 ` Nigel Cunningham
2008-03-12 1:45 ` Huang, Ying
2008-03-12 2:17 ` Eric W. Biederman
2008-03-12 6:54 ` Huang, Ying
2008-03-12 19:37 ` Vivek Goyal
2008-03-14 8:03 ` Huang, Ying
2008-03-21 19:12 ` Vivek Goyal
2008-03-25 7:25 ` Huang, Ying
2008-03-12 19:47 ` Vivek Goyal
2008-04-09 9:34 ` Pavel Machek
2008-04-09 12:30 ` Vivek Goyal
2008-05-14 16:03 ` Vivek Goyal
2008-05-14 17:49 ` Vivek Goyal
2008-05-14 20:52 ` Vivek Goyal
2008-05-15 2:32 ` Huang, Ying
2008-05-15 20:09 ` Vivek Goyal
2008-05-16 1:48 ` Huang, Ying
2008-05-16 1:51 ` Vivek Goyal
2008-05-16 2:08 ` Huang, Ying
2008-05-16 12:13 ` Pavel Machek
2008-05-15 5:41 ` Huang, Ying
2008-05-15 18:42 ` Eric W. Biederman
2008-05-16 0:51 ` Vivek Goyal
2008-05-16 1:35 ` Eric W. Biederman
2008-05-16 1:55 ` Huang, Ying
2008-05-27 7:27 ` Huang, Ying
2008-05-27 22:15 ` Vivek Goyal
2008-05-28 1:35 ` Huang, Ying
2008-05-14 22:30 ` Eric W. Biederman
2008-05-14 23:55 ` Rafael J. Wysocki
2008-05-15 22:03 ` Eric W. Biederman
2008-05-15 23:20 ` Rafael J. Wysocki
2008-05-16 12:18 ` Pavel Machek
2008-05-16 14:20 ` [linux-pm] " Alan Stern
2008-05-15 1:42 ` Huang, Ying [this message]
2008-05-15 19:05 ` Rafael J. Wysocki
2008-05-15 14:14 ` [linux-pm] " Alan Stern
2008-05-15 20:48 ` Eric W. Biederman
2008-05-15 21:07 ` Alan Stern
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=1210815739.23707.74.camel@caritas-dev.intel.com \
--to=ying.huang@intel.com \
--cc=akpm@linux-foundation.org \
--cc=ebiederm@xmission.com \
--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 \
--cc=rjw@sisk.pl \
--cc=vgoyal@redhat.com \
/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