Something that is worrying is that we don't expose group information.I just want perf generic codes have less dependency on KVM codes.
perf will multiplex the events for us, but there will be a loss in accuracy.
#ifdef CONFIG_HAVE_HW_BREAKPOINTCan we have real types instead of void pointers?
#include<asm/hw_breakpoint.h>
#endif
@@ -753,6 +752,20 @@ struct perf_event {
perf_overflow_handler_t overflow_handler;
+ /*
+ * pointers used by kvm perf paravirt interface.
+ *
+ * 1) Used in host kernel and points to host_perf_shadow which
+ * has information about guest perf_event
+ */
+ void *host_perf_shadow;
It's a little hard to split the patches if they change the same file. Perhaps+ /*It's strange to see both guest and host parts in the same patch.
+ * 2) Used in guest kernel and points to guest_perf_shadow which
+ * is used as a communication area with host kernel. Host kernel
+ * copies overflow data to it when an event overflows.
+ */
+ void *guest_perf_shadow;
Splitting to separate patches will really help review.
I could add more statements before the patch when I send it out.
It's a good idea. But that will touch many perf generic codes which causes it's hard@@ -1626,9 +1629,22 @@ void perf_event_task_tick(struct task_stPerhaps we can have a batch read interface which will read many counters
if (ctx&& ctx->nr_events&& ctx->nr_events != ctx->nr_active)
rotate = 1;
- perf_ctx_adjust_freq(&cpuctx->ctx);
- if (ctx)
- perf_ctx_adjust_freq(ctx);
+#ifdef CONFIG_KVM_PERF
+ if (kvm_para_available()) {
+ /*
+ * perf_ctx_adjust_freq causes lots of pmu->read which would
+ * trigger too many vmexit to host kernel. We disable it
+ * under para virt situation
+ */
+ adjust_freq = 0;
+ }
+#endif
at once.
to maintain or follow future changes.