qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kurz <gkurz@linux.vnet.ibm.com>
To: Jun Koi <junkoi2004@gmail.com>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] dump-guest-memory command?
Date: Fri, 16 May 2014 12:15:40 +0200	[thread overview]
Message-ID: <20140516121540.0e39c90d@bahia.local> (raw)
In-Reply-To: <CA+g7VZ3GpK494RaqhxfwCU+WqbG8RZ=UPG1FOA79BhtrSO7jow@mail.gmail.com>

On Fri, 16 May 2014 17:59:25 +0800
Jun Koi <junkoi2004@gmail.com> wrote:

> On Fri, May 16, 2014 at 5:51 PM, Greg Kurz <gkurz@linux.vnet.ibm.com> wrote:
> 
> > On Fri, 16 May 2014 16:40:23 +0800
> > Jun Koi <junkoi2004@gmail.com> wrote:
> > > On Fri, May 16, 2014 at 3:03 PM, Greg Kurz <gkurz@linux.vnet.ibm.com>
> > wrote:
> > >
> > > > On Fri, 16 May 2014 14:24:16 +0800
> > > > Jun Koi <junkoi2004@gmail.com> wrote:
> > > > > Hi,
> > > > >
> > > > > Anybody please help me on this dump-guest-memory command? How does
> > the
> > > > > virtual memory map to the dumped file?
> > > > >
> > > > > For example, if x86 register RIP points to 0x12345, how does that
> > map to
> > > > > the dump file? Meaning how can I find where this address 0x12345 in
> > the
> > > > > dump?
> > > > >
> > > > > I tried, but couldnt find much documentation on this command.
> > > > >
> > > > > Thank you a lot,
> > > > > Jun
> > > >
> > > > Hi Jun,
> > > >
> > > > The dump file is in ELF format and data is written in ELF notes.
> > > > Use readelf -a on the file and you'll get something like the
> > > > following at the end of the output:
> > > >
> > > > ...
> > > >
> > > > Notes at offset 0x000001c8 with length 0x00000328:
> > > >   Owner                 Data size       Description
> > > >   CORE                 0x00000150       NT_PRSTATUS (prstatus
> > structure)
> > > >   QEMU                 0x000001b0       Unknown note type: (0x00000000)
> > > >
> > > > The registers sit in the NT_PRSTATUS note (hence somewhere offset
> > > > 0x000001c8 and 0x000001c8+0x00000150+0x14 (the latter is the ELF note
> > > > header size). Be aware that intel is little endian: if RIP is
> > 0x00012345,
> > > > you need to look for '45 23 01 00' in the file.
> > > >
> > > >
> > > Thanks so much, but perhaps you misunderstood my question? What I want to
> > > know is how to map 0x12345 (virtual address) back to the dump file.
> > >
> >
> > Heh... sorry for that, morning isn't the best time to answer questions I
> > guess ;)
> >
> > > For example, if 0x12345 was executing some filesystem code at the time I
> > > dumped the VM, then I can locate exactly that code in the dumpfile,
> > thanks
> > > to the given RIP address (which is 0x12345 in this example)
> > >
> > > I hope I explain my idea clear enough this time?
> > >
> >
> > Yeah. Maybe the crash utility (http://people.redhat.com/anderson) can
> > help.
> >
> >
> but my VM is not Linux, so is this tool helpful?
> 
> some questions:
> 
> - is it true that dump-guest-memory just write down physical memory page,
> and does not consider the virtual-memory concept?
> 
> - if above is true, how can i translate virtual address to physical
> address? (since only after that i can map my virtual address to its
> position in the dumpfile)
> 
> thanks!
> Jun
> 

from dump.c:

static int write_elf64_load(DumpState *s, MemoryMapping *memory_mapping,
                            int phdr_index, hwaddr offset,
                            hwaddr filesz)
{
    Elf64_Phdr phdr;
    int ret;
    int endian = s->dump_info.d_endian;

    memset(&phdr, 0, sizeof(Elf64_Phdr));
    phdr.p_type = cpu_convert_to_target32(PT_LOAD, endian);
    phdr.p_offset = cpu_convert_to_target64(offset, endian);
    phdr.p_paddr = cpu_convert_to_target64(memory_mapping->phys_addr, endian);
    phdr.p_filesz = cpu_convert_to_target64(filesz, endian);
    phdr.p_memsz = cpu_convert_to_target64(memory_mapping->length, endian);
    phdr.p_vaddr = cpu_convert_to_target64(memory_mapping->virt_addr, endian);

It looks like the information is part of the ELF program header.

Cheers.

-- 
Gregory Kurz                                     kurzgreg@fr.ibm.com
                                                 gkurz@linux.vnet.ibm.com
Software Engineer @ IBM/Meiosys                  http://www.ibm.com
Tel +33 (0)562 165 496

"Anarchy is about taking complete responsibility for yourself."
        Alan Moore.

  reply	other threads:[~2014-05-16 10:16 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-16  6:24 [Qemu-devel] dump-guest-memory command? Jun Koi
2014-05-16  7:03 ` Greg Kurz
2014-05-16  8:40   ` Jun Koi
2014-05-16  8:45     ` Andreas Färber
2014-05-16  8:51       ` Jun Koi
2014-05-16 10:00         ` Greg Kurz
2014-05-16  9:51     ` Greg Kurz
2014-05-16  9:59       ` Jun Koi
2014-05-16 10:15         ` Greg Kurz [this message]
2014-05-16 11:30         ` Laszlo Ersek
2014-05-16 13:01           ` Jun Koi
2014-05-16 15:38             ` Laszlo Ersek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140516121540.0e39c90d@bahia.local \
    --to=gkurz@linux.vnet.ibm.com \
    --cc=junkoi2004@gmail.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).