dump memory when host pci device is used by guest

RFC Superseded Wen Congyang 4 participants 7 messages Nov 16, 2011 – Nov 29, 2011 Kbuild

lore

Share & tools

lore

Wen Congyang

author

2011-11-16 08:26 UTC #0 lore raw

RFC 1/1 dump memory when host pci device is used by guest

Hi, all

'virsh dump' can not work when host pci device is used by guest. We have discussed this issue here:
http://lists.nongnu.org/archive/html/qemu-devel/2011-10/msg00736.html

We have determined to introduce a new command dump to dump memory. The core file's format can be elf.

I created a kdump-elf vmcore, and found that it can be used by both crash and gdb:

# gdb /usr/lib/debug/lib/modules/2.6.32-71.el6.x86_64/vmlinux /work/core/vmcore
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-48.el6)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/lib/debug/lib/modules/2.6.32-71.el6.x86_64/vmlinux...done.
[New Thread 1691]
[New <main task>]
#0  sysrq_handle_crash (key=99, tty=0x0) at drivers/char/sysrq.c:130
130	drivers/char/sysrq.c: No such file or directory.
	in drivers/char/sysrq.c
(gdb) bt
#0  sysrq_handle_crash (key=99, tty=0x0) at drivers/char/sysrq.c:130
#1  0xffffffff8130d822 in __handle_sysrq (key=99, tty=0x0, check_mask=<value optimized out>) at drivers/char/sysrq.c:521
#2  0xffffffff8130d8de in write_sysrq_trigger (file=<value optimized out>, buf=<value optimized out>, count=2, ppos=<value optimized out>) at drivers/char/sysrq.c:599
#3  0xffffffff811cf31e in proc_reg_write (file=<value optimized out>, buf=0x7fdabafea000 <Address 0x7fdabafea000 out of bounds>, count=2, ppos=<value optimized out>)
    at fs/proc/inode.c:207
#4  0xffffffff8116c818 in vfs_write (file=0xffff88003c7bb740, buf=0x7fdabafea000 <Address 0x7fdabafea000 out of bounds>, count=<value optimized out>, pos=0xffff88003767ff48)
    at fs/read_write.c:347
#5  0xffffffff8116d251 in sys_write (fd=<value optimized out>, buf=0x7fdabafea000 <Address 0x7fdabafea000 out of bounds>, count=2) at fs/read_write.c:399
#6  0xffffffff81013172 in ?? () at arch/x86/kernel/entry_64.S:487
#7  0x0000000000000246 in ?? ()
#8  0x00000000ffffffff in ?? ()
#9  0x00007fdabafde700 in ?? ()
#10 0x000000000000000a in ?? ()
#11 0x0000000000000001 in ?? ()
#12 0x0000000000000002 in ?? ()
#13 0x0000000000000001 in ?? ()
#14 0x00000030f80d4230 in ?? ()
#15 0x0000000000000033 in ?? ()
#16 0x0000000000010206 in ?? ()
#17 0x00007fff8a126470 in ?? ()
#18 0x000000000000002b in ?? ()
#19 0xffff8800374f5000 in ?? ()
#20 0xffff88003c6f9000 in ?? ()
#21 0x0000000000000080 in ?? ()
#22 0xffff880037680080 in ?? ()
#23 0xffffffff00000014 in ?? ()
#24 0x0000000000000000 in ?? ()
(gdb) q
# crash -s /usr/lib/debug/lib/modules/2.6.32-71.el6.x86_64/vmlinux /work/core/vmcore 
crash> bt
PID: 1691   TASK: ffff88003711d520  CPU: 0   COMMAND: "bash"
 #0 [ffff88003767fae0] machine_kexec at ffffffff8103695b
 #1 [ffff88003767fb40] crash_kexec at ffffffff810b8f08
 #2 [ffff88003767fc10] oops_end at ffffffff814cbbd0
 #3 [ffff88003767fc40] no_context at ffffffff8104651b
 #4 [ffff88003767fc90] __bad_area_nosemaphore at ffffffff810467a5
 #5 [ffff88003767fce0] bad_area at ffffffff810468ce
 #6 [ffff88003767fd10] do_page_fault at ffffffff814cd740
 #7 [ffff88003767fd60] page_fault at ffffffff814caf45
    [exception RIP: sysrq_handle_crash+22]
    RIP: ffffffff8130d566  RSP: ffff88003767fe18  RFLAGS: 00010096
    RAX: 0000000000000010  RBX: 0000000000000063  RCX: 0000000000000000
    RDX: 0000000000000000  RSI: 0000000000000000  RDI: 0000000000000063
    RBP: ffff88003767fe18   R8: 0000000000000000   R9: ffffffff815106c0
    R10: 0000000000000001  R11: 0000000000000000  R12: 0000000000000000
    R13: ffffffff8179e6c0  R14: 0000000000000286  R15: 0000000000000007
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
 #8 [ffff88003767fe20] __handle_sysrq at ffffffff8130d822
 #9 [ffff88003767fe70] write_sysrq_trigger at ffffffff8130d8de
