kvm: nVMX: reflect MTF VM-exits if injected by L1
PATCH 1/1 kvm: nVMX: reflect MTF VM-exits if injected by L1
According to SDM 26.6.2, it is possible to inject an MTF VM-exit via the VM-entry interruption-information field regardless of the 'monitor trap flag' VM-execution control. KVM appropriately copies the VM-entry interruption-information field from vmcs12 to vmcs02. However, if L1 has not set the 'monitor trap flag' VM-execution control, KVM fails to reflect the subsequent MTF VM-exit into L1.
Fix this by consulting the VM-entry interruption-information field of vmcs12 to determine if L1 has injected the MTF VM-exit. If so, reflect the exit, regardless of the 'monitor trap flag' VM-execution control.
---
Parent commit: dbef2808af6c5 ("KVM: VMX: fix crash cleanup when KVM wasn't used")
arch/x86/kvm/vmx/nested.c | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-)
arch/x86/kvm/vmx/nested.c +19 -1
@@ -5533,6 +5533,24 @@ static bool nested_vmx_exit_handled_vmcs_access(struct kvm_vcpu *vcpu,return 1 & (b >> (field &7 )); } +static bool nested_vmx_exit_handled_mtf (struct kvm_vcpu *vcpu, +struct vmcs12 *vmcs12) +{ +u32 entry_intr_info = vmcs12->vm_entry_intr_info_field; + +if (nested_cpu_has_mtf (vmcs12)) +return true; + +/* +* An MTF VM-exit may be injected into the guest by setting the +* interruption-type to 7 (other event) and the vector field to 0. Such +* is the case regardless of the 'monitor trap flag' VM-execution +* control. +*/ +return entry_intr_info == (INTR_INFO_VALID_MASK + |INTR_TYPE_OTHER_EVENT ); +} +/* * Return 1 if we should exit from L2 to L1 to handle an exit, or 0 if we * should handle it ourselves in L0 (and then continue L2). Only call this
@@ -5633,7 +5651,7 @@ bool nested_vmx_exit_reflected(struct kvm_vcpu *vcpu, u32 exit_reason)case EXIT_REASON_MWAIT_INSTRUCTION :return nested_cpu_has (vmcs12,CPU_BASED_MWAIT_EXITING );case EXIT_REASON_MONITOR_TRAP_FLAG : -return nested_cpu_has_mtf (vmcs12); +return nested_vmx_exit_handled_mtf (vcpu, vmcs12);case EXIT_REASON_MONITOR_INSTRUCTION :return nested_cpu_has (vmcs12,CPU_BASED_MONITOR_EXITING );case EXIT_REASON_PAUSE_INSTRUCTION :
Signature · 1 line
2.26.0.110.g2183baf09c-goog
PATCH 1/1 x86: VMX: test MTF VM-exit event injection
SDM 26.6.2 describes how the VM-entry interruption-information field may be configured to inject an MTF VM-exit upon VM-entry. Ensure that an MTF VM-exit occurs when the VM-entry interruption-information field is configured appropriately by the host.
---
Parent commit: b16df9e ("arch-run: Add reserved variables to the default environ")
x86/vmx_tests.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-)
x86/vmx_tests.c +11 -2
@@ -4964,6 +4964,7 @@ static void test_vmx_preemption_timer(void)extern unsigned char test_mtf1;extern unsigned char test_mtf2;extern unsigned char test_mtf3; +extern unsigned char test_mtf4;static void test_mtf_guest (void ) {
@@ -4992,7 +4993,10 @@ static void test_mtf_guest(void)* documented, don't rely on assemblers enumerating the * instruction. Resort to hand assembly. */ - ".byte 0xf1;\n\t"); +".byte 0xf1;\n\t" +"vmcall;\n\t" +"test_mtf4:\n\t" + "mov $0, %eax;\n\t"); }static void test_mtf_gp_handler (struct ex_regs *regs)
@@ -5037,7 +5041,7 @@ static void report_mtf(const char *insn_name, unsigned long exp_rip)unsigned long rip =vmcs_read (GUEST_RIP );assert_exit_reason (VMX_MTF ); -report (rip == exp_rip,"MTF VM-exit after %s instruction. RIP: 0x%lx (expected 0x%lx)" , +report (rip == exp_rip,"MTF VM-exit after %s. RIP: 0x%lx (expected 0x%lx)" , insn_name, rip, exp_rip); }
@@ -5114,7 +5118,12 @@ static void vmx_mtf_test(void)disable_mtf ();enter_guest (); +skip_exit_vmcall ();handle_exception (DB_VECTOR , old_db); +vmcs_write (ENT_INTR_INFO ,INTR_INFO_VALID_MASK |INTR_TYPE_OTHER_EVENT ); +enter_guest (); +report_mtf ("injected MTF" , (unsigned long ) &test_mtf4); +enter_guest (); }/*
Signature · 1 line
2.26.0.110.g2183baf09c-goog
Re: [kvm-unit-tests PATCH] x86: VMX: test MTF VM-exit event injection
Re: [kvm-unit-tests PATCH] x86: VMX: test MTF VM-exit event injection
Quoted 2 lines · Peter Shier
Reviewed-by Peter Shier<[email protected]>
Gentle ping :) Paolo, I believe you've already taken the associated kernel commit for this test.
--
Thanks,
Oliver