ABCDEFGHIJKLMNOPQRSTUVWXYZAAABAC
1
SDM Description contains every piece of text from the SDM that describes MTF operation. Text was extracted in order of appearance in the May 2019 SDM Vol 3

Anywhere this spreadsheet uses the language "L1 gets MTF" the assumption is that L0 receives the MTF exit and reflects into L1		Condition describes the various circumstances under which a particular rule from the SDM may applyExpected Behavior in L1 is the result from L1's POV when the condition occurrs
Handled in HW: if 'N' then some software intervention beyond simply forwarding the MTF into VMCS02 is needed to achieve the expected behavior in L1		Work items as determined by this spreadsheet are here
2
SDM DescriptionConditionExpected Behavior in L1Handled in HW?NotesLast ReviewResonable to test?Test Priority
0=highest
3
If the “monitor trap flag” VM-execution control is 1 and VM entry is injecting a vectored event (see Section 26.5.1), an MTF VM exit is pending on the instruction boundary before the first instruction following the VM entry.VMCS12.MTF=1
L1 executes VMAUNCH/VMRESUME with VMCS12 specifying injection of vectored event
L1 gets MTF exit with RIP at 1st instruction of L2 event handlerYpshier 9-1-2019Y1
4
VMCS12.MTF=1
L0 handles some exit on behalf of L2 but does not emulate the L2 instruction, does not change L2 RIP
L0 resumes L2 specifying injection of vectored event

L1 gets MTF exit with RIP at 1st instruction of L2 event handlerYpshier 9-1-2019Y1
5
If VM entry is injecting a pending MTF VM exit (see Section 26.6.2), an MTF VM exit is pending on the instruction boundary before the first instruction following the VM entry. This is the case even if the “monitor trap flag” VM-execution control is 0.VMCS12.MTF=1
L0 has emulated an L2 instruction and advanced L2 RIP
L0 injects pending MTF exit into VMSC02
L1 gets MTF exit with L2 RIP where L0 advanced itYL0 will only inject an MTF into VMCS02 after emulating an L2 instruction.

pshier 9-1-2019Y0
6
VMCS.MTF=1 or VMCS.MTF=0
L1 executes VMLAUNCH/VMRESUME with VMCS12.interrupt info injecting MTF
i.e. L2 is running a hypervisor as well		L1 gets MTF at current L2 RIP and reflects it into L2NL1 could inject an MTF exit into L2 (in a multi-nested scenario e.g. L2 is also running a hypervisor). In that case L0 would copy the injection from the VMCS12 interrupt info field into VMCS02, L0 would get the MTF, reflect it into L1, L1 would then reflect the MTF into L2.

even if the "monitor trap flag" execution control is 0

This could happen in the mult-nested case where VMCS12.MTF=0 but it is doing MTF injection. SW must copy VMCS12.interrrupt info to VMCS02 even if VMCS12.MTF=0		pshier 9-1-2019Y3
7
If the “monitor trap flag” VM-execution control is 1, VM entry is not injecting an event, and a pending event (e.g., debug exception or interrupt) is delivered before an instruction can execute, an MTF VM exit is pending on the instruction boundary following delivery of the event (or any nested exception).VMCS12.MTF=1
L1 executes VMAUNCH/VMRESUME with VMCS12 not injecting event
Pending event delivered before 1st L2 instruction executes e.g. L2 has set TF or a breakpoint on that instruction and it is not intercepted by L0 or L1

Possible events are:
1) pending debug exceptions in vmcs02
2) instruction breakpoint
3) posted interrupt		L1 gets MTF exit with RIP at 1st instruction of L2 event handlerYpshier 9-1-2019Y1
8
VMCS12.MTF=1
L0 handles some exit on behalf of L2, does not emulate L2 instruction, does not change L2 RIP
L0 resumes L2, not injecting event
Pending event delivered before L2 instruction executes e.g. L2 has set TF or a breakpoint on that instruction and it is not intercepted by L0 or L1
L1 gets MTF exit with RIP at 1st instruction of L2 event handlerYpshier 9-1-2019Y1
9
VMCS12.MTF=1
L0 has emulated an L2 instruction and advanced RIP
L0 injects MTF exit into VMCS02
Pending event delivered before 1st L2 instruction e.g. L2 has set TF or a breakpoint on the instruction at new RIP
L1 gets MTF exit with RIP at 1st instruction of L2 event handlerYpshier 9-1-2019Y0
10
Suppose that the “monitor trap flag” VM-execution control is 1, VM entry is not injecting an event, and the first instruction following VM entry is a REP-prefixed string instruction:

—If the first iteration of the instruction causes a fault, an MTF VM exit is pending on the instruction boundary following delivery of the fault (or any nested exception).

—If the first iteration of the instruction does not cause a fault, an MTF VM exit is pending on the instruction boundary after that iteration.		VMCS12.MTF=1
L1 executes VMAUNCH/VMRESUME with VMCS12 not injecting event
or
L0 resumes L2, not injecting event
L2 RIP is at REP instruction
First iteration causes fault
L1 gets MTF exit with RIP at 1st instruction of L2 fault handlerYpshier 9-1-2019Y1
11
VMCS12.MTF=1
L1 executes VMAUNCH/VMRESUME with VMCS12 not injecting event
or
L0 resumes L2, not injecting event
L2 RIP is at REP instruction
First iteration does not cause fault
L1 gets MTF exit with RIP after 1st iterationY"RIP after first iteration" means that L2 RIP will be either:
1) At REP instruction if termination condition not met after iteration execution
2) After REP instruction if termination condition met after iteration execution		pshier 9-1-2019Y1
12
VMCS12.MTF=1
L0 has emulated a REP instruction on behalf of L2
Emulation causes fault
L0 injects fault into VMCS02		L1 gets MTF exit with RIP at 1st instruction of L2 fault handlerYThis presumes:
1. VMCS02.MTF=1
2. VMCS02.interrupt info specifies the fault injection
3. HW delivers the fault and exits on MTF at start of L2 fault handler.		pshier 9-1-2019Y0
13
VMCS12.MTF=1
L0 has emulated a REP instruction on behalf of L2
Emulation does not cause fault
L0 injects MTF into VMCS02		L1 gets MTF exit with RIP after 1st iterationYThis only works if the emulator resumes the VM after every iteration and does not do the whole REP in a single swoop and advance RIP to after the REP.
If REP emulation does not work this way today it is very low priority for nested MTF support because it would only come into play if L1 passed through I/O ports to L2 and L2 did REP INS/OUTS on those ports or REP MOVES on MMIO regions passed through to L2		pshier 9-1-2019Y0
14
Suppose that the “monitor trap flag” VM-execution control is 1, VM entry is not injecting an event, and the first instruction following VM entry is the XBEGIN instruction. In this case, an MTF VM exit is pending at the fallback instruction address of the XBEGIN instruction. This behavior applies regardless of whether advanced debugging of RTM transactional regions has been enabled (see Section 16.3.7, “RTM-Enabled Debugger Support,” of Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1).VMCS12.MTF=1
L1 VMLAUNCH/VMRESUME not injecting event
L2 RIP at XBEGIN
L2.RTM disabled which could be one of the following:
L2.DR7.RTM=0 and L2.IA32_DEBUGCTL.RTM=0
L2.DR7.RTM=0 and L2.IA32_DEBUGCTL.RTM=1
L2.DR7.RTM=1 and L2.IA32_DEBUGCTL.RTM=0		L1 gets MTF at fallback addressYAssumption is that L0 never emulates XBEGINpshier 9-1-2019Y1
15
VMCS12.MTF=1
L1 VMLAUNCH/VMRESUME not injecting event
L2 RIP at XBEGIN
L2.RTM enabled because
L2.DR7.RTM=1 and L2.IA32_DEBUGCTL.RTM=1		L1 gets MTF at fallback addressYThis case will not happen because KVM does not virtualize RTM. See kvm_set_msr_common handling of MSR_IA32_DEBUGCTLMSR. Attempting to enable RTM will result in #GP injected into L2pshier 11-11-2019N4
16
Suppose that the “monitor trap flag” VM-execution control is 1, VM entry is not injecting an event, and the first instruction following VM entry is neither a REP-prefixed string instruction or the XBEGIN instruction:

—If the instruction causes a fault, an MTF VM exit is pending on the instruction boundary following delivery of the fault (or any nested exception).

—If the instruction does not cause a fault, an MTF VM exit is pending on the instruction boundary following execution of that instruction. If the instruction is INT1, INT3, or INTO, this boundary follows delivery of any software exception. If the instruction is INT n, this boundary follows delivery of a software interrupt. If the instruction is HLT, the MTF VM exit will be from the HLT activity state. No MTF VM exit occurs if another VM exit occurs before reaching the instruction boundary on which an MTF VM exit would be pending (e.g., due to an exception or triple fault).
VMCS12.MTF=1
L1 VMLAUNCH/VMRESUME not injecting event
L2 RIP not at XBEGIN/REP
First L2 instruction causes fault
L1 gets MTF at RIP of 1st instruction of L2 fault handlerYpshier 9-1-2019Y1
17
VMCS12.MTF=1
L1 VMLAUNCH/VMRESUME not injecting event
L2 RIP not at XBEGIN/REP/INT1/INT3/INTO/INTn/HLT
First L2 instruction does not cause fault
L1 gets MTF at RIP of 2nd instructionYpshier 9-1-2019Y1
18
VMCS12.MTF=1
L1 VMLAUNCH/VMRESUME not injecting event
First L2 instruction does not cause fault
L2 RIP at INT1/INT3/INTO
L1 gets MTF at RIP of 1st instruction of exception handlerYpshier 9-1-2019Y1
19
VMCS12.MTF=1
L1 VMLAUNCH/VMRESUME not injecting event
First L2 instruction does not cause fault
L2 RIP at INTn		L1 gets MTF at RIP of 1st instruction of interrupt handlerYpshier 9-1-2019Y1
20
VMCS12.MTF=1
L1 VMLAUNCH/VMRESUME not injecting event
First L2 instruction does not cause fault
L2 RIP at HLT
L1 intercepts HLT		L1 gets MTF in HLT activity state, RIP at instruction following HLT


YL0 reflects the MTF into L1 with VMCS12.activity state=HLT
If L1 does a VMRESUME of L2 HW will generate the HLT exit and L0 will reflect it into L1
pshier 9-1-2019Y1
21
VMCS12.MTF=1
L1 VMLAUNCH/VMRESUME not injecting event
First L2 instruction does not cause fault
L2 RIP at HLT
L1 does not intercept HLT		L1 gets MTF in HLT activity state, RIP at instruction following HLT


