From: "Liang, Kan" <kan.liang@linux.intel.com>
To: Peter Zijlstra <peterz@infradead.org>,
Sean Christopherson <seanjc@google.com>
Cc: Marc Zyngier <maz@kernel.org>,
Oliver Upton <oliver.upton@linux.dev>,
Tianrui Zhao <zhaotianrui@loongson.cn>,
Bibo Mao <maobibo@loongson.cn>,
Huacai Chen <chenhuacai@kernel.org>,
Anup Patel <anup@brainfault.org>,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>, Xin Li <xin@zytor.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Andy Lutomirski <luto@kernel.org>, Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Paolo Bonzini <pbonzini@redhat.com>,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
kvm@vger.kernel.org, loongarch@lists.linux.dev,
kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
Yongwei Ma <yongwei.ma@intel.com>,
Mingwei Zhang <mizhang@google.com>,
Xiong Zhang <xiong.y.zhang@linux.intel.com>,
Sandipan Das <sandipan.das@amd.com>,
Dapeng Mi <dapeng1.mi@linux.intel.com>
Subject: Re: [PATCH v5 09/44] perf/x86: Switch LVTPC to/from mediated PMI vector on guest load/put context
Date: Mon, 18 Aug 2025 13:07:39 -0700 [thread overview]
Message-ID: <4e58688f-22e0-4e20-9043-dee76d01d24f@linux.intel.com> (raw)
In-Reply-To: <20250818161210.GJ3289052@noisy.programming.kicks-ass.net>
On 2025-08-18 9:12 a.m., Peter Zijlstra wrote:
> On Mon, Aug 18, 2025 at 08:25:34AM -0700, Sean Christopherson wrote:
>
>>> OK, so *IF* doing the VM-exit during PMI is sound, this is something
>>> that needs a comment somewhere.
>>
>> I'm a bit lost here. Are you essentially asking if it's ok to take a VM-Exit
>> while the guest is handling a PMI? If so, that _has_ to work, because there are
>> myriad things that can/will trigger a VM-Exit at any point while the guest is
>> active.
>
> Yes, that's what I'm asking. Why is this VM-exit during PMI nonsense not
> subject to the same failures that mandates the mid/late PMI ACK.
>
> And yes, I realize this needs to work. But so far I'm not sure I
> understand why that is a safe thing to do.
>
> Like I wrote, I suspect writing all the PMU MSRs serializes things
> sufficiently, but if that is the case, that needs to be explicitly
> mentioned. Because that also doesn't explain why we needs mid-ack
> instead of late-ack on ADL e-cores for instance.
The mid-ack and late-ack only require under some corner cases, e.g., two
PMIs are triggered simultaneously with PEBS.
Because the ucode of p-core and e-core handle the pending PEBS records
and PMIs differently.
For p-core, the ACK should be as close to EOM. Otherwise, the pending
PMI will trigger a spurious PMI warning.
For e-core, the uncode handles the pending PMI well. There is no
spurious PMI. However, it impacts the update of the PEBS_DATA_CFG. The
PEBS_DATA_CFG is global. If the ACK cannot be done before re-enabling
counters, the stale PEBS_DATA_CFG will somehow be written into the next
PEBS record of the pending PMI. It triggers the malformed PEBS record.
For the upcoming arch PEBS, the data cfg is per-counter.
The mid-ack workaround should not be required.
>
> Could it perhaps be that we don't let the guests do PEBS because DS
> doesn't virtualize? And thus we don't have the malformed PEBS record?
>
Yes, I don't think it can impact the mediated PMU. The legacy PEBS for
vPMU is not supported.
Since the configuration is per-counter with the arch PEBS, the malformed
PEBS record should not be triggered either.
Thanks,
Kan
--
kvm-riscv mailing list
kvm-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kvm-riscv
WARNING: multiple messages have this Message-ID (diff)
From: "Liang, Kan" <kan.liang@linux.intel.com>
To: Peter Zijlstra <peterz@infradead.org>,
Sean Christopherson <seanjc@google.com>
Cc: Marc Zyngier <maz@kernel.org>,
Oliver Upton <oliver.upton@linux.dev>,
Tianrui Zhao <zhaotianrui@loongson.cn>,
Bibo Mao <maobibo@loongson.cn>,
Huacai Chen <chenhuacai@kernel.org>,
Anup Patel <anup@brainfault.org>,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>, Xin Li <xin@zytor.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Andy Lutomirski <luto@kernel.org>, Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Paolo Bonzini <pbonzini@redhat.com>,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
kvm@vger.kernel.org, loongarch@lists.linux.dev,
kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
Yongwei Ma <yongwei.ma@intel.com>,
Mingwei Zhang <mizhang@google.com>,
Xiong Zhang <xiong.y.zhang@linux.intel.com>,
Sandipan Das <sandipan.das@amd.com>,
Dapeng Mi <dapeng1.mi@linux.intel.com>
Subject: Re: [PATCH v5 09/44] perf/x86: Switch LVTPC to/from mediated PMI vector on guest load/put context
Date: Mon, 18 Aug 2025 13:07:39 -0700 [thread overview]
Message-ID: <4e58688f-22e0-4e20-9043-dee76d01d24f@linux.intel.com> (raw)
In-Reply-To: <20250818161210.GJ3289052@noisy.programming.kicks-ass.net>
On 2025-08-18 9:12 a.m., Peter Zijlstra wrote:
> On Mon, Aug 18, 2025 at 08:25:34AM -0700, Sean Christopherson wrote:
>
>>> OK, so *IF* doing the VM-exit during PMI is sound, this is something
>>> that needs a comment somewhere.
>>
>> I'm a bit lost here. Are you essentially asking if it's ok to take a VM-Exit
>> while the guest is handling a PMI? If so, that _has_ to work, because there are
>> myriad things that can/will trigger a VM-Exit at any point while the guest is
>> active.
>
> Yes, that's what I'm asking. Why is this VM-exit during PMI nonsense not
> subject to the same failures that mandates the mid/late PMI ACK.
>
> And yes, I realize this needs to work. But so far I'm not sure I
> understand why that is a safe thing to do.
>
> Like I wrote, I suspect writing all the PMU MSRs serializes things
> sufficiently, but if that is the case, that needs to be explicitly
> mentioned. Because that also doesn't explain why we needs mid-ack
> instead of late-ack on ADL e-cores for instance.
The mid-ack and late-ack only require under some corner cases, e.g., two
PMIs are triggered simultaneously with PEBS.
Because the ucode of p-core and e-core handle the pending PEBS records
and PMIs differently.
For p-core, the ACK should be as close to EOM. Otherwise, the pending
PMI will trigger a spurious PMI warning.
For e-core, the uncode handles the pending PMI well. There is no
spurious PMI. However, it impacts the update of the PEBS_DATA_CFG. The
PEBS_DATA_CFG is global. If the ACK cannot be done before re-enabling
counters, the stale PEBS_DATA_CFG will somehow be written into the next
PEBS record of the pending PMI. It triggers the malformed PEBS record.
For the upcoming arch PEBS, the data cfg is per-counter.
The mid-ack workaround should not be required.
>
> Could it perhaps be that we don't let the guests do PEBS because DS
> doesn't virtualize? And thus we don't have the malformed PEBS record?
>
Yes, I don't think it can impact the mediated PMU. The legacy PEBS for
vPMU is not supported.
Since the configuration is per-counter with the arch PEBS, the malformed
PEBS record should not be triggered either.
Thanks,
Kan
WARNING: multiple messages have this Message-ID (diff)
From: "Liang, Kan" <kan.liang@linux.intel.com>
To: Peter Zijlstra <peterz@infradead.org>,
Sean Christopherson <seanjc@google.com>
Cc: Marc Zyngier <maz@kernel.org>,
Oliver Upton <oliver.upton@linux.dev>,
Tianrui Zhao <zhaotianrui@loongson.cn>,
Bibo Mao <maobibo@loongson.cn>,
Huacai Chen <chenhuacai@kernel.org>,
Anup Patel <anup@brainfault.org>,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>, Xin Li <xin@zytor.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Andy Lutomirski <luto@kernel.org>, Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Paolo Bonzini <pbonzini@redhat.com>,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
kvm@vger.kernel.org, loongarch@lists.linux.dev,
kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
Yongwei Ma <yongwei.ma@intel.com>,
Mingwei Zhang <mizhang@google.com>,
Xiong Zhang <xiong.y.zhang@linux.intel.com>,
Sandipan Das <sandipan.das@amd.com>,
Dapeng Mi <dapeng1.mi@linux.intel.com>
Subject: Re: [PATCH v5 09/44] perf/x86: Switch LVTPC to/from mediated PMI vector on guest load/put context
Date: Mon, 18 Aug 2025 13:07:39 -0700 [thread overview]
Message-ID: <4e58688f-22e0-4e20-9043-dee76d01d24f@linux.intel.com> (raw)
In-Reply-To: <20250818161210.GJ3289052@noisy.programming.kicks-ass.net>
On 2025-08-18 9:12 a.m., Peter Zijlstra wrote:
> On Mon, Aug 18, 2025 at 08:25:34AM -0700, Sean Christopherson wrote:
>
>>> OK, so *IF* doing the VM-exit during PMI is sound, this is something
>>> that needs a comment somewhere.
>>
>> I'm a bit lost here. Are you essentially asking if it's ok to take a VM-Exit
>> while the guest is handling a PMI? If so, that _has_ to work, because there are
>> myriad things that can/will trigger a VM-Exit at any point while the guest is
>> active.
>
> Yes, that's what I'm asking. Why is this VM-exit during PMI nonsense not
> subject to the same failures that mandates the mid/late PMI ACK.
>
> And yes, I realize this needs to work. But so far I'm not sure I
> understand why that is a safe thing to do.
>
> Like I wrote, I suspect writing all the PMU MSRs serializes things
> sufficiently, but if that is the case, that needs to be explicitly
> mentioned. Because that also doesn't explain why we needs mid-ack
> instead of late-ack on ADL e-cores for instance.
The mid-ack and late-ack only require under some corner cases, e.g., two
PMIs are triggered simultaneously with PEBS.
Because the ucode of p-core and e-core handle the pending PEBS records
and PMIs differently.
For p-core, the ACK should be as close to EOM. Otherwise, the pending
PMI will trigger a spurious PMI warning.
For e-core, the uncode handles the pending PMI well. There is no
spurious PMI. However, it impacts the update of the PEBS_DATA_CFG. The
PEBS_DATA_CFG is global. If the ACK cannot be done before re-enabling
counters, the stale PEBS_DATA_CFG will somehow be written into the next
PEBS record of the pending PMI. It triggers the malformed PEBS record.
For the upcoming arch PEBS, the data cfg is per-counter.
The mid-ack workaround should not be required.
>
> Could it perhaps be that we don't let the guests do PEBS because DS
> doesn't virtualize? And thus we don't have the malformed PEBS record?
>
Yes, I don't think it can impact the mediated PMU. The legacy PEBS for
vPMU is not supported.
Since the configuration is per-counter with the arch PEBS, the malformed
PEBS record should not be triggered either.
Thanks,
Kan
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2025-08-18 21:27 UTC|newest]
Thread overview: 234+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-06 19:56 [PATCH v5 00/44] KVM: x86: Add support for mediated vPMUs Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` [PATCH v5 01/44] perf: Skip pmu_ctx based on event_type Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` [PATCH v5 02/44] perf: Add generic exclude_guest support Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` [PATCH v5 03/44] perf: Move security_perf_event_free() call to __free_event() Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` [PATCH v5 04/44] perf: Add APIs to create/release mediated guest vPMUs Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` [PATCH v5 05/44] perf: Clean up perf ctx time Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` [PATCH v5 06/44] perf: Add a EVENT_GUEST flag Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` [PATCH v5 07/44] perf: Add APIs to load/put guest mediated PMU context Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-08 7:30 ` Mi, Dapeng
2025-08-08 7:30 ` Mi, Dapeng
2025-08-08 7:30 ` Mi, Dapeng
2025-08-06 19:56 ` [PATCH v5 08/44] perf: core/x86: Register a new vector for handling mediated guest PMIs Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` [PATCH v5 09/44] perf/x86: Switch LVTPC to/from mediated PMI vector on guest load/put context Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-15 11:39 ` Peter Zijlstra
2025-08-15 11:39 ` Peter Zijlstra
2025-08-15 11:39 ` Peter Zijlstra
2025-08-15 15:41 ` Sean Christopherson
2025-08-15 15:41 ` Sean Christopherson
2025-08-15 15:41 ` Sean Christopherson
2025-08-15 15:55 ` Sean Christopherson
2025-08-15 15:55 ` Sean Christopherson
2025-08-15 15:55 ` Sean Christopherson
2025-08-18 14:32 ` Peter Zijlstra
2025-08-18 14:32 ` Peter Zijlstra
2025-08-18 14:32 ` Peter Zijlstra
2025-08-18 15:25 ` Sean Christopherson
2025-08-18 15:25 ` Sean Christopherson
2025-08-18 15:25 ` Sean Christopherson
2025-08-18 16:12 ` Peter Zijlstra
2025-08-18 16:12 ` Peter Zijlstra
2025-08-18 16:12 ` Peter Zijlstra
2025-08-18 20:07 ` Liang, Kan [this message]
2025-08-18 20:07 ` Liang, Kan
2025-08-18 20:07 ` Liang, Kan
2025-11-19 21:31 ` Sean Christopherson
2025-11-19 21:31 ` Sean Christopherson
2025-11-19 21:31 ` Sean Christopherson
2025-08-15 13:04 ` Peter Zijlstra
2025-08-15 13:04 ` Peter Zijlstra
2025-08-15 13:04 ` Peter Zijlstra
2025-08-15 15:51 ` Sean Christopherson
2025-08-15 15:51 ` Sean Christopherson
2025-08-15 15:51 ` Sean Christopherson
2025-08-06 19:56 ` [PATCH v5 10/44] perf/x86/core: Do not set bit width for unavailable counters Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` [PATCH v5 11/44] perf/x86/core: Plumb mediated PMU capability from x86_pmu to x86_pmu_cap Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` [PATCH v5 12/44] perf/x86/intel: Support PERF_PMU_CAP_MEDIATED_VPMU Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` [PATCH v5 13/44] perf/x86/amd: Support PERF_PMU_CAP_MEDIATED_VPMU for AMD host Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` [PATCH v5 14/44] KVM: VMX: Setup canonical VMCS config prior to kvm_x86_vendor_init() Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` [PATCH v5 15/44] KVM: SVM: Check pmu->version, not enable_pmu, when getting PMC MSRs Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-13 9:58 ` Sandipan Das
2025-08-13 9:58 ` Sandipan Das
2025-08-13 9:58 ` Sandipan Das
2025-08-06 19:56 ` [PATCH v5 16/44] KVM: Add a simplified wrapper for registering perf callbacks Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-22 10:32 ` Anup Patel
2025-08-22 10:32 ` Anup Patel
2025-08-22 10:32 ` Anup Patel
2025-08-06 19:56 ` [PATCH v5 17/44] KVM: x86/pmu: Snapshot host (i.e. perf's) reported PMU capabilities Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-13 9:56 ` Sandipan Das
2025-08-13 9:56 ` Sandipan Das
2025-08-13 9:56 ` Sandipan Das
2025-08-06 19:56 ` [PATCH v5 18/44] KVM: x86/pmu: Start stubbing in mediated PMU support Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` [PATCH v5 19/44] KVM: x86/pmu: Implement Intel mediated PMU requirements and constraints Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` [PATCH v5 20/44] KVM: x86/pmu: Implement AMD mediated PMU requirements Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-13 9:49 ` Sandipan Das
2025-08-13 9:49 ` Sandipan Das
2025-08-13 9:49 ` Sandipan Das
2025-08-06 19:56 ` [PATCH v5 21/44] KVM: x86/pmu: Register PMI handler for mediated vPMU Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` [PATCH v5 22/44] KVM: x86: Rename vmx_vmentry/vmexit_ctrl() helpers Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` [PATCH v5 23/44] KVM: x86/pmu: Move PMU_CAP_{FW_WRITES,LBR_FMT} into msr-index.h header Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` [PATCH v5 24/44] KVM: x86: Rework KVM_REQ_MSR_FILTER_CHANGED into a generic RECALC_INTERCEPTS Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` [PATCH v5 25/44] KVM: x86: Use KVM_REQ_RECALC_INTERCEPTS to react to CPUID updates Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` [PATCH v5 26/44] KVM: VMX: Add helpers to toggle/change a bit in VMCS execution controls Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` [PATCH v5 27/44] KVM: x86/pmu: Disable RDPMC interception for compatible mediated vPMU Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` [PATCH v5 28/44] KVM: x86/pmu: Load/save GLOBAL_CTRL via entry/exit fields for mediated PMU Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-11-25 1:48 ` Sean Christopherson
2025-11-25 1:48 ` Sean Christopherson
2025-11-25 1:48 ` Sean Christopherson
2025-11-25 5:02 ` Mi, Dapeng
2025-11-25 5:02 ` Mi, Dapeng
2025-11-25 5:02 ` Mi, Dapeng
2025-11-25 17:08 ` Sean Christopherson
2025-11-25 17:08 ` Sean Christopherson
2025-11-25 17:08 ` Sean Christopherson
2025-11-26 0:23 ` Mi, Dapeng
2025-11-26 0:23 ` Mi, Dapeng
2025-11-26 0:23 ` Mi, Dapeng
2025-08-06 19:56 ` [PATCH v5 29/44] KVM: x86/pmu: Use BIT_ULL() instead of open coded equivalents Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` [PATCH v5 30/44] KVM: x86/pmu: Move initialization of valid PMCs bitmask to common x86 Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` [PATCH v5 31/44] KVM: x86/pmu: Restrict GLOBAL_{CTRL,STATUS}, fixed PMCs, and PEBS to PMU v2+ Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` [PATCH v5 32/44] KVM: x86/pmu: Disable interception of select PMU MSRs for mediated vPMUs Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-09-26 7:12 ` Sandipan Das
2025-09-26 7:12 ` Sandipan Das
2025-09-26 7:12 ` Sandipan Das
2025-10-01 18:14 ` Sean Christopherson
2025-10-01 18:14 ` Sean Christopherson
2025-10-01 18:14 ` Sean Christopherson
2025-10-03 5:03 ` Sandipan Das
2025-10-03 5:03 ` Sandipan Das
2025-10-03 5:03 ` Sandipan Das
2025-10-09 2:19 ` Mi, Dapeng
2025-10-09 2:19 ` Mi, Dapeng
2025-10-09 2:19 ` Mi, Dapeng
2025-10-15 18:48 ` Sean Christopherson
2025-10-15 18:48 ` Sean Christopherson
2025-10-15 18:48 ` Sean Christopherson
2025-10-16 0:04 ` Mi, Dapeng
2025-10-16 0:04 ` Mi, Dapeng
2025-10-16 0:04 ` Mi, Dapeng
2025-08-06 19:56 ` [PATCH v5 33/44] KVM: x86/pmu: Bypass perf checks when emulating mediated PMU counter accesses Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-13 10:01 ` Sandipan Das
2025-08-13 10:01 ` Sandipan Das
2025-08-13 10:01 ` Sandipan Das
2025-08-06 19:56 ` [PATCH v5 34/44] KVM: x86/pmu: Introduce eventsel_hw to prepare for pmu event filtering Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` [PATCH v5 35/44] KVM: x86/pmu: Reprogram mediated PMU event selectors on event filter updates Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` [PATCH v5 36/44] KVM: x86/pmu: Always stuff GuestOnly=1,HostOnly=0 for mediated PMCs on AMD Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` [PATCH v5 37/44] KVM: x86/pmu: Load/put mediated PMU context when entering/exiting guest Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:56 ` Sean Christopherson
2025-08-06 19:57 ` [PATCH v5 38/44] KVM: x86/pmu: Disallow emulation in the fastpath if mediated PMCs are active Sean Christopherson
2025-08-06 19:57 ` Sean Christopherson
2025-08-06 19:57 ` Sean Christopherson
2025-08-13 9:53 ` Sandipan Das
2025-08-13 9:53 ` Sandipan Das
2025-08-13 9:53 ` Sandipan Das
2025-08-06 19:57 ` [PATCH v5 39/44] KVM: x86/pmu: Handle emulated instruction for mediated vPMU Sean Christopherson
2025-08-06 19:57 ` Sean Christopherson
2025-08-06 19:57 ` Sean Christopherson
2025-08-06 19:57 ` [PATCH v5 40/44] KVM: nVMX: Add macros to simplify nested MSR interception setting Sean Christopherson
2025-08-06 19:57 ` Sean Christopherson
2025-08-06 19:57 ` Sean Christopherson
2025-08-06 19:57 ` [PATCH v5 41/44] KVM: nVMX: Disable PMU MSR interception as appropriate while running L2 Sean Christopherson
2025-08-06 19:57 ` Sean Christopherson
2025-08-06 19:57 ` Sean Christopherson
2025-08-06 19:57 ` [PATCH v5 42/44] KVM: nSVM: " Sean Christopherson
2025-08-06 19:57 ` Sean Christopherson
2025-08-06 19:57 ` Sean Christopherson
2025-08-06 19:57 ` [PATCH v5 43/44] KVM: x86/pmu: Expose enable_mediated_pmu parameter to user space Sean Christopherson
2025-08-06 19:57 ` Sean Christopherson
2025-08-06 19:57 ` Sean Christopherson
2025-08-06 19:57 ` [PATCH v5 44/44] KVM: x86/pmu: Elide WRMSRs when loading guest PMCs if values already match Sean Christopherson
2025-08-06 19:57 ` Sean Christopherson
2025-08-06 19:57 ` Sean Christopherson
2025-11-14 6:19 ` Manali Shukla
2025-11-14 6:19 ` Manali Shukla
2025-11-14 6:19 ` Manali Shukla
2025-08-08 8:28 ` [PATCH v5 00/44] KVM: x86: Add support for mediated vPMUs Mi, Dapeng
2025-08-08 8:28 ` Mi, Dapeng
2025-08-08 8:28 ` Mi, Dapeng
2025-08-08 8:35 ` Mi, Dapeng
2025-08-08 8:35 ` Mi, Dapeng
2025-08-08 8:35 ` Mi, Dapeng
2025-08-13 9:45 ` Sandipan Das
2025-08-13 9:45 ` Sandipan Das
2025-08-13 9:45 ` Sandipan Das
2025-08-22 8:12 ` Hao, Xudong
2025-08-22 8:12 ` Hao, Xudong
2025-08-22 8:12 ` Hao, Xudong
2025-09-19 0:10 ` Sean Christopherson
2025-09-19 0:10 ` Sean Christopherson
2025-09-19 0:10 ` Sean Christopherson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4e58688f-22e0-4e20-9043-dee76d01d24f@linux.intel.com \
--to=kan.liang@linux.intel.com \
--cc=acme@kernel.org \
--cc=anup@brainfault.org \
--cc=aou@eecs.berkeley.edu \
--cc=chenhuacai@kernel.org \
--cc=dapeng1.mi@linux.intel.com \
--cc=hpa@zytor.com \
--cc=kvm-riscv@lists.infradead.org \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=loongarch@lists.linux.dev \
--cc=luto@kernel.org \
--cc=maobibo@loongson.cn \
--cc=maz@kernel.org \
--cc=mingo@redhat.com \
--cc=mizhang@google.com \
--cc=namhyung@kernel.org \
--cc=oliver.upton@linux.dev \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=sandipan.das@amd.com \
--cc=seanjc@google.com \
--cc=xin@zytor.com \
--cc=xiong.y.zhang@linux.intel.com \
--cc=yongwei.ma@intel.com \
--cc=zhaotianrui@loongson.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.