[Crash-utility] PATCH 00/10] teach crash to work with "live" ramdump

[Oleg Nesterov]

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 at 0
> >
> > or even just
> >
> > 	$ crash path-to-your-vmlinux live:/dev/crash at 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 at 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.