From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60356) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WueSx-0004LT-Fh for qemu-devel@nongnu.org; Wed, 11 Jun 2014 05:05:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WueSm-0007tx-Iz for qemu-devel@nongnu.org; Wed, 11 Jun 2014 05:05:07 -0400 Received: from mail-pb0-f52.google.com ([209.85.160.52]:60719) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WueSm-0007t3-Dm for qemu-devel@nongnu.org; Wed, 11 Jun 2014 05:04:56 -0400 Received: by mail-pb0-f52.google.com with SMTP id rr13so7256410pbb.39 for ; Wed, 11 Jun 2014 02:04:55 -0700 (PDT) Message-ID: <53981BA9.4010505@ozlabs.ru> Date: Wed, 11 Jun 2014 19:04:41 +1000 From: Alexey Kardashevskiy 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> In-Reply-To: <1A9DA1AC-C696-452F-8D7E-68C49E339785@suse.de> Content-Type: text/plain; charset=UTF-8 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: Alexander Graf , 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 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? 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? 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 > -- Alexey