#10 [ffff88003767fea0] proc_reg_write at ffffffff811cf31e
#11 [ffff88003767fef0] vfs_write at ffffffff8116c818
#12 [ffff88003767ff30] sys_write at ffffffff8116d251
#13 [ffff88003767ff80] system_call_fastpath at ffffffff81013172
    RIP: 00000030f80d4230  RSP: 00007fff8a126470  RFLAGS: 00010206
    RAX: 0000000000000001  RBX: ffffffff81013172  RCX: 0000000000000400
    RDX: 0000000000000002  RSI: 00007fdabafea000  RDI: 0000000000000001
    RBP: 00007fdabafea000   R8: 000000000000000a   R9: 00007fdabafde700
    R10: 00000000ffffffff  R11: 0000000000000246  R12: 0000000000000002
    R13: 00000030f8379780  R14: 0000000000000002  R15: 00000030f8379780
    ORIG_RAX: 0000000000000001  CS: 0033  SS: 002b
crash>

I wrote a sample(not finished). It only can works on x86_64(both host and guest) I use it to create a core file:

# readelf -h /tmp/vm2.save 
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              CORE (Core file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          64 (bytes into file)
  Start of section headers:          0 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         9
  Size of section headers:           0 (bytes)
  Number of section headers:         0
  Section header string table index: 0
# readelf -l /tmp/vm2.save

Elf file type is CORE (Core file)
Entry point 0x0
There are 9 program headers, starting at offset 64

Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
NOTE 0x0000000000000238 0x0000000000000000 0x0000000000000000

                 0x00000000000002c8 0x00000000000002c8         0
  LOAD           0x0000000000000500 0xffffffff81000000 0x0000000001000000
                 0x000000001f000000 0x000000001f000000         0
  LOAD           0x000000001f000500 0x0000000000000000 0x0000000000000000
                 0x0000000001000000 0x0000000001000000         0
  LOAD           0x0000000020000500 0x0000000000000000 0x0000000020000000
                 0x0000000000020000 0x0000000000020000         0
  LOAD           0x0000000020020500 0x0000000000000000 0x0000000020870000
                 0x0000000000010000 0x0000000000010000         0
  LOAD           0x0000000020030500 0x0000000000000000 0x0000000020850000
                 0x0000000000020000 0x0000000000020000         0
  LOAD           0x0000000020050500 0x0000000000000000 0x0000000020840000
                 0x0000000000010000 0x0000000000010000         0
  LOAD           0x0000000020060500 0x0000000000000000 0x0000000020040000
                 0x0000000000800000 0x0000000000800000         0
  LOAD           0x0000000020860500 0x0000000000000000 0x0000000020020000
                 0x0000000000020000 0x0000000000020000         0

I can use crash to anaylze the file, but I can not use gdb to anaylze it.

# gdb /usr/lib/debug/lib/modules/2.6.32-71.el6.x86_64/vmlinux /tmp/vm2.save 
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-48.el6)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/lib/debug/lib/modules/2.6.32-71.el6.x86_64/vmlinux...done.
[New <main task>]
[New <main task>]
#0  0x8103be8b00000000 in ?? ()
(gdb) bt
#0  0x8103be8b00000000 in ?? ()
Cannot access memory at address 0x8170dec800000000
(gdb) q

My first and the most important question is that: Is there necessary to continue this work?

The attachment is the sample patch.

Thanks
Wen Congyang

Quoted 1 line

From bdb3daaeb2743a14df2cab364622e2f47ae25093 Mon Sep 17 00:00:00 2001

From: Wen Congyang <[email protected]>
Date: Wed, 16 Nov 2011 16:06:10 +0800
Subject: [PATCH] dump sample

---
 Makefile.target |    1 +
 dump.c          |  377 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 dump.h          |    1 +
 hmp-commands.hx |   16 +++
 monitor.c       |    3 +
 qmp-commands.hx |   24 ++++
 6 files changed, 422 insertions(+), 0 deletions(-)
 create mode 100644 dump.c
 create mode 100644 dump.h

Makefile.target +1 -0

index a111521..95d48a5 100644
@@ -84,6 +84,7 @@ libobj-y += cpu_init.o
 endif
 libobj-$(TARGET_SPARC) += int32_helper.o
 libobj-$(TARGET_SPARC64) += int64_helper.o
+libobj-y += dump.o
 
 libobj-y += disas.o
 libobj-$(CONFIG_TCI_DIS) += tci-dis.o

dump.c new file +377 -0

377 lines not on this page · raw message

dump.h new file +1 -0

