x86: nVMX: Fix NMI/INTR-window tests

From: Nadav Amit <[email protected]>

According to Intel SDM 26.3.1.5 "Checks on Guest Non-Register State", if the activity state is HLT, the only events that can be injected are NMI, MTF and "Those with interruption type hardware exception and vector 1 (debug exception) or vector 18 (machine-check exception)."

Two tests, verify_nmi_window_exit() and verify_intr_window_exit(), try to do something that real hardware disallows (i.e., fail the VM-entry) by injecting #UD in HLT-state. Inject #DB instead as the injection should succeed in these tests.

Cc Jim Mattson <[email protected]>

Cc Sean Christopherson <[email protected]>

Signed-off-by Nadav Amit <[email protected]>

From: Nadav Amit <[email protected]>
Date: Wed, May 8, 2019 at 10:47 AM
To: Paolo Bonzini
Cc: <[email protected]>, Nadav Amit, Jim Mattson, Sean Christopherson

Quoted 7 lines

From: Nadav Amit <[email protected]>

According to Intel SDM 26.3.1.5 "Checks on Guest Non-Register State", if the activity state is HLT, the only events that can be injected are NMI, MTF and "Those with interruption type hardware exception and vector 1 (debug exception) or vector 18 (machine-check exception)."

Quoted 8 lines

Two tests, verify_nmi_window_exit() and verify_intr_window_exit(), try to do something that real hardware disallows (i.e., fail the VM-entry) by injecting #UD in HLT-state. Inject #DB instead as the injection should succeed in these tests.

Cc Jim Mattson <[email protected]>

Cc Sean Christopherson <[email protected]>

Signed-off-by Nadav Amit <[email protected]>

Reviewed-by Jim Mattson <[email protected]>

Thanks for the fix!

It has always bothered me that there is no easy way to validate a kvm-unit-test on physical hardware. Do you have a mechanism for doing so? If so, would you be willing to share?

I don't suppose you have a patch for kvm to fail the VM-entry in this case?

I just hope that this support would convince you, and others, to prefer (when possible) kvm-unit-tests over the selftest environment.

Quoted 2 lines · Nadav Amit

I just hope that this support would convince you, and others, to prefer (when possible) kvm-unit-tests over the selftest environment.

kvm-unit-tests are not superseded by selftests; selftests are mostly meant to test the KVM API. While they are more easily debuggable than kvm-unit-tests, the benefit is not big enough to justify the effort of rewriting everything.

Furthermore, being able to run kvm-unit-tests on bare metal is useful, even if it's not something that people commonly do, and consistent with KVM's design of not departing radically for what bare metal does.

I’m sorry for not collecting the patches into a set, but I know that it would just cause me to resend all of them for individual patch issue.

From: Nadav Amit <[email protected]>

Intel SDM 26.6.5 says regarding interrupt-window exiting that: "These events wake the logical processor if it just entered the HLT state because of a VM entry." A similar statement is told about NMI-window exiting.

However, running tests which are similar to verify_nmi_window_exit() and verify_intr_window_exit() on bare-metal suggests that real CPUs do not wake up. Until someone figures what the correct behavior is, just reset the activity state to "active" after each test to prevent the whole test-suite from getting stuck.

Cc Jim Mattson <[email protected]>

Cc Sean Christopherson <[email protected]>

Signed-off-by Nadav Amit <[email protected]>

From: Nadav Amit <[email protected]>
Date: Wed, May 8, 2019 at 10:47 AM
To: Paolo Bonzini
Cc: <[email protected]>, Nadav Amit, Jim Mattson, Sean Christopherson

Quoted 13 lines

From: Nadav Amit <[email protected]>

Intel SDM 26.6.5 says regarding interrupt-window exiting that: "These events wake the logical processor if it just entered the HLT state because of a VM entry." A similar statement is told about NMI-window exiting.

However, running tests which are similar to verify_nmi_window_exit() and verify_intr_window_exit() on bare-metal suggests that real CPUs do not wake up. Until someone figures what the correct behavior is, just reset the activity state to "active" after each test to prevent the whole test-suite from getting stuck.

Quoted 3 lines

Cc Jim Mattson <[email protected]>

Cc Sean Christopherson <[email protected]>

Signed-off-by Nadav Amit <[email protected]>

Reviewed-by Jim Mattson <[email protected]>

I think I have been assuming that "wake the logical processor" means "causes the logical processor to enter the 'active' activity state." Maybe that's not what "wake" means?

Quoted 23 lines · Jim Mattson

From: Nadav Amit <[email protected]>
Date: Wed, May 8, 2019 at 10:47 AM
To: Paolo Bonzini
Cc: <[email protected]>, Nadav Amit, Jim Mattson, Sean Christopherson

Quoted 16 lines

From: Nadav Amit <[email protected]>

Intel SDM 26.6.5 says regarding interrupt-window exiting that: "These events wake the logical processor if it just entered the HLT state because of a VM entry." A similar statement is told about NMI-window exiting.

