----- 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
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
