Messages in this thread | | | Subject | Re: [patch 0/9] kdump: Patch series for s390 support | From | Michael Holzheu <> | Date | Thu, 21 Jul 2011 16:58:18 +0200 |
| |
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:
[snip]
> > 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 you.
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 accordingly.
Michael
| |