Re: [Qemu-ppc] [PATCH v3 1/4] cpus: Define NMI callback

[Luiz Capitulino]

On Wed, 11 Jun 2014 15:36:57 +0200
Cornelia Huck <address@hidden> wrote:

> On Wed, 11 Jun 2014 09:10:36 -0400
> Luiz Capitulino <address@hidden> wrote:
> 
> > On Tue, 10 Jun 2014 18:29:43 +0200
> > Paolo Bonzini <address@hidden> 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).