2017-09-25 10:09+0200, Ladi Prosek: > Entering SMM while running in guest mode wasn't working very well because several > pieces of the vcpu state were left set up for nested operation. > > Some of the issues observed: > > * L1 was getting unexpected VM exits (using L1 interception controls but running > in SMM execution environment) > * MMU was confused (walk_mmu was still set to nested_mmu) > * INTERCEPT_SMI was not emulated for L1 (KVM never injected SVM_EXIT_SMI) > > Intel SDM actually prescribes the logical processor to "leave VMX operation" upon > entering SMM in 34.14.1 Default Treatment of SMI Delivery. AMD doesn't seem to > document this but they provide fields in the SMM state-save area to stash the > current state of SVM. What we need to do is basically get out of guest mode for > the duration of SMM. All this completely transparent to L1, i.e. L1 is not given > control and no L1 observable state changes. The best description I found is in APM vol. 2, 15.22 SMM Support: • The simplest solution is to not intercept SMI signals. SMIs encountered while in a guest context are taken from within the guest context. In this case, the SMM handler is not subject to any intercepts set up by the VMM and consequently runs outside of the virtualization controls. The state saved in the SMM State-Save area as seen by the SMM handler reflects the state of the guest that had been running at the time the SMI was encountered. When the SMM handler executes the RSM instruction, the processor returns to executing in the guest context, and any modifications to the SMM State-Save area made by the SMM handler are reflected in the guest state. I think that the last sentence is not implemented correctly: svm_prep_enter_smm() loads the host state into VMCB and enter_smm_save_state_64() then puts host state where the SMM handler would expect guest state. Do Windows intercept SMI? Thanks.
