From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LmB2q-00048o-Nx for qemu-devel@nongnu.org; Tue, 24 Mar 2009 14:08:12 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LmB2m-00041L-3U for qemu-devel@nongnu.org; Tue, 24 Mar 2009 14:08:12 -0400 Received: from [199.232.76.173] (port=36344 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LmB2l-00041G-VX for qemu-devel@nongnu.org; Tue, 24 Mar 2009 14:08:08 -0400 Received: from mx2.redhat.com ([66.187.237.31]:43041) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LmB2j-0005mg-Vp for qemu-devel@nongnu.org; Tue, 24 Mar 2009 14:08:07 -0400 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n2OI82qh002195 for ; Tue, 24 Mar 2009 14:08:02 -0400 Message-ID: <49C921A6.3070202@redhat.com> Date: Tue, 24 Mar 2009 20:08:38 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Kernel core dumps from qemu References: <20090324165401.GA2999@ldl.fc.hp.com> In-Reply-To: <20090324165401.GA2999@ldl.fc.hp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: dave.anderson@redhat.com Chris Smith wrote: > Hello. > > I have been looking at adding a monitor command > > (qemu) dump > > to produce a snapshot kernel core dump similar to /proc/vmcore. > > There is nothing wrong with kdump in the guest, but having > a host dumper (in addition) would have some advantages: > > - saves 64 meg in each Linux guest (reserved for dump-capture kernel) > > - can write a snapshot dump and continue, kdump cannot > (can automatically dump on OOPS as well as panic) > > - produces dump in the host filesystem, easier for management tools > > - Xen has this, virsh supports this > > - not limited to Linux guests > > I'll outline some specific ideas and issues. > > My question is: might qemu/KVM be interested in adopting something like this? > In due course. > > Ok... kdump vmcores are 64-bit ELF core files, even on 32-bit i386. > So too it should be with host dumps. > > Linux-x64 maps physical memory twice, at 0xffff880000000000 > and at 0xffffffff80000000. An ELF dump that gives those addresses > both pointing to a copy of phys_ram[] is satisfactory to crash and gdb. > > It would be unwholesome for qemu to know those constants (__PAGE_OFFSET > and __START_KERNEL_map). Worse than unwholesome, __PAGE_OFFSET recently > changed. > > So: qemu writes an ELF dump, but without providing virtual addresses. > Crash will be able to read this as is. For others, a tool can examine > System.map or vmlinux and fix up the vmcore. For ease of use, piping > the dump through the tool can have some easy syntax. > > This also handles Windows dumps, Solaris dumps, DMX dumps, and so on. > qemu provides the info it has, and need not worry about the formatting. > > Registers are needed too. > > vmcores have elf NT_PRSTATUS notes with the registers filled in and > the rest zero. (Except current->pid which I hope isn't needed because > qemu can't do it.) > > So, NT_PRSTATUS is reasonable. Also, since it's inevitably > machine dependent, CPUState plus a version number would allow access > to pretty much everything. Or the standard thing would be pt_regs. > (It is easy to add new note types.) > > Last, there should be a note giving the version number of the spec. > > Comments appreciated. > This looks useful. I'd suggest a 'format' argument, so we can extend this later to dump in non-ELF formats (the Windows native memory dump format would be useful). I suppose the core format handles smp? -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.