I obviously got a bit hasty with the whole svm_leave_smm() thing. *sigh* Except for the minor detail of being wrong :-) And while I agree it's probably "cleaner", I think it's actually harder for readers to understand, especially for readers that are familiar with nVMX. E.g. having a separate #VMEXIT path for consistency checks can actually be helpful, because it highlights things that happen on #VMEXIT even when KVM hasn't started loading L2 state. My preference is to completely drop these: KVM: nSVM: Unify handling of VMRUN failures with proper cleanup KVM: nSVM: Refactor minimal #VMEXIT handling out of nested_svm_vmexit() KVM: nSVM: Call nested_svm_init_mmu_context() before switching to VMCB02 KVM: nSVM: Call nested_svm_merge_msrpm() from enter_svm_guest_mode() KVM: nSVM: Call enter_guest_mode() before switching to VMCB02 And then moving these to the end of the series (or at least, beyond the stable@ patches): KVM: nSVM: Make nested_svm_merge_msrpm() return an errno KVM: nSVM: Drop nested_vmcb_check_{save/control}() wrappers After paging more of this stuff back in (it's been a while since I looked at the equivalent nVMX flow in depth), I'm quite opposed to aiming for a unified #VMEXIT path for VMRUN. Although it might seem otherwise at times, nVMX and nSVM didn't end up with nested_vmx_load_cr3() buried toward the end of their flows purely to make the code harder to read, there are real dependencies that need to be taken into account. And there's also value in having similar flows for nVMX and nSVM, e.g. where most consistency checks occur before KVM starts loading L2 state. VMX just happens to architecturally _require_ that, whereas with SVM it was a naturally consequence of writing the code. Without the unification, a minimal #VMEXIT helper doesn't make any sense, and I don't see any strong justification for shuffling around the order.[PATCH v6 16/31] KVM: nSVM: Unify handling of VMRUN failures with proper cleanupSean Christopherson undefinedYosry Ahmed undefined undefined undefined undefined undefinedMq