| Message ID | 1539346817-8638-1-git-send-email-wei.w.wang@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v1] KVM/x86/vPMU: Guest PMI Optimization | expand |
> 4. Results > - Without this optimization, the guest pmi handling time is > ~4500000 ns, and the max sampling rate is reduced to 250. > - With this optimization, the guest pmi handling time is ~9000 ns > (i.e. 1 / 500 of the non-optimization case), and the max sampling > rate remains at the original 100000. Impressive performance improvement! It's not clear to me why you're special casing PMIs here. The optimization should work generically, right? perf will enable/disable the PMU even outside PMIs, e.g. on context switches, which is a very important path too. > @@ -237,9 +267,23 @@ static int intel_pmu_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info) > default: > if ((pmc = get_gp_pmc(pmu, msr, MSR_IA32_PERFCTR0)) || > (pmc = get_fixed_pmc(pmu, msr))) { > - if (!msr_info->host_initiated) > - data = (s64)(s32)data; > - pmc->counter += data - pmc_read_counter(pmc); > + if (pmu->in_pmi) { > + /* > + * Since we are not re-allocating a perf event > + * to reconfigure the sampling time when the > + * guest pmu is in PMI, just set the value to > + * the hardware perf counter. Counting will > + * continue after the guest enables the > + * counter bit in MSR_CORE_PERF_GLOBAL_CTRL. > + */ > + struct hw_perf_event *hwc = > + &pmc->perf_event->hw; > + wrmsrl(hwc->event_base, data); Is that guaranteed to be always called on the right CPU that will run the vcpu? AFAIK there's an ioctl to set MSRs in the guest from qemu, I'm pretty sure it won't handle that. May need to be delayed to entry time. -Andi
Hi, On 12.10.2018 19:30, Andi Kleen wrote: >> 4. Results >> - Without this optimization, the guest pmi handling time is >> ~4500000 ns, and the max sampling rate is reduced to 250. >> - With this optimization, the guest pmi handling time is ~9000 ns >> (i.e. 1 / 500 of the non-optimization case), and the max sampling >> rate remains at the original 100000. > > Impressive performance improvement! Might want it into distributions' and secondary kernels as well. Thanks, Alexey > > It's not clear to me why you're special casing PMIs here. The optimization > should work generically, right? > > perf will enable/disable the PMU even outside PMIs, e.g. on context > switches, which is a very important path too. > >> @@ -237,9 +267,23 @@ static int intel_pmu_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info) >> default: >> if ((pmc = get_gp_pmc(pmu, msr, MSR_IA32_PERFCTR0)) || >> (pmc = get_fixed_pmc(pmu, msr))) { >> - if (!msr_info->host_initiated) >> - data = (s64)(s32)data; >> - pmc->counter += data - pmc_read_counter(pmc); >> + if (pmu->in_pmi) { >> + /* >> + * Since we are not re-allocating a perf event >> + * to reconfigure the sampling time when the >> + * guest pmu is in PMI, just set the value to >> + * the hardware perf counter. Counting will >> + * continue after the guest enables the >> + * counter bit in MSR_CORE_PERF_GLOBAL_CTRL. >> + */ >> + struct hw_perf_event *hwc = >> + &pmc->perf_event->hw; >> + wrmsrl(hwc->event_base, data); > > Is that guaranteed to be always called on the right CPU that will run the vcpu? > > AFAIK there's an ioctl to set MSRs in the guest from qemu, I'm pretty sure > it won't handle that. > > May need to be delayed to entry time. > > -Andi >
On Saturday, October 13, 2018 12:31 AM, Andi Kleen wrote: > > 4. Results > > - Without this optimization, the guest pmi handling time is > > ~4500000 ns, and the max sampling rate is reduced to 250. > > - With this optimization, the guest pmi handling time is ~9000 ns > > (i.e. 1 / 500 of the non-optimization case), and the max sampling > > rate remains at the original 100000. > > Impressive performance improvement! > > It's not clear to me why you're special casing PMIs here. The optimization > should work generically, right? Yes, seems doable. I plan to try some lazy approach for the perf event allocation. > Is that guaranteed to be always called on the right CPU that will run the vcpu? > > AFAIK there's an ioctl to set MSRs in the guest from qemu, I'm pretty sure it > won't handle that. Thanks, will consider that case. Best, Wei
On 12/10/2018 18:30, Andi Kleen wrote: >> 4. Results >> - Without this optimization, the guest pmi handling time is >> ~4500000 ns, and the max sampling rate is reduced to 250. >> - With this optimization, the guest pmi handling time is ~9000 ns >> (i.e. 1 / 500 of the non-optimization case), and the max sampling >> rate remains at the original 100000. > > Impressive performance improvement! Agreed! > It's not clear to me why you're special casing PMIs here. The optimization > should work generically, right? Yeah, you can even just check if the counter is in the struct cpu_hw_events guest mask, and if so always write the counter MSR directly. >> @@ -237,9 +267,23 @@ static int intel_pmu_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info) >> default: >> if ((pmc = get_gp_pmc(pmu, msr, MSR_IA32_PERFCTR0)) || >> (pmc = get_fixed_pmc(pmu, msr))) { >> - if (!msr_info->host_initiated) >> - data = (s64)(s32)data; >> - pmc->counter += data - pmc_read_counter(pmc); >> + if (pmu->in_pmi) { >> + /* >> + * Since we are not re-allocating a perf event >> + * to reconfigure the sampling time when the >> + * guest pmu is in PMI, just set the value to >> + * the hardware perf counter. Counting will >> + * continue after the guest enables the >> + * counter bit in MSR_CORE_PERF_GLOBAL_CTRL. >> + */ >> + struct hw_perf_event *hwc = >> + &pmc->perf_event->hw; >> + wrmsrl(hwc->event_base, data); > > Is that guaranteed to be always called on the right CPU that will run the vcpu? > > AFAIK there's an ioctl to set MSRs in the guest from qemu, I'm pretty sure > it won't handle that. How much of the performance improvement comes from here? In theory pmc_read_counter() should always hit a relatively fast path, because the smp_call_function_single in perf_event_read doesn't need an IPI. In any case, this should be a separate patch. Paolo > May need to be delayed to entry time. > > -Andi >
On Fri, Oct 12, 2018 at 08:20:17PM +0800, Wei Wang wrote: > Guest changing MSR_CORE_PERF_GLOBAL_CTRL causes KVM to reprogram pmc > counters, which re-allocates a host perf event. This process is Yea gawds, that's horrific. Why does it do that? We have PERF_EVENT_IOC_PERIOD which does that much better. Still, what you're proposing is faster still -- if it is correct. > This patch implements a fast path to handle the guest change of > MSR_CORE_PERF_GLOBAL_CTRL for the guest pmi case. Guest change of the > msr will be applied to the hardware when entering the guest, and the > old perf event will continue to be used. The guest setting of the > perf counter for the next irq period in pmi will also be written > directly to the hardware counter when entering the guest. What you're failing to explain here is why exactly it is ok to write to the MSR directly without updating the perf_event state. I didn't take the time to go through all that, but it certainly needs documenting. This is something that can certainly get broken by accident. Is there any documentation/comment that explains how this virtual PMU crud works in general? > +u64 intel_pmu_disable_guest_counters(void) > +{ > + struct cpu_hw_events *cpuc = this_cpu_ptr(&cpu_hw_events); > + u64 mask = cpuc->intel_ctrl_host_mask; > + > + cpuc->intel_ctrl_host_mask = ULONG_MAX; > + > + return mask; > +} > +EXPORT_SYMBOL_GPL(intel_pmu_disable_guest_counters); OK, this them gets the MSR written when we re-enter the guest, after the WRMSR trap, right? > diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c > index 58ead7d..210e5df 100644 > --- a/arch/x86/kvm/pmu.c > +++ b/arch/x86/kvm/pmu.c > @@ -80,6 +80,7 @@ static void kvm_perf_overflow_intr(struct perf_event *perf_event, > (unsigned long *)&pmu->reprogram_pmi)) { > __set_bit(pmc->idx, (unsigned long *)&pmu->global_status); > kvm_make_request(KVM_REQ_PMU, pmc->vcpu); > + pmu->in_pmi = true; > > /* > * Inject PMI. If vcpu was in a guest mode during NMI PMI > diff --git a/arch/x86/kvm/pmu_intel.c b/arch/x86/kvm/pmu_intel.c > index 5ab4a36..5f6ac3c 100644 > --- a/arch/x86/kvm/pmu_intel.c > +++ b/arch/x86/kvm/pmu_intel.c > @@ -55,6 +55,27 @@ static void reprogram_fixed_counters(struct kvm_pmu *pmu, u64 data) > pmu->fixed_ctr_ctrl = data; > } > > +static void fast_global_ctrl_changed(struct kvm_pmu *pmu, u64 data) > +{ > + pmu->global_ctrl = data; > + > + if (!data) { > + /* > + * The guest PMI handler is asking for disabling all the perf > + * counters > + */ > + pmu->counter_mask = intel_pmu_disable_guest_counters(); > + } else { > + /* > + * The guest PMI handler is asking for enabling the perf > + * counters. This happens at the end of the guest PMI handler, > + * so clear in_pmi. > + */ > + intel_pmu_enable_guest_counters(pmu->counter_mask); > + pmu->in_pmi = false; > + } > +} The v4 PMI handler does not in fact do that I think. > @@ -237,9 +267,23 @@ static int intel_pmu_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info) > default: > if ((pmc = get_gp_pmc(pmu, msr, MSR_IA32_PERFCTR0)) || > (pmc = get_fixed_pmc(pmu, msr))) { > - if (!msr_info->host_initiated) > - data = (s64)(s32)data; > - pmc->counter += data - pmc_read_counter(pmc); > + if (pmu->in_pmi) { > + /* > + * Since we are not re-allocating a perf event > + * to reconfigure the sampling time when the > + * guest pmu is in PMI, just set the value to > + * the hardware perf counter. Counting will > + * continue after the guest enables the > + * counter bit in MSR_CORE_PERF_GLOBAL_CTRL. > + */ > + struct hw_perf_event *hwc = > + &pmc->perf_event->hw; > + wrmsrl(hwc->event_base, data); But all this relies on the event calling the overflow handler; how does this not corrupt the event state such that x86_perf_event_set_period() might decide that the generated PMI is a spurious one? > + } else { > + if (!msr_info->host_initiated) > + data = (s64)(s32)data; > + pmc->counter += data - pmc_read_counter(pmc); > + } > return 0; > } else if ((pmc = get_gp_pmc(pmu, msr, MSR_P6_EVNTSEL0))) { > if (data == pmc->eventsel) > -- > 2.7.4 >
On 10/13/2018 04:09 PM, Paolo Bonzini wrote: > >> It's not clear to me why you're special casing PMIs here. The optimization >> should work generically, right? > Yeah, you can even just check if the counter is in the struct > cpu_hw_events guest mask, and if so always write the counter MSR directly. Not sure if we could do that. I think the guest mask on the host reflects which counters are used by the host. Here is the plan I have in mind: #1 Creates a host perf event on the guest's first bit-setting to MSR_CORE_PERF_GLOBAL_CTRL; Meanwhile, disable the intercept of guest access to this perf counter related MSRs (i.e. config_base and event_base). #2 When the vCPU is sched in, #2.1 make the MSRs of the perf counters (assigned to the guest in #1) interceptible, so that guest accesses to such a counter is captured, and marked it "used", and disable the intercept again; #2.2 also check if there is any counter that wasn't "used" in the last vCPU time slice, if there is, release that counter and the perf event. > >>> @@ -237,9 +267,23 @@ static int intel_pmu_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info) >>> default: >>> if ((pmc = get_gp_pmc(pmu, msr, MSR_IA32_PERFCTR0)) || >>> (pmc = get_fixed_pmc(pmu, msr))) { >>> - if (!msr_info->host_initiated) >>> - data = (s64)(s32)data; >>> - pmc->counter += data - pmc_read_counter(pmc); >>> + if (pmu->in_pmi) { >>> + /* >>> + * Since we are not re-allocating a perf event >>> + * to reconfigure the sampling time when the >>> + * guest pmu is in PMI, just set the value to >>> + * the hardware perf counter. Counting will >>> + * continue after the guest enables the >>> + * counter bit in MSR_CORE_PERF_GLOBAL_CTRL. >>> + */ >>> + struct hw_perf_event *hwc = >>> + &pmc->perf_event->hw; >>> + wrmsrl(hwc->event_base, data); >> Is that guaranteed to be always called on the right CPU that will run the vcpu? >> >> AFAIK there's an ioctl to set MSRs in the guest from qemu, I'm pretty sure >> it won't handle that. > How much of the performance improvement comes from here? In theory > pmc_read_counter() should always hit a relatively fast path, because the > smp_call_function_single in perf_event_read doesn't need an IPI. > > In any case, this should be a separate patch. Actually this change wasn't intended for performance improvement. It was adapted for the "fast path" we added to the MSR_CORE_PERF_GLOBAL_CTRL write handling. The old implementation captures the guest updating of the period in pmc->counter, and then uses the pmc->counter for the perf event creation, which gets the guest requested period written to the underlying counter via the host perf core. The fast path avoids the perf event creation, and accordingly, we need to update the period value directly to the hardware counter. Best, Wei
On 10/13/2018 09:30 PM, Peter Zijlstra wrote: > On Fri, Oct 12, 2018 at 08:20:17PM +0800, Wei Wang wrote: >> Guest changing MSR_CORE_PERF_GLOBAL_CTRL causes KVM to reprogram pmc >> counters, which re-allocates a host perf event. This process is > Yea gawds, that's horrific. Why does it do that? We have > PERF_EVENT_IOC_PERIOD which does that much better. Still, what you're > proposing is faster still -- if it is correct. I'm not sure about the back story. Probably it was an initial functional implementation. >> This patch implements a fast path to handle the guest change of >> MSR_CORE_PERF_GLOBAL_CTRL for the guest pmi case. Guest change of the >> msr will be applied to the hardware when entering the guest, and the >> old perf event will continue to be used. The guest setting of the >> perf counter for the next irq period in pmi will also be written >> directly to the hardware counter when entering the guest. > What you're failing to explain here is why exactly it is ok to write to > the MSR directly without updating the perf_event state. I didn't take > the time to go through all that, but it certainly needs documenting. OK. The guest itself has the perf event (the one that is using the hardware counter), and the event state is managed by the guest perf core. The host side perf event isn't the one that uses the hardware counter. Essentially, it is here on the host just to occupy the counter (via the host perf core) for the guest. The writing to the MSR here is essentially performed on behave of the guest perf event. So, for the host side perf event, I think its state should be active as long as the guest is using the counter. The state will be changed to inactive (as usual) when the vCPU is scheduled out. > This is something that can certainly get broken by accident. > > Is there any documentation/comment that explains how this virtual PMU > crud works in general? I haven't found any docs that could be useful so far. >> +u64 intel_pmu_disable_guest_counters(void) >> +{ >> + struct cpu_hw_events *cpuc = this_cpu_ptr(&cpu_hw_events); >> + u64 mask = cpuc->intel_ctrl_host_mask; >> + >> + cpuc->intel_ctrl_host_mask = ULONG_MAX; >> + >> + return mask; >> +} >> +EXPORT_SYMBOL_GPL(intel_pmu_disable_guest_counters); > OK, this them gets the MSR written when we re-enter the guest, after the > WRMSR trap, right? Yes, the guest value will be loaded to the MSR. > > + /* > + * The guest PMI handler is asking for enabling the perf > + * counters. This happens at the end of the guest PMI handler, > + * so clear in_pmi. > + */ > + intel_pmu_enable_guest_counters(pmu->counter_mask); > + pmu->in_pmi = false; > + } > +} > The v4 PMI handler does not in fact do that I think. > >> @@ -237,9 +267,23 @@ static int intel_pmu_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info) >> default: >> if ((pmc = get_gp_pmc(pmu, msr, MSR_IA32_PERFCTR0)) || >> (pmc = get_fixed_pmc(pmu, msr))) { >> - if (!msr_info->host_initiated) >> - data = (s64)(s32)data; >> - pmc->counter += data - pmc_read_counter(pmc); >> + if (pmu->in_pmi) { >> + /* >> + * Since we are not re-allocating a perf event >> + * to reconfigure the sampling time when the >> + * guest pmu is in PMI, just set the value to >> + * the hardware perf counter. Counting will >> + * continue after the guest enables the >> + * counter bit in MSR_CORE_PERF_GLOBAL_CTRL. >> + */ >> + struct hw_perf_event *hwc = >> + &pmc->perf_event->hw; >> + wrmsrl(hwc->event_base, data); > But all this relies on the event calling the overflow handler; how does > this not corrupt the event state such that x86_perf_event_set_period() > might decide that the generated PMI is a spurious one? > We will make the optimization more general in the next version, instead of relying on PMI, so the above 2 questions would be gone then. Best, Wei
On Sunday, October 14, 2018 8:41 PM, Wei Wang wrote: > Here is the plan I have in mind: > #1 Creates a host perf event on the guest's first bit-setting to > MSR_CORE_PERF_GLOBAL_CTRL; Meanwhile, disable the intercept of guest > access to this perf counter related MSRs (i.e. config_base and event_base). > #2 When the vCPU is sched in, > #2.1 make the MSRs of the perf counters (assigned to the guest in > #1) interceptible, so that guest accesses to such a counter is captured, and > marked it "used", and disable the intercept again; > #2.2 also check if there is any counter that wasn't "used" in the last vCPU > time slice, if there is, release that counter and the perf event. Just thought of an issue with passing through config_base and event base - the guest's view of the perf counter is possible to be different from the one assigned by the host, which results in guest using a different config_base and event_base. So we would still need keep those MSRs being intercepted by the host. The remaining part (the lazy allocation and release of the host perf event) can still work. Best, Wei
diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c index 035c374..b1e1294 100644 --- a/arch/x86/events/intel/core.c +++ b/arch/x86/events/intel/core.c @@ -1858,6 +1858,41 @@ static __initconst const u64 knl_hw_cache_extra_regs }, }; +/** + * intel_pmu_disable_guest_counters - disable perf counters for the guest + * + * Disable all the perf counters for the guest via setting the host mask. + * This will cause all the perf counters to be disabled when entering + * the guest. + * + * Returns: the old counter mask. + */ +u64 intel_pmu_disable_guest_counters(void) +{ + struct cpu_hw_events *cpuc = this_cpu_ptr(&cpu_hw_events); + u64 mask = cpuc->intel_ctrl_host_mask; + + cpuc->intel_ctrl_host_mask = ULONG_MAX; + + return mask; +} +EXPORT_SYMBOL_GPL(intel_pmu_disable_guest_counters); + +/** + * intel_pmu_enable_guest_counters - enable perf counters for the guest + * + * Enable perf counters for the guest via setting the host mask to the + * caller's counter mask. The counters corresponding to the unmasked bits + * will be enabled when entering the guest. + */ +void intel_pmu_enable_guest_counters(u64 mask) +{ + struct cpu_hw_events *cpuc = this_cpu_ptr(&cpu_hw_events); + + cpuc->intel_ctrl_host_mask = mask; +} +EXPORT_SYMBOL_GPL(intel_pmu_enable_guest_counters); + /* * Used from PMIs where the LBRs are already disabled. * diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h index 09b2e3e..9dc2fed 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -427,6 +427,8 @@ struct kvm_pmu { u64 counter_bitmask[2]; u64 global_ctrl_mask; u64 reserved_bits; + u64 counter_mask; + bool in_pmi; u8 version; struct kvm_pmc gp_counters[INTEL_PMC_MAX_GENERIC]; struct kvm_pmc fixed_counters[INTEL_PMC_MAX_FIXED]; diff --git a/arch/x86/include/asm/perf_event.h b/arch/x86/include/asm/perf_event.h index 78241b7..d653b12 100644 --- a/arch/x86/include/asm/perf_event.h +++ b/arch/x86/include/asm/perf_event.h @@ -296,6 +296,8 @@ static inline void perf_check_microcode(void) { } #ifdef CONFIG_CPU_SUP_INTEL extern void intel_pt_handle_vmx(int on); +extern u64 intel_pmu_disable_guest_counters(void); +extern void intel_pmu_enable_guest_counters(u64 mask); #endif #if defined(CONFIG_PERF_EVENTS) && defined(CONFIG_CPU_SUP_AMD) diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c index 58ead7d..210e5df 100644 --- a/arch/x86/kvm/pmu.c +++ b/arch/x86/kvm/pmu.c @@ -80,6 +80,7 @@ static void kvm_perf_overflow_intr(struct perf_event *perf_event, (unsigned long *)&pmu->reprogram_pmi)) { __set_bit(pmc->idx, (unsigned long *)&pmu->global_status); kvm_make_request(KVM_REQ_PMU, pmc->vcpu); + pmu->in_pmi = true; /* * Inject PMI. If vcpu was in a guest mode during NMI PMI diff --git a/arch/x86/kvm/pmu_intel.c b/arch/x86/kvm/pmu_intel.c index 5ab4a36..5f6ac3c 100644 --- a/arch/x86/kvm/pmu_intel.c +++ b/arch/x86/kvm/pmu_intel.c @@ -55,6 +55,27 @@ static void reprogram_fixed_counters(struct kvm_pmu *pmu, u64 data) pmu->fixed_ctr_ctrl = data; } +static void fast_global_ctrl_changed(struct kvm_pmu *pmu, u64 data) +{ + pmu->global_ctrl = data; + + if (!data) { + /* + * The guest PMI handler is asking for disabling all the perf + * counters + */ + pmu->counter_mask = intel_pmu_disable_guest_counters(); + } else { + /* + * The guest PMI handler is asking for enabling the perf + * counters. This happens at the end of the guest PMI handler, + * so clear in_pmi. + */ + intel_pmu_enable_guest_counters(pmu->counter_mask); + pmu->in_pmi = false; + } +} + /* function is called when global control register has been updated. */ static void global_ctrl_changed(struct kvm_pmu *pmu, u64 data) { @@ -219,6 +240,15 @@ static int intel_pmu_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info) } break; /* RO MSR */ case MSR_CORE_PERF_GLOBAL_CTRL: + /* + * If this is from the guest PMI handler to disable or enable + * the perf counters, there is no need to release and allocate + * a new perf event, which is too time consuming. + */ + if (pmu->in_pmi) { + fast_global_ctrl_changed(pmu, data); + return 0; + } if (pmu->global_ctrl == data) return 0; if (!(data & pmu->global_ctrl_mask)) { @@ -237,9 +267,23 @@ static int intel_pmu_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info) default: if ((pmc = get_gp_pmc(pmu, msr, MSR_IA32_PERFCTR0)) || (pmc = get_fixed_pmc(pmu, msr))) { - if (!msr_info->host_initiated) - data = (s64)(s32)data; - pmc->counter += data - pmc_read_counter(pmc); + if (pmu->in_pmi) { + /* + * Since we are not re-allocating a perf event + * to reconfigure the sampling time when the + * guest pmu is in PMI, just set the value to + * the hardware perf counter. Counting will + * continue after the guest enables the + * counter bit in MSR_CORE_PERF_GLOBAL_CTRL. + */ + struct hw_perf_event *hwc = + &pmc->perf_event->hw; + wrmsrl(hwc->event_base, data); + } else { + if (!msr_info->host_initiated) + data = (s64)(s32)data; + pmc->counter += data - pmc_read_counter(pmc); + } return 0; } else if ((pmc = get_gp_pmc(pmu, msr, MSR_P6_EVNTSEL0))) { if (data == pmc->eventsel)
Guest changing MSR_CORE_PERF_GLOBAL_CTRL causes KVM to reprogram pmc counters, which re-allocates a host perf event. This process is heavyweight and results in a long guest pmi handling time. This also makes the perf samping events in the guest hard to move forward as the sampling rate will be adjusted to a low value (e.g. the minimum 250). This patch implements a fast path to handle the guest change of MSR_CORE_PERF_GLOBAL_CTRL for the guest pmi case. Guest change of the msr will be applied to the hardware when entering the guest, and the old perf event will continue to be used. The guest setting of the perf counter for the next irq period in pmi will also be written directly to the hardware counter when entering the guest. Tests: 1. CPU: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz 2. Add host booting parameter "nowatchdog" to avoid the noise from watchdog_hld 3. Run "perf stat -e cycles ./test_program" on the guest 4. Results - Without this optimization, the guest pmi handling time is ~4500000 ns, and the max sampling rate is reduced to 250. - With this optimization, the guest pmi handling time is ~9000 ns (i.e. 1 / 500 of the non-optimization case), and the max sampling rate remains at the original 100000. Signed-off-by: Wei Wang <wei.w.wang@intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Paolo Bonzini <pbonzini@redhat.com> --- arch/x86/events/intel/core.c | 35 +++++++++++++++++++++++++++ arch/x86/include/asm/kvm_host.h | 2 ++ arch/x86/include/asm/perf_event.h | 2 ++ arch/x86/kvm/pmu.c | 1 + arch/x86/kvm/pmu_intel.c | 50 ++++++++++++++++++++++++++++++++++++--- 5 files changed, 87 insertions(+), 3 deletions(-)