Npshier 9-1-2019Y1
22
VMCS12.MTF=1
L1 VMLAUNCH/VMRESUME not injecting event
L2 RIP not at XBEGIN/REP
First L2 instruction does not cause fault
A different VM exit occurs before instruction boundary for MTF		No MTF occurrsYpshier 9-1-2019Y1
23
VMCS12.MTF=1
L0 has emulated instruction for L2 and advanced L2 RIP
L0 VMRESUME of VMCS02 not injecting event
New L2 RIP not at XBEGIN/REP
L0 determines a different VM exit is required before VMRESUME VMCS02 e.g. emulation generates exception
L0 does not inject an MTF into VMCS02
L0 reflects or injects the other VM exit into L1		NDetails are in next rulepshier 9-1-2019Y0
24
No MTF VM exit occurs if another VM exit occurs before reaching the instruction boundary on which an MTF VM exit would be pending (e.g., due to an exception or triple fault).VMCS12.MTF=1
L0 has emulated instruction for L2
Emulation generated exception e.g. #GP
L1 intercepts exception		No MTF occurrs
L0 queues the exception, but before resuming L2, L0 checks to see if L1 intercepts the exception and emulates a VM-exit.		Ypshier 9-1-2019Y0
25
VMCS12.MTF=1
L0 has emulated instruction for L2
Emulation generated exception e.g. #GP
L1 does not intercept exception
L0 resumes L2, injecting the exception
MTF occurs at RIP of 1st instruction of L2 exception handler
Ypshier 9-1-2019Y0
26
VMCS12.MTF=1
L0 has emulated instruction for L2
Emulation generated a double fault contributory exception e.g. #GP (see SDM May 2019 Vol 3 Table 6-5 " Conditions for Generating a Double Fault")
L1 does not intercept contibutory exception
Exception is promoted to double fault by HW
L1 does intercept double fault		L0 resumes L2, injecting the exception
HW promotes to #DF because of second contributory exception on 1st instruction of L2 exception handler e.g. stack fault or another #GP
Exception exit occurs for #DF and L0 reflects it to L1 		NFrom emulation POV rule is the same as prior condition i.e. emulation generates exception and L0 injects exception into L2pshier 9-1-2019N1
27
VMCS12.MTF=1
L0 has emulated instruction for L2
Emulation generated a double fault contributory exception e.g. #GP (see SDM May 2019 Vol 3 Table 6-5 " Conditions for Generating a Double Fault")
L1 does not intercept contibutory exception
Exception is promoted to double fault by HW
L1 does not intercept double fault		L0 resumes L2, injecting the exception
HW promotes to #DF because of second contributory exception on 1st instruction of L2 exception handler e.g. stack fault or another #GP
L0 does not intercept #DF so HW delivers it to L2.
L2 #DF handler runs and MTF occurrs at RIP of 1st instruction of L2 #DF handler		YFrom emulation POV rule is the same as prior condition i.e. emulation generates exception and L0 injects exception into L2pshier 9-1-2019N1
28
VMCS12.MTF=1
L0 has emulated instruction for L2
Emulation generated a double fault contributory exception e.g. #GP (see SDM May 2019 Vol 3, Table 6-5 " Conditions for Generating a Double Fault")
L1 does not intercept contributory exception
Exception is promoted to double fault by HW
L1 does not intercept double fault
HW promotes exception to triple fault
L0 resumes L2, injecting the exception
HW promotes to #DF because of second contributory exception on 1st instruction of L2 exception handler e.g. stack fault or another #GP
No exception exit occurs for #DF
HW promotes to triple fault
L2 exits to L0 on triple fault (exit reason 2, guest activity state=shutdown)
L0 reflects triple fault to L1		Npshier 9-1-2019N1
29
An MTF VM exit occurs on the instruction boundary on which it is pending unless a higher priority event takes precedence or the MTF VM exit is blocked due to the activity state:

• System-management interrupts (SMIs), INIT signals, and higher priority events take priority over MTF VM exits. MTF VM exits take priority over debug-trap exceptions and lower priority events.

• No MTF VM exit occurs if the processor is in either the shutdown activity state or wait-for-SIPI activity state. If a non-maskable interrupt subsequently takes the logical processor out of the shutdown activity state without causing a VM exit, an MTF VM exit is pending after delivery of that interrupt. Special treatment may apply to Intel SGX instructions or if the logical processor is in enclave mode. See Section 42.2 for details.		VMCS12.MTF=1
SMI occurs		Exit with reason 28 - SMM with pending MTFNNot supported in GCE today. May need to do this for upstream one day. If so will need to pay particular attention to section 34.14.1 "Default Treatment of SMI Delivery" which describes "VMX-critical state".
pshier 11-14-2019N4
30
VMCS12.MTF=1
KVM has exited to user space
User space sends sends virtual INIT signal using IOCTL KVM_SET_MP_STATE with state=KVM_MP_STATE_INIT_RECEIVED		No MTF - see notes to the right
vCPU enters virtual "wait for SIPI" state		Nvcpu_enter_guest (x86.c) will only call kvm_apic_accept_events when in this state (i.e. it will not run the vCPU until the state changes)
kvm_apic_accept_events will not do anything until SIPI is received so vCPU is in virtual "wait for SIPI" state

Note: no new SW changes needed for this rule		pshier 9-2-2019N4
31
VMCS12.MTF=1
L2 is running and VM has > 1 vCPUS and a peer vCPU running L1 sends INIT to the L2 vCPU's local APIC
INIT IPI causes external interrupt exit from L2 to L0
No MTF - see notes to the right
vCPU is reset and either enters virtual "wait for SIPI" state or if it is the BSP (bootstrap processor) it becomes runnable		NSource vCPU sends INIT IPI to target by writing to source's local APIC

Source local APIC sets KVM_APIC_INIT in target kvm_lapic.pending_events, sets KVM_REQ_EVENT on target vCPU and does a "kick" i.e. sends HW IPI to force it out of VMX non-root if needed.

Target vCPU in next run of vcpu_enter_guest (x86.c) calls kvm_apic_accept_events which sees KVM_APIC_INIT state and calls kvm_vcpu_reset and sets KVM_MP_STATE_INIT_RECEIVED. This puts the vCPU into virtual "wait for SIPI" state or, for the BSP vCPU, makes it runnable.		pshier 9-2-2019N3
32
VMCS12.MTF=1
L2 causes debug trap exception e.g. L2.RFLAGS.TF=1		L1 gets MTF with L2 RIP at start of L2 exception handlerYpshier 9-2-2019Y1
33
VMCS12.MTF=1
L0 has emulated an instruction on behalf of L2
Emulated instruction causes debug trap exception e.g. VMCS02.GUEST_RFLAGS.TF=1
L0 injects MTF into VMCS02		L0 reflects MTF into L1 and populates pending debug exceptions in VMCS01 with the pending debug trap.
Pending debug exception is copied from VMCS01 to VMCS02 on subsequent L2 VMRESUME		Ypshier 9-2-2019Y0
34
VMCS12.MTF=1
L2 is running
HW puts CPU into shutdown state e.g. due to triple fault		No MTF.
L0 receives triple fault exit (exit reason=2) and reflects it to L1		YNo new SW needed here.pshier 9-2-2019N4
35
VMCS12.MTF=1
L1 launches L2 in shutdown state		No MTF.
NKVM does not support launch into shutdown state.
L2 launch will fail
See check_vmentry_prereqs		pshier 9-2-2019N4
36
VMCS12.MTF=1
CPU enters wait-for-SIPI state - HW initiated		A CPU cannot enter wait-for-SIPI state while in VMX operation. This will never happenNpshier 11-14-2019N99
37
VMCS12.MTF=1
CPU enters wait-for-SIPI state - SW initiated		No MTF exitNSee case above for virtual INIT received from user space with KVM_SET_MP_STATEpshier 9-2-2019N4
38
VMCS12.MTF=1
CPU enters shutdown state while running L2
NMI occurrs but does not cause VM exit		This is not possibleYIt is not possible to get L2 into HW shutdown state.
If CR4.MCE=0 while in L2 and an MCE occurred, that would put L2 into shutdown state but -
KVM does not let a guest set this bit to zero (vmx_set_cr4 in vmx.c).
A "machine check during VM entry" exit (reason=41) is handled inline in vcpu_run and it machine-checks the host (see vmx_complete_atomic_exit in vmx.c)

NMI while in shutdown state cannot cause a VM exit.
See SDM (26.7.2 May 2019) "Activity State":

The shutdown state blocks external interrupts and SIPIs. External interrupts that arrive while a logical
processor is in the shutdown state and in VMX non-root operation do not cause VM exits even if the
“external-interrupt exiting” VM-execution control is 1.
pshier 11-14-2019N99
39
Fields relevant to VM-entry event injection must be set properly. These fields are the VM-entry interruption-information field (see Table 24-13 in Section 24.8.3), the VM-entry exception error code, and the VM-entry instruction length. If the valid bit (bit 31) in the VM-entry interruption-information field is 1, the following must hold:

— The field’s interruption type (bits 10:8) is not set to a reserved value. Value 1 is reserved on all logical processors; value 7 (other event) is reserved on logical processors that do not support the 1-setting of the “monitor trap flag” VM-execution control.

— The field’s vector (bits 7:0) is consistent with the interruption type:
If the interruption type is non-maskable interrupt (NMI), the vector is 2.
If the interruption type is hardware exception, the vector is at most 31.
If the interruption type is other event, the vector is 0 (pending MTF VM exit).
VMCS12.MTF=1
L1 executes VMLAUNCH/VMRESUME
VMCS02 interrupt-information type is "other" (7)
VMCS02 interrupt-information vector is non-zero		VM entry fails, L1 does not runYThis condition describes a possible bug in KVM which HW would catchpshier 9-2-2019N4
40
VMCS12.MTF=1
VMCS12 interrupt-information type is "other" (7)
VMCS12 interrupt-information vector is non-zero
L1 executes VMLAUNCH/VMRESUME		L1 gets VM entry failureNcheck_vmentry_prereqs (vmx.c) checks both of these conditionspshier 9-2-2019Y2
41
VM Entry
26.3.1.5 Checks on Guest Non-Register State
The following checks are performed on fields in the guest-state area corresponding to non-register state:
Activity state.
—If the valid bit (bit 31) in the VM-entry interruption-information field is 1, the interruption to be delivered (as defined by interruption type and vector) must not be one that would normally be blocked while a logical processor is in the activity state corresponding to the contents of the activity-state field. The following items enumerate the interruptions (as specified in the VM-entry interruption-information field) whose injection is allowed for the different activity states:
HLT. The only events allowed are the following:
— Those with interruption type external interrupt or non-maskable interrupt (NMI).
— Those with interruption type hardware exception and vector 1 (debug exception) or vector 18 machine-check exception).
— Those with interruption type other event and vector 0 (pending MTF VM exit).		VMCS12.MTF
L0 VMLAUNCH/VMRESUME VMCS02 in HLT activity state and injecting MTF		L1 receives MTF exit with L2 in HLT state.

NNote - Per 26.7.8 "Pending MTF Exits" and 27.1 "ARCHITECTURAL STATE BEFORE A VM EXIT" - the MTF exit takes L2 out of HLT activity state when L2 restarts after MTF exit (assuming that L1 does not put it back into HLT state)pshier 9-2-2019Y2
42
If a pending debug exception is delivered after VM entry, it has the priority of “traps on the previous instruction” (see Section 6.9 in the Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A). Thus, INIT signals and system-management interrupts (SMIs) take priority over such an exception, as do VM exits induced by the TPR threshold (see Section 26.6.7) and pending MTF VM exits (see Section 26.6.8). The exception takes priority over any pending non-maskable interrupt (NMI) or external interrupt and also over VM exits due to the 1-settings of the “interrupt-window exiting” and “NMI-window exiting” VM-execution controls.

