Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 164
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 26 7月, 2019 1 次提交
  3. 19 6月, 2019 1 次提交
  5. 17 3月, 2018 1 次提交
  7. 01 3月, 2017 1 次提交
    • R
      KVM: x86: never specify a sample period for virtualized in_tx_cp counters · bba82fd7
      由 Robert O'Callahan 提交于 
      pmc_reprogram_counter() always sets a sample period based on the value of
pmc->counter. However, hsw_hw_config() rejects sample periods less than
2^31 - 1. So for example, if a KVM guest does

    struct perf_event_attr attr;
    memset(&attr, 0, sizeof(attr));
    attr.type = PERF_TYPE_RAW;
    attr.size = sizeof(attr);
    attr.config = 0x2005101c4; // conditional branches retired IN_TXCP
    attr.sample_period = 0;
    int fd = syscall(__NR_perf_event_open, &attr, 0, -1, -1, 0);
    ioctl(fd, PERF_EVENT_IOC_DISABLE, 0);
    ioctl(fd, PERF_EVENT_IOC_ENABLE, 0);

the guest kernel counts some conditional branch events, then updates the
virtual PMU register with a nonzero count. The host reaches
pmc_reprogram_counter() with nonzero pmc->counter, triggers EOPNOTSUPP
in hsw_hw_config(), prints "kvm_pmu: event creation failed" in
pmc_reprogram_counter(), and silently (from the guest's point of view) stops
counting events.

We fix event counting by forcing attr.sample_period to always be zero for
in_tx_cp counters. Sampling doesn't work, but it already didn't work and
can't be fixed without major changes to the approach in hsw_hw_config().
Signed-off-by: NRobert O'Callahan <robert@ocallahan.org>
Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com>
      bba82fd7
  9. 09 2月, 2016 1 次提交
  11. 23 6月, 2015 2 次提交
  13. 19 6月, 2015 5 次提交
  15. 18 3月, 2015 1 次提交
  17. 20 8月, 2014 1 次提交
  19. 18 6月, 2014 1 次提交
  21. 24 4月, 2014 1 次提交
    • N
      KVM: x86: Fix wrong/stuck PMU when guest does not use PMI · 671bd993
      由 Nadav Amit 提交于 
      If a guest enables a performance counter but does not enable PMI, the
hypervisor currently does not reprogram the performance counter once it
overflows.  As a result the host performance counter is kept with the original
sampling period which was configured according to the value of the guest's
counter when the counter was enabled.

Such behaviour can cause very bad consequences. The most distrubing one can
cause the guest not to make any progress at all, and keep exiting due to host
PMI before any guest instructions is exeucted. This situation occurs when the
performance counter holds a very high value when the guest enables the
performance counter. As a result the host's sampling period is configured to be
very short. The host then never reconfigures the sampling period and get stuck
at entry->PMI->exit loop. We encountered such a scenario in our experiments.

The solution is to reprogram the counter even if the guest does not use PMI.
Signed-off-by: NNadav Amit <namit@cs.technion.ac.il>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
      671bd993
  23. 20 7月, 2013 1 次提交
  25. 02 4月, 2013 1 次提交
    • P
      pmu: prepare for migration support · afd80d85
      由 Paolo Bonzini 提交于 
      In order to migrate the PMU state correctly, we need to restore the
values of MSR_CORE_PERF_GLOBAL_STATUS (a read-only register) and
MSR_CORE_PERF_GLOBAL_OVF_CTRL (which has side effects when written).
We also need to write the full 40-bit value of the performance counter,
which would only be possible with a v3 architectural PMU's full-width
counter MSRs.

To distinguish host-initiated writes from the guest's, pass the
full struct msr_data to kvm_pmu_set_msr.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NGleb Natapov <gleb@redhat.com>
      afd80d85
  27. 21 7月, 2012 1 次提交
  29. 06 7月, 2012 1 次提交
  31. 10 4月, 2012 1 次提交
  33. 06 4月, 2012 1 次提交
  35. 08 3月, 2012 4 次提交
  37. 27 12月, 2011 1 次提交