On Tue, Aug 03, 2021, Xiaoyao Li wrote: > On 8/2/2021 11:46 PM, Sean Christopherson wrote: > > > > > @@ -5642,6 +5653,31 @@ static int handle_bus_lock_vmexit(struct kvm_vcpu *vcpu) > > > > > return 0; > > > > > } > > > > > +static int handle_notify(struct kvm_vcpu *vcpu) > > > > > +{ > > > > > + unsigned long exit_qual = vmx_get_exit_qual(vcpu); > > > > > + > > > > > + if (!(exit_qual & NOTIFY_VM_CONTEXT_INVALID)) { > > > > > > > > What does CONTEXT_INVALID mean? The ISE doesn't provide any information whatsoever. > > > > > > It means whether the VM context is corrupted and not valid in the VMCS. > > > > Well that's a bit terrifying. Under what conditions can the VM context become > > corrupted? E.g. if the context can be corrupted by an inopportune NOTIFY exit, > > then KVM needs to be ultra conservative as a false positive could be fatal to a > > guest. > > > > Short answer is no case will set the VM_CONTEXT_INVALID bit. But something must set it, otherwise it wouldn't exist. The condition(s) under which it can be set matters because it affects how KVM should respond. E.g. if the guest can trigger VM_CONTEXT_INVALID at will, then we should probably treat it as a shutdown and reset the VMCS. But if VM_CONTEXT_INVALID can occur if and only if there's a hardware/ucode issue, then we can do: if (KVM_BUG_ON(exit_qual & NOTIFY_VM_CONTEXT_INVALID, vcpu->kvm)) return -EIO; Either way, to enable this by default we need some form of documentation that describes what conditions lead to VM_CONTEXT_INVALID. > VM_CONTEXT_INVALID is so fatal and IMHO it won't be set for any inopportune > NOTIFY exit.