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 wrote:
> >>>>>>>>>>>> Found while browsing Xen code: While we assume that the STI
> >>>>>>>>>>>> interrupt
> >>>>>>>>>>>> shadow also inplies virtual NMI blocking, some processors may
> >>>>>>>>>>>> have a
> >>>>>>>>>>>> different opinion (SDM 3: 22.3). To avoid misunderstandings 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_allowed()?
> >>>>>>>>>>> IIRC this
> >>>>>>>>>>> is documented that on some CPUs STI does not block NMI.
> >>>>>>>>>>>
> >>>>>>>>>> Probably because we will stumble and fall on those CPUs that 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 blocking vs.
> >>>>>> NMI injection. If we can rely on this, removing STI blocking from
> >>>>>> vmx_nmi_allowed should suffice. Or, better, can we get an official
> >>>>>> confirmation from Intel?
> >>>>>>
> >>>>> SDM 2b says about STI instruction:
> >>>>> The IF flag and the STI and CLI instructions do not prohibit the
> >>>>> generation of exceptions and NMI interrupts. NMI interrupts (and SMIs)
> >>>>> may be blocked for one macroinstruction following an STI.
> >>>> Yes, it's likely that this is the architectural reason for the delayed
> >>>> 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? Any 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 NMIs
> 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 version
> 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 NMI
after MOV SS. What part of SDM does this contradict? I found nothing in
latest SDM.
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