new file mode 100644
index 0000000..b5d9eb4
@@ -0,0 +1 @@
+int do_dump(Monitor *mon, const QDict *qdict, QObject **ret_data);

hmp-commands.hx +16 -0

index 089c1ac..ebbce8c 100644
@@ -772,6 +772,22 @@ Migrate to @var{uri} (using -d to not wait for completion).
 ETEXI
 
     {
+        .name       = "dump",
+        .args_type  = "file:s",
+        .params     = "file",
+        .help       = "dump to file",
+        .user_print = monitor_user_noop,
+        .mhandler.cmd_new = do_dump,
+    },
+
+
+STEXI
+@item dump @var{file}
+@findex dump
+Dump to @var{file}.
+ETEXI
+
+    {
         .name       = "migrate_cancel",
         .args_type  = "",
         .params     = "",

monitor.c +3 -0

index 5ea35de..5df35e0 100644
@@ -73,6 +73,9 @@
 #endif
 #include "hw/lm32_pic.h"
 
+/* for dump */
+#include "dump.h"
+
 //#define DEBUG
 //#define DEBUG_COMPLETION

qmp-commands.hx +24 -0

index 97975a5..5cf21c5 100644
@@ -485,6 +485,30 @@ Notes:
 EQMP
 
     {
+        .name       = "dump",
+        .args_type  = "file:s",
+        .params     = "file",
+        .help       = "dump to file",
+        .user_print = monitor_user_noop,
+        .mhandler.cmd_new = do_dump,
+    },
+
+SQMP
+dump
+-------
+
+Dump to file.
+
+Arguments: None.
+
+Example:
+
+-> { "execute": "dump", "arguments": { "file": "fd:dump" } }
+<- { "return": {} }
+
+EQMP
+
+    {
         .name       = "migrate_cancel",
         .args_type  = "",
         .params     = "",

Signature · 1 line

1.7.1

Dave Anderson

2011-11-16 16:30 UTC #1 lore raw

----- Original Message -----

Quoted 181 lines

Hi, all

'virsh dump' can not work when host pci device is used by guest. We have discussed this issue here:
http://lists.nongnu.org/archive/html/qemu-devel/2011-10/msg00736.html

We have determined to introduce a new command dump to dump memory. The core file's format can be elf.

I created a kdump-elf vmcore, and found that it can be used by both crash and gdb:

# gdb /usr/lib/debug/lib/modules/2.6.32-71.el6.x86_64/vmlinux
/work/core/vmcore
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-48.el6)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show
copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from
/usr/lib/debug/lib/modules/2.6.32-71.el6.x86_64/vmlinux...done.
[New Thread 1691]
[New <main task>]
#0  sysrq_handle_crash (key=99, tty=0x0) at drivers/char/sysrq.c:130
130	drivers/char/sysrq.c: No such file or directory.
	in drivers/char/sysrq.c
(gdb) bt
#0  sysrq_handle_crash (key=99, tty=0x0) at drivers/char/sysrq.c:130
#1  0xffffffff8130d822 in __handle_sysrq (key=99, tty=0x0,
check_mask=<value optimized out>) at drivers/char/sysrq.c:521
#2  0xffffffff8130d8de in write_sysrq_trigger (file=<value optimized
out>, buf=<value optimized out>, count=2, ppos=<value optimized
out>) at drivers/char/sysrq.c:599
#3  0xffffffff811cf31e in proc_reg_write (file=<value optimized out>,
buf=0x7fdabafea000 <Address 0x7fdabafea000 out of bounds>, count=2,
ppos=<value optimized out>)
    at fs/proc/inode.c:207
#4  0xffffffff8116c818 in vfs_write (file=0xffff88003c7bb740,
buf=0x7fdabafea000 <Address 0x7fdabafea000 out of bounds>,
count=<value optimized out>, pos=0xffff88003767ff48)
    at fs/read_write.c:347
