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

[Oleg Nesterov]

On 04/25, Dave Anderson wrote:
>
> I see that your overloading the ramdump.c file, but the ramdump facility was
> proposed and added by companies that use a firmware-based facility for dumping
> raw ARM/ARM64/MIPS RAM into one or more ramdump files, typically because they
> do/did not have kdump capability with their embedded hardware.  I really don't
> feel comfortable conflating that facility with a remote/live QEMU/KVM memory
> source.

It's a pity ;) But this is minor.

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.


> Those companies support it, and so any changes that you've added to
> ramdump.c should be accomplished elsewhere.

OK, we can add the new (say) --rawdump/livedump options and avoid any
changes in ramdump.c. Except probably 08/10 which can help to avoid
the code duplicating. But again, this is minor.

> Also, we don't want to get this confused in any way with the REMOTE_xxx
> stuff.

Yes. And this series tries to not mess with REMOTE logic. And this is why
I didn't try to define LOCAL_ACTIVE() as (say) !REMOTE_ACTIVE().

At the same time, it tries to re-introduce the ability to debug the remote
live kernels. And the QEMU/KVM memory source is just the example.

And that is why I think we need 1-7. More on this in another email.

> The remote.c file and remote access facility was deprecated many
> years ago, but recently resurrected in crash-7.0.4 by Verizon specifically
> for use like so:

OK, I see, thanks.

> Anyway, this is a great idea, and one I've pondered in the past, but is there a
> concrete reason that it could not be a simple matter of plugging in a new function
> into pc->readmem()?

Simply because read_ramdump() is already implemented and it does exactly we need.
And, say, "pc->flags2 |= RAMDUMP" makes sense too, display_sys_stats() will use
show_ramdump_files().

Sure, it would be simple to write another plugin. The main problem is that there
is no room in pc->flags and that is why this series abuses CRASHBUILTIN ;)

Oleg.