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@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.