#5  0xffffffff8116d251 in sys_write (fd=<value optimized out>,
buf=0x7fdabafea000 <Address 0x7fdabafea000 out of bounds>, count=2)
at fs/read_write.c:399
#6  0xffffffff81013172 in ?? () at arch/x86/kernel/entry_64.S:487
#7  0x0000000000000246 in ?? ()
#8  0x00000000ffffffff in ?? ()
#9  0x00007fdabafde700 in ?? ()
#10 0x000000000000000a in ?? ()
#11 0x0000000000000001 in ?? ()
#12 0x0000000000000002 in ?? ()
#13 0x0000000000000001 in ?? ()
#14 0x00000030f80d4230 in ?? ()
#15 0x0000000000000033 in ?? ()
#16 0x0000000000010206 in ?? ()
#17 0x00007fff8a126470 in ?? ()
#18 0x000000000000002b in ?? ()
#19 0xffff8800374f5000 in ?? ()
#20 0xffff88003c6f9000 in ?? ()
#21 0x0000000000000080 in ?? ()
#22 0xffff880037680080 in ?? ()
#23 0xffffffff00000014 in ?? ()
#24 0x0000000000000000 in ?? ()
(gdb) q
# crash -s /usr/lib/debug/lib/modules/2.6.32-71.el6.x86_64/vmlinux /work/core/vmcore
crash> bt
PID: 1691   TASK: ffff88003711d520  CPU: 0   COMMAND: "bash"
 #0 [ffff88003767fae0] machine_kexec at ffffffff8103695b
 #1 [ffff88003767fb40] crash_kexec at ffffffff810b8f08
 #2 [ffff88003767fc10] oops_end at ffffffff814cbbd0
 #3 [ffff88003767fc40] no_context at ffffffff8104651b
 #4 [ffff88003767fc90] __bad_area_nosemaphore at ffffffff810467a5
 #5 [ffff88003767fce0] bad_area at ffffffff810468ce
 #6 [ffff88003767fd10] do_page_fault at ffffffff814cd740
 #7 [ffff88003767fd60] page_fault at ffffffff814caf45
    [exception RIP: sysrq_handle_crash+22]
    RIP: ffffffff8130d566  RSP: ffff88003767fe18  RFLAGS: 00010096
    RAX: 0000000000000010  RBX: 0000000000000063  RCX: 0000000000000000
    RDX: 0000000000000000  RSI: 0000000000000000  RDI: 0000000000000063
    RBP: ffff88003767fe18   R8: 0000000000000000   R9: ffffffff815106c0
    R10: 0000000000000001  R11: 0000000000000000  R12: 0000000000000000
    R13: ffffffff8179e6c0  R14: 0000000000000286  R15: 0000000000000007
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
 #8 [ffff88003767fe20] __handle_sysrq at ffffffff8130d822
 #9 [ffff88003767fe70] write_sysrq_trigger at ffffffff8130d8de
#10 [ffff88003767fea0] proc_reg_write at ffffffff811cf31e
#11 [ffff88003767fef0] vfs_write at ffffffff8116c818
#12 [ffff88003767ff30] sys_write at ffffffff8116d251
#13 [ffff88003767ff80] system_call_fastpath at ffffffff81013172
    RIP: 00000030f80d4230  RSP: 00007fff8a126470  RFLAGS: 00010206
    RAX: 0000000000000001  RBX: ffffffff81013172  RCX: 0000000000000400
    RDX: 0000000000000002  RSI: 00007fdabafea000  RDI: 0000000000000001
    RBP: 00007fdabafea000   R8: 000000000000000a   R9: 00007fdabafde700
    R10: 00000000ffffffff  R11: 0000000000000246  R12: 0000000000000002
    R13: 00000030f8379780  R14: 0000000000000002  R15: 00000030f8379780
    ORIG_RAX: 0000000000000001  CS: 0033  SS: 002b
crash>

I wrote a sample(not finished). It only can works on x86_64(both host and guest) I use it to create a core file:

# readelf -h /tmp/vm2.save
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              CORE (Core file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          64 (bytes into file)
  Start of section headers:          0 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         9
  Size of section headers:           0 (bytes)
  Number of section headers:         0
  Section header string table index: 0
# readelf -l /tmp/vm2.save

Elf file type is CORE (Core file)
Entry point 0x0
There are 9 program headers, starting at offset 64

Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
NOTE 0x0000000000000238 0x0000000000000000 0x0000000000000000

                 0x00000000000002c8 0x00000000000002c8         0
  LOAD           0x0000000000000500 0xffffffff81000000 0x0000000001000000
                 0x000000001f000000 0x000000001f000000         0
  LOAD           0x000000001f000500 0x0000000000000000 0x0000000000000000
                 0x0000000001000000 0x0000000001000000         0
  LOAD           0x0000000020000500 0x0000000000000000 0x0000000020000000
                 0x0000000000020000 0x0000000000020000         0
  LOAD           0x0000000020020500 0x0000000000000000 0x0000000020870000
                 0x0000000000010000 0x0000000000010000         0
  LOAD           0x0000000020030500 0x0000000000000000 0x0000000020850000
                 0x0000000000020000 0x0000000000020000         0
  LOAD           0x0000000020050500 0x0000000000000000 0x0000000020840000
                 0x0000000000010000 0x0000000000010000         0
  LOAD           0x0000000020060500 0x0000000000000000 0x0000000020040000
                 0x0000000000800000 0x0000000000800000         0
  LOAD           0x0000000020860500 0x0000000000000000 0x0000000020020000
                 0x0000000000020000 0x0000000000020000         0

I can use crash to anaylze the file, but I can not use gdb to anaylze it.

# gdb /usr/lib/debug/lib/modules/2.6.32-71.el6.x86_64/vmlinux /tmp/vm2.save
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-48.el6)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show
copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from
/usr/lib/debug/lib/modules/2.6.32-71.el6.x86_64/vmlinux...done.
[New <main task>]
[New <main task>]
#0  0x8103be8b00000000 in ?? ()
(gdb) bt
#0  0x8103be8b00000000 in ?? ()
Cannot access memory at address 0x8170dec800000000
(gdb) q

