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

[Dave Anderson]

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

I'm getting somewhat confused now.  I was under the impression that this QEMU/KVM
concept for live systems only.  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.  (as long
as it doesn't break compatibility with the aims of the embedded folks who wrote it
and use it).

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.  Even if there is duplication
of effort, please keep any initialization functions, its pc->readmem plugin,
and so on in its own separate file.
 
> 
> > 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 ;)
 
That's not a problem -- see subsequent email.

Dave