[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <129c59a7-1715-41f4-b839-19e6a0adb9f1@amd.com>
Date: Thu, 7 Aug 2025 11:53:24 +0530
From: Sandipan Das <sandipan.das@....com>
To: Sean Christopherson <seanjc@...gle.com>,
Paolo Bonzini <pbonzini@...hat.com>
Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org, Xin Li
<xin@...or.com>, Dapeng Mi <dapeng1.mi@...ux.intel.com>
Subject: Re: [PATCH 00/18] KVM: x86: Fastpath cleanups and PMU prep work
On 06-08-2025 00:35, Sean Christopherson wrote:
> This is a prep series for the mediated PMU, and for Xin's series to add
> support for the immediate forms of RDMSR and WRMSRNS (I'll post a v3 of
> that series on top of this).
>
> The first half cleans up a variety of warts and flaws in the VM-Exit fastpath
> handlers. The second half cleans up the PMU code related to "triggering"
> instruction retired and branches retired events. The end goal of the two
> halves (other than general cleanup) is to be able bail from the fastpath when
> using the mediated PMU and the guest is counting instructions retired, with
> minimal overhead, e.g. without having to acquire SRCU.
>
> Because the mediated PMU context switches PMU state _outside_ of the fastpath,
> the mediated PMU won't be able to increment PMCs in the fastpath, and so won't
> be able to skip emulated instructions in the fastpath if the vCPU is counting
> instructions retired.
>
> The last patch to handle INVD in the fastpath is a bit dubious. It works just
> fine, but it's dangerously close to "just because we can, doesn't mean we
> should" territory. I added INVD to the fastpath before I realized that
> MSR_IA32_TSC_DEADLINE could be handled in the fastpath irrespective of the
> VMX preemption timer, i.e. on AMD CPUs. But being able to use INVD to test
> the fastpath is still super convenient, as there are no side effects (unless
> someone ran the test on bare metal :-D), no register constraints, and no
> vCPU model requirements. So, I kept it, because I couldn't come up with a
> good reason not to.
>
> Sean Christopherson (18):
> KVM: SVM: Skip fastpath emulation on VM-Exit if next RIP isn't valid
> KVM: x86: Add kvm_icr_to_lapic_irq() helper to allow for fastpath IPIs
> KVM: x86: Only allow "fast" IPIs in fastpath WRMSR(X2APIC_ICR) handler
> KVM: x86: Drop semi-arbitrary restrictions on IPI type in fastpath
> KVM: x86: Unconditionally handle MSR_IA32_TSC_DEADLINE in fastpath
> exits
> KVM: x86: Acquire SRCU in WRMSR fastpath iff instruction needs to be
> skipped
> KVM: x86: Unconditionally grab data from EDX:EAX in WRMSR fastpath
> KVM: x86: Fold WRMSR fastpath helpers into the main handler
> KVM: x86/pmu: Move kvm_init_pmu_capability() to pmu.c
> KVM: x86/pmu: Add wrappers for counting emulated instructions/branches
> KVM: x86/pmu: Calculate set of to-be-emulated PMCs at time of WRMSRs
> KVM: x86/pmu: Rename pmc_speculative_in_use() to
> pmc_is_locally_enabled()
> KVM: x86/pmu: Open code pmc_event_is_allowed() in its callers
> KVM: x86/pmu: Drop redundant check on PMC being globally enabled for
> emulation
> KVM: x86/pmu: Drop redundant check on PMC being locally enabled for
> emulation
> KVM: x86/pmu: Rename check_pmu_event_filter() to
> pmc_is_event_allowed()
> KVM: x86: Push acquisition of SRCU in fastpath into
> kvm_pmu_trigger_event()
> KVM: x86: Add a fastpath handler for INVD
>
> arch/x86/include/asm/kvm_host.h | 3 +
> arch/x86/kvm/lapic.c | 59 ++++++++----
> arch/x86/kvm/lapic.h | 3 +-
> arch/x86/kvm/pmu.c | 155 +++++++++++++++++++++++++-------
> arch/x86/kvm/pmu.h | 60 ++-----------
> arch/x86/kvm/svm/svm.c | 14 ++-
> arch/x86/kvm/vmx/nested.c | 2 +-
> arch/x86/kvm/vmx/pmu_intel.c | 2 +-
> arch/x86/kvm/vmx/vmx.c | 2 +
> arch/x86/kvm/x86.c | 85 +++++-------------
> arch/x86/kvm/x86.h | 1 +
> 11 files changed, 218 insertions(+), 168 deletions(-)
>
>
> base-commit: 196d9e72c4b0bd68b74a4ec7f52d248f37d0f030
No issues observed with KVM Unit Tests on recent AMD platforms (Milan, Genoa and Turin).
Powered by blists - more mailing lists