My first and the most important question is that: Is there necessary to continue this work?

Quoted 6 lines

The attachment is the sample patch.
Thanks
Wen Congyang
From an enterprise/support point of view, the wholesale replacement

of the current use of the savevm dumpfile format by "virsh dump" with this ELF style format would be a *huge* improvement.

Dave Anderson

Jan Kiszka

2011-11-18 12:46 UTC #2 lore raw

Quoted 184 lines · Dave Anderson

----- Original Message -----

Quoted 181 lines

Hi, all

'virsh dump' can not work when host pci device is used by guest. We have discussed this issue here:
http://lists.nongnu.org/archive/html/qemu-devel/2011-10/msg00736.html

We have determined to introduce a new command dump to dump memory. The core file's format can be elf.

I created a kdump-elf vmcore, and found that it can be used by both crash and gdb:

# gdb /usr/lib/debug/lib/modules/2.6.32-71.el6.x86_64/vmlinux
/work/core/vmcore
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-48.el6)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show
copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from
/usr/lib/debug/lib/modules/2.6.32-71.el6.x86_64/vmlinux...done.
[New Thread 1691]
[New <main task>]
#0  sysrq_handle_crash (key=99, tty=0x0) at drivers/char/sysrq.c:130
130	drivers/char/sysrq.c: No such file or directory.
	in drivers/char/sysrq.c
(gdb) bt
#0  sysrq_handle_crash (key=99, tty=0x0) at drivers/char/sysrq.c:130
#1  0xffffffff8130d822 in __handle_sysrq (key=99, tty=0x0,
check_mask=<value optimized out>) at drivers/char/sysrq.c:521
#2  0xffffffff8130d8de in write_sysrq_trigger (file=<value optimized
out>, buf=<value optimized out>, count=2, ppos=<value optimized
out>) at drivers/char/sysrq.c:599
#3  0xffffffff811cf31e in proc_reg_write (file=<value optimized out>,
buf=0x7fdabafea000 <Address 0x7fdabafea000 out of bounds>, count=2,
ppos=<value optimized out>)
    at fs/proc/inode.c:207
#4  0xffffffff8116c818 in vfs_write (file=0xffff88003c7bb740,
buf=0x7fdabafea000 <Address 0x7fdabafea000 out of bounds>,
count=<value optimized out>, pos=0xffff88003767ff48)
    at fs/read_write.c:347
#5  0xffffffff8116d251 in sys_write (fd=<value optimized out>,
buf=0x7fdabafea000 <Address 0x7fdabafea000 out of bounds>, count=2)
at fs/read_write.c:399
#6  0xffffffff81013172 in ?? () at arch/x86/kernel/entry_64.S:487
#7  0x0000000000000246 in ?? ()
#8  0x00000000ffffffff in ?? ()
#9  0x00007fdabafde700 in ?? ()
#10 0x000000000000000a in ?? ()
#11 0x0000000000000001 in ?? ()
#12 0x0000000000000002 in ?? ()
#13 0x0000000000000001 in ?? ()
#14 0x00000030f80d4230 in ?? ()
#15 0x0000000000000033 in ?? ()
#16 0x0000000000010206 in ?? ()
#17 0x00007fff8a126470 in ?? ()
#18 0x000000000000002b in ?? ()
#19 0xffff8800374f5000 in ?? ()
#20 0xffff88003c6f9000 in ?? ()
#21 0x0000000000000080 in ?? ()
#22 0xffff880037680080 in ?? ()
#23 0xffffffff00000014 in ?? ()
#24 0x0000000000000000 in ?? ()
(gdb) q
# crash -s /usr/lib/debug/lib/modules/2.6.32-71.el6.x86_64/vmlinux /work/core/vmcore
crash> bt
PID: 1691   TASK: ffff88003711d520  CPU: 0   COMMAND: "bash"
 #0 [ffff88003767fae0] machine_kexec at ffffffff8103695b
 #1 [ffff88003767fb40] crash_kexec at ffffffff810b8f08
 #2 [ffff88003767fc10] oops_end at ffffffff814cbbd0
 #3 [ffff88003767fc40] no_context at ffffffff8104651b
 #4 [ffff88003767fc90] __bad_area_nosemaphore at ffffffff810467a5
 #5 [ffff88003767fce0] bad_area at ffffffff810468ce
 #6 [ffff88003767fd10] do_page_fault at ffffffff814cd740
 #7 [ffff88003767fd60] page_fault at ffffffff814caf45
    [exception RIP: sysrq_handle_crash+22]
    RIP: ffffffff8130d566  RSP: ffff88003767fe18  RFLAGS: 00010096
    RAX: 0000000000000010  RBX: 0000000000000063  RCX: 0000000000000000
    RDX: 0000000000000000  RSI: 0000000000000000  RDI: 0000000000000063
    RBP: ffff88003767fe18   R8: 0000000000000000   R9: ffffffff815106c0
    R10: 0000000000000001  R11: 0000000000000000  R12: 0000000000000000
    R13: ffffffff8179e6c0  R14: 0000000000000286  R15: 0000000000000007
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
 #8 [ffff88003767fe20] __handle_sysrq at ffffffff8130d822
 #9 [ffff88003767fe70] write_sysrq_trigger at ffffffff8130d8de
