On 06/10/2014 07:39 AM, Luiz Capitulino wrote: > On Wed, 4 Jun 2014 18:08:47 +1000 > Alexey Kardashevskiy <a...@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 <a...@ozlabs.ru>
>> +++ 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 > > Eric, any thoughts? How would libvirt know whether the optional parameter is supported, short of trying it and getting a failure on older qemu that lacks it? At this point, since we still don't have global qapi introspection, the addition of a new command is nicer than the addition of an optional parameter. But I definitely agree that we have a discrepancy between HMP being able to specify a current CPU, vs. QMP being unable to direct which CPU gets the interrupt. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