A pending debug exception delivered after VM entry causes a VM exit if the bit 1 (#DB) is 1 in the exception bitmap. If it does not cause a VM exit, it updates DR6 normally.		The exception takes priority over any pending non-maskable interrupt (NMI) or external interrupt and also over VM exits due to the 1-settings of the “interrupt-window exiting” and “NMI-window exiting” VM-execution controls.

"The exception" in the above refers to debug exceptions. As MTF takes precedence over debug exceptions this implies that MTF also takes precedence over all the exits mentioned above.
43
VMCS12.MTF=1
L1 has turned on NMI exiting in VMCS12
L2 is running
A peer L1 vCPU sends an NMI IPI to the vCPU running L2
L1 gets MTF with L2 RIP at first instruction of L2 NMI handler
L1 gets NMI exit after the MTF		YSource vCPU writes to its own local APIC's ICR with delivery mode=NMI (vector is ignored) and target's destination.
__apic_accept_irq on target calls kvm_make_request(KVM_REQ_NMI) on target vCPU and then kvm_vcpu_kick to send a HW IPI and take the target out of L2.

Target returns to run loop where it sees the KVM_REQ_NMI. It records the NMI request, sets KVM_REQ_EVENT and in that processing it calls inject_pending_event which calls kvm_x86_ops->set_nmi.
vmx_inject_nmi writes the NMI to the VMCS02 interrupt-information field.

Run loop re-enters L2 and HW will give precedence to the MTF which will have RIP on first instruction of L2 NMI handler

On L2 resume HW should generate the NMI exit		pshier 9-2-2019N3
44
VMCS12.MTF=1
L1 has not turned on NMI exiting in VMCS12
L2 is running
A peer L1 vCPU sends an NMI IPI to the vCPU running L2
L1 gets MTF with L2 RIP at first instruction of L2 NMI handlerYpshier 9-2-2019N3
45
VMCS12.MTF=1
L1 has turned on external interrupt exiting in VMCS12
L2 is running
A peer L1 vCPU sends an IPI with delivery mode=fixed and an arbitrary vector to the vCPU running L2
L1 get MTF with L2 RIP at first instruction of interrupt handler
L1 gets external interrupt exit after the MTF		Ypshier 9-2-2019N3
46
VMCS12.MTF=1
L1 has not turned on external interrupt exiting in VMCS12
L2 is running
A peer L1 vCPU sends an IPI with delivery mode=fixed and an arbitrary vector to the vCPU running L2
L1 get MTF with L2 RIP at first instruction of interrupt handlerYpshier 9-2-2019N3
47
VMCS12.MTF=1
L1 has turned on interrupt window exiting in VMCS12
Interrupt window arises when L2 running		L1 gets MTF followed by interrupt window exitYpshier 9-2-2019N2
48
VMCS12.MTF=1
L1 has turned on NMI window exiting in VMCS12
NMI window arises when L2 running		L1 gets MTF followed by NMI window exitYpshier 9-2-2019N2
49
The pending debug exceptions field is saved as clear for all VM exits except the following:

— A VM exit caused by an INIT signal, a machine-check exception, or a system-management interrupt (SMI).
— A VM exit with basic exit reason “TPR below threshold”,2 “virtualized EOI”, “APIC write”, or “monitor trap flag.”
— VM exits that are not caused by debug exceptions and that occur while there is MOV-SS blocking of debug exceptions.

— Suppose that a VM exit is due to an INIT signal, a machine-check exception, or an SMI; or that a VM exit has basic exit reason “TPR below threshold” or “monitor trap flag.” In this case, the value saved sets bits corresponding to the causes of any debug exceptions that were pending at the time of the VM exit. If the VM exit occurs immediately after VM entry, the value saved may match that which was loaded on VM entry (see Section 26.6.3). Otherwise, the following items apply:
Bit 12 (enabled breakpoint) is set to 1 in any of the following cases:
— If there was at least one matched data or I/O breakpoint that was enabled in DR7.
— If it had been set on VM entry, causing there to be valid pending debug exceptions (see Section 26.6.3) and the VM exit occurred before those exceptions were either delivered or lost.
— If the XBEGIN instruction was executed immediately before the VM exit and advanced debugging of RTM transactional regions had been enabled (see Section 16.3.7, “RTM-Enabled Debugger Support,” of Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1). (This does not apply to VM exits with basic exit reason “monitor trap flag.”)
In other cases, bit 12 is cleared to 0.
Bit 14 (BS) is set if RFLAGS.TF = 1 in either of the following cases:
— IA32_DEBUGCTL.BTF = 0 and the cause of a pending debug exception was the execution of a single instruction.
— IA32_DEBUGCTL.BTF = 1 and the cause of a pending debug exception was a taken branch.
Bit 16 (RTM) is set if a debug exception (#DB) or a breakpoint exception (#BP) occurred inside an RTM region while advanced debugging of RTM transactional regions had been enabled. (This does not apply to VM exits with basic exit reason “monitor trap flag.”)
Simplified statement of this rule

An MTF exit will have the pending debug exceptions field populated with either
1) The bits present in the field at time of VM entry
OR
2) The following:
Bit 12=1 (enabled breakpoint) for matched data or I/O breakpoint enabled in DR7
Bit 12=1 if it was set on VM entry and MTF occurred before exception was delivered
Bit 12=0 if XBEGIN executed before MTF and RTM enabled is enabled in L2
Bit 12=0 for all other cases

