Re: [Crash-utility] PATCH 00/10] teach crash to work with "live" ramdump
----- Original Message -----
On 04/27, Dave Anderson wrote:
>
> > > OK, so we're running on a host machine that has one of these memory
files
> > > that is accessible as a regular file.
> >
> > Yes, and this file is the physical memory of the guest. So it is essentially
> > the RAM dump which can be used by "crash PATH-TO-THIS-FILE@0" right
now without
> > any patches. And in this particular case the offset is always zero.
> >
> > But not on x86-64, is_ramdump() insists on ramdump_to_elf() even if we could
> > use read_ramdump(), and ramdump_to_elf() doesn't support x86-64.
>
> Right, but that's a trivial fix, right? As I mentiond before, the only reason
> it doesn't support is because nobody's tried/asked/needed-to.
Probably yes, I simply do not know. I know nothing about elf magic.
It should simply be a matter of setting e_machine to EM_X86_64 in ramdump_to_elf(),
and letting alloc_elf_header() do the rest.
> And with x86_64 support put into place, at least the "non-live" file
should be a considered
> a ramdump, right?
Sure. But again, we do not even need to update ramdump_to_elf() and create
the elf header, read_ramdump() can work just fine. This is what 09/10 does.
Right, I understand. But it would be preferable if "-o dumpfile" could still be
used
for use with the "non-live" file.
> > And of course, you can't use this RAM dump in "live" mode
(without these
> > changes).
>
> Right -- that's the rub here. The "live version of a dumpfile" is a
hybrid that's
> never been considered before.
Yes, so 10/10 is just a one-liner. But it depends on 1-7. Say, without 02/10
memory_source_init() fails. Without 04/10 /bin/crash segfaults.
Right, but there should be no need for the "raw" distinction given that the
"non-live" dumpfile is really just a "regular" ramdump, for lack of a
better
term (and with x86_64 support added).
And yes, the 1-7 qualifiers (and probably a few others) are always going to be
necessary for the "live-dump-hybrid".
So, getting back to our original discussions, the handling of this hybrid-live
dumpfile is the main issue. I don't like the re-use of unrelated definitions
like MEMSRC_LOCAL, which was used back in the remote-access days if the vmlinux
file was available on a remote machine but the dumpfile had been copied to the
host machine running crash. But I still don't know what to call it so that it
makes sense. And BTW, give that the live-dump-hybrid will still require a new
dumpfile-type #define that can be plugged into the pc->flags MEMORY_SOURCES bitmask,
I see now that the MEMSRC_LOCAL would be a great candidate to move from pc->flags
to pc->flags2.
Dave