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

[Dave Anderson]

----- Original Message -----
> On 04/26, Dave Anderson wrote:
> >
> >
> > ----- Original Message -----
> > > On 04/26, Dave Anderson wrote:
> > > >
> > > > > No, just a regular file, qemu creates it and does mmap(MAP_SHARED) on
> > > > > it.
> > > > >
> > > > > > that constantly contains the
> > > > > > current contents of the guest's physical memory?
> > > > >
> > > > > Yes,
> > > > >
> > > > > > Is it like /dev/mem?
> > > > >
> > > > > yes, but more like /dev/crash.
> > > > >
> > > > > Oleg.
> > > >
> > > > Unfortunately I am completely unfamiliar with qemu option
> > > > specifications.
> > >
> > > I too do not know much about qemu options,
> > >
> > > > So if I were to log into the guest machine, does a /tmp/MEM file exist?
> > >
> > > No,
> > >
> > > > Or does it exist on the host machine?
> > >
> > > Yes, it is just the normal file on the host which runs qemu.
> > >
> > > Well, "normal" is not neccessarily true in that you can use, for example,
> > >
> > > 	mem-path=/path/to/hugetlb-mount/...
> > >
> > > but this doesn't matter. It is still the "regular" file mmaped by qemu,
> > > the
> > > host can read it to acess the guest's physical memory.
> > >
> > > Oleg.
> >
> > 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 at 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.  And with x86_64
support put into place, at least the "non-live" file should be a considered
a ramdump, right? 
 
> 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.
 
> > So what's the remote access needed
> > for -- just to query for the particulars of the layout of the memory file?
> 
> Sorry, I don't understand...
> 
> Do you ask me what qemu does with this file or what?

This is where I totally got off on the wrong foot.  I thought you had mentioned
something about remote gdb protocol, or something along those lines where there
was some remote communication protocal?  I'm sorry about that, I really went off
into the weeds...

Dave