Bit 14=1 (BS - single step triggered) if L2.RFLAGS.TF=1 and L2.IA32_DEBUGCRL.BTF=0 and single instruction execution caused debug exception
Bit 14=1 if L2.IA32_DEBUGCRL.BTF=1 and branch taken caused debug exception

Bit 16=0 (RTM) if #DB or #BP occurred in RTM region with RTM enabled (note: this can only happen on XBEGIN because MTF will abort the transaction and L2 RIP at MTF exit will be at fallback address)
50
VMCS12.MTF=1
L2 incurs debug exception e.g. L2.RFLAGS.TF=1
L1 gets MTF exit with RIP at 1st instruction of L2 event handler
Pending debug exceptions fiield is populated e.g. VMCS01.PendingDebugExceptions.BS=1 for the L2 TF		YSW must copy pending debug exceptions field from VMCS02 to VMCS01 before reflecting the MTF into L1pshier 9-2-2019Y0
51
VMCS12.MTF=1
L0 has emulated an L2 instruction and advanced RIP
No debug exception occurs during emulation.
L0 injects MTF exit into VMCS02 at new RIP
L2 incurs debug exception at new RIP e.g. L2 breakpoint hit
L1 gets MTF exit with RIP at 1st instruction of L2 event handler
Pending debug exceptions fiield is populated i.e. VMCS01.PendingDebugExceptions.B0=1 for the L2 breakpoint		NSW must copy pending debug exceptions field from VMCS02 to VMCS01 before reflecting the MTF into L1

Note: the emulation condition here is for illustrative purposes only. L0 is following the simple post-emulation rule and injecting the MTF at the new L2 RIP. The rule implied here is that when L0 gets an MTF and there are pending debug exceptions, they must be included in the reflected MTF to L1		pshier 9-2-2019Y0
52
VMCS12.MTF=1
L2 executes XBEGIN and L2 incurs debug exception e.g. breakpoint hit
L2.DR7.RTM=1 and L2.IA32_DEBUGCTL.RTM=1		N/AYNot possible because KVM does not virtualize RTMpshier 9-2-2019Y0
53
VMCS12.MTF=1
#DB occured in RTM region
L2.DR7.RTM=1 and L2.IA32_DEBUGCTL.RTM=1"		N/AYThis condition is not possible because the XBEGIN would have caused an MTF at the fallback address and exited the transactionpshier 9-2-2019N4
54
VMCS12.MTF=1
#BP occured in RTM region
L2.DR7.RTM=1 and L2.IA32_DEBUGCTL.RTM=1"		N/AYThis condition is not possible because the XBEGIN would have caused an MTF at the fallback address and exited the transactionpshier 9-2-2019N4