#10 [ffff88003767fea0] proc_reg_write at ffffffff811cf31e
#11 [ffff88003767fef0] vfs_write at ffffffff8116c818
#12 [ffff88003767ff30] sys_write at ffffffff8116d251
#13 [ffff88003767ff80] system_call_fastpath at ffffffff81013172
    RIP: 00000030f80d4230  RSP: 00007fff8a126470  RFLAGS: 00010206
    RAX: 0000000000000001  RBX: ffffffff81013172  RCX: 0000000000000400
    RDX: 0000000000000002  RSI: 00007fdabafea000  RDI: 0000000000000001
    RBP: 00007fdabafea000   R8: 000000000000000a   R9: 00007fdabafde700
    R10: 00000000ffffffff  R11: 0000000000000246  R12: 0000000000000002
    R13: 00000030f8379780  R14: 0000000000000002  R15: 00000030f8379780
    ORIG_RAX: 0000000000000001  CS: 0033  SS: 002b
crash>

I wrote a sample(not finished). It only can works on x86_64(both host and guest) I use it to create a core file:

# readelf -h /tmp/vm2.save
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              CORE (Core file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          64 (bytes into file)
  Start of section headers:          0 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         9
  Size of section headers:           0 (bytes)
  Number of section headers:         0
  Section header string table index: 0
# readelf -l /tmp/vm2.save

Elf file type is CORE (Core file)
Entry point 0x0
There are 9 program headers, starting at offset 64

Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
NOTE 0x0000000000000238 0x0000000000000000 0x0000000000000000

                 0x00000000000002c8 0x00000000000002c8         0
  LOAD           0x0000000000000500 0xffffffff81000000 0x0000000001000000
                 0x000000001f000000 0x000000001f000000         0
  LOAD           0x000000001f000500 0x0000000000000000 0x0000000000000000
                 0x0000000001000000 0x0000000001000000         0
  LOAD           0x0000000020000500 0x0000000000000000 0x0000000020000000
                 0x0000000000020000 0x0000000000020000         0
  LOAD           0x0000000020020500 0x0000000000000000 0x0000000020870000
                 0x0000000000010000 0x0000000000010000         0
  LOAD           0x0000000020030500 0x0000000000000000 0x0000000020850000
                 0x0000000000020000 0x0000000000020000         0
  LOAD           0x0000000020050500 0x0000000000000000 0x0000000020840000
                 0x0000000000010000 0x0000000000010000         0
  LOAD           0x0000000020060500 0x0000000000000000 0x0000000020040000
                 0x0000000000800000 0x0000000000800000         0
  LOAD           0x0000000020860500 0x0000000000000000 0x0000000020020000
                 0x0000000000020000 0x0000000000020000         0

I can use crash to anaylze the file, but I can not use gdb to anaylze it.

# gdb /usr/lib/debug/lib/modules/2.6.32-71.el6.x86_64/vmlinux /tmp/vm2.save
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-48.el6)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show
copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from
/usr/lib/debug/lib/modules/2.6.32-71.el6.x86_64/vmlinux...done.
[New <main task>]
[New <main task>]
#0  0x8103be8b00000000 in ?? ()
(gdb) bt
#0  0x8103be8b00000000 in ?? ()
Cannot access memory at address 0x8170dec800000000
(gdb) q

My first and the most important question is that: Is there necessary to continue this work?

Quoted 8 lines

Quoted 4 lines
The attachment is the sample patch.
Thanks
Wen Congyang
From an enterprise/support point of view, the wholesale replacement of the current use of the savevm dumpfile format by "virsh dump" with this ELF style format would be a *huge* improvement.

Yes, fully agree. Would be cool if that could actually work for both crash and gdb. Looking forward!

Jan

Wen Congyang

author

2011-11-21 08:04 UTC #3 lore raw

At 11/18/2011 08:46 PM, Jan Kiszka Write:

Quoted 17 lines · Dave Anderson

