On Fri, Sep 22, 2023, Mingwei Zhang wrote: > On Fri, Sep 22, 2023 at 1:34 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > > > On Fri, Sep 22, 2023, Mingwei Zhang wrote: > > > Agree. Both patches are fixing the general potential buggy situation > > > of multiple PMI injection on one vm entry: one software level defense > > > (forcing the usage of KVM_REQ_PMI) and one hardware level defense > > > (preventing PMI injection using mask). > > > > > > Although neither patch in this series is fixing the root cause of this > > > specific double PMI injection bug, I don't see a reason why we cannot > > > add a "fixes" tag to them, since we may fix it and create it again. > > > > > > I am currently working on it and testing my patch. Please give me some > > > time, I think I could try sending out one version today. Once that is > > > done, I will combine mine with the existing patch and send it out as a > > > series. > > > > Me confused, what patch? And what does this patch have to do with Jim's series? > > Unless I've missed something, Jim's patches are good to go with my nits addressed. > > Let me step back. > > We have the following problem when we run perf inside guest: > > [ 1437.487320] Uhhuh. NMI received for unknown reason 20 on CPU 3. > [ 1437.487330] Dazed and confused, but trying to continue > > This means there are more NMIs that guest PMI could understand. So > there are potentially two approaches to solve the problem: 1) fix the > PMI injection issue: only one can be injected; 2) fix the code that > causes the (incorrect) multiple PMI injection. No, because the LVTPC masking fix isn't optional, the current KVM behavior is a clear violation of the SDM. And I'm struggling to think of a sane way to fix the IRQ work bug, e.g. KVM would have to busy on the work finishing before resuming the guest, which is rather crazy. I'm not saying there isn't more work to be done, nor am I saying that we shouldn't further harden KVM against double-injection. I'm just truly confused as to what that has to do with Jim's fixes. > I am working on the 2nd one. So, the property of the 2nd one is: > without patches in 1) (Jim's patches), we could still avoid the above > warning messages.
