From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: [PATCH] KVM: VMX: Translate interrupt shadow when waiting on NMI window Date: Mon, 3 May 2010 10:32:55 +0300 Message-ID: <20100503073255.GA16976@redhat.com> References: <20100216101705.GG2995@redhat.com> <4B7A72FB.8020709@siemens.com> <20100216103235.GH2995@redhat.com> <4B7A755B.80009@siemens.com> <20100216103816.GI2995@redhat.com> <4BCF08DF.8060709@siemens.com> <20100421143007.GE14124@redhat.com> <4BCF0EA2.3010100@siemens.com> <20100421144401.GF14124@redhat.com> <4BCF163C.8060408@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=cp1255 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Avi Kivity , Marcelo Tosatti , kvm To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:57118 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753785Ab0ECHc7 convert rfc822-to-8bit (ORCPT ); Mon, 3 May 2010 03:32:59 -0400 Content-Disposition: inline In-Reply-To: <4BCF163C.8060408@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: On Wed, Apr 21, 2010 at 05:14:04PM +0200, Jan Kiszka wrote: > > No you don't. I was told that software should be prepared to handle= NMI > > after MOV SS. What part of SDM does this contradict? I found nothin= g in > > latest SDM. >=20 > [ updated to March 2010 version ] >=20 > To sum up the scenario again, I think it started with >=20 > =95 If the =93NMI-window exiting=94 VM-execution control is 1, a VM e= xit occurs before > execution of any instruction if there is no virtual-NMI blocking an= d there is no > blocking of events by MOV SS (see Table 21-3). (A logical processor= may also > prevent such a VM exit if there is blocking of events by STI.) Such= a VM exit > occurs immediately after VM entry if the above conditions are true = (see Section > 23.6.6). >=20 >=20 > We included STI into the NMI shadow, but we /may/ get early exits on > some processors according to the statement above. According to your > latest info, we can also get that when the MOV SS shadow is on!? But > simply allowing NMI injection under MOV SS is not possible: >=20 > 23.3 CHECKING AND LOADING GUEST STATE > 23.3.1.5 Checks on Guest Non-Register State >=20 > =95 Interruptibility state. > ... > =97 Bit 1 (blocking by MOV-SS) must be 0 if the valid bit (bit 31) = in the VM-entry > interruption-information field is 1 and the interruption type (bi= ts 10:8) in that > field has value 2, indicating non-maskable interrupt (NMI). >=20 >=20 > And doing this for STI sounds risky too: >=20 > =97 A processor may require bit 0 (blocking by STI) to be 0 if the = valid bit (bit 31) > in the VM-entry interruption-information field is 1 and the inter= ruption type > (bits 10:8) in that field has value 2, indicating NMI. Other proc= essors may not > make this requirement. >=20 >=20 > Should we start stepping over the shadow like we do for svm? >=20 Intel's answer is that text above describes model-specific behaviour in bare metal which can block NMI for one instruction after STI/MOV SS, but since software should not rely on model-specific behaviour we can safely inject NMI after STI/MOV SS (clearing "blocked by STI/MOV SS" bi= t before injecting). -- Gleb.