[lkml]   [2008]   [Mar]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH -mm] kexec jump -v9
    On Tue, 2008-03-11 at 20:17 -0600, Eric W. Biederman wrote:
    > "Huang, Ying" <> writes:
    > > Yes. The entry point should be saved in dump.elf itself, this can be
    > > done via a user-space tool such as "makedumpfile". Because
    > > "makedumpfile" is also used to exclude free pages from disk image, it
    > > needs a communication method between two kernels (to get backup pages
    > > map or something like that from kernel A). We have talked about this
    > > before.
    > >
    > > - Your opinion is to communicate via the purgatory. (But I don't know
    > > how to communicate between kernel A and purgatory).
    > How about the return address on the stack?
    > > - Eric's opinion is to communicate between the user space in kernel A
    > > and user space in kernel B.
    > Purgatory is for all intents and purposes user space. Because the
    > return address falls on the trampoline page we won't know it's
    > address before we call kexec. But a return address and a stack
    > on that page should be a perfectly good way to communicate.
    > > - My opinion is to communicate between two kernel directly.
    > >
    > > I think as a minimal infrastructure patch, we can communicate minimal
    > > information between user space of two kernels. When we have consensus on
    > > this topic, we can use makedumpfile for both excluding free pages and
    > > saving the entry point. Now, we can save the entry point in a separate
    > > file or I can write a simple tool to do this.
    > We need a fixed protocol so we do not make assumptions about how things
    > will be implemented, allowing kernels to diverge and kinds of other
    > good things.
    > For communicating extra information from the kernel being shut down
    > we have elf notes.
    > Direct kernel to kernel communication is forbidden. We must have
    > a well defined protocol. Allowing the implementations to change
    > at their different speeds, and still work together.

    This sounds reasonable. But after some initial trying I found it is
    fairly difficult for me to define a communication protocol to be back
    compatible with original kexec/kdump, doing work in user space as far as
    possible, dealing with some special scenario (such as: A kexec B, then B
    kexec C). So I will try my best to work on this, and propose a
    communication protocol combining the proposals from you and Vivek in
    several days.

    > >> May be we can have a separate load flag (--load-resume-image) to mark
    > >> that we are resuming an hibernated image and kexec does not have to
    > >> prepare commandline, does not have to prepare zero page/setup page etc.
    > >
    > > There is already similar flag in original kexec-tools implementation:
    > > "--args-none". If it is specified, kexec-tools does not prepare command
    > > line and zero page/setup page etc. I think we can just re-use this flag.
    > > And If it is desired an alias is good for me too.
    > My gut feel is we look at the image and detect what kind it is, and simply
    > not enable image processing after we have read the note that says it
    > is a resumable core or whatever.

    Yes. This sounds good.

    Best Regards,
    Huang Ying

     \ /
      Last update: 2008-03-12 07:55    [W:0.030 / U:5.604 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site