From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: VMX: NMI injection without virtual NMI support Date: Thu, 11 Sep 2008 17:11:14 +0200 Message-ID: <48C93512.4050805@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: kvm-devel To: "Yang, Sheng" Return-path: Received: from lizzard.sbs.de ([194.138.37.39]:15867 "EHLO lizzard.sbs.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751293AbYIKPLS (ORCPT ); Thu, 11 Sep 2008 11:11:18 -0400 Sender: kvm-owner@vger.kernel.org List-ID: Hi Sheng, we had parts of this discussion privately a while back, but now I need to dig deeper. I finally have to complete and push out user space NMI injection that bitrots over and over again in my queue. Intel CPUs with virtual NMI support can easily be programmed to inject NMIs only when the guest CPU is ready or tell the guest to exit as soon as it changes its NMI readiness. But we are also facing a lot of CPUs that were produced without this feature, and we need to find some way to achieve virtual NMI support for them, even if the interruptibility of the guest is not as good as with true virtual NMIs. Now my questions to you or anyone else with VMX expert knowledge: The System Programming Guide, Volume 3B, 27.2 says that "Without NMI-window exiting support, the VMM will need to poll and check the interruptibility state of the guest to deliver virtual NMIs." Interruptibility involves, besides "blocked by MOV SS" and "blocked by STI", the NMI nesting. So, how can the VMM track if the guest is still inside its NMI handler after event injection? According to 22.6.1, NMI blocking is active as long as the guest runs if the "NMI-exiting" control bit is 1 (and setting it appears to be required to avoid that the guest can block NMIs for the host, right?). But what does this mean for bit 3 of the interruptibility state? Can I still use it after some guest exit for whatever reason (like a hard IRQ) to poll if the guest can now accept pending virtual NMIs? In that case, virtual NMI injections would only be delayed a bit on older CPUs, but could still work reliably, right? Or is there some other way to track the NMI interruptibility on such CPUs? TiA, Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux