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. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
