From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: VMX: NMI injection without virtual NMI support Date: Sat, 13 Sep 2008 11:58:33 +0300 Message-ID: <48CB80B9.10201@qumranet.com> References: <48C93512.4050805@siemens.com> <200809121429.51455.sheng.yang@intel.com> <48CA298A.8080404@siemens.com> <48CB4C2A.5030804@qumranet.com> <48CB5D3E.1000505@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: "Yang, Sheng" , kvm-devel To: Jan Kiszka Return-path: Received: from il.qumranet.com ([212.179.150.194]:30226 "EHLO il.qumranet.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754946AbYIMJBJ (ORCPT ); Sat, 13 Sep 2008 05:01:09 -0400 In-Reply-To: <48CB5D3E.1000505@web.de> Sender: kvm-owner@vger.kernel.org List-ID: Jan Kiszka wrote: >> In some cases misbehaving NMIs are worse than no NMIs. For example, a >> software watchdog may use NMIs to monitor a system. But if the guest >> spins with interrupts disabled, the irq window will never open, and NMIs >> will never be delivered, so the watchdog will deliver a false negative. >> >> > > I fail to see the regression. Currently that watchdog would _always_ > deliver false positives and pull the trigger immediately (in fact, this > is precisely the situation we face @work with some special board > emulation where we have to provide an NMI-based watchdog). > > Linux checks whether nmi works and enables it only if it does (I think -- not sure). So for Linux, there would be a regression. > Moreover, only the second and succeeding NMIs under the same > interrupts-disabled window need to get lost: Along with injecting the > first NMI we could request the IRQ window unconditionally, using it to > reset the virtual NMI-blocked state. > But the interrupt window would never open. Consider a spin_lock() executing with interrupts disabled, on a spin lock that is already locked by the current cpu. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.