qemu-devel
[Top][All Lists]
Advanced

[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
 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]