From: david ahern <daahern@cisco.com>
To: Avi Kivity <avi@qumranet.com>
Cc: kvm-devel <kvm-devel@lists.sourceforge.net>
Subject: Re: tools to dump guest memory and generate core file
Date: Mon, 17 Mar 2008 17:36:06 -0600 [thread overview]
Message-ID: <47DF0066.1090602@cisco.com> (raw)
In-Reply-To: <47DE32EF.5090903@qumranet.com>
Attaching gdb to qemu you work with addresses as seen by the qemu process; the
idea is to work with addresses as seen inside the guest.
For example, in the qemu console you can examine guest kernel memory such as
task structs using guest kernel based addresses:
(qemu) x /128w 0xc0327a80
00000000c0327a80: 0x00000000 0xc039a000 0x00000002 0x00000000
00000000c0327a90: 0x00000000 0xffffffff 0x0000008c 0x00000078
00000000c0327aa0: 0xc0327aa0 0xc0327aa0 0x00000000 0x00000000
00000000c0327ab0: 0xffffff9b 0xdae71a00 0x003d098c 0xdae71a00
00000000c0327ac0: 0x003d098c 0x00000000 0x00000000 0xffffffff
...
where 0xc0327a80 is the address of the first task (init_task symbol). This form
is really painful to decipher much less follow the task list.
Now, if you attach gdb to the qemu process,
gdb /usr/local/bin/qemu-system-x86_64 2346
and run that same memory dump request you get:
(gdb) x /128w 0xc0327a80
0xc0327a80: Cannot access memory at address 0xc0327a80
because from qemu's perspective 0xc0327a80 is not a valid address.
Ideally it would be much more convenient to dump the guest memory based on its
view of addresses and then run crash. e.g.,
crash> foreach task
PID: 0 TASK: c0327a80 CPU: 0 COMMAND: "swapper"
struct task_struct {
state = 0,
thread_info = 0xc039a000,
usage = {
counter = 2
...
Does that make sense?
Such a tool would be really useful to figure out why for example a guest appears
to have locked up or why it is sucking up host cpu time.
david
Avi Kivity wrote:
> david ahern wrote:
>> Does anyone know of tools that can dump memory for a qemu guest with
>> addresses
>> as seen by the guest and generate a core file? For instance, say you
>> know the
>> guest is running a 32-bit linux kernel with a 1G/3G split. Then you
>> would want
>> to dump 1G of memory starting 0xc0000000 and create an ELF core file.
>> The core
>> file could then be analyzed using tools like crash (or gdb for the truly
>> adventurous).
>>
>> I know VMware can take a snapshot and generate such a core file. Does
>> a similar
>> tool exist for qemu? I see that the qemu console supports a raw memory
>> dump, so
>> it should be possible. (Note I am not talking about a core file of the
>> qemu
>> process, but rather a core file based on guest memory addressing.)
>>
>>
>
> You might try connecting with gdb and using the generate-core-file command.
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
next prev parent reply other threads:[~2008-03-17 23:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-17 3:02 tools to dump guest memory and generate core file david ahern
2008-03-17 8:59 ` Avi Kivity
2008-03-17 23:36 ` david ahern [this message]
2008-03-18 6:15 ` Avi Kivity
2008-03-18 9:30 ` Uri Lublin
2008-03-19 0:19 ` david ahern
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=47DF0066.1090602@cisco.com \
--to=daahern@cisco.com \
--cc=avi@qumranet.com \
--cc=kvm-devel@lists.sourceforge.net \
/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