From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH] KVM: VMX: Translate interrupt shadow when waiting on NMI window Date: Wed, 21 Apr 2010 17:14:04 +0200 Message-ID: <4BCF163C.8060408@siemens.com> References: <20100216100635.GE2995@redhat.com> <4B7A7015.6000802@siemens.com> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Avi Kivity , Marcelo Tosatti , kvm To: Gleb Natapov Return-path: Received: from david.siemens.de ([192.35.17.14]:19258 "EHLO david.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755647Ab0DUPOZ (ORCPT ); Wed, 21 Apr 2010 11:14:25 -0400 In-Reply-To: <20100421144401.GF14124@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Gleb Natapov wrote: > On Wed, Apr 21, 2010 at 04:41:38PM +0200, Jan Kiszka wrote: >> Gleb Natapov wrote: >>> On Wed, Apr 21, 2010 at 04:17:03PM +0200, Jan Kiszka wrote: >>>> Gleb Natapov wrote: >>>>> On Tue, Feb 16, 2010 at 11:37:15AM +0100, Jan Kiszka wrote: >>>>>> Gleb Natapov wrote: >>>>>>> On Tue, Feb 16, 2010 at 11:27:07AM +0100, Jan Kiszka wrote: >>>>>>>> Gleb Natapov wrote: >>>>>>>>> On Tue, Feb 16, 2010 at 11:14:45AM +0100, Jan Kiszka wrote: >>>>>>>>>> Gleb Natapov wrote: >>>>>>>>>>> On Tue, Feb 16, 2010 at 11:04:10AM +0100, Jan Kiszka wrote: >>>>>>>>>>>> Gleb Natapov wrote: >>>>>>>>>>>>> On Tue, Feb 16, 2010 at 10:16:12AM +0100, Jan Kiszka wrot= e: >>>>>>>>>>>>>> Found while browsing Xen code: While we assume that the = STI interrupt >>>>>>>>>>>>>> shadow also inplies virtual NMI blocking, some processor= s may have a >>>>>>>>>>>>>> different opinion (SDM 3: 22.3). To avoid misunderstandi= ngs that would >>>>>>>>>>>>>> cause endless VM entry attempts, translate STI into MOV = SS blocking when >>>>>>>>>>>>>> requesting the NMI window. >>>>>>>>>>>>>> >>>>>>>>>>>>> Why not just remove "block by STI" check in vmx_nmi_allow= ed()? IIRC this >>>>>>>>>>>>> is documented that on some CPUs STI does not block NMI. >>>>>>>>>>>>> >>>>>>>>>>>> Probably because we will stumble and fall on those CPUs th= at do care. >>>>>>>>>>>> >>>>>>>>>>> But this defines behaviour of cpu _we_ emulate. So on _our_= cpu NMI will >>>>>>>>>>> not be blocked by STI. >>>>>>>>>> The host CPU decides if it accepts an NMI injections while >>>>>>>>> Are you sure? I haven't found such check during VMENTRY. >>>>>>>> I also only find the explicitly stated exclusion of MOV SS blo= cking vs. >>>>>>>> NMI injection. If we can rely on this, removing STI blocking f= rom >>>>>>>> vmx_nmi_allowed should suffice. Or, better, can we get an offi= cial >>>>>>>> confirmation from Intel? >>>>>>>> >>>>>>> SDM 2b says about STI instruction: >>>>>>> The IF flag and the STI and CLI instructions do not prohibit th= e >>>>>>> generation of exceptions and NMI interrupts. NMI interrupts (an= d SMIs) >>>>>>> may be blocked for one macroinstruction following an STI. >>>>>> Yes, it's likely that this is the architectural reason for the d= elayed >>>>>> NMI window signaling after STI. Still, we are looking for the >>>>>> entry-check logic. >>>>>> >>>>> Will ask Intel. >>>>> >>>> Just remembered that there was some open topic... Did your ask? An= y answer? >>>> >>> I did and got answer last week :) The answer is that NMI is blocked= only >>> if GUEST_INTR_STATE_NMI flag is set. MOV SS and STI shouldn't block= NMI, >>> so vmx_nmi_allowed() should check only GUEST_INTR_STATE_NMI flag. >> Cool, that's now increasing my level of confusion again: :( >> >> Thought we only wanted to confirm that it's still safe to inject NMI= s >> when blocked-by-STI is set. Now we hear that it's also safe when MOV= SS >> is active? That would directly contradict the SDM (at least the vers= ion >> I have at hand: June 2009). Or did I misunderstand the answer? >> > No you don't. I was told that software should be prepared to handle N= MI > after MOV SS. What part of SDM does this contradict? I found nothing = in > latest SDM. [ updated to March 2010 version ] To sum up the scenario again, I think it started with =E2=80=A2 If the =E2=80=9CNMI-window exiting=E2=80=9D VM-execution cont= rol is 1, a VM exit occurs before execution of any instruction if there is no virtual-NMI blocking and = there is no blocking of events by MOV SS (see Table 21-3). (A logical processor m= ay 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 (s= ee Section 23.6.6). 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: 23.3 CHECKING AND LOADING GUEST STATE 23.3.1.5 Checks on Guest Non-Register State =E2=80=A2 Interruptibility state. ... =E2=80=94 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 (bits= 10:8) in that field has value 2, indicating non-maskable interrupt (NMI). And doing this for STI sounds risky too: =E2=80=94 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 interru= ption type (bits 10:8) in that field has value 2, indicating NMI. Other proces= sors may not make this requirement. Should we start stepping over the shadow like we do for svm? [ There should be a law that requires hardware builders to write software according to their own manuals... ] Jan --=20 Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux