----- 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
--
Crash-utility mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/crash-utility
