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

[Dave Anderson]

----- Original Message -----
> On 04/26, Dave Anderson wrote:
> >
> > > 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.
> 
> I see. What I can't understand is why (2) sets KDUMP but switches to 
> pc->readmem = read_ramdump() instead of read_kdump(), even if it creates the
> same elf vmcore.

I didn't write this code, but here's how I understand it.

(1) If the crash command line contains a memory at address reference, then it's describing
    a ramdump, and it calls ramdump_to_elf() to create an ELF header.  

(2) If "-o dumpfile" had also been specified, then it creates a new ELF vmcore file.  

(3) If "-o" was not used, then it creates a temporary in-memory ELF header.

(4) It then calls is_kdump() to verify that the ELF header was created correctly, and 
    sets KDUMP because it needs to set at least one of the bits in MEMORY_SOURCES.

(5) If it's just using the temporary ELF header, it uses read_ramdump().

(6) If it created a new ELF kdump clone vmcore, it uses read_kdump(). 

As far as (5) and (6) go, certainly read_ramdump() is far more efficient than
using read_kdump() in the temporary ELF header case.  As for using read_kdump()
with the newly-created kdump clone, perhaps they wanted to make absolutely
sure that it would work in the future if/when they re-use the vmcore as if it
were a real kdump vmcore, i.e., entering "crash vmlinux vmcore"?  Or it could
be because the "-o clone" option was added after the initial ramdump supporting
only the temporary header was put in place?  Honestly, I'm not sure.

> 
> > > > 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...
> 
> Me too ;)
> 
> > 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?
> 
> OK. So I am running the rhel7 guest on my Fedora machine and I pass the following
> (additional) options to qemu:
> 
> 	-object memory-backend-file,id=MEM,size=128m,mem-path=/tmp/MEM,share=on \
> 	-numa node,memdev=MEM \
> 		
> so in this (trivial) case /tmp/MEM represents the physical memory as it seen by
> the guest.

Exactly what is this /tmp/MEM that you speak of?

> 
> Now suppose that this guest crashes and qemu exits. In this case the "live" mode
> makes no sense, if nothing else it is slower.

I don't understand.  Does the /tmp/MEM file still exist somewhere after the guest
crashed?

> 
> So I can do
> 
> 	$ crash path-to-rhel7-vmlinux raw:/tmp/MEM at 0
> 
> on the host, and it works. Sure, not that useful. I could do dump-guest-memory
> from qemu before exiting and use the generated kvm dump.
> 
> "live" ramdump is a bit more interesting. I can do
> 
> 	$ crash path-to-rhel7-vmlinux live:/tmp/MEM at 0

Again, I am clueless as to what /tmp/MEM consists of on the guest.  How does it
get there to begin with?  Is is a pseudo-file that constantly contains the
current contents of the guest's physical memory?  Is it like /dev/mem?

Dave