On Wed, Jul 6, 2022 at 4:55 AM Maxim Levitsky <mlevitsk@xxxxxxxxxx> wrote: > 1. Since #SMI is higher priority than the #MTF, that means that unless dual monitor treatment is used, > and the dual monitor handler figures out that #MTF was pending and re-injects it when it > VMRESUME's the 'host', the MTF gets lost, and there is no way for a normal hypervisor to > do anything about it. > > Or maybe pending MTF is saved to SMRAM somewhere. > > In case you will say that I am inventing this again, I am saying now that the above is > just a guess. This is covered in the SDM, volume 3, section 31.14.1: "Default Treatment of SMI Delivery:" The pseudocode above makes reference to the saving of VMX-critical state. This state consists of the following: (1) SS.DPL (the current privilege level); (2) RFLAGS.VM2; (3) the state of blocking by STI and by MOV SS (see Table 24-3 in Section 24.4.2); (4) the state of virtual-NMI blocking (only if the processor is in VMX non-root oper- ation and the “virtual NMIs” VM-execution control is 1); and (5) an indication of whether an MTF VM exit is pending (see Section 25.5.2). These data may be saved internal to the processor or in the VMCS region of the current VMCS. Processors that do not support SMI recognition while there is blocking by STI or by MOV SS need not save the state of such blocking. Saving VMX-critical state to SMRAM is not documented as an option. > 2. For case 7, what about General Detect? Since to raise it, the CPU needs to decode the instruction > Its more natural to have it belong to case 9. I think it actually belongs in case 10. The Intel table says, "Fault-class Debug Exceptions (#DB due to instruction breakpoint)," and I probably just blindly added "General Detect," because it is a fault-class debug exception. You're right; the CPU has to decode the instruction before it can deliver a #DB for general detect.
