From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35559) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WuehQ-0007nH-0e for qemu-devel@nongnu.org; Wed, 11 Jun 2014 05:20:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WuehG-0005LU-Qx for qemu-devel@nongnu.org; Wed, 11 Jun 2014 05:20:03 -0400 Message-ID: <53981F37.2050607@suse.de> Date: Wed, 11 Jun 2014 11:19:51 +0200 From: Alexander Graf MIME-Version: 1.0 References: <1401869330-32449-1-git-send-email-aik@ozlabs.ru> <1401869330-32449-2-git-send-email-aik@ozlabs.ru> <20140610093951.6dd64ea4@redhat.com> <20140610164107.249d8290.cornelia.huck@de.ibm.com> <20140610104847.1cb5a424@redhat.com> <53973277.4090500@redhat.com> <539749EB.2050608@suse.de> <1A9DA1AC-C696-452F-8D7E-68C49E339785@suse.de> <53981BA9.4010505@ozlabs.ru> In-Reply-To: <53981BA9.4010505@ozlabs.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3 1/4] cpus: Define NMI callback List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexey Kardashevskiy , Peter Maydell Cc: Stefan Hajnoczi , QEMU Developers , Markus Armbruster , "qemu-ppc@nongnu.org" , Alex Bligh , Cornelia Huck , Paolo Bonzini , Luiz Capitulino , =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= , Richard Henderson On 11.06.14 11:04, Alexey Kardashevskiy wrote: > On 06/11/2014 10:28 AM, Alexander Graf wrote: >> >>> Am 11.06.2014 um 02:23 schrieb Peter Maydell : >>> >>>> On 10 June 2014 19:09, Alexander Graf wrote: >>>> I agree. I see two different paths forward: >>>> >>>> 1) Use the patches as they are - they seem pretty sound and take the >>>> existing x86/s390 only feature to spapr >>>> 2) Model an "NMI" button. That button would get instantiated by the >>>> machine model. That would allow the wiring to be defined by the board. >>>> Monitor / QMP would only "press" that button (trigger an edge interrupt? >>>> call a function? something). >>>> >>>> >>>> I don't mind much either way - option 2 is the architecturally correct way >>>> of doing this. Option 1 probably won't hurt us either. >>> In an ideal world I'd like (2), ie actually model front panel switches >>> per machine and with whatever the machine's behaviour actually >>> is. However pragmatically speaking that's an awful lot of work >>> (especially since it basically requires adding a lot of U/I which is >>> always controversial and hard to drive through). I think pragmatism >>> should probably win here. >> Could we just stick a new nmi function callback into the machine class with the nmi command calling it? > > MachineClass::nmi_monitor_handler()? Or interface? That's an implementation detail to me - I don't care either way :). > What about x86/s390? Leave them alone? Or implement nmi_monitor_handler() > for them too? I did "grep TYPE_MACHINE", looks like I'll have to implement > TYPE_PC_MACHINE and TYPE_S390_MACHINE (or more), is that correct? or the button device that implements the interface ;). Really what I'd like to see eventually is that the "nmi" monitor command just searches for a device labeled "NMI button". That device implements a way (qemu_irq or callback) to trigger the NMI. In the future when someone who's good at UIs wants to take a stab at it, he could then expose that button via the UI as well. Anything that goes into that direction is a step into the right direction IMHO. Alex > > > v1 of this was implementing an interface for a SPAPR machine (like > fw_path_provider) and it was pointed out that CPUClass is the right place. > Now I am _really_ confused :) > > >> That gets us on the right track to the right direction without putting >> too much work on Alexey's shoulders. Converting from there to an actual >> button object should become reasonably straight forward later. >> >> >> Alex >> >