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

[Dave Anderson]

----- Original Message -----
> 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".

Correct.  It's only supported the architectures listed because they are the only
architectures used by the companies who wrote and support the facility.  If somebody
comes along and makes it work with x86_64, it can easily be added.  Nobody has.

> 
> 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.

Right, it is confusing.  There are two ways to utilize their ramdump files.
You can take the ramdump file and either:

(1) use the -o option to create a new vmcore containing an ELF header prepended to the
    ramdump file, and then access it like the kdump clone that it is.  At that point, 
    the original ramdump file can be deleted.
(2) create a temporary in-memory ELF header for accessing the ramdump during the
    crash session.

> 
> 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.

Sorry Oleg, but I'm afraid that I seem to be regressing...

I don't understand the difference between what you call a "raw" and a "live" ramdump?

Let's get back to basics.  Is is possible for the crash utility to simply issue readmem
requests for physical memory to whatever magic you've got running on the live guest,
and have it satisfy the request?  So that it would be essentially the same thing as
reading from /dev/mem, /proc/kcore or /dev/crash?

Or is there always going to have to be an actual dumpfile somewhere?

Dave