From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:39174) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDDjW-0007Qj-PE for qemu-devel@nongnu.org; Mon, 10 Oct 2011 07:09:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RDDjV-0007KY-Fs for qemu-devel@nongnu.org; Mon, 10 Oct 2011 07:09:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:21282) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDDjV-0007KU-7a for qemu-devel@nongnu.org; Mon, 10 Oct 2011 07:09:21 -0400 Message-ID: <4E92D25D.10905@redhat.com> Date: Mon, 10 Oct 2011 13:09:17 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <4E8ED167.1000705@siemens.com> <20111008151622.GA17181@amd.home.annexia.org> <4E916035.5050906@web.de> <20111009102338.GN16799@amd.home.annexia.org> <4E92568E.2010507@cn.fujitsu.com> <20111010090825.GG9408@redhat.com> <20111010091021.GH9408@redhat.com> <4E92BC34.6090500@siemens.com> <20111010102112.GB2550@bow.tlv.redhat.com> <4E92CD94.4090104@redhat.com> <20111010110444.GQ9408@redhat.com> In-Reply-To: <20111010110444.GQ9408@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Question] dump memory when host pci device is used by guest List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Jan Kiszka , Luiz Capitulino , qemu-devel , "Richard W.M. Jones" On 10/10/2011 01:04 PM, Daniel P. Berrange wrote: > On Mon, Oct 10, 2011 at 12:48:52PM +0200, Paolo Bonzini wrote: >> > On 10/10/2011 12:21 PM, Alon Levy wrote: >>>> > >> A core file would be that format - for direct gdb processing. No >>>> > >> proprietary re-inventions please. >>> > > >>> > >Just a note: A core file to windows core dump file would be nice for >>> > >windows guest crashes. >> > >> > That requires cooperation from a kernel driver in the Windows guest. >> > The driver must call KeInitializeCrashDumpHeader and write somewhere >> > the physical address of the buffer. > That won't be suitable for 'virsh dump' then, because we need this to > work when the guest OS is in a crashed/non-responsive state, and so > we cna't rely on talking to it. Note that the guest can generate the buffer before it crashes. Paolo