On 23/9/2023 6:42 am, Mingwei Zhang wrote:
On Fri, Sep 22, 2023 at 2:06 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
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.
hmm, I will take the "two approaches" back. You are right on that.
"two directions" is what I mean.
Oh, I think I did not elaborate the full context to you maybe. That
might cause confusion and sorry about that.
The context of Jim's patches is to fix the multiple PMI injections
when using perf, starting from
https://lore.kernel.org/all/ZJ7y9DuedQyBb9eU@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/
So, regarding the fix, there are multiple layers and they may or may
not be logically connected closely, but we are solving the same
problem. In fact, I was asking Jim to help me with this specific issue
:)
So yes, they could be put together and they could be put separately.
But I don't see why they _cannot_ be together or cause confusion. So,
I would like to put them together in the same context with a cover
letter fully describing the details.
FYI for reviewers: to reproduce the spurious PMI issue in the guest
VM, you need to let KVM emulate some instructions during the runtime,
so the function kvm_pmu_incr_counter() will be triggered more. One
option is to add a kernel cmdline like "idle=nomwait" to your guest
kernel. Regarding the workload in guest vm, please run the perf
command specified in
https://lore.kernel.org/all/ZKCD30QrE5g9XGIh@xxxxxxxxxx/
Hi Mingwei,
I would encourage you to convert this perf use case into a sequence of MSRs
accesses so that it's easier to understand where the emulation fails on KVM.
Thanks.
-Mingwei
-Mingwei
