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

[Cornelia Huck <cornelia.huck@de.ibm.com>]

On Wed, 11 Jun 2014 10:38:14 +0200
Cornelia Huck <cornelia.huck@de.ibm.com> wrote:

> On Wed, 11 Jun 2014 16:50:35 +1000
> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
> 
> > On 06/11/2014 12:41 AM, Cornelia Huck wrote:
> > > On Tue, 10 Jun 2014 09:39:51 -0400
> > > Luiz Capitulino <lcapitulino@redhat.com> wrote:
> > > 
> > >> On Wed,  4 Jun 2014 18:08:47 +1000
> > >> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
> > >>
> > >>> This introduces an NMI (non maskable interrupt) callback per CPU class
> > >>> which QMP's "nmi" command may use to issue NMI on a CPU.
> > >>>
> > >>> This adds support for it in qmp_inject_nmi(). Since no architecture
> > >>> supports it at the moment, there is no change in behaviour.
> > >>>
> > >>> This changes inject-nmi command description for HMP and QMP.
> > >>>
> > >>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> > >>> ---
> > >>> Changes:
> > >>> v3:
> > >>> * actual nmi() enablement moved from last patch to first patch
> > >>> * changed description for QMP command too
> > >>> ---
> > >>>  cpus.c            | 11 ++++++++++-
> > >>>  hmp-commands.hx   |  6 ++----
> > >>>  include/qom/cpu.h |  1 +
> > >>>  qapi-schema.json  |  4 +---
> > >>>  qmp-commands.hx   |  3 +--
> > >>>  5 files changed, 15 insertions(+), 10 deletions(-)
> > >>>
> 
> > >>> diff --git a/qapi-schema.json b/qapi-schema.json
> > >>> index 7bc33ea..dcf6642 100644
> > >>> --- a/qapi-schema.json
> > >>> +++ b/qapi-schema.json
> > >>> @@ -1748,13 +1748,11 @@
> > >>>  ##
> > >>>  # @inject-nmi:
> > >>>  #
> > >>> -# Injects an Non-Maskable Interrupt into all guest's VCPUs.
> > >>> +# Injects an Non-Maskable Interrupt into the given guest's VCPU.
> > >>
> > >> QMP doesn't have the concept of "current monitored CPU" you talk in the
> > >> intro email. In QMP you have to specify the CPU. You have to choices:
> > >>
> > >>  - Add a new command that takes a CPU parameter (seems the best to me, as
> > >>    people were asking for a different command anyways)
> > >>
> > >>  - Add an optional parameter to inject-nmi. When the CPU parameter is
> > >>    not specified, the command sends the NMI to all CPUs
> > > 
> > > 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.
> > 
> > 
> > Interesting thing. I was pushing "nmi" for ppc which did nmi only on the
> > current cpu but according to our architect Ben, I should inject NMI on all
> > CPUs because although XMON (inkernel debugger) tries to stop other CPUs, it
> > may fail to do that because of some interrupt deadlock. And - this is
> > important for us - this is what pHyp (native IBM hypervisor) does.
> > 
> > Now I wonder how you are getting away with injecting NMI on one CPU only
> > and what will happen if we inject NMI on all?
> 
> The Linux restart handler does stop the other cpus before doing any
> other work - see restart_int_handler in arch/s390/kernel/entry64.S and
> do_restart in arch/s390/kernel/ipl.c for the gory details ;)
> 
> Other operating systems need to have something similar in place, as the
> restart interrupt is always directed to a single cpu (for example, z/VM
> has SYSTEM RESTART, which is always directed either to the default cpu
> or to a specified cpu).

FWIW (just checked):

On the HMC (i.e., when working with LPARs), the restart is always
directed to "the first available cpu", with no way to select a specific
cpu. So I guess a machine callback that just grabs any cpu to inject
the restart interrupt on would be fine for s390.