From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:58416) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RRNq7-0007gZ-5S for qemu-devel@nongnu.org; Fri, 18 Nov 2011 07:46:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RRNq5-0006VV-K7 for qemu-devel@nongnu.org; Fri, 18 Nov 2011 07:46:43 -0500 Received: from fmmailgate05.web.de ([217.72.192.243]:56007) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RRNq4-0006VM-VA for qemu-devel@nongnu.org; Fri, 18 Nov 2011 07:46:41 -0500 Received: from moweb002.kundenserver.de (moweb002.kundenserver.de [172.19.20.108]) by fmmailgate05.web.de (Postfix) with ESMTP id 947AE67A4688 for ; Fri, 18 Nov 2011 13:46:39 +0100 (CET) Message-ID: <4EC653A4.5010801@web.de> Date: Fri, 18 Nov 2011 10:46:28 -0200 From: Jan Kiszka MIME-Version: 1.0 References: <4EC373F8.6080300@cn.fujitsu.com> <94fa6b35-8681-45e0-85dd-ffbe2ec95f74@zmail15.collab.prod.int.phx2.redhat.com> In-Reply-To: <94fa6b35-8681-45e0-85dd-ffbe2ec95f74@zmail15.collab.prod.int.phx2.redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6D1E8694E93B5F8532EF1951" Subject: Re: [Qemu-devel] [RFC] dump memory when host pci device is used by guest List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wen Congyang Cc: Dave Anderson , qemu-devel This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6D1E8694E93B5F8532EF1951 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2011-11-16 14:29, Dave Anderson wrote: >=20 >=20 > ----- Original Message ----- >> Hi, all >> >> 'virsh dump' can not work when host pci device is used by guest. We ha= ve >> 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 >> >> 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: >> ... >> Reading symbols from >> /usr/lib/debug/lib/modules/2.6.32-71.el6.x86_64/vmlinux...done. >> [New Thread 1691] >> [New
] >> #0 sysrq_handle_crash (key=3D99, tty=3D0x0) at drivers/char/sysrq.c:1= 30 >> 130 drivers/char/sysrq.c: No such file or directory. >> in drivers/char/sysrq.c >> (gdb) bt >> #0 sysrq_handle_crash (key=3D99, tty=3D0x0) at drivers/char/sysrq.c:1= 30 >> #1 0xffffffff8130d822 in __handle_sysrq (key=3D99, tty=3D0x0, >> check_mask=3D) at drivers/char/sysrq.c:521 >> #2 0xffffffff8130d8de in write_sysrq_trigger (file=3D> out>, buf=3D, count=3D2, ppos=3D> out>) at drivers/char/sysrq.c:599 >> #3 0xffffffff811cf31e in proc_reg_write (file=3D= , >> buf=3D0x7fdabafea000
, count=3D2= , >> ppos=3D) >> at fs/proc/inode.c:207 >> #4 0xffffffff8116c818 in vfs_write (file=3D0xffff88003c7bb740, >> buf=3D0x7fdabafea000
, >> count=3D, pos=3D0xffff88003767ff48) >> at fs/read_write.c:347 >> #5 0xffffffff8116d251 in sys_write (fd=3D, >> buf=3D0x7fdabafea000
, count=3D2= ) >> 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 /wo= rk/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: 000000000000000= 0 >> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000000000006= 3 >> RBP: ffff88003767fe18 R8: 0000000000000000 R9: ffffffff815106c= 0 >> R10: 0000000000000001 R11: 0000000000000000 R12: 000000000000000= 0 >> R13: ffffffff8179e6c0 R14: 0000000000000286 R15: 000000000000000= 7 >> 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: 000000000000040= 0 >> RDX: 0000000000000002 RSI: 00007fdabafea000 RDI: 000000000000000= 1 >> RBP: 00007fdabafea000 R8: 000000000000000a R9: 00007fdabafde70= 0 >> R10: 00000000ffffffff R11: 0000000000000246 R12: 000000000000000= 2 >> R13: 00000030f8379780 R14: 0000000000000002 R15: 00000030f837978= 0 >> 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 0x0000000000000= 000 >> 0x00000000000002c8 0x00000000000002c8 0 >> LOAD 0x0000000000000500 0xffffffff81000000 0x0000000001000= 000 >> 0x000000001f000000 0x000000001f000000 0 >> LOAD 0x000000001f000500 0x0000000000000000 0x0000000000000= 000 >> 0x0000000001000000 0x0000000001000000 0 >> LOAD 0x0000000020000500 0x0000000000000000 0x0000000020000= 000 >> 0x0000000000020000 0x0000000000020000 0 >> LOAD 0x0000000020020500 0x0000000000000000 0x0000000020870= 000 >> 0x0000000000010000 0x0000000000010000 0 >> LOAD 0x0000000020030500 0x0000000000000000 0x0000000020850= 000 >> 0x0000000000020000 0x0000000000020000 0 >> LOAD 0x0000000020050500 0x0000000000000000 0x0000000020840= 000 >> 0x0000000000010000 0x0000000000010000 0 >> LOAD 0x0000000020060500 0x0000000000000000 0x0000000020040= 000 >> 0x0000000000800000 0x0000000000800000 0 >> LOAD 0x0000000020860500 0x0000000000000000 0x0000000020020= 000 >> 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= =2Esave >> 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 >> >> 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: >> ... >> Reading symbols from >> /usr/lib/debug/lib/modules/2.6.32-71.el6.x86_64/vmlinux...done. >> [New
] >> [New
] >> #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 >=20 > 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.=20 Yes, fully agree. Would be cool if that could actually work for both crash and gdb. Looking forward! Jan --------------enig6D1E8694E93B5F8532EF1951 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7GU6QACgkQitSsb3rl5xRgvgCcCZfBJjq1xnsGjKNr11iMMHMz uCIAoMRNPjchW0JzxnHsDsDWRJBCX5vj =a849 -----END PGP SIGNATURE----- --------------enig6D1E8694E93B5F8532EF1951--