Re: [Crash-utility] PATCH 00/10] teach crash to work with "live" ramdump
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@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.