Hello Sean, On Mon, 30 Oct 2023 at 20:41, Sean Christopherson <seanjc@xxxxxxxxxx> wrote: >> if a fix patch like below would be acceptable OR reverting above patch is >> more reasonable? > > No, a revert would break AMD's vNMI. * Okay, that confirmation helps. >> - kvm_make_request(KVM_REQ_NMI, vcpu); >> + if (events->nmi.pending) >> + kvm_make_request(KVM_REQ_NMI, vcpu); > > This looks sane, but it should be unnecessary as KVM_REQ_NMI nmi_queued=0 should > be a (costly) nop. Hrm, unless the vCPU is in HLT, in which case KVM will treat > a spurious KVM_REQ_NMI as a wake event. When I made this change, my assumption > was that userspace would set KVM_VCPUEVENT_VALID_NMI_PENDING iff there was > relevant information to process. But if I'm reading the code correctly, QEMU > invokes KVM_SET_VCPU_EVENTS with KVM_VCPUEVENT_VALID_NMI_PENDING at the end of > machine creation. > > Hmm, but even that should be benign unless userspace is stuffing other guest > state. E.g. KVM will spuriously exit to userspace with -EAGAIN while the vCPU > is in KVM_MP_STATE_UNINITIALIZED, and I don't see a way for the vCPU to be put > into a blocking state after transitioning out of UNINITIATED via INIT+SIPI without > processing KVM_REQ_NMI. > > Please provide more information on what is breaking and/or how to reproduce the > issue. E.g. at the very least, a trace of KVM_{G,S}ET_VCPU_EVENTS. There's not > even enough info here to write a changelog. > * I see, I'll try to understand in more detail about what's really happening and will get back asap. Thank you. --- - Prasad