On Fri, Mar 11, 2022, Chenyi Qiang wrote: > > On 3/11/2022 1:43 AM, Sean Christopherson wrote: > > On Thu, Mar 10, 2022, Chenyi Qiang wrote: > > > @@ -4976,6 +4977,9 @@ static int kvm_vcpu_ioctl_x86_set_vcpu_events(struct kvm_vcpu *vcpu, > > > } > > > } > > > + if (events->flags & KVM_VCPUEVENT_SHUTDOWN) > > > + kvm_make_request(KVM_REQ_TRIPLE_FAULT, vcpu); > > > > Huh. I think we need to make this bidirection and add it to get_vcpu_events() > > as well, and treat it as a bug fix. In direct triple fault cases, i.e. hardware > > detected and morphed to VM-Exit, KVM will never lose the triple fault. But for > > triple faults sythesized by KVM, e.g. the RSM path or nested_vmx_abort(), if KVM > > exits to userspace before the request is serviced, userspace could migrate the > > VM and lose the triple fault. > > Good catch. Then the name of this definition is not quit fit now. How about > changing to KVM_VCPUEVENT_SYTHESIZED_TRIPLE_FAULT? I don't think the SYNTHESIZED part is necessary. KVM doesn't make that distinction for other events/exceptions, and whose to say that KVM won't end up with a case where a "real" triple fault needs to be migrated. I do have a slight preference for KVM_VCPUEVENT_TRIPLE_FAULT or KVM_VCPUEVENT_SHUTDOWN, but it's a very slight preference.
