Re: [PATCH v3 6/6] KVM: nSVM: fix SMI injection in guest mode

["Radim Krčmář" <rkrcmar@redhat.com>]

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.