* [Qemu-devel] dump-guest-memory command?
@ 2014-05-16 6:24 Jun Koi
2014-05-16 7:03 ` Greg Kurz
0 siblings, 1 reply; 12+ messages in thread
From: Jun Koi @ 2014-05-16 6:24 UTC (permalink / raw)
To: qemu-devel@nongnu.org
[-- Attachment #1: Type: text/plain, Size: 352 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 484 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] dump-guest-memory command?
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
0 siblings, 1 reply; 12+ messages in thread
From: Greg Kurz @ 2014-05-16 7:03 UTC (permalink / raw)
To: Jun Koi; +Cc: qemu-devel@nongnu.org
[-- Attachment #1: Type: text/plain, Size: 1533 bytes --]
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.
The attached script may help to display the dump file content.
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.
[-- Attachment #2: elfnote --]
[-- Type: application/octet-stream, Size: 691 bytes --]
#!/bin/bash
usage() {
cat<<EOF>&2
USAGE: elfnote <corefile> <note pattern>
example: elfnote ./vmcore PRSTATUS will show PRSTATUS (registers)
EOF
exit 1
}
[[ -n "$1" ]] || usage
file="$1"
shift
[[ -n "$1" ]] || usage
pattern="$1"
shift
notes=( $(readelf -n $file | awk --non-decimal-data \
"/Notes at offset/ { offset = \$4 } \
/$pattern/ { print offset + 20 \":\" 0 + \$2 } \
/CORE|QEMU/ { offset += 20 + \$2 }"))
for note in "${notes[@]}"
do
offset=${note%:*}
size=${note#*:}
printf "offset: 0x%x size: 0x%x\n" $offset $size
echo "------------------------------------------------------"
od -A x -t x1 -j $offset -N $size $file
echo
done
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] dump-guest-memory command?
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 9:51 ` Greg Kurz
0 siblings, 2 replies; 12+ messages in thread
From: Jun Koi @ 2014-05-16 8:40 UTC (permalink / raw)
To: Greg Kurz; +Cc: qemu-devel@nongnu.org
[-- Attachment #1: Type: text/plain, Size: 1695 bytes --]
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.
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?
Thanks a lot,
Jun
[-- Attachment #2: Type: text/html, Size: 2402 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] dump-guest-memory command?
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 9:51 ` Greg Kurz
1 sibling, 1 reply; 12+ messages in thread
From: Andreas Färber @ 2014-05-16 8:45 UTC (permalink / raw)
To: Jun Koi; +Cc: qemu-devel@nongnu.org, Greg Kurz
Am 16.05.2014 10:40, schrieb Jun Koi:
> What I want
> to know is how to map 0x12345 (virtual address) back to the dump file.
>
> 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?
Using dump-guest-memory sounds more complicated than needed. You can
just use the monitor commands for disassembling that address or the
built-in gdb stub (-s).
Regards,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] dump-guest-memory command?
2014-05-16 8:45 ` Andreas Färber
@ 2014-05-16 8:51 ` Jun Koi
2014-05-16 10:00 ` Greg Kurz
0 siblings, 1 reply; 12+ messages in thread
From: Jun Koi @ 2014-05-16 8:51 UTC (permalink / raw)
To: Andreas Färber; +Cc: qemu-devel@nongnu.org, Greg Kurz
[-- Attachment #1: Type: text/plain, Size: 1039 bytes --]
On Fri, May 16, 2014 at 4:45 PM, Andreas Färber <afaerber@suse.de> wrote:
> Am 16.05.2014 10:40, schrieb Jun Koi:
> > What I want
> > to know is how to map 0x12345 (virtual address) back to the dump file.
> >
> > 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?
>
> Using dump-guest-memory sounds more complicated than needed.
No, this is important, since i can have a whole image to do offline
analysis.
> You can
> just use the monitor commands for disassembling that address
What is this command? I try "help" but cannot find any. Before I remember
we had "disas" or something like that, but I cannot find that again in
latest Qemu code.
> or the
> built-in gdb stub (-s).
>
>
Is this true that this only works for pure emulator, not for kvm-enable VM?
Thanks,
Jun
[-- Attachment #2: Type: text/html, Size: 1782 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] dump-guest-memory command?
2014-05-16 8:40 ` Jun Koi
2014-05-16 8:45 ` Andreas Färber
@ 2014-05-16 9:51 ` Greg Kurz
2014-05-16 9:59 ` Jun Koi
1 sibling, 1 reply; 12+ messages in thread
From: Greg Kurz @ 2014-05-16 9:51 UTC (permalink / raw)
To: Jun Koi; +Cc: qemu-devel@nongnu.org
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.
> Thanks a lot,
> Jun
--
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] dump-guest-memory command?
2014-05-16 9:51 ` Greg Kurz
@ 2014-05-16 9:59 ` Jun Koi
2014-05-16 10:15 ` Greg Kurz
2014-05-16 11:30 ` Laszlo Ersek
0 siblings, 2 replies; 12+ messages in thread
From: Jun Koi @ 2014-05-16 9:59 UTC (permalink / raw)
To: Greg Kurz; +Cc: qemu-devel@nongnu.org
[-- Attachment #1: Type: text/plain, Size: 2915 bytes --]
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
>
> --
> 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.
>
>
[-- Attachment #2: Type: text/html, Size: 4605 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] dump-guest-memory command?
2014-05-16 8:51 ` Jun Koi
@ 2014-05-16 10:00 ` Greg Kurz
0 siblings, 0 replies; 12+ messages in thread
From: Greg Kurz @ 2014-05-16 10:00 UTC (permalink / raw)
To: Jun Koi; +Cc: Andreas Färber, qemu-devel@nongnu.org
On Fri, 16 May 2014 16:51:36 +0800
Jun Koi <junkoi2004@gmail.com> wrote:
> On Fri, May 16, 2014 at 4:45 PM, Andreas Färber <afaerber@suse.de> wrote:
>
> > Am 16.05.2014 10:40, schrieb Jun Koi:
> > > What I want
> > > to know is how to map 0x12345 (virtual address) back to the dump file.
> > >
> > > 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?
> >
> > Using dump-guest-memory sounds more complicated than needed.
>
>
> No, this is important, since i can have a whole image to do offline
> analysis.
>
>
> > You can
> > just use the monitor commands for disassembling that address
>
>
> What is this command? I try "help" but cannot find any. Before I remember
> we had "disas" or something like that, but I cannot find that again in
> latest Qemu code.
>
It is the 'x' command.
(qemu) x/i $pc
>
> > or the
> > built-in gdb stub (-s).
> >
> >
> Is this true that this only works for pure emulator, not for kvm-enable VM?
>
Dunno the status for intel targets... give it a try ! ;)
> Thanks,
> Jun
--
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] dump-guest-memory command?
2014-05-16 9:59 ` Jun Koi
@ 2014-05-16 10:15 ` Greg Kurz
2014-05-16 11:30 ` Laszlo Ersek
1 sibling, 0 replies; 12+ messages in thread
From: Greg Kurz @ 2014-05-16 10:15 UTC (permalink / raw)
To: Jun Koi; +Cc: qemu-devel@nongnu.org
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] dump-guest-memory command?
2014-05-16 9:59 ` Jun Koi
2014-05-16 10:15 ` Greg Kurz
@ 2014-05-16 11:30 ` Laszlo Ersek
2014-05-16 13:01 ` Jun Koi
1 sibling, 1 reply; 12+ messages in thread
From: Laszlo Ersek @ 2014-05-16 11:30 UTC (permalink / raw)
To: Jun Koi, Greg Kurz; +Cc: qemu-devel@nongnu.org
On 05/16/14 11:59, Jun Koi wrote:
> - is it true that dump-guest-memory just write down physical memory
> page, and does not consider the virtual-memory concept?
No, it isn't.
Basically, "dump-guest-memory" supports two modes of operation, "paging
enabled" and "paging disabled".
Many (most?) people dump for the "crash" utility, which is super smart,
and extra paging info is not needed. For "crash" we just dump the
guest-phys memory ranges the way the guest sees them, and that's it;
"crash" figures out everything from that.
If you want to use "gdb" rather than "crash", or need the guest-virtual
addresses in the ELF vmcore for some other reason, then you should
invoke "dump-guest-memory" with paging enabled.
Enter "help dump-guest-memory" at the qemu monitor prompt, and look for
the "-p" option.
Laszlo
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] dump-guest-memory command?
2014-05-16 11:30 ` Laszlo Ersek
@ 2014-05-16 13:01 ` Jun Koi
2014-05-16 15:38 ` Laszlo Ersek
0 siblings, 1 reply; 12+ messages in thread
From: Jun Koi @ 2014-05-16 13:01 UTC (permalink / raw)
To: Laszlo Ersek; +Cc: qemu-devel@nongnu.org, Greg Kurz
[-- Attachment #1: Type: text/plain, Size: 1023 bytes --]
On Fri, May 16, 2014 at 7:30 PM, Laszlo Ersek <lersek@redhat.com> wrote:
> On 05/16/14 11:59, Jun Koi wrote:
>
> > - is it true that dump-guest-memory just write down physical memory
> > page, and does not consider the virtual-memory concept?
>
> No, it isn't.
>
> Basically, "dump-guest-memory" supports two modes of operation, "paging
> enabled" and "paging disabled".
>
> Many (most?) people dump for the "crash" utility, which is super smart,
> and extra paging info is not needed. For "crash" we just dump the
> guest-phys memory ranges the way the guest sees them, and that's it;
> "crash" figures out everything from that.
>
> If you want to use "gdb" rather than "crash", or need the guest-virtual
> addresses in the ELF vmcore for some other reason, then you should
> invoke "dump-guest-memory" with paging enabled.
>
> Enter "help dump-guest-memory" at the qemu monitor prompt, and look for
> the "-p" option.
>
so i suppose this works for all kind of OS in guest VM, not only Linux
guest?
thanks so much,
Jun
[-- Attachment #2: Type: text/html, Size: 1571 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] dump-guest-memory command?
2014-05-16 13:01 ` Jun Koi
@ 2014-05-16 15:38 ` Laszlo Ersek
0 siblings, 0 replies; 12+ messages in thread
From: Laszlo Ersek @ 2014-05-16 15:38 UTC (permalink / raw)
To: Jun Koi; +Cc: qemu-devel@nongnu.org, Greg Kurz
On 05/16/14 15:01, Jun Koi wrote:
>
>
>
> On Fri, May 16, 2014 at 7:30 PM, Laszlo Ersek <lersek@redhat.com
> <mailto:lersek@redhat.com>> wrote:
>
> On 05/16/14 11:59, Jun Koi wrote:
>
> > - is it true that dump-guest-memory just write down physical memory
> > page, and does not consider the virtual-memory concept?
>
> No, it isn't.
>
> Basically, "dump-guest-memory" supports two modes of operation, "paging
> enabled" and "paging disabled".
>
> Many (most?) people dump for the "crash" utility, which is super smart,
> and extra paging info is not needed. For "crash" we just dump the
> guest-phys memory ranges the way the guest sees them, and that's it;
> "crash" figures out everything from that.
>
> If you want to use "gdb" rather than "crash", or need the guest-virtual
> addresses in the ELF vmcore for some other reason, then you should
> invoke "dump-guest-memory" with paging enabled.
>
> Enter "help dump-guest-memory" at the qemu monitor prompt, and look for
> the "-p" option.
>
>
> so i suppose this works for all kind of OS in guest VM, not only Linux
> guest?
far as I remember, it should; the virtual mappings "in effect" are
searched starting from cr3:
qmp_dump_guest_memory() [dump.c]
dump_init()
qemu_get_guest_memory_mapping() [memory_mapping.c]
for (almost) all VCPUs:
cpu_get_memory_mapping() [qom/cpu.c]
x86_cpu_get_memory_mapping()
[target-i386/arch_memory_mapping.c]
check cr3, cr4; walk page tables etc
There are some caveats / limitations: search "qapi-schema.json" for the
string "dump-guest-memory", and read that section.
Laszlo
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2014-05-16 15:38 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2014-05-16 11:30 ` Laszlo Ersek
2014-05-16 13:01 ` Jun Koi
2014-05-16 15:38 ` Laszlo Ersek
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).