lkml.org 
[lkml]   [2008]   [May]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH -mm] kexec jump -v9
    Date
    On Thursday, 15 of May 2008, Huang, Ying wrote:
    > 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.

    Thanks, I'm also open for collaboration. There will be a lot of work to do
    related to the new callbacks, so any contribution is certainly welcome.

    Thanks,
    Rafael


    \
     
     \ /
      Last update: 2008-05-15 21:09    [W:4.109 / U:0.096 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site