On 04/18/2011 02:39 AM, Lai Jiangshan wrote:
>>> +int qemuMonitorTextInjectNMI(qemuMonitorPtr mon, unsigned int flags ATTRIBUTE_UNUSED)
>>> +{
>>> + const char *cmd = "nmi 0";
>>> + char *reply = NULL;
>>> +
>>> + /*
>>> + * FIXME: qemu's nmi command just injects NMI to a specified CPU,
>>> + * use "nmi 0" instead temporary.
>>> + */
>>
>> This bothers me. Is it possible to inject NMI to a particular CPU in
>> bare-metal hardware? If so, then we ought to support that in the API.
>>
>
> The real world NMI button just sends NMI to all cpus, the qemu side code will
> also be modified that hmp nmi command just sends NMI to all CPU and
> the cpu-index parameter will be removed.
>
> My original qemu side patch lefts cpu-index parameter for kernel debugging,
> but the qemu guys persuade me that inject-nmi command should just send NMI
> to CPUs. I accepted it. I think the libvirt will handle it at the same way.
Makes sense, and matches with what I learned on a google search about
the "NMI button" on real hardware. Thus, the real fixme is that qemu's
nmi command has a bogus argument during preliminary patch review that
will be going away before inject-nmi is made official, and therefore,
libvirt should just be sending "nmi" and not "nmi 0" once there is a
released version of qemu that actually supports injecting NMI, and you
are right that the API should not expose a vcpu parameter.
Any timeframe on when a released qemu might support nmi injection, or
even a pointer to a URL where the qemu patch stream is under discussion?
It doesn't make too much sense to push this patch into libvirt until we
are reasonably sure that the qemu interface is well-baked, to minimize
needing later libvirt tweaks.
--
Eric Blake eblake@xxxxxxxxxx +1-801-349-2682
Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list