Re: [Crash-utility] PATCH 00/10] teach crash to work with "live" ramdump
On 04/26, Dave Anderson wrote:
> But let me also say that there is nothing qemu-specific in this series. Except
> it happens to work with the recent memory-backend-file qemu option.
>
> I mean, you can just do
>
> $ dd if=/dev/crash of=RAMDUMP count=...
>
> and then
>
> $ crash path-to-your-vmlinux raw:RAMDUMP@0
>
> or even just
>
> $ crash path-to-your-vmlinux live:/dev/crash@0
>
> and this should work. Not that I think this makes sense, but should work.
>
> 9/10 and 10/10 just add the "raw:" and "live:" options. The 1st
one means
> that crash should avoid avoid ramdump_to_elf()/read_kdump() and just use
> read_ramdump() to access this RAM dump. The 2nd one naturally tells that
> this memory is alive.
I'm getting somewhat confused now. I was under the impression that this QEMU/KVM
concept for live systems only.
No,
If you create a ramdump file that fits within the
constraints of the ramdump.c functionality -- essentially creating a "ramdump
clone",
then yes, I guess I can understand why you would want to use ramdump.c.
Yes. And to remind, MEMORY-IMAGE@ADDRESS (which is even documented in crash.8 as
"raw RAM dumpfile that has no header information") doesn't work on x86-64,
because
ramdump_to_elf() fails with "unsupported machine type".
So imo 08/10 (which is the trivial preparation) and 09/10 make sense anyway, this
doesn't need the previous LOCAL_ACTIVE patches.
Yes, let me repeat that 09/10 asks for cleanup (the change in main.c). This is
because I fail to understand this "if (is_ramdump())" block in main(), it looks
simply wrong to me, but this is off-topic right now.
And can refactor these changes so that ramdump.c won't be changed at all, we can
move these simple changes to the caller.
(as long
as it doesn't break compatibility with the aims of the embedded folks who wrote it
and use it).
It shouldn't. As long they do not try to use a RAMDUMP file which name starts with
"raw:" or "live:" prefix.
If we're *just* talking about supporting live system access of a
QEMU/KVM guest,
then it should have nothing to do with ramdump.c.
See above. But as for "live" ramdump's I do not see another use-case except
qemu
running with memory-backend-file.
But note that this feature comes in 10/10 which is essentially on-liner! We only
need to set "pc->flags |= LIVE_SYSTEM", but this change depends on the
previous
LOCAL_ACTIVE changes. Because again, currently crash can not work correctly with
remote live kernels.
Oleg.