From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53078) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wuina-0003Lb-Gt for qemu-devel@nongnu.org; Wed, 11 Jun 2014 09:42:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WuinU-0006Er-D3 for qemu-devel@nongnu.org; Wed, 11 Jun 2014 09:42:42 -0400 Date: Wed, 11 Jun 2014 09:42:24 -0400 From: Luiz Capitulino Message-ID: <20140611094224.60d5bf05@redhat.com> In-Reply-To: <20140611153657.5feb3fc2.cornelia.huck@de.ibm.com> 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> <20140611091036.39defd45@redhat.com> <20140611153657.5feb3fc2.cornelia.huck@de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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: Cornelia Huck Cc: qemu-devel@nongnu.org, Stefan Hajnoczi , Alexey Kardashevskiy , Alexander Graf , Markus Armbruster , qemu-ppc@nongnu.org, Alex Bligh , Paolo Bonzini , Andreas =?UTF-8?B?RsOkcmJlcg==?= , Richard Henderson On Wed, 11 Jun 2014 15:36:57 +0200 Cornelia Huck wrote: > On Wed, 11 Jun 2014 09:10:36 -0400 > Luiz Capitulino wrote: > > > On Tue, 10 Jun 2014 18:29:43 +0200 > > Paolo Bonzini wrote: > > > > > Il 10/06/2014 16:48, Luiz Capitulino ha scritto: > > > > > The s390 restart interrupt is a per-vcpu interrupt, which we really > > > > > don't want to inject on _all_ vcpus. OTOH, we want to inject that > > > > > interrupt on any vcpu - we don't care which one it is. So I'd really > > > > > like an "inject nmi on default cpu" option. > > > > > > > > We could define a default CPU for the command. What isn't going to work > > > > is to use the human monitor's "current CPU" concept (set with the cpu > > > > command). > > > > > > It isn't going to work, but to me it seems like a bug. Why was the NMI > > > command even converted to QAPI if it cannot work? > > > > It works by sending the NMI to all CPUs. > > Not on s390. Yeah, that part of the problem with the current command I got. > > That's the solution we found to > > avoid creating a dependency between a QMP command and HMP w/o breaking the > > nmi command compatibility. > > Well, for s390 the qmp command currently has a dependency on the > monitor-set cpu. But this could be replaced by "issue command on > first cpu; if it fails with anything else than 'not implemented', try > the next one", which would remove any dependencies and still be > backward-compatible. I don't think that on s390 we need to be able to > specify a cpu via a new command; the main reasoning for that would be > that we're currently able to do so under z/VM. Your solution looks good to me. It's fine for different archs to have different semantics. All we have to do is to document it (in qapi-schema.json).