From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH 1/1] Disable GUEST_INTR_STATE_STI flag before injecting NMI to guest on VMX Date: Fri, 27 Aug 2010 13:06:34 +0200 Message-ID: <4C779C3A.5050507@siemens.com> References: <1282853162-16925-1-git-send-email-Jes.Sorensen@redhat.com> <1282853162-16925-2-git-send-email-Jes.Sorensen@redhat.com> <4C7776F9.4070306@siemens.com> <4C778909.2030509@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: "Jes.Sorensen@redhat.com" , "kvm@vger.kernel.org" , "gleb@redhat.com" To: Avi Kivity Return-path: Received: from david.siemens.de ([192.35.17.14]:20329 "EHLO david.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753148Ab0H0LGw (ORCPT ); Fri, 27 Aug 2010 07:06:52 -0400 In-Reply-To: <4C778909.2030509@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Avi Kivity wrote: > On 08/27/2010 11:27 AM, Jan Kiszka wrote: >> Am 26.08.2010 22:06, Jes.Sorensen@redhat.com wrote: >>> From: Jes Sorensen >>> >>> Injecting an NMI while GUEST_INTR_STATE_STI is set may fail, >>> which can cause an EXIT with invalid state, resulting in the >>> guest dieing. >> Very interesting. Reality obviously doesn't bother about the statement >> of the vendor [1]. >> >> Just curious: is this limited to specific CPU models or actually a >> generic issue? >> > > The manual states that whether a processor accepts NMIs when > blocked-by-STI or not is processor dependent. Yes, but this is fairly new, and when Gleb asked Intel, the answer was a clear "no, there is no such requirement". Maybe someone found the related processor code in the meantime... > >> Thinking about the implications: Independent of virtualization, this >> means that no code code can in any way rely on the STI shadow if there >> are NMIs present that could "consume" it. Because after return from >> those NMIs, interrupts could then be injected on the instruction that >> was originally under the shadow. >> > > Wow. Maybe we should request an interrupt window instead when > blocked-by-STI is active instead of clearing it. > Then we are (almost) back in pre-NMI-window times when the guest happens to spin with IRQs disabled. What a mess. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux