Re: [PATCH] KVM: VMX: Translate interrupt shadow when waiting on NMI window
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 nothing in latest SDM. [ updated to March 2010 version ] To sum up the scenario again, I think it started with • If the “NMI-window exiting” VM-execution control 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 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). 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 • Interruptibility state. ... — 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: — 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 interruption type (bits 10:8) in that field has value 2, indicating NMI. Other processors may not make this requirement. Should we start stepping over the shadow like we do for svm? 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 bit before injecting). -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: VMX: Translate interrupt shadow when waiting on NMI window
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? 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: VMX: Translate interrupt shadow when waiting on NMI window
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. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: VMX: Translate interrupt shadow when waiting on NMI window
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? 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: VMX: Translate interrupt shadow when waiting on NMI window
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: VMX: Translate interrupt shadow when waiting on NMI window
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 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. [ updated to March 2010 version ] To sum up the scenario again, I think it started with • If the “NMI-window exiting” VM-execution control 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 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). 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 • Interruptibility state. ... — 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: — 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 interruption type (bits 10:8) in that field has value 2, indicating NMI. Other processors 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 -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: VMX: Translate interrupt shadow when waiting on NMI window
On Wed, Apr 21, 2010 at 05:14:04PM +0200, Jan Kiszka wrote: 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 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. [ updated to March 2010 version ] To sum up the scenario again, I think it started with • If the “NMI-window exiting” VM-execution control 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 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). 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 • Interruptibility state. ... — 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: — 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 interruption type (bits 10:8) in that field has value 2, indicating NMI. Other processors may not make this requirement. Should we start stepping over the shadow like we do for svm? If x86 ISA allows NMI to be injected after STI and MOV SS we can clear blocking by STI/MOV SS bits before injecting NMI. But why would Intel add those checks then. Will ask Intel once again. Hope will get response sooner now. [ There should be a law that requires hardware builders to write software according to their own manuals... ] +1 -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at
[PATCH] KVM: VMX: Translate interrupt shadow when waiting on NMI window
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.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
arch/x86/kvm/vmx.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 14873b9..474f720 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2614,12 +2614,27 @@ static void enable_irq_window(struct kvm_vcpu *vcpu)
static void enable_nmi_window(struct kvm_vcpu *vcpu)
{
u32 cpu_based_vm_exec_control;
+ u32 interruptibility;
if (!cpu_has_virtual_nmis()) {
enable_irq_window(vcpu);
return;
}
+ /*
+* SDM 3: 22.3 (June 2009)
+* A logical processor may also prevent such a VM exit [NMI-window
+* exit] if there is blocking of events by STI.
+* So better convert STI blocking into MOV SS to avoid premature VM
+* exits that would end up in an endless loop.
+*/
+ interruptibility = vmcs_read32(GUEST_INTERRUPTIBILITY_INFO);
+ if (interruptibility GUEST_INTR_STATE_STI) {
+ interruptibility = ~GUEST_INTR_STATE_STI;
+ interruptibility |= GUEST_INTR_STATE_MOV_SS;
+ vmcs_write32(GUEST_INTERRUPTIBILITY_INFO, interruptibility);
+ }
+
cpu_based_vm_exec_control = vmcs_read32(CPU_BASED_VM_EXEC_CONTROL);
cpu_based_vm_exec_control |= CPU_BASED_VIRTUAL_NMI_PENDING;
vmcs_write32(CPU_BASED_VM_EXEC_CONTROL, cpu_based_vm_exec_control);
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: VMX: Translate interrupt shadow when waiting on NMI window
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.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
arch/x86/kvm/vmx.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 14873b9..474f720 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2614,12 +2614,27 @@ static void enable_irq_window(struct kvm_vcpu *vcpu)
static void enable_nmi_window(struct kvm_vcpu *vcpu)
{
u32 cpu_based_vm_exec_control;
+ u32 interruptibility;
if (!cpu_has_virtual_nmis()) {
enable_irq_window(vcpu);
return;
}
+ /*
+ * SDM 3: 22.3 (June 2009)
+ * A logical processor may also prevent such a VM exit [NMI-window
+ * exit] if there is blocking of events by STI.
+ * So better convert STI blocking into MOV SS to avoid premature VM
+ * exits that would end up in an endless loop.
+ */
+ interruptibility = vmcs_read32(GUEST_INTERRUPTIBILITY_INFO);
+ if (interruptibility GUEST_INTR_STATE_STI) {
+ interruptibility = ~GUEST_INTR_STATE_STI;
+ interruptibility |= GUEST_INTR_STATE_MOV_SS;
+ vmcs_write32(GUEST_INTERRUPTIBILITY_INFO, interruptibility);
+ }
+
cpu_based_vm_exec_control = vmcs_read32(CPU_BASED_VM_EXEC_CONTROL);
cpu_based_vm_exec_control |= CPU_BASED_VIRTUAL_NMI_PENDING;
vmcs_write32(CPU_BASED_VM_EXEC_CONTROL, cpu_based_vm_exec_control);
--
Gleb.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: VMX: Translate interrupt shadow when waiting on NMI window
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. 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: VMX: Translate interrupt shadow when waiting on NMI window
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. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: VMX: Translate interrupt shadow when waiting on NMI window
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? 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: VMX: Translate interrupt shadow when waiting on NMI window
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. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: VMX: Translate interrupt shadow when waiting on NMI window
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: VMX: Translate interrupt shadow when waiting on NMI window
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. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
