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

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1795 bytes --]

On 06/10/2014 07:39 AM, Luiz Capitulino 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>

>> +++ 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]