Quoted 15 lines
----- Original Message -----
Quoted 12 lines
Hi, all
'virsh dump' can not work when host pci device is used by guest. We have discussed this issue here:
http://lists.nongnu.org/archive/html/qemu-devel/2011-10/msg00736.html
We have determined to introduce a new command dump to dump memory. The core file's format can be elf.
I created a kdump-elf vmcore, and found that it can be used by both crash and gdb:

Quoted 6 lines

Quoted 3 lines
From an enterprise/support point of view, the wholesale replacement of the current use of the savevm dumpfile format by "virsh dump" with this ELF style format would be a *huge* improvement.
Yes, fully agree. Would be cool if that could actually work for both crash and gdb. Looking forward!

Because the memory size for x86 machine can greater than 4G, so we should create elf64 format core file for 32bit OS.

I create a vmcore: the guest OS is 32-bit, and the vmcore is elf64 format. I can use crash to anaylyze it, but gdb can not do the same thing.

I create a kdump-elf64 vmcore on 32-bit machine, and gdb still can not anaylyze it.

Does gdb support elf64 format core file on x86 box?

Thanks
Wen Congyang

Quoted 3 lines

Jan

Jan Kiszka

2011-11-26 10:27 UTC #4 lore raw

Quoted 28 lines · Wen Congyang

At 11/18/2011 08:46 PM, Jan Kiszka Write:
Quoted 17 lines · Dave Anderson
Quoted 15 lines
----- Original Message -----
Quoted 12 lines
Hi, all
'virsh dump' can not work when host pci device is used by guest. We have discussed this issue here:
http://lists.nongnu.org/archive/html/qemu-devel/2011-10/msg00736.html
We have determined to introduce a new command dump to dump memory. The core file's format can be elf.
I created a kdump-elf vmcore, and found that it can be used by both crash and gdb:
Quoted 6 lines
Quoted 3 lines
From an enterprise/support point of view, the wholesale replacement of the current use of the savevm dumpfile format by "virsh dump" with this ELF style format would be a *huge* improvement.
Yes, fully agree. Would be cool if that could actually work for both crash and gdb. Looking forward!
Because the memory size for x86 machine can greater than 4G, so we should create elf64 format core file for 32bit OS.

Quoted 8 lines

I create a vmcore: the guest OS is 32-bit, and the vmcore is elf64 format. I can use crash to anaylyze it, but gdb can not do the same thing.
I create a kdump-elf64 vmcore on 32-bit machine, and gdb still can not anaylyze it.
Does gdb support elf64 format core file on x86 box?

Dunno, but I'm trying to pull in some interested gdb folks.

Jan

Sergio Durigan Junior

2011-11-26 21:46 UTC #5 lore raw

Quoted 31 lines · Jan Kiszka

Quoted 30 lines · Wen Congyang
At 11/18/2011 08:46 PM, Jan Kiszka Write:
Quoted 16 lines · Dave Anderson
Quoted 14 lines
----- Original Message -----
Quoted 11 lines
Hi, all
'virsh dump' can not work when host pci device is used by guest. We have discussed this issue here:
http://lists.nongnu.org/archive/html/qemu-devel/2011-10/msg00736.html>>>>
We have determined to introduce a new command dump to dump memory. The core file's format can be elf.
I created a kdump-elf vmcore, and found that it can be used by both crash and gdb:
Quoted 6 lines
Quoted 3 lines
From an enterprise/support point of view, the wholesale replacement of the current use of the savevm dumpfile format by "virsh dump" with this ELF style format would be a *huge* improvement.
Yes, fully agree. Would be cool if that could actually work for both crash and gdb. Looking forward!
Because the memory size for x86 machine can greater than 4G, so we should create elf64 format core file for 32bit OS.
I create a vmcore: the guest OS is 32-bit, and the vmcore is elf64 format. I can use crash to anaylyze it, but gdb can not do the same thing.

Quoted 7 lines

Quoted 5 lines
I create a kdump-elf64 vmcore on 32-bit machine, and gdb still can not anaylyze it.
Does gdb support elf64 format core file on x86 box?
Dunno, but I'm trying to pull in some interested gdb folks.

Hello,

IIRC, GDB supports ELF64 corefiles on x86 boxes, but only when configured with `--enable-64-bit-bfd'. Otherwise, it won't be able to properly understand the format.

Wen Congyang

author

2011-11-29 05:39 UTC #6 lore raw

RFC PATCH 1/1 introduce a new monitor command 'dump' to dump guest's memory

In reply to Wen Congyang

'virsh dump' can not work when host pci device is used by guest. We have discussed this issue here:
http://lists.nongnu.org/archive/html/qemu-devel/2011-10/msg00736.html

We have determined to introduce a new command dump to dump memory. The core file's format is elf.

Note:
1. The guest should be x86 or x86_64. The other arch is not supported.
2. gdb can not convert the virtual address to physical address sometimes, because the PT_LOAD in the core file does not contain enough information.
3. If you use old gdb, gdb may crash. I use gdb-7.3.1, and it does not crash.

Signed-off-by Wen Congyang <[email protected]>

---
 Makefile.target |    8 +-
 dump.c          |  772 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 dump.h          |    6 +
 hmp-commands.hx |   16 ++
 monitor.c       |    3 +
 qmp-commands.hx |   24 ++
 6 files changed, 825 insertions(+), 4 deletions(-)
 create mode 100644 dump.c
 create mode 100644 dump.h

Makefile.target +4 -4

index a111521..a4f0e6d 100644
@@ -118,7 +118,7 @@ $(call set-vpath, $(SRC_PATH)/linux-user:$(SRC_PATH)/linux-user/$(TARGET_ABI_DIR
 QEMU_CFLAGS+=-I$(SRC_PATH)/linux-user/$(TARGET_ABI_DIR) -I$(SRC_PATH)/linux-user
 obj-y = main.o syscall.o strace.o mmap.o signal.o thunk.o \
       elfload.o linuxload.o uaccess.o gdbstub.o cpu-uname.o \
-      user-exec.o $(oslib-obj-y)
+      user-exec.o $(oslib-obj-y) dump.o
 
 obj-$(TARGET_HAS_BFLT) += flatload.o

@@ -156,7 +156,7 @@ LDFLAGS+=-Wl,-segaddr,__STD_PROG_ZONE,0x1000 -image_base 0x0e000000
 LIBS+=-lmx
 
 obj-y = main.o commpage.o machload.o mmap.o signal.o syscall.o thunk.o \
-        gdbstub.o user-exec.o
+        gdbstub.o user-exec.o dump.o
 
 obj-i386-y += ioport-user.o

@@ -178,7 +178,7 @@ $(call set-vpath, $(SRC_PATH)/bsd-user)
 QEMU_CFLAGS+=-I$(SRC_PATH)/bsd-user -I$(SRC_PATH)/bsd-user/$(TARGET_ARCH)
 
 obj-y = main.o bsdload.o elfload.o mmap.o signal.o strace.o syscall.o \
-        gdbstub.o uaccess.o user-exec.o
+        gdbstub.o uaccess.o user-exec.o dump.o
 
 obj-i386-y += ioport-user.o

@@ -194,7 +194,7 @@ endif #CONFIG_BSD_USER
 # System emulator target
 ifdef CONFIG_SOFTMMU
 
-obj-y = arch_init.o cpus.o monitor.o machine.o gdbstub.o balloon.o ioport.o
+obj-y = arch_init.o cpus.o monitor.o machine.o gdbstub.o balloon.o ioport.o dump.o
 # virtio has to be here due to weird dependency between PCI and virtio-net.
 # need to fix this properly
 obj-$(CONFIG_NO_PCI) += pci-stub.o

dump.c new file +772 -0

772 lines not on this page · raw message

dump.h new file +6 -0

new file mode 100644
index 0000000..c91fa2c
@@ -0,0 +1,6 @@
+#ifndef DUMP_H
+#define DUMP_H
+
+int do_dump(Monitor *mon, const QDict *qdict, QObject **ret_data);
+
+#endif

hmp-commands.hx +16 -0

index 089c1ac..ebbce8c 100644
@@ -772,6 +772,22 @@ Migrate to @var{uri} (using -d to not wait for completion).
 ETEXI
 
     {
+        .name       = "dump",
+        .args_type  = "file:s",
+        .params     = "file",
+        .help       = "dump to file",
+        .user_print = monitor_user_noop,
+        .mhandler.cmd_new = do_dump,
+    },
+
+
+STEXI
+@item dump @var{file}
+@findex dump
+Dump to @var{file}.
+ETEXI
+
+    {
         .name       = "migrate_cancel",
         .args_type  = "",
         .params     = "",

monitor.c +3 -0

index 1be222e..9f26c3d 100644
@@ -73,6 +73,9 @@
 #endif
 #include "hw/lm32_pic.h"
 
+/* for dump */
+#include "dump.h"
+
 //#define DEBUG
 //#define DEBUG_COMPLETION

qmp-commands.hx +24 -0

index 97975a5..5cf21c5 100644
@@ -485,6 +485,30 @@ Notes:
 EQMP
 
     {
+        .name       = "dump",
+        .args_type  = "file:s",
+        .params     = "file",
+        .help       = "dump to file",
+        .user_print = monitor_user_noop,
+        .mhandler.cmd_new = do_dump,
+    },
+
+SQMP
+dump
+-------
+
+Dump to file.
+
+Arguments: None.
+
+Example:
+
+-> { "execute": "dump", "arguments": { "file": "fd:dump" } }
+<- { "return": {} }
+
+EQMP
+
+    {
         .name       = "migrate_cancel",
         .args_type  = "",
         .params     = "",

Signature · 1 line

1.7.1