On Wed, 11 Jun 2014 15:36:57 +0200 Cornelia Huck <cornelia.h...@de.ibm.com> wrote:
> On Wed, 11 Jun 2014 09:10:36 -0400 > Luiz Capitulino <lcapitul...@redhat.com> wrote: > > > On Tue, 10 Jun 2014 18:29:43 +0200 > > Paolo Bonzini <pbonz...@redhat.com> 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).
