[lkml]   [2011]   [Jul]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch 0/9] kdump: Patch series for s390 support
    Hello Vivek,

    On Wed, 2011-07-20 at 15:25 -0400, Vivek Goyal wrote:
    > On Mon, Jul 18, 2011 at 08:03:08PM +0200, Michael Holzheu wrote:


    > > What you as kdump framework maintainer would have to accept with this
    > > solution is that it is allowed now to start kdump directly via purgatory
    > > without using code from the old kernel (e.g. crash_kexec). This has as
    > > implication that all things that the old kernel has to initialize for
    > > kdump has to be done before the system crashes. Currently this is only
    > > the initialization of vmcoreinfo.
    > Hi Michael,
    > Instead of introdcuing a new entry point for second kernel, why not
    > jump to crash_kexec() from stand alone tools? That should be functionally
    > equivalent to what you described above without any need to pass the
    > purgatory details to stand alone tools.

    That has the drawback that we still execute unchecked code from the
    crashed kernel. But ...

    ... I discussed that with Martin and we had an idea how to deal with
    this problem. On s390 when an invalid opcode is executed or invalid
    parameters are used, we get a program check interrupt. When the
    crash_kexec() code path or data is corrupted, it is almost sure that we
    get a program check. The stand-alone dump tools could establish a
    program check interrupt handler that jumps back to the dump tools code
    and then create full-blown dump.

    So I think with this mechanism we could use an entry point (name it
    s390_kdump_entry) in the old kernel that calls crash_kexec().

    We would change the purgatory code that for s390 it returns to the
    caller, if the checksum test fails. This *requires* that
    s390_kdump_entry()->crash_kexec()->machine_kexec() is allowed to return.
    Currently this is the case.

    > Only thing which needs to be figured out is how to pass the address of
    > crash_kexec() to stand alone tools and set registers/parameters
    > appropriately.

    We could do this s390 specific (e.g. using meminfo). In this case this
    would only be used for kernel/dump tools communication and not for
    kernel/kernel communication. So I hope this should not be a problem for

    Then the design would look like the following:
    * Define s390_kdump_entry in old kernel that calls crash_kexec()
    * Use preallocated ELF core header
    * s390_kdump_entry code path stores registers to ELF notes, ...
    * ... and finally jumps to purgatory code
    * For s390 the purgatory code returns to caller in case of
    checksum failure
    * dump tools call s390_kdump_entry with program check handler
    for error handling

    I think, if we do it that way, we do not affect the current kdump
    framework at all.

    Is that acceptable for you? If yes, I would rework my patches


     \ /
      Last update: 2011-07-21 17:01    [W:2.244 / U:0.000 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site