From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: [PATCH 1/1] Disable GUEST_INTR_STATE_STI flag before injecting NMI to guest on VMX Date: Fri, 27 Aug 2010 14:25:39 +0300 Message-ID: <20100827112539.GC21909@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> <4C778909.2030509@redhat.com> <20100827111650.GB21909@redhat.com> <4C77A01A.70702@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Avi Kivity , "Jes.Sorensen@redhat.com" , "kvm@vger.kernel.org" To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:27727 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752007Ab0H0LZn (ORCPT ); Fri, 27 Aug 2010 07:25:43 -0400 Content-Disposition: inline In-Reply-To: <4C77A01A.70702@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: On Fri, Aug 27, 2010 at 01:23:06PM +0200, Jan Kiszka wrote: > Gleb Natapov wrote: > > On Fri, Aug 27, 2010 at 12:44:41PM +0300, Avi Kivity wrote: > >>> 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. > >> > > Wow indeed. We can remember blocked by sti state before injecting NMI > > and request nmi window open exit. When we get nmi window open exit we > > can restore blocked by sti flag. > > For sure we could. But I still wonder what happens to the shadow in such > a scenario on real HW. > Me too, so lets wait for vendor answer. -- Gleb.