From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 1/1] Disable GUEST_INTR_STATE_STI flag before injecting NMI to guest on VMX Date: Fri, 27 Aug 2010 12:44:41 +0300 Message-ID: <4C778909.2030509@redhat.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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: Jes.Sorensen@redhat.com, kvm@vger.kernel.org, gleb@redhat.com To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:7941 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754845Ab0H0Jos (ORCPT ); Fri, 27 Aug 2010 05:44:48 -0400 In-Reply-To: <4C7776F9.4070306@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: 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. > 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. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.