[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] dump memory when host pci device is used by guest
From: |
Dave Anderson |
Subject: |
Re: [Qemu-devel] [RFC] dump memory when host pci device is used by guest |
Date: |
Wed, 16 Nov 2011 11:29:51 -0500 (EST) |
----- Original Message -----
> 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
>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
[Qemu-devel] [RFC][PATCH] introduce a new monitor command 'dump' to dump guest's memory, Wen Congyang, 2011/11/29