ahhh I see, so /tmp/MEM@0 appears in host right ? where I can find guest image mapped
there.so you are debugging whole image from your host. is my understanding correct ?
Regards,Oza.
On Saturday, 30 April 2016, 21:29, Oleg Nesterov <oleg(a)redhat.com> wrote:
Hi Paawan,
On 04/30, paawan oza wrote:
right now ramdump.c just addresses ARM since we work on ARM arch.
All we (this series) need from ramdump.c is read_ramdump() which is arch-agnostic.
And just in case, we do not really change this file.
if we have to support x86/_64, headers need to be dealt differently.
see above, this series doesn't use/need the header.
Just was curious, what kind of addition your patch is bringing
? Broadcom brought th
support for raw ramdump, well you know justpreparing ELF header and sparse support.
so just wanted to understand how what you patch does, it addresses live dump ?
could you elaborate on it ?
The changelog in 10/10 says:
Now I can run qemu with the memory-backend-file option and use /usr/bin/crash
in "live" mode using the file(s) specified by mem-path argument as a RAM
dump.
For example,
$ qemu-kmv ...other-options... \
-object memory-backend-file,id=MEM,size=128m,mem-path=/tmp/MEM,share=on \
-numa node,memdev=MEM -m 128
and
$ crash path-to-guests-vmlinux live:/tmp/MEM@0
that is. You can use /bin/crash do debug the kernel in "live" mode in case when
MEMORY-IMAGE[@ADDRESS] files are mmaped directly to guest's physical memory.
Oleg.