On 2011-11-16 14:29, Dave Anderson wrote: > > > ----- 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.
Yes, fully agree. Would be cool if that could actually work for both crash and gdb. Looking forward! Jan
signature.asc
Description: OpenPGP digital signature
