qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Question] dump memory when host pci device is used by


From: Jan Kiszka
Subject: Re: [Qemu-devel] [Question] dump memory when host pci device is used by guest
Date: Tue, 18 Oct 2011 15:34:58 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]