However, running tests which are similar to verify_nmi_window_exit() and verify_intr_window_exit() on bare-metal suggests that real CPUs do not wake up. Until someone figures what the correct behavior is, just reset the activity state to "active" after each test to prevent the whole test-suite from getting stuck.

Cc Jim Mattson <[email protected]>

Cc Sean Christopherson <[email protected]>

Signed-off-by Nadav Amit <[email protected]>

Quoted 5 lines

Reviewed-by Jim Mattson <[email protected]>

I think I have been assuming that "wake the logical processor" means "causes the logical processor to enter the 'active' activity state." Maybe that's not what "wake" means?

I really don’t know. Reading the specifications, I thought that the test is valid. I don’t manage to read it any differently than you did.

From: Nadav Amit <[email protected]>

Intel SDM 26.6.5 says regarding interrupt-window exiting that: "These events wake the logical processor if it just entered the HLT state because of a VM entry." A similar statement is told about NMI-window exiting.

However, running tests which are similar to verify_nmi_window_exit() and verify_intr_window_exit() on bare-metal suggests that real CPUs do not wake up. Until someone figures what the correct behavior is, just reset the activity state to "active" after each test to prevent the whole test-suite from getting stuck.

Cc Jim Mattson <[email protected]>

Cc Sean Christopherson <[email protected]>

Signed-off-by Nadav Amit <[email protected]>

---
 x86/vmx_tests.c | 2 ++
 1 file changed, 2 insertions(+)

x86/vmx_tests.c +0 -0

index f921286..2d6b12d 100644

x86/vmx_tests.c +1 -0

 }
 
 static void vmx_nmi_window_test(void)

@@ -7199,6 +7200,7 @@ static void verify_intr_window_exit(u64 rip)
 	report("Activity state (%ld) is 'ACTIVE'",
 	       vmcs_read(GUEST_ACTV_STATE) == ACTV_ACTIVE,
 	       vmcs_read(GUEST_ACTV_STATE));
+	vmcs_write(GUEST_ACTV_STATE, ACTV_ACTIVE);
 }
 
 static void vmx_intr_window_test(void)

Signature · 1 line

2.17.1

Quoted 20 lines · Nadav Amit

From: Nadav Amit <[email protected]>

Intel SDM 26.6.5 says regarding interrupt-window exiting that: "These events wake the logical processor if it just entered the HLT state because of a VM entry." A similar statement is told about NMI-window exiting.

However, running tests which are similar to verify_nmi_window_exit() and verify_intr_window_exit() on bare-metal suggests that real CPUs do not wake up. Until someone figures what the correct behavior is, just reset the activity state to "active" after each test to prevent the whole test-suite from getting stuck.

Cc Jim Mattson <[email protected]>

Cc Sean Christopherson <[email protected]>

Signed-off-by Nadav Amit <[email protected]>

---
x86/vmx_tests.c | 2 ++

1 file changed, 2 insertions(+)

x86/vmx_tests.c static void verify_nmi_window_exit(u64 rip) · line 7066

Quoted 9 lines

x86/vmx_tests.c +1 -0

index f921286..2d6b12d 100644
@@ -7063,6 +7063,7 @@ static void verify_nmi_window_exit(u64 rip)
 	report("Activity state (%ld) is 'ACTIVE'",
 	       vmcs_read(GUEST_ACTV_STATE) == ACTV_ACTIVE,
 	       vmcs_read(GUEST_ACTV_STATE));
+	vmcs_write(GUEST_ACTV_STATE, ACTV_ACTIVE);

Don't you need to remove (or modify) the above report() as well to avoid failing the current test?

Quoted 23 lines · Sean Christopherson

Quoted 20 lines · Nadav Amit

From: Nadav Amit <[email protected]>

Intel SDM 26.6.5 says regarding interrupt-window exiting that: "These events wake the logical processor if it just entered the HLT state because of a VM entry." A similar statement is told about NMI-window exiting.

However, running tests which are similar to verify_nmi_window_exit() and verify_intr_window_exit() on bare-metal suggests that real CPUs do not wake up. Until someone figures what the correct behavior is, just reset the activity state to "active" after each test to prevent the whole test-suite from getting stuck.

Cc Jim Mattson <[email protected]>

Cc Sean Christopherson <[email protected]>

Signed-off-by Nadav Amit <[email protected]>

---
x86/vmx_tests.c | 2 ++

1 file changed, 2 insertions(+)

Quoted 12 lines

x86/vmx_tests.c static void verify_nmi_window_exit(u64 rip) · line 7066

Quoted 9 lines

x86/vmx_tests.c +1 -0

index f921286..2d6b12d 100644
@@ -7063,6 +7063,7 @@ static void verify_nmi_window_exit(u64 rip)
 	report("Activity state (%ld) is 'ACTIVE'",
 	       vmcs_read(GUEST_ACTV_STATE) == ACTV_ACTIVE,
 	       vmcs_read(GUEST_ACTV_STATE));
+	vmcs_write(GUEST_ACTV_STATE, ACTV_ACTIVE);

Don't you need to remove (or modify) the above report() as well to avoid failing the current test?

Thanks for checking it (in your second email).

So should I remove this test completely for v2? Or do you have any different test you want to run?