From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:52161) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RG9ot-0006z2-O4 for qemu-devel@nongnu.org; Tue, 18 Oct 2011 09:35:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RG9os-0003OX-PQ for qemu-devel@nongnu.org; Tue, 18 Oct 2011 09:35:03 -0400 Received: from david.siemens.de ([192.35.17.14]:23456) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RG9os-0003NF-GP for qemu-devel@nongnu.org; Tue, 18 Oct 2011 09:35:02 -0400 Message-ID: <4E9D8082.6070802@siemens.com> Date: Tue, 18 Oct 2011 15:34:58 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4E9D3678.3010904@siemens.com> <4E9D3804.5040000@cn.fujitsu.com> <4E9D3847.8040202@siemens.com> <4E9D3965.4090003@cn.fujitsu.com> <4E9D394E.6050907@siemens.com> <20111018083416.GL8872@amd.home.annexia.org> <4E9D3A80.10402@siemens.com> <4E9D3B29.5060207@siemens.com> <4E9D57C6.8040809@redhat.com> <4E9D593B.705@siemens.com> <20111018133015.GO8872@amd.home.annexia.org> In-Reply-To: <20111018133015.GO8872@amd.home.annexia.org> Content-Type: text/plain; charset=ISO-8859-1 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: "Richard W.M. Jones" Cc: Paolo Bonzini , qemu-devel , Luiz Capitulino On 2011-10-18 15:30, Richard W.M. Jones wrote: > On Tue, Oct 18, 2011 at 12:47:23PM +0200, Jan Kiszka wrote: >> On 2011-10-18 12:41, Paolo Bonzini wrote: >>> On 10/18/2011 10:39 AM, Jan Kiszka wrote: >>>>>> >>>>>> Yeah, I see. Could also be solved via gdb scripts, but crash is already >>>>>> there. >>>> [ BTW, crash is for the dead. But having those features in form of gdb >>>> scripts would also allow live system analysis. Looks like it's worth >>>> obsoleting crash on the long run. ] >>> >>> Crash can also do live system analysis. :) >> >> Does it work via remote interface? And it's still the wrong way around: >> You have to append "gdb" to the majority of command when doing debugging >> instead of issuing additional analysis commands from the gdb shell. >> That's understandable given the limited scripting power of old gdbs. But >> that's now history thanks to its python interface. > > Before this conversation heads any further into the realm of > absurdity, let's get back to the key requirements for production > systems: > > (A) No development tools can be installed. > > (B) The core file must be removed from the production system quickly > and analyzed by on another machine (indeed, often by experts from > another company entirely). > > Anything that involves live debugging using GDB is simply not > acceptable for production systems, whether you think that's right or > not. My memory is usually that bad, but not in this case. :) This discussion should also work out a bigger picture than just your (valid) scenario. We should look at meeting that requirements but also see what would be a useful foundation for future extensions like having post-crash analysis and live debugging at a similar feature level with very similar or (much better) identical tools. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux