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
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm
