12:38 p.m.
----- Original Message -----
On 04/26, Dave Anderson wrote:
>
> > Yes. And to remind, MEMORY-IMAGE@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@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@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@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