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

[Oleg Nesterov]

On 04/26, Dave Anderson wrote:
>
> I didn't write this code, but here's how I understand it.

Thanks Dave, I'll read your explanation tomorrow, I need to run away again.

> > 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?

please note the "mem-path=/tmp/MEM" in the memory-backend-file arg above.

With this option qemu doesn't use the anonymous/private mapping for the guest's
physical memory it creates a file (specified by mem-path=). The host can read
(and write of course) to this file. This file _is_ the guest's physical memory.

Just in case, you pass multiple memory-backend-file/numa arguments, so you will
have the "multi-file" ramdump.

> > 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?

Yes,

>
> > "live" ramdump is a bit more interesting. I can do
> >
> > 	$ crash path-to-rhel7-vmlinux live:/tmp/MEM at 0
>
> Again, I am clueless as to what /tmp/MEM consists of on the guest.

See above,

> Is is a pseudo-file

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.