kvm: nVMX: reflect MTF VM-exits if injected by L1
PATCH v2 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")
v1 => v2:
- removed unused 'struct kvm_vcpu *vcpu' from the signature of helper function
arch/x86/kvm/vmx/nested.c | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-)
arch/x86/kvm/vmx/nested.c +18 -1
@@ -5533,6 +5533,23 @@ 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 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 +5650,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 (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
Quoted 55 lines · Oliver Upton
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.
Fixes 5f3d45e7f282 ("kvm/x86: add support for MONITOR_TRAP_FLAG")Signed-off-by Oliver Upton <[email protected]>Reviewed-by Peter Shier <[email protected]>Reviewed-by Jim Mattson <[email protected]>---
Parent commit:dbef2808af6c5("KVM: VMX: fix crash cleanup when KVM wasn't used")v1 => v2:
- removed unused 'structkvm_vcpu*vcpu' from the signature of helper functionarch/x86/kvm/vmx/nested.c | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-)arch/x86/kvm/vmx/nested.c +17
-0@@ -5533,6 +5533,23 @@ 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 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
arch/x86/kvm/vmx/nested.c bool nested_vmx_exit_reflected(struct kvm_vcpu *vcpu, u32 exit_reason) · line 5656
Quoted 8 lines
arch/x86/kvm/vmx/nested.c +1
-1@@ -5633,7 +5650,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 (vmcs12);case EXIT_REASON_MONITOR_INSTRUCTION :return nested_cpu_has (vmcs12,CPU_BASED_MONITOR_EXITING );case EXIT_REASON_PAUSE_INSTRUCTION :
Queued, thanks.
Paolo