| Message ID | 20240405235603.1173076-1-seanjc@google.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | KVM: x86: Fix LVTPC masking on AMD CPUs | expand |
On Fri, 05 Apr 2024 16:55:53 -0700, Sean Christopherson wrote: > This is kinda sorta v2 of Sandipan's fix for KVM's incorrect setting of > the MASK bit when delivering PMIs through the LVTPC. > > It's a bit rushed, as I want to get Sandipan's fix applied early next > week so that it can make its way to Linus' tree for -rc4. And I didn't > want to apply Sandipan's patch as-is, because I'm a little paranoid that > the guest CPUID check could be noticeable slow, and it's easy to avoid. > > [...] Applied 1 and 2 to kvm-x86 fixes. [01/10] KVM: x86: Snapshot if a vCPU's vendor model is AMD vs. Intel compatible https://github.com/kvm-x86/linux/commit/3b764d0af391 [02/10] KVM: x86/pmu: Do not mask LVTPC when handling a PMI on AMD platforms https://github.com/kvm-x86/linux/commit/85cff527ab31 -- https://github.com/kvm-x86/linux/tree/next
On Sat, Apr 6, 2024 at 1:56 AM Sean Christopherson <seanjc@google.com> wrote: > > This is kinda sorta v2 of Sandipan's fix for KVM's incorrect setting of > the MASK bit when delivering PMIs through the LVTPC. > > It's a bit rushed, as I want to get Sandipan's fix applied early next > week so that it can make its way to Linus' tree for -rc4. And I didn't > want to apply Sandipan's patch as-is, because I'm a little paranoid that > the guest CPUID check could be noticeable slow, and it's easy to avoid. > > My plan is to grab patches 1-2 for 6.9 asap, and let the rest simmer for > much, much longer (they are *very* lightly tested). Oops---I missed your queuing message and pushed the same to kvm/master. Is it okay if you use commit 49ff3b4aec51e as the basis for any 6.10 topic branches that may conflict (or that build open the first two patches)? Paolo Paolo > > As for why this looks wildy different than Sandipan's compat_vendor idea, > when I started looking at KVM's various AMD vs. Intel checks, I realized > it makes no sense to support an "unknown" vendor. KVM can't do *nothing*, > and so practically speaking, an "unknown" vendor vCPU would actually end > up with a weird mix of AMD *and* Intel behavior, not AMD *or* Intel > behavior. > > Sandipan Das (1): > KVM: x86/pmu: Do not mask LVTPC when handling a PMI on AMD platforms > > Sean Christopherson (9): > KVM: x86: Snapshot if a vCPU's vendor model is AMD vs. Intel > compatible > KVM: x86/pmu: Squash period for checkpointed events based on host > HLE/RTM > KVM: x86: Apply Intel's TSC_AUX reserved-bit behavior to Intel compat > vCPUs > KVM: x86: Inhibit code #DBs in MOV-SS shadow for all Intel compat > vCPUs > KVM: x86: Use "is Intel compatible" helper to emulate SYSCALL in > !64-bit > KVM: SVM: Emulate SYSENTER RIP/RSP behavior for all Intel compat vCPUs > KVM: x86: Allow SYSENTER in Compatibility Mode for all Intel compat > vCPUs > KVM: x86: Open code vendor_intel() in string_registers_quirk() > KVM: x86: Bury guest_cpuid_is_amd_or_hygon() in cpuid.c > > arch/x86/include/asm/kvm_host.h | 1 + > arch/x86/kvm/cpuid.c | 13 ++++++ > arch/x86/kvm/cpuid.h | 16 ++------ > arch/x86/kvm/emulate.c | 71 ++++++++++----------------------- > arch/x86/kvm/kvm_emulate.h | 1 + > arch/x86/kvm/lapic.c | 3 +- > arch/x86/kvm/mmu/mmu.c | 2 +- > arch/x86/kvm/pmu.c | 2 +- > arch/x86/kvm/svm/svm.c | 14 +++---- > arch/x86/kvm/x86.c | 30 ++++++++------ > 10 files changed, 68 insertions(+), 85 deletions(-) > > > base-commit: 8cb4a9a82b21623dbb4b3051dd30d98356cf95bc > -- > 2.44.0.478.gd926399ef9-goog >
On Fri, 05 Apr 2024 16:55:53 -0700, Sean Christopherson wrote: > This is kinda sorta v2 of Sandipan's fix for KVM's incorrect setting of > the MASK bit when delivering PMIs through the LVTPC. > > It's a bit rushed, as I want to get Sandipan's fix applied early next > week so that it can make its way to Linus' tree for -rc4. And I didn't > want to apply Sandipan's patch as-is, because I'm a little paranoid that > the guest CPUID check could be noticeable slow, and it's easy to avoid. > > [...] Applied 3-10 to kvm-x86 misc (1-2 went into 6.9). [01/10] KVM: x86: Snapshot if a vCPU's vendor model is AMD vs. Intel compatible (previously applied) [02/10] KVM: x86/pmu: Do not mask LVTPC when handling a PMI on AMD platforms (previously applied) [03/10] KVM: x86/pmu: Squash period for checkpointed events based on host HLE/RTM https://github.com/kvm-x86/linux/commit/5a4f8b3026fc [04/10] KVM: x86: Apply Intel's TSC_AUX reserved-bit behavior to Intel compat vCPUs https://github.com/kvm-x86/linux/commit/6463e5e41842 [05/10] KVM: x86: Inhibit code #DBs in MOV-SS shadow for all Intel compat vCPUs https://github.com/kvm-x86/linux/commit/c092fc879f99 [06/10] KVM: x86: Use "is Intel compatible" helper to emulate SYSCALL in !64-bit https://github.com/kvm-x86/linux/commit/d99e4cb2ae2e [07/10] KVM: SVM: Emulate SYSENTER RIP/RSP behavior for all Intel compat vCPUs https://github.com/kvm-x86/linux/commit/dc2b8b2b524a [08/10] KVM: x86: Allow SYSENTER in Compatibility Mode for all Intel compat vCPUs https://github.com/kvm-x86/linux/commit/4067c2395e80 [09/10] KVM: x86: Open code vendor_intel() in string_registers_quirk() https://github.com/kvm-x86/linux/commit/bdaff4f92bce [10/10] KVM: x86: Bury guest_cpuid_is_amd_or_hygon() in cpuid.c https://github.com/kvm-x86/linux/commit/1028893a73fe -- https://github.com/kvm-x86/linux/tree/next
This is kinda sorta v2 of Sandipan's fix for KVM's incorrect setting of the MASK bit when delivering PMIs through the LVTPC. It's a bit rushed, as I want to get Sandipan's fix applied early next week so that it can make its way to Linus' tree for -rc4. And I didn't want to apply Sandipan's patch as-is, because I'm a little paranoid that the guest CPUID check could be noticeable slow, and it's easy to avoid. My plan is to grab patches 1-2 for 6.9 asap, and let the rest simmer for much, much longer (they are *very* lightly tested). As for why this looks wildy different than Sandipan's compat_vendor idea, when I started looking at KVM's various AMD vs. Intel checks, I realized it makes no sense to support an "unknown" vendor. KVM can't do *nothing*, and so practically speaking, an "unknown" vendor vCPU would actually end up with a weird mix of AMD *and* Intel behavior, not AMD *or* Intel behavior. Sandipan Das (1): KVM: x86/pmu: Do not mask LVTPC when handling a PMI on AMD platforms Sean Christopherson (9): KVM: x86: Snapshot if a vCPU's vendor model is AMD vs. Intel compatible KVM: x86/pmu: Squash period for checkpointed events based on host HLE/RTM KVM: x86: Apply Intel's TSC_AUX reserved-bit behavior to Intel compat vCPUs KVM: x86: Inhibit code #DBs in MOV-SS shadow for all Intel compat vCPUs KVM: x86: Use "is Intel compatible" helper to emulate SYSCALL in !64-bit KVM: SVM: Emulate SYSENTER RIP/RSP behavior for all Intel compat vCPUs KVM: x86: Allow SYSENTER in Compatibility Mode for all Intel compat vCPUs KVM: x86: Open code vendor_intel() in string_registers_quirk() KVM: x86: Bury guest_cpuid_is_amd_or_hygon() in cpuid.c arch/x86/include/asm/kvm_host.h | 1 + arch/x86/kvm/cpuid.c | 13 ++++++ arch/x86/kvm/cpuid.h | 16 ++------ arch/x86/kvm/emulate.c | 71 ++++++++++----------------------- arch/x86/kvm/kvm_emulate.h | 1 + arch/x86/kvm/lapic.c | 3 +- arch/x86/kvm/mmu/mmu.c | 2 +- arch/x86/kvm/pmu.c | 2 +- arch/x86/kvm/svm/svm.c | 14 +++---- arch/x86/kvm/x86.c | 30 ++++++++------ 10 files changed, 68 insertions(+), 85 deletions(-) base-commit: 8cb4a9a82b21623dbb4b3051dd30d98356cf95bc