qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command


From: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command
Date: Thu, 07 Apr 2011 09:29:00 +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-04-06 21:34, Anthony Liguori wrote:
> On 04/06/2011 02:27 PM, Peter Maydell wrote:
>>> Right, but honestly speaking, I don't know how this works for other arches.
>>>
>>> So, the best thing to do is to have a general design that can be used
>>> by any architecture. Of course that we can also add a new command later
>>> if needed.
>> Well, I'm not sure "send a random interrupt to the core" makes
>> much sense for ARM... So what are we actually trying to model here?
>> Some sort of way to do "press a front panel switch" via remote monitor
>> protocol? I guess you could have an API for boards to register any
>> switches they had...
> 
> http://publib.boulder.ibm.com/infocenter/lnxinfo/v3r0m0/index.jsp?topic=/liaai/crashdump/liaaicrashdumpnmiipmi.htm
> 
> If an OS is totally hosed (spinning with interrupts disabled), and NMI 
> can be used to generate a crash dump.
> 
> It's a debug feature and modelling it exactly the way we are probably 
> makes sense for other architectures too.  The real semantics are 
> basically force guest crash dump.

Right, it's a debugging tool. And that does not necessarily means it has
to match real hardware. I could imagine scenarios where it could be
helpful to direct the NMI to a specific core, e.g. in AMP setups if only
one OS ran wild.

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]