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.