KVM in-guest performance monitoring

From: Avi Kivity <[email protected]>

Use perf_events to emulate an architectural PMU, version 2.

arch/x86/kvm/pmu.c new file +6 -0

+
+/* mapping between fixed pmc index and arch_events array */
+int fixed_pmc_events[] = {1, 0, 2};
+
+static bool pmc_is_gp(struct kvm_pmc *pmc)
+{

arch/x86/kvm/pmu.c new file +7 -0

+
+static inline int pmc_to_global_idx(struct kvm_pmc *pmc)
+{
+	struct kvm_pmu *pmu = &pmc->vcpu->arch.pmu;
+	struct kvm_pmc *counters;
+	int shift;
+

arch/x86/kvm/pmu.c new file +12 -0

+
+static void kvm_perf_overflow(struct perf_event *perf_event,
+			      struct perf_sample_data *data,
+			      struct pt_regs *regs)
+{
+	struct kvm_pmc *pmc = perf_event->overflow_handler_context;
+	struct kvm_pmu *pmu = &pmc->vcpu->arch.pmu;
+	__set_bit(pmc_to_global_idx(pmc),
+			(unsigned long *)&pmu->global_status);
+}
+
+static void kvm_perf_overflow_intr(struct perf_event *perf_event,

arch/x86/kvm/pmu.c new file +6 -0

+
+static void reprogram_fixed_counter(struct kvm_pmc *pmc, u8 en_pmi, int idx)
+{
+	unsigned en = en_pmi & 0x3;
+	bool pmi = en_pmi & 0x8;
+

arch/x86/kvm/pmu.c new file +37 -0

+	default:
+		if ((pmc = get_gp_pmc(pmu, index, MSR_IA32_PERFCTR0)) ||
+				(pmc = get_fixed_pmc(pmu, index))) {
+			data = (s64)(s32)data;
+			pmc->counter += data - read_pmc(pmc);
+			return 0;
+		} else if ((pmc = get_gp_pmc(pmu, index, MSR_P6_EVNTSEL0))) {
+			if (data == pmc->eventsel)
+				return 0;
+			if (!(data & 0xffffffff00200000ull)) {
+				reprogram_gp_counter(pmc, data);
+				return 0;
+			}
+		}
+	}
+	return 1;
+}
+
+
+void kvm_pmu_cpuid_update(struct kvm_vcpu *vcpu)
+{
+	struct kvm_pmu *pmu = &vcpu->arch.pmu;
+	struct kvm_cpuid_entry2 *entry;
+	unsigned bitmap_len;
+
+	pmu->nr_arch_gp_counters = 0;
+	pmu->nr_arch_fixed_counters = 0;
+	pmu->fixed_counter_bitmask = 0;
+	pmu->version = 0;
+
+	entry = kvm_find_cpuid_entry(vcpu, 0xa, 0);
+	if (!entry)
+		return;
+
+	pmu->version = entry->eax & 0xff;
+	if (!pmu->version)
+		return;

Quoted 1 line · Gleb Natapov

From: Avi Kivity <[email protected]>

This has changed significantly, so please update the authorship. You can say 'based on original patch by ...' to provide due credit.

Quoted 12 lines

Use perf_events to emulate an architectural PMU, version 2.

arch/x86/kvm/pmu.c new file +10 -0

+
+/* mapping between fixed pmc index and arch_events array */
+int fixed_pmc_events[] = {1, 0, 2};
+
+static bool pmc_is_gp(struct kvm_pmc *pmc)
+{
+	return pmc->type == KVM_PMC_GP;
+}
+
+static inline u64 pmc_bitmask(struct kvm_pmc *pmc)

arch/x86/kvm/pmu.c line 51

Quoted 6 lines

arch/x86/kvm/pmu.c new file +6 -0

+{
+	struct kvm_pmu *pmu = &pmc->vcpu->arch.pmu;
+
+	return pmc_is_gp(pmc) ? pmu->gp_counter_bitmask :
+		pmu->fixed_counter_bitmask;
+}

Nicer to just push the bitmask (or bitwidth) into the counter itself.

Quoted 11 lines

arch/x86/kvm/pmu.c new file +11 -0

+
+static inline int pmc_to_global_idx(struct kvm_pmc *pmc)
+{
+	struct kvm_pmu *pmu = &pmc->vcpu->arch.pmu;
+	struct kvm_pmc *counters;
+	int shift;
+
+	if (pmc_is_gp(pmc)) {
+		counters = pmu->gp_counters;
+		shift = X86_PMC_IDX_GENERIC;
+	} else {

arch/x86/kvm/pmu.c line 68

Quoted 6 lines

arch/x86/kvm/pmu.c new file +6 -0

+		counters = pmu->fixed_counters;
+		shift = X86_PMC_IDX_FIXED;
+	}
+
+	return pmc - counters + shift;
+}

Again, push the global index into struct kvm_pmc.

Quoted 17 lines

arch/x86/kvm/pmu.c new file +16 -0

+
+static void kvm_perf_overflow(struct perf_event *perf_event,
+			      struct perf_sample_data *data,
+			      struct pt_regs *regs)
+{
+	struct kvm_pmc *pmc = perf_event->overflow_handler_context;
+	struct kvm_pmu *pmu = &pmc->vcpu->arch.pmu;
+	__set_bit(pmc_to_global_idx(pmc),
+			(unsigned long *)&pmu->global_status);
+}
+
+static void kvm_perf_overflow_intr(struct perf_event *perf_event,
+		struct perf_sample_data *data, struct pt_regs *regs)
+{
+	struct kvm_pmc *pmc = perf_event->overflow_handler_context;
+	struct kvm_pmu *pmu = &pmc->vcpu->arch.pmu;

arch/x86/kvm/pmu.c line 122

Quoted 6 lines

arch/x86/kvm/pmu.c new file +6 -0

+	if (!__test_and_set_bit(pmc_to_global_idx(pmc),
+				(unsigned long *)&pmu->reprogram_pmi)) {
+		kvm_perf_overflow(perf_event, data, regs);
+		kvm_make_request(KVM_REQ_PMU, pmc->vcpu);
+	}
+}

Is it safe to use the __ versions here?

Do we need to follow kvm_make_request() with kvm_vcpu_kick()? If there is a skew between the overflow and the host PMI, the guest might have executed a HLT.

Quoted 11 lines

arch/x86/kvm/pmu.c new file +10 -0

+
+static void reprogram_fixed_counter(struct kvm_pmc *pmc, u8 en_pmi, int idx)
+{
+	unsigned en = en_pmi & 0x3;
+	bool pmi = en_pmi & 0x8;
+
+	stop_counter(pmc);
+
+	if (!en || !pmc_enabled(pmc))
+		return;

arch/x86/kvm/pmu.c line 242

Quoted 6 lines

arch/x86/kvm/pmu.c new file +6 -0

+
+	reprogram_counter(pmc, PERF_TYPE_HARDWARE,
+			arch_events[fixed_pmc_events[idx]].event_type,
+			!(en & 0x2), /* exclude user */
+			!(en & 0x1), /* exclude kernel */
+			pmi);

Are there no #defines for those constants?

arch/x86/kvm/pmu.c line 245

Quoted 3 lines

arch/x86/kvm/pmu.c new file +3 -0

+}
+
+#define FIXED_EN_PMI(R, I) (((R) >> ((I) * 4)) & 0xf)

function

Quoted 37 lines

arch/x86/kvm/pmu.c new file +37 -0

+	default:
+		if ((pmc = get_gp_pmc(pmu, index, MSR_IA32_PERFCTR0)) ||
+				(pmc = get_fixed_pmc(pmu, index))) {
+			data = (s64)(s32)data;
+			pmc->counter += data - read_pmc(pmc);
+			return 0;
+		} else if ((pmc = get_gp_pmc(pmu, index, MSR_P6_EVNTSEL0))) {
+			if (data == pmc->eventsel)
+				return 0;
+			if (!(data & 0xffffffff00200000ull)) {
+				reprogram_gp_counter(pmc, data);
+				return 0;
+			}
+		}
+	}
+	return 1;
+}
+
+
+void kvm_pmu_cpuid_update(struct kvm_vcpu *vcpu)
+{
+	struct kvm_pmu *pmu = &vcpu->arch.pmu;
+	struct kvm_cpuid_entry2 *entry;
+	unsigned bitmap_len;
+
+	pmu->nr_arch_gp_counters = 0;
+	pmu->nr_arch_fixed_counters = 0;
+	pmu->fixed_counter_bitmask = 0;
+	pmu->version = 0;
+
+	entry = kvm_find_cpuid_entry(vcpu, 0xa, 0);
+	if (!entry)
+		return;
+
+	pmu->version = entry->eax & 0xff;
+	if (!pmu->version)
+		return;

arch/x86/kvm/pmu.c line 442

Quoted 10 lines

arch/x86/kvm/pmu.c new file +10 -0

+
+	pmu->nr_arch_gp_counters = min((int)(entry->eax >> 8) & 0xff,
+			X86_PMC_MAX_GENERIC);
+	pmu->gp_counter_bitmask = ((u64)1 << ((entry->eax >> 16) & 0xff)) - 1;
+	bitmap_len = (entry->eax >> 24) & 0xff;
+	pmu->available_event_types = ~entry->ebx & ((1ull << bitmap_len) - 1);
+
+	if (pmu->version > 1) {
+		pmu->nr_arch_fixed_counters = min((int)(entry->edx) & 0x1f,
+				X86_PMC_MAX_FIXED);

Misplaced parentheses (though no effect on generated code).

arch/x86/kvm/pmu.c line 444

Quoted 2 lines

arch/x86/kvm/pmu.c new file +2 -0

+		pmu->fixed_counter_bitmask =
+			((u64)1 << ((entry->edx >> 5) & 0xff)) - 1;

The user can cause this to be very small (even zero). Can this cause an NMI storm?

arch/x86/kvm/pmu.c line 450

Quoted 6 lines

arch/x86/kvm/pmu.c new file +6 -0

+		pmu->global_ctrl_mask = ~(((1 << pmu->nr_arch_gp_counters) - 1)
+				| (((1ull << pmu->nr_arch_fixed_counters) - 1)
+					<< X86_PMC_IDX_FIXED));
+	} else
+		pmu->global_ctrl = (1 << pmu->nr_arch_gp_counters) - 1;
+}

Nicer to just return early if version < 2; less indentation and easier to prepare for version 3.

Signature · 2 lines

I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Quoted 17 lines

Quoted 17 lines

arch/x86/kvm/pmu.c new file +16 -0

+
+static void kvm_perf_overflow(struct perf_event *perf_event,
+			      struct perf_sample_data *data,
+			      struct pt_regs *regs)
+{
+	struct kvm_pmc *pmc = perf_event->overflow_handler_context;
+	struct kvm_pmu *pmu = &pmc->vcpu->arch.pmu;
+	__set_bit(pmc_to_global_idx(pmc),
+			(unsigned long *)&pmu->global_status);
+}
+
+static void kvm_perf_overflow_intr(struct perf_event *perf_event,
+		struct perf_sample_data *data, struct pt_regs *regs)
+{
+	struct kvm_pmc *pmc = perf_event->overflow_handler_context;
+	struct kvm_pmu *pmu = &pmc->vcpu->arch.pmu;

Quoted 9 lines

arch/x86/kvm/pmu.c line 122

Quoted 6 lines

arch/x86/kvm/pmu.c new file +6 -0

+	if (!__test_and_set_bit(pmc_to_global_idx(pmc),
+				(unsigned long *)&pmu->reprogram_pmi)) {
+		kvm_perf_overflow(perf_event, data, regs);
+		kvm_make_request(KVM_REQ_PMU, pmc->vcpu);
+	}
+}

Is it safe to use the __ versions here?

It supposed to run in an NMI context on the same CPU that just ran the vcpu so simultaneous access to the same variable from different CPUs shouldn't be possible. But if your scenario below can happen then that assumption may not hold. The question is if PMI delivery can be so skewed as to be delivered long after vmexit (which switches perf msr values btw).

Quoted 26 lines · Gleb Natapov

Quoted 17 lines

Quoted 17 lines

arch/x86/kvm/pmu.c new file +16 -0

+
+static void kvm_perf_overflow(struct perf_event *perf_event,
+			      struct perf_sample_data *data,
+			      struct pt_regs *regs)
+{
+	struct kvm_pmc *pmc = perf_event->overflow_handler_context;
+	struct kvm_pmu *pmu = &pmc->vcpu->arch.pmu;
+	__set_bit(pmc_to_global_idx(pmc),
+			(unsigned long *)&pmu->global_status);
+}
+
+static void kvm_perf_overflow_intr(struct perf_event *perf_event,
+		struct perf_sample_data *data, struct pt_regs *regs)
+{
+	struct kvm_pmc *pmc = perf_event->overflow_handler_context;
+	struct kvm_pmu *pmu = &pmc->vcpu->arch.pmu;

Quoted 9 lines

arch/x86/kvm/pmu.c line 122

Quoted 6 lines

arch/x86/kvm/pmu.c new file +6 -0

+	if (!__test_and_set_bit(pmc_to_global_idx(pmc),
+				(unsigned long *)&pmu->reprogram_pmi)) {
+		kvm_perf_overflow(perf_event, data, regs);
+		kvm_make_request(KVM_REQ_PMU, pmc->vcpu);
+	}
+}

Is it safe to use the __ versions here?

Quoted 7 lines

It supposed to run in an NMI context on the same CPU that just ran the vcpu so simultaneous access to the same variable from different CPUs shouldn't be possible. But if your scenario below can happen then that assumption may not hold. The question is if PMI delivery can be so skewed as to be delivered long after vmexit (which switches perf msr values btw).

Thinking about it some more since perf events we create are bound to a vcpu task it is impossible to have event callback called on a different CPU.

Quoted 34 lines · Gleb Natapov

Quoted 33 lines · Gleb Natapov

Quoted 17 lines

Quoted 17 lines

arch/x86/kvm/pmu.c new file +16 -0

+
+static void kvm_perf_overflow(struct perf_event *perf_event,
+			      struct perf_sample_data *data,
+			      struct pt_regs *regs)
+{
+	struct kvm_pmc *pmc = perf_event->overflow_handler_context;
+	struct kvm_pmu *pmu = &pmc->vcpu->arch.pmu;
+	__set_bit(pmc_to_global_idx(pmc),
+			(unsigned long *)&pmu->global_status);
+}
+
+static void kvm_perf_overflow_intr(struct perf_event *perf_event,
+		struct perf_sample_data *data, struct pt_regs *regs)
+{
+	struct kvm_pmc *pmc = perf_event->overflow_handler_context;
+	struct kvm_pmu *pmu = &pmc->vcpu->arch.pmu;

Quoted 9 lines

arch/x86/kvm/pmu.c line 122

Quoted 6 lines

arch/x86/kvm/pmu.c new file +6 -0

+	if (!__test_and_set_bit(pmc_to_global_idx(pmc),
+				(unsigned long *)&pmu->reprogram_pmi)) {
+		kvm_perf_overflow(perf_event, data, regs);
+		kvm_make_request(KVM_REQ_PMU, pmc->vcpu);
+	}
+}

Is it safe to use the __ versions here?

It supposed to run in an NMI context on the same CPU that just ran the vcpu so simultaneous access to the same variable from different CPUs shouldn't be possible. But if your scenario below can happen then that assumption may not hold. The question is if PMI delivery can be so skewed as to be delivered long after vmexit (which switches perf msr values btw).

Quoted 2 lines

Thinking about it some more since perf events we create are bound to a vcpu task it is impossible to have event callback called on a different CPU.

Ok. Maybe there is some theoretical skew value that gets the NMI delayed past the context switch, but not on any real cpu.

Quoted 10 lines

Quoted 10 lines

arch/x86/kvm/pmu.c new file +10 -0

+
+/* mapping between fixed pmc index and arch_events array */
+int fixed_pmc_events[] = {1, 0, 2};
+
+static bool pmc_is_gp(struct kvm_pmc *pmc)
+{
+	return pmc->type == KVM_PMC_GP;
+}
+
+static inline u64 pmc_bitmask(struct kvm_pmc *pmc)

Quoted 9 lines

arch/x86/kvm/pmu.c line 51

Quoted 6 lines

arch/x86/kvm/pmu.c new file +6 -0

+{
+	struct kvm_pmu *pmu = &pmc->vcpu->arch.pmu;
+
+	return pmc_is_gp(pmc) ? pmu->gp_counter_bitmask :
+		pmu->fixed_counter_bitmask;
+}

Nicer to just push the bitmask (or bitwidth) into the counter itself.

Hmm, is it really nicer to replicate the same information 35 times?

Quoted 6 lines

Quoted 6 lines

arch/x86/kvm/pmu.c new file +6 -0

+
+static void kvm_perf_overflow_intr(struct perf_event *perf_event,
+		struct perf_sample_data *data, struct pt_regs *regs)
+{
+	struct kvm_pmc *pmc = perf_event->overflow_handler_context;
+	struct kvm_pmu *pmu = &pmc->vcpu->arch.pmu;

Quoted 9 lines

arch/x86/kvm/pmu.c line 122

Quoted 6 lines

arch/x86/kvm/pmu.c new file +6 -0

+	if (!__test_and_set_bit(pmc_to_global_idx(pmc),
+				(unsigned long *)&pmu->reprogram_pmi)) {
+		kvm_perf_overflow(perf_event, data, regs);
+		kvm_make_request(KVM_REQ_PMU, pmc->vcpu);
+	}
+}

Is it safe to use the __ versions here?

It supposed to run in an NMI context on the same CPU that just ran the vcpu so simultaneous access to the same variable from different CPUs shouldn't be possible. But if your scenario below can happen then that assumption may not hold. The question is if PMI delivery can be so skewed as to be delivered long after vmexit (which switches perf msr values btw).

Quoted 3 lines

Do we need to follow kvm_make_request() with kvm_vcpu_kick()? If there is a skew between the overflow and the host PMI, the guest might have executed a HLT.

Is kvm_vcpu_kick() safe for NMI context?

Quoted 11 lines

Quoted 11 lines

arch/x86/kvm/pmu.c new file +10 -0

+
+static void reprogram_fixed_counter(struct kvm_pmc *pmc, u8 en_pmi, int idx)
+{
+	unsigned en = en_pmi & 0x3;
+	bool pmi = en_pmi & 0x8;
+
+	stop_counter(pmc);
+
+	if (!en || !pmc_enabled(pmc))
+		return;

Quoted 9 lines

arch/x86/kvm/pmu.c line 242

Quoted 6 lines

arch/x86/kvm/pmu.c new file +6 -0

+
+	reprogram_counter(pmc, PERF_TYPE_HARDWARE,
+			arch_events[fixed_pmc_events[idx]].event_type,
+			!(en & 0x2), /* exclude user */
+			!(en & 0x1), /* exclude kernel */
+			pmi);

Are there no #defines for those constants?

Nope. perf_event_intel.c open codes them too.

Quoted 4 lines

The user can cause this to be very small (even zero). Can this cause an NMI storm?

If user will set it to zero then attr.sample_period will always be 0 and perf will think that the event is non sampling and will use max_period instead. For a small value greater than zero how is it different from userspace creating an event with sample_period of 1?

Quoted 19 lines · Gleb Natapov

Quoted 19 lines

Quoted 6 lines

arch/x86/kvm/pmu.c new file +6 -0

+
+/* mapping between fixed pmc index and arch_events array */
+int fixed_pmc_events[] = {1, 0, 2};
+
+static bool pmc_is_gp(struct kvm_pmc *pmc)
+{

arch/x86/kvm/pmu.c line 51

Quoted 10 lines

arch/x86/kvm/pmu.c new file +10 -0

+	return pmc->type == KVM_PMC_GP;
+}
+
+static inline u64 pmc_bitmask(struct kvm_pmc *pmc)
+{
+	struct kvm_pmu *pmu = &pmc->vcpu->arch.pmu;
+
+	return pmc_is_gp(pmc) ? pmu->gp_counter_bitmask :
+		pmu->fixed_counter_bitmask;
+}

Nicer to just push the bitmask (or bitwidth) into the counter itself.

Quoted 1 line

Hmm, is it really nicer to replicate the same information 35 times?

If it were 35 times, you could do pmu->type->bitmask. But it's just 5 or 6 times.

Quoted 15 lines

Quoted 6 lines

Quoted 6 lines

arch/x86/kvm/pmu.c new file +6 -0

+
+static void kvm_perf_overflow_intr(struct perf_event *perf_event,
+		struct perf_sample_data *data, struct pt_regs *regs)
+{
+	struct kvm_pmc *pmc = perf_event->overflow_handler_context;
+	struct kvm_pmu *pmu = &pmc->vcpu->arch.pmu;

Quoted 9 lines

arch/x86/kvm/pmu.c line 122

Quoted 6 lines

arch/x86/kvm/pmu.c new file +6 -0

+	if (!__test_and_set_bit(pmc_to_global_idx(pmc),
+				(unsigned long *)&pmu->reprogram_pmi)) {
+		kvm_perf_overflow(perf_event, data, regs);
+		kvm_make_request(KVM_REQ_PMU, pmc->vcpu);
+	}
+}

Is it safe to use the __ versions here?

Quoted 6 lines

It supposed to run in an NMI context on the same CPU that just ran the vcpu so simultaneous access to the same variable from different CPUs shouldn't be possible. But if your scenario below can happen then that assumption may not hold. The question is if PMI delivery can be so skewed as to be delivered long after vmexit (which switches perf msr values btw).

The compiler/runtime is allowed to implement __test_and_set_bit() as multiple instructions, no? Do we have any similar sequences outside nmi context?

Quoted 4 lines

Quoted 3 lines

Do we need to follow kvm_make_request() with kvm_vcpu_kick()? If there is a skew between the overflow and the host PMI, the guest might have executed a HLT.

Is kvm_vcpu_kick() safe for NMI context?

No. There is irq_work_queue() for that. Would be good to avoid it if we know that it's safe to (for example if we have PF_VCPU set).

Quoted 20 lines

Quoted 11 lines

Quoted 11 lines

arch/x86/kvm/pmu.c new file +10 -0

+
+static void reprogram_fixed_counter(struct kvm_pmc *pmc, u8 en_pmi, int idx)
+{
+	unsigned en = en_pmi & 0x3;
+	bool pmi = en_pmi & 0x8;
+
+	stop_counter(pmc);
+
+	if (!en || !pmc_enabled(pmc))
+		return;

Quoted 9 lines

arch/x86/kvm/pmu.c line 242

Quoted 6 lines

arch/x86/kvm/pmu.c new file +6 -0

+
+	reprogram_counter(pmc, PERF_TYPE_HARDWARE,
+			arch_events[fixed_pmc_events[idx]].event_type,
+			!(en & 0x2), /* exclude user */
+			!(en & 0x1), /* exclude kernel */
+			pmi);

Are there no #defines for those constants?

Quoted 1 line

Nope. perf_event_intel.c open codes them too.

Okay.

Quoted 4 lines

Quoted 4 lines

The user can cause this to be very small (even zero). Can this cause an NMI storm?

Quoted 4 lines

If user will set it to zero then attr.sample_period will always be 0 and perf will think that the event is non sampling and will use max_period instead. For a small value greater than zero how is it different from userspace creating an event with sample_period of 1?

I don't know. Does the kernel survive it?

Quoted 3 lines · Avi Kivity

No. There is irq_work_queue() for that. Would be good to avoid it if we know that it's safe to (for example if we have PF_VCPU set).

Checking PF_VCPU will not tell us that vcpu is going to reenter guest mode again.

Quoted 8 lines

Quoted 7 lines

Quoted 3 lines

The user can cause this to be very small (even zero). Can this cause an NMI storm?

If user will set it to zero then attr.sample_period will always be 0 and perf will think that the event is non sampling and will use max_period instead. For a small value greater than zero how is it different from userspace creating an event with sample_period of 1?

Quoted 2 lines

I don't know. Does the kernel survive it?

Need to test, but I do not see anything in the kernel that prevent userspace from setting it to any value.

Not all compilers accept anonymous field initialization, e.g. gcc 4.5.1.

Signed-off-by Jan Kiszka <[email protected]>

---
 arch/x86/kvm/pmu.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

arch/x86/kvm/pmu.c +0 -0

index 061a03f..7aad544 100644

arch/x86/kvm/pmu.c +0 -0

 		.config = config,
 	};

Quoted 17 lines · Jan Kiszka

Not all compilers accept anonymous field initialization, e.g. gcc 4.5.1.

Signed-off-by Jan Kiszka <[email protected]>

---
 arch/x86/kvm/pmu.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

arch/x86/kvm/pmu.c +0 -1

index 061a03f..7aad544 100644
@@ -170,10 +170,11 @@ static void reprogram_counter(struct kvm_pmc *pmc, u32 type,
 		.exclude_host = 1,
 		.exclude_user = exclude_user,
 		.exclude_kernel = exclude_kernel,
-		.sample_period = (-pmc->counter) & pmc_bitmask(pmc),

(quoted diff) +1 -0

+		{ .sample_period = ... },

Does that work?

Not all compilers accept anonymous field initialization, e.g. gcc 4.5.1.

KVM needs to know perf capability to decide which PMU it can expose to a guest.

Signed-off-by Gleb Natapov <[email protected]>

---
 arch/x86/include/asm/perf_event.h      |   11 +++++++++++
 arch/x86/kernel/cpu/perf_event.c       |   11 +++++++++++
 arch/x86/kernel/cpu/perf_event.h       |    2 ++
 arch/x86/kernel/cpu/perf_event_intel.c |    3 +++
 4 files changed, 27 insertions(+), 0 deletions(-)

KVM needs to know perf capability to decide which PMU it can expose to a guest.

Signed-off-by Gleb Natapov <[email protected]>

---
 arch/x86/include/asm/perf_event.h      |   11 +++++++++++
 arch/x86/kernel/cpu/perf_event.c       |   11 +++++++++++
 arch/x86/kernel/cpu/perf_event.h       |    2 ++
 arch/x86/kernel/cpu/perf_event_intel.c |    3 +++
 4 files changed, 27 insertions(+), 0 deletions(-)

arch/x86/include/asm/perf_event.h +5 -0

index f61c62f..7d7e57f 100644
@@ -201,7 +201,18 @@ struct perf_guest_switch_msr {
 	u64 host, guest;
 };
 
+struct x86_pmu_capability {
+	int version;
+	int num_counters_gp;
+	int num_counters_fixed;
+	int bit_width_gp;

arch/x86/kernel/cpu/perf_event.c +11 -0

index 6408910..94ac9ca 100644
@@ -1570,3 +1570,14 @@ unsigned long perf_misc_flags(struct pt_regs *regs)
 
 	return misc;
 }
+
+void perf_get_x86_pmu_capability(struct x86_pmu_capability *cap)
+{
+	cap->version = x86_pmu.version;
+	cap->num_counters_gp = x86_pmu.num_counters;
+	cap->num_counters_fixed = x86_pmu.num_counters_fixed;
+	cap->bit_width_gp = cap->bit_width_fixed = x86_pmu.cntval_bits;
+	cap->events_mask = x86_pmu.events_mask;
+	cap->events_mask_len = x86_pmu.events_mask_len;
+}
+EXPORT_SYMBOL_GPL(perf_get_x86_pmu_capability);

arch/x86/kernel/cpu/perf_event.h +2 -0

index b9698d4..e9ed238 100644
@@ -259,6 +259,8 @@ struct x86_pmu {
 	int		num_counters_fixed;
 	int		cntval_bits;
 	u64		cntval_mask;
+	u32		events_mask;
+	int		events_mask_len;
 	int		apic;
 	u64		max_period;
 	struct event_constraint *

arch/x86/kernel/cpu/perf_event_intel.c +3 -0

index e09ca20..64e5f35 100644
@@ -1580,6 +1580,8 @@ __init int intel_pmu_init(void)
 	x86_pmu.num_counters		= eax.split.num_counters;
 	x86_pmu.cntval_bits		= eax.split.bit_width;
 	x86_pmu.cntval_mask		= (1ULL << eax.split.bit_width) - 1;
+	x86_pmu.events_mask		= ebx;
+	x86_pmu.events_mask_len		= eax.split.mask_length;
 
 	/*
 	 * Quirk: v2 perfmon does not report fixed-purpose events, so

@@ -1651,6 +1653,7 @@ __init int intel_pmu_init(void)
 			 * architectural event which is often completely bogus:
 			 */
 			intel_perfmon_event_map[PERF_COUNT_HW_BRANCH_MISSES] = 0x7f89;
+			x86_pmu.events_mask &= ~0x40;
 
 			pr_cont("erratum AAJ80 worked around, ");
 		}

Quoted 30 lines · Gleb Natapov

KVM needs to know perf capability to decide which PMU it can expose to a guest.

Signed-off-by Gleb Natapov <[email protected]>

---
 arch/x86/include/asm/perf_event.h      |   11 +++++++++++
 arch/x86/kernel/cpu/perf_event.c       |   11 +++++++++++
 arch/x86/kernel/cpu/perf_event.h       |    2 ++
 arch/x86/kernel/cpu/perf_event_intel.c |    3 +++
 4 files changed, 27 insertions(+), 0 deletions(-)

arch/x86/include/asm/perf_event.h +10 -0

index f61c62f..7d7e57f 100644
@@ -201,7 +201,18 @@ struct perf_guest_switch_msr {
 	u64 host, guest;
 };
 
+struct x86_pmu_capability {
+	int version;
+	int num_counters_gp;
+	int num_counters_fixed;
+	int bit_width_gp;
+	int bit_width_fixed;
+	unsigned int events_mask;
+	int events_mask_len;
+};
+
 extern struct perf_guest_switch_msr *perf_guest_get_msrs(int *nr);

arch/x86/include/asm/perf_event.h struct perf_guest_switch_msr { · line 218

Quoted 4 lines

arch/x86/include/asm/perf_event.h +1 -0

+extern void perf_get_x86_pmu_capability(struct x86_pmu_capability *cap);
 #else
 static inline perf_guest_switch_msr *perf_guest_get_msrs(int *nr)
 {

What about version of perf_get_x86_pmu_capability for CONFIG_PERF_EVENTS not enabled in host kernel? Next patch for KVM assumes the function is defined.

David

Quoted 51 lines

arch/x86/kernel/cpu/perf_event.c +11 -0

index 6408910..94ac9ca 100644
@@ -1570,3 +1570,14 @@ unsigned long perf_misc_flags(struct pt_regs *regs)
 
 	return misc;
 }
+
+void perf_get_x86_pmu_capability(struct x86_pmu_capability *cap)
+{
+	cap->version = x86_pmu.version;
+	cap->num_counters_gp = x86_pmu.num_counters;
+	cap->num_counters_fixed = x86_pmu.num_counters_fixed;
+	cap->bit_width_gp = cap->bit_width_fixed = x86_pmu.cntval_bits;
+	cap->events_mask = x86_pmu.events_mask;
+	cap->events_mask_len = x86_pmu.events_mask_len;
+}
+EXPORT_SYMBOL_GPL(perf_get_x86_pmu_capability);

arch/x86/kernel/cpu/perf_event.h +2 -0

index b9698d4..e9ed238 100644
@@ -259,6 +259,8 @@ struct x86_pmu {
 	int		num_counters_fixed;
 	int		cntval_bits;
 	u64		cntval_mask;
+	u32		events_mask;
+	int		events_mask_len;
 	int		apic;
 	u64		max_period;
 	struct event_constraint *

arch/x86/kernel/cpu/perf_event_intel.c +3 -0

index e09ca20..64e5f35 100644
@@ -1580,6 +1580,8 @@ __init int intel_pmu_init(void)
 	x86_pmu.num_counters		= eax.split.num_counters;
 	x86_pmu.cntval_bits		= eax.split.bit_width;
 	x86_pmu.cntval_mask		= (1ULL << eax.split.bit_width) - 1;
+	x86_pmu.events_mask		= ebx;
+	x86_pmu.events_mask_len		= eax.split.mask_length;
 
 	/*
 	 * Quirk: v2 perfmon does not report fixed-purpose events, so

@@ -1651,6 +1653,7 @@ __init int intel_pmu_init(void)
 			 * architectural event which is often completely bogus:
 			 */
 			intel_perfmon_event_map[PERF_COUNT_HW_BRANCH_MISSES] = 0x7f89;
+			x86_pmu.events_mask &= ~0x40;
 

arch/x86/kernel/cpu/perf_event_intel.c __init int intel_pmu_init(void) · line 1659

Quoted 2 lines

arch/x86/kernel/cpu/perf_event_intel.c +0 -0

 			pr_cont("erratum AAJ80 worked around, ");
 		}

Quoted 31 lines · David Ahern

Quoted 30 lines · Gleb Natapov

KVM needs to know perf capability to decide which PMU it can expose to a guest.

Signed-off-by Gleb Natapov <[email protected]>

---
 arch/x86/include/asm/perf_event.h      |   11 +++++++++++
 arch/x86/kernel/cpu/perf_event.c       |   11 +++++++++++
 arch/x86/kernel/cpu/perf_event.h       |    2 ++
 arch/x86/kernel/cpu/perf_event_intel.c |    3 +++
 4 files changed, 27 insertions(+), 0 deletions(-)

arch/x86/include/asm/perf_event.h +10 -0

index f61c62f..7d7e57f 100644
@@ -201,7 +201,18 @@ struct perf_guest_switch_msr {
 	u64 host, guest;
 };
 
+struct x86_pmu_capability {
+	int version;
+	int num_counters_gp;
+	int num_counters_fixed;
+	int bit_width_gp;
+	int bit_width_fixed;
+	unsigned int events_mask;
+	int events_mask_len;
+};
+
 extern struct perf_guest_switch_msr *perf_guest_get_msrs(int *nr);

Quoted 9 lines

arch/x86/include/asm/perf_event.h struct perf_guest_switch_msr { · line 218

Quoted 4 lines

arch/x86/include/asm/perf_event.h +1 -0

+extern void perf_get_x86_pmu_capability(struct x86_pmu_capability *cap);
 #else
 static inline perf_guest_switch_msr *perf_guest_get_msrs(int *nr)
 {

What about version of perf_get_x86_pmu_capability for CONFIG_PERF_EVENTS not enabled in host kernel? Next patch for KVM assumes the function is defined.

As far as I understand it is not possible to build x86 without CONFIG_PERF_EVENTS right now. Actually kvm pmu code depends on CONFIG_PERF_EVENTS been enabled. I can easily provide the stub if needed though.

Quoted 41 lines · Gleb Natapov

Quoted 40 lines · David Ahern

Quoted 24 lines · Gleb Natapov

KVM needs to know perf capability to decide which PMU it can expose to a guest.

Signed-off-by Gleb Natapov <[email protected]>

---
 arch/x86/include/asm/perf_event.h      |   11 +++++++++++
 arch/x86/kernel/cpu/perf_event.c       |   11 +++++++++++
 arch/x86/kernel/cpu/perf_event.h       |    2 ++
 arch/x86/kernel/cpu/perf_event_intel.c |    3 +++
 4 files changed, 27 insertions(+), 0 deletions(-)

arch/x86/include/asm/perf_event.h +5 -0

index f61c62f..7d7e57f 100644
@@ -201,7 +201,18 @@ struct perf_guest_switch_msr {
 	u64 host, guest;
 };
 
+struct x86_pmu_capability {
+	int version;
+	int num_counters_gp;
+	int num_counters_fixed;
+	int bit_width_gp;

arch/x86/include/asm/perf_event.h struct perf_guest_switch_msr { · line 218

Quoted 10 lines

arch/x86/include/asm/perf_event.h +6 -0

+	int bit_width_fixed;
+	unsigned int events_mask;
+	int events_mask_len;
+};
+
 extern struct perf_guest_switch_msr *perf_guest_get_msrs(int *nr);
+extern void perf_get_x86_pmu_capability(struct x86_pmu_capability *cap);
 #else
 static inline perf_guest_switch_msr *perf_guest_get_msrs(int *nr)
 {

What about version of perf_get_x86_pmu_capability for CONFIG_PERF_EVENTS not enabled in host kernel? Next patch for KVM assumes the function is defined.

Quoted 4 lines

As far as I understand it is not possible to build x86 without CONFIG_PERF_EVENTS right now. Actually kvm pmu code depends on CONFIG_PERF_EVENTS been enabled. I can easily provide the stub if needed though.

Right. Originally it could be enabled/disabled. Right now it cannot be, but I believe Frederic is working on making it configurable again.

Quoted 41 lines · Gleb Natapov

Quoted 31 lines · David Ahern

Quoted 30 lines · Gleb Natapov

KVM needs to know perf capability to decide which PMU it can expose to a guest.

Signed-off-by Gleb Natapov <[email protected]>

---
 arch/x86/include/asm/perf_event.h      |   11 +++++++++++
 arch/x86/kernel/cpu/perf_event.c       |   11 +++++++++++
 arch/x86/kernel/cpu/perf_event.h       |    2 ++
 arch/x86/kernel/cpu/perf_event_intel.c |    3 +++
 4 files changed, 27 insertions(+), 0 deletions(-)

arch/x86/include/asm/perf_event.h +10 -0

index f61c62f..7d7e57f 100644
@@ -201,7 +201,18 @@ struct perf_guest_switch_msr {
 	u64 host, guest;
 };
 
+struct x86_pmu_capability {
+	int version;
+	int num_counters_gp;
+	int num_counters_fixed;
+	int bit_width_gp;
+	int bit_width_fixed;
+	unsigned int events_mask;
+	int events_mask_len;
+};
+
 extern struct perf_guest_switch_msr *perf_guest_get_msrs(int *nr);

Quoted 9 lines

arch/x86/include/asm/perf_event.h struct perf_guest_switch_msr { · line 218

Quoted 4 lines

arch/x86/include/asm/perf_event.h +1 -0

+extern void perf_get_x86_pmu_capability(struct x86_pmu_capability *cap);
 #else
 static inline perf_guest_switch_msr *perf_guest_get_msrs(int *nr)
 {

What about version of perf_get_x86_pmu_capability for CONFIG_PERF_EVENTS not enabled in host kernel? Next patch for KVM assumes the function is defined.

Quoted 4 lines

As far as I understand it is not possible to build x86 without CONFIG_PERF_EVENTS right now. Actually kvm pmu code depends on CONFIG_PERF_EVENTS been enabled. I can easily provide the stub if needed though.

Right. Originally it could be enabled/disabled. Right now it cannot be, but I believe Frederic is working on making it configurable again.

David

Quoted 3 lines · David Ahern

Right. Originally it could be enabled/disabled. Right now it cannot be, but I believe Frederic is working on making it configurable again.

Quoted 1 line

David

Yep. Will Deacon is working on making the breakpoints able to process pure arch informations (ie: without beeing forced to use the perf attr as a midlayer to define them).

Once we have that I can seperate the breakpoints implementation from perf and make it opt-able.

Hi Frederic,

Quoted 4 lines · Frederic Weisbecker

Quoted 3 lines · David Ahern

Right. Originally it could be enabled/disabled. Right now it cannot be, but I believe Frederic is working on making it configurable again.

Quoted 8 lines

Quoted 1 line

David

Yep. Will Deacon is working on making the breakpoints able to process pure arch informations (ie: without beeing forced to use the perf attr as a midlayer to define them).

Once we have that I can seperate the breakpoints implementation from perf and make it opt-able.

How do you foresee kdb fitting into this? I see that currently [on x86] we cook up perf_event structures with a specific overflow handler set. If we want to move this over to using a completely arch-defined structure, then we're going to end up with an overflow handler field in both perf_event *and* the arch-specific structure, which doesn't feel right to me.

Of course, if the goal is only to separate ptrace (i.e. user debugging) from the perf dependency then we don't need the overflow handler because we'll always just send SIGTRAP to the current task.

Any ideas?

Quoted 20 lines · Will Deacon

Hi Frederic,

Quoted 11 lines · Frederic Weisbecker

Quoted 4 lines · David Ahern

Right. Originally it could be enabled/disabled. Right now it cannot be, but I believe Frederic is working on making it configurable again.

David

Yep. Will Deacon is working on making the breakpoints able to process pure arch informations (ie: without beeing forced to use the perf attr as a midlayer to define them).

Once we have that I can seperate the breakpoints implementation from perf and make it opt-able.

How do you foresee kdb fitting into this? I see that currently [on x86] we cook up perf_event structures with a specific overflow handler set. If we want to move this over to using a completely arch-defined structure, then we're going to end up with an overflow handler field in both perf_event *and* the arch-specific structure, which doesn't feel right to me.

Quoted 5 lines

Of course, if the goal is only to separate ptrace (i.e. user debugging) from the perf dependency then we don't need the overflow handler because we'll always just send SIGTRAP to the current task.

Any ideas?

I don't know if we want to convert x86/kgdb to use pure arch breakpoints. If kgdb one day wants to extend this use to generic code, it may be a good idea to keep the things as is. I don't know, I'm adding Jason in Cc.

Quoted 21 lines · Frederic Weisbecker

Quoted 20 lines · Will Deacon

Hi Frederic,

Quoted 11 lines · Frederic Weisbecker

Quoted 4 lines · David Ahern

Right. Originally it could be enabled/disabled. Right now it cannot be, but I believe Frederic is working on making it configurable again.

David

Yep. Will Deacon is working on making the breakpoints able to process pure arch informations (ie: without beeing forced to use the perf attr as a midlayer to define them).

Once we have that I can seperate the breakpoints implementation from perf and make it opt-able.

How do you foresee kdb fitting into this? I see that currently [on x86] we cook up perf_event structures with a specific overflow handler set. If we want to move this over to using a completely arch-defined structure, then we're going to end up with an overflow handler field in both perf_event *and* the arch-specific structure, which doesn't feel right to me.

Quoted 8 lines

Quoted 5 lines

Of course, if the goal is only to separate ptrace (i.e. user debugging) from the perf dependency then we don't need the overflow handler because we'll always just send SIGTRAP to the current task.

Any ideas?

I don't know if we want to convert x86/kgdb to use pure arch breakpoints. If kgdb one day wants to extend this use to generic code, it may be a good idea to keep the things as is. I don't know, I'm adding Jason in Cc.

I think the important part is to share the allocation code (meaning who owns which break point slots). This is why kgdb/kdb allocates the perf structures. The kgdb code will also directly write data to the slots once it has reserved them it would be good to share this code, but it was not shared because it was not usable early enough in the boot cycle on x86.

Certainly there are others who could consume the same infrastructure such as kprobes.

Jason.

From: Avi Kivity <[email protected]>

Provide a CPUID leaf that describes the emulated PMU.

Signed-off-by Avi Kivity <[email protected]>

Signed-off-by Gleb Natapov <[email protected]>

---
 arch/x86/kvm/x86.c |   23 ++++++++++++++++++++++-
 1 files changed, 22 insertions(+), 1 deletions(-)

arch/x86/kvm/x86.c +6 -0

index 5ea4cb8..56153a9 100644
@@ -2543,6 +2543,28 @@ static void do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function,
 	}
 	case 9:
 		break;
+	case 0xa: { /* Architectural Performance Monitoring */
+		struct x86_pmu_capability cap;
+
+		perf_get_x86_pmu_capability(&cap);
+
+		/*

Quoted 28 lines · Gleb Natapov

From: Avi Kivity <[email protected]>

Provide a CPUID leaf that describes the emulated PMU.

Signed-off-by Avi Kivity <[email protected]>

Signed-off-by Gleb Natapov <[email protected]>

---
 arch/x86/kvm/x86.c |   23 ++++++++++++++++++++++-
 1 files changed, 22 insertions(+), 1 deletions(-)

arch/x86/kvm/x86.c +10 -0

index 5ea4cb8..56153a9 100644
@@ -2543,6 +2543,28 @@ static void do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function,
 	}
 	case 9:
 		break;
+	case 0xa: { /* Architectural Performance Monitoring */
+		struct x86_pmu_capability cap;
+
+		perf_get_x86_pmu_capability(&cap);
+
+		/*
+		 * Only support guest architectural pmu on a host
+		 * with architectural pmu.
+		 */
+		if (!cap.version)

arch/x86/kvm/x86.c static void do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function, · line 2561

Quoted 6 lines

arch/x86/kvm/x86.c +6 -0

+			memset(&cap, 0, sizeof(cap));
+
+		entry->eax = min(cap.version, 2)
+			| (cap.num_counters_gp << 8)
+			| (cap.bit_width_gp << 16)
+			| (cap.events_mask_len << 24);

What if num_counters_gp is larger than our array?

arch/x86/kvm/x86.c static void do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function, · line 2565

Quoted 4 lines

arch/x86/kvm/x86.c +4 -0

+		entry->ebx = cap.events_mask;
+		entry->ecx = 0;
+		entry->edx = cap.num_counters_fixed
+			| (cap.bit_width_fixed << 5);

Ditto.

From: Avi Kivity <[email protected]>

Provide a CPUID leaf that describes the emulated PMU.

Signed-off-by Avi Kivity <[email protected]>

Signed-off-by Gleb Natapov <[email protected]>

---
 arch/x86/kvm/x86.c |   23 ++++++++++++++++++++++-
 1 files changed, 22 insertions(+), 1 deletions(-)

arch/x86/kvm/x86.c +12 -0

index 5ea4cb8..56153a9 100644
@@ -2543,6 +2543,28 @@ static void do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function,
 	}
 	case 9:
 		break;
+	case 0xa: { /* Architectural Performance Monitoring */
+		struct x86_pmu_capability cap;
+
+		perf_get_x86_pmu_capability(&cap);
+
+		/*
+		 * Only support guest architectural pmu on a host
+		 * with architectural pmu.
+		 */
+		if (!cap.version)
+			memset(&cap, 0, sizeof(cap));
+

arch/x86/kvm/x86.c +0 -1

 	/* function 0xb has additional index. */
 	case 0xb: {
 		int i, level_type;

@@ -2637,7 +2659,6 @@ static void do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function,
 	case 3: /* Processor serial number */
 	case 5: /* MONITOR/MWAIT */
 	case 6: /* Thermal management */
-	case 0xA: /* Architectural Performance Monitoring */
 	case 0x80000007: /* Advanced power management */
 	case 0xC0000002:
 	case 0xC0000003:

Quoted 35 lines · Gleb Natapov

From: Avi Kivity <[email protected]>

Provide a CPUID leaf that describes the emulated PMU.

Signed-off-by Avi Kivity <[email protected]>

Signed-off-by Gleb Natapov <[email protected]>

---
 arch/x86/kvm/x86.c |   23 ++++++++++++++++++++++-
 1 files changed, 22 insertions(+), 1 deletions(-)

arch/x86/kvm/x86.c +17 -0

index 5ea4cb8..56153a9 100644
@@ -2543,6 +2543,28 @@ static void do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function,
 	}
 	case 9:
 		break;
+	case 0xa: { /* Architectural Performance Monitoring */
+		struct x86_pmu_capability cap;
+
+		perf_get_x86_pmu_capability(&cap);
+
+		/*
+		 * Only support guest architectural pmu on a host
+		 * with architectural pmu.
+		 */
+		if (!cap.version)
+			memset(&cap, 0, sizeof(cap));
+
+		entry->eax = min(cap.version, 2)
+			| (cap.num_counters_gp << 8)
+			| (cap.bit_width_gp << 16)
+			| (cap.events_mask_len << 24);
+		entry->ebx = cap.events_mask;

arch/x86/kvm/x86.c static void do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function, · line 2567

Quoted 5 lines

arch/x86/kvm/x86.c +5 -0

+		entry->ecx = 0;
+		entry->edx = cap.num_counters_fixed
+			| (cap.bit_width_fixed << 5);
+		break;
+	}

If PERF_EVENTS is disabled in the host kernel will KVM return the right thing for the guest that might have PERF_EVENTS enabled?

David

arch/x86/kvm/x86.c static void do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function, · line 2664

Quoted 11 lines

arch/x86/kvm/x86.c +0 -1

 	/* function 0xb has additional index. */
 	case 0xb: {
 		int i, level_type;

@@ -2637,7 +2659,6 @@ static void do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function,
 	case 3: /* Processor serial number */
 	case 5: /* MONITOR/MWAIT */
 	case 6: /* Thermal management */
-	case 0xA: /* Architectural Performance Monitoring */
 	case 0x80000007: /* Advanced power management */
 	case 0xC0000002:
 	case 0xC0000003:

Quoted 36 lines · David Ahern

Quoted 35 lines · Gleb Natapov

From: Avi Kivity <[email protected]>

Provide a CPUID leaf that describes the emulated PMU.

Signed-off-by Avi Kivity <[email protected]>

Signed-off-by Gleb Natapov <[email protected]>

---
 arch/x86/kvm/x86.c |   23 ++++++++++++++++++++++-
 1 files changed, 22 insertions(+), 1 deletions(-)

arch/x86/kvm/x86.c +17 -0

index 5ea4cb8..56153a9 100644
@@ -2543,6 +2543,28 @@ static void do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function,
 	}
 	case 9:
 		break;
+	case 0xa: { /* Architectural Performance Monitoring */
+		struct x86_pmu_capability cap;
+
+		perf_get_x86_pmu_capability(&cap);
+
+		/*
+		 * Only support guest architectural pmu on a host
+		 * with architectural pmu.
+		 */
+		if (!cap.version)
+			memset(&cap, 0, sizeof(cap));
+
+		entry->eax = min(cap.version, 2)
+			| (cap.num_counters_gp << 8)
+			| (cap.bit_width_gp << 16)
+			| (cap.events_mask_len << 24);
+		entry->ebx = cap.events_mask;

Quoted 9 lines

arch/x86/kvm/x86.c static void do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function, · line 2567

Quoted 5 lines

arch/x86/kvm/x86.c +5 -0

+		entry->ecx = 0;
+		entry->edx = cap.num_counters_fixed
+			| (cap.bit_width_fixed << 5);
+		break;
+	}

If PERF_EVENTS is disabled in the host kernel will KVM return the right thing for the guest that might have PERF_EVENTS enabled?

With correct implementation of perf_get_x86_pmu_capability() it should. PERF_EVENTS disable version should set cap.version to zero, so guest will find that vcpu does not provide architectural PMU.

Quoted 46 lines · Gleb Natapov

Quoted 36 lines · David Ahern

Quoted 35 lines · Gleb Natapov

From: Avi Kivity <[email protected]>

Provide a CPUID leaf that describes the emulated PMU.

Signed-off-by Avi Kivity <[email protected]>

Signed-off-by Gleb Natapov <[email protected]>

---
 arch/x86/kvm/x86.c |   23 ++++++++++++++++++++++-
 1 files changed, 22 insertions(+), 1 deletions(-)

arch/x86/kvm/x86.c +17 -0

index 5ea4cb8..56153a9 100644
@@ -2543,6 +2543,28 @@ static void do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function,
 	}
 	case 9:
 		break;
+	case 0xa: { /* Architectural Performance Monitoring */
+		struct x86_pmu_capability cap;
+
+		perf_get_x86_pmu_capability(&cap);
+
+		/*
+		 * Only support guest architectural pmu on a host
+		 * with architectural pmu.
+		 */
+		if (!cap.version)
+			memset(&cap, 0, sizeof(cap));
+
+		entry->eax = min(cap.version, 2)
+			| (cap.num_counters_gp << 8)
+			| (cap.bit_width_gp << 16)
+			| (cap.events_mask_len << 24);
+		entry->ebx = cap.events_mask;

Quoted 9 lines

arch/x86/kvm/x86.c static void do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function, · line 2567

Quoted 5 lines

arch/x86/kvm/x86.c +5 -0

+		entry->ecx = 0;
+		entry->edx = cap.num_counters_fixed
+			| (cap.bit_width_fixed << 5);
+		break;
+	}

If PERF_EVENTS is disabled in the host kernel will KVM return the right thing for the guest that might have PERF_EVENTS enabled?

Quoted 3 lines

With correct implementation of perf_get_x86_pmu_capability() it should. PERF_EVENTS disable version should set cap.version to zero, so guest will find that vcpu does not provide architectural PMU.

Ok.

I was also thinking about kvm-kmod where newer KVM source is compiled against older kernels - which at one point had PERF_EVENTS as a configurable parameter. In this case it is possible to have perf events disabled host side yet enabled guest side.

Quoted 7 lines

Quoted 6 lines

Quoted 3 lines

If PERF_EVENTS is disabled in the host kernel will KVM return the right thing for the guest that might have PERF_EVENTS enabled?

With correct implementation of perf_get_x86_pmu_capability() it should. PERF_EVENTS disable version should set cap.version to zero, so guest will find that vcpu does not provide architectural PMU.

Quoted 7 lines

Ok.

I was also thinking about kvm-kmod where newer KVM source is compiled against older kernels - which at one point had PERF_EVENTS as a configurable parameter. In this case it is possible to have perf events disabled host side yet enabled guest side.

KVM PMU implementation uses host perf events to talk to HW. Without host perf infrastructure KVM will not be able to provide PMU to a guest. Or are you saying that we should support compiling KVM with !PERF_EVENTS? I'd rather just make KVM select PERF_EVENTS.

Quoted 14 lines · Gleb Natapov

Quoted 7 lines

Quoted 6 lines

Quoted 3 lines

If PERF_EVENTS is disabled in the host kernel will KVM return the right thing for the guest that might have PERF_EVENTS enabled?

With correct implementation of perf_get_x86_pmu_capability() it should. PERF_EVENTS disable version should set cap.version to zero, so guest will find that vcpu does not provide architectural PMU.

Quoted 7 lines

Ok.

I was also thinking about kvm-kmod where newer KVM source is compiled against older kernels - which at one point had PERF_EVENTS as a configurable parameter. In this case it is possible to have perf events disabled host side yet enabled guest side.

Quoted 4 lines

KVM PMU implementation uses host perf events to talk to HW. Without host perf infrastructure KVM will not be able to provide PMU to a guest. Or are you saying that we should support compiling KVM with !PERF_EVENTS? I'd rather just make KVM select PERF_EVENTS.

Strictly speaking KVM does not require PERF_EVENTS; it only requires it if a PMU is to be offered to the guest -- which is a new KVM feature.

Not requiring PERF_EVENTS makes kvm-kmod a bit simpler, a use case where the kvm source deals with a pre-configured kernel.

This patchset exposes an emulated version 2 architectural performance monitoring unit to KVM guests. The PMU is emulated using perf_events, so the host kernel can multiplex host-wide, host-user, and the guest on available resources.

The patches should be applied on top of KVM patches from the patch series "[PATCH v2 0/9] perf support for x86 guest/host-only bits" [1]

If you want to try running perf in a guest you need to apply the patch below to qemu-kvm and use -cpu host on qemu command line. But DO NOT TRY those patches without applying [2][3] to the host kernel first. Don't tell me I didn't warn you!

[1] https://lkml.org/lkml/2011/10/5/153
[2] https://lkml.org/lkml/2011/10/18/390
[3] https://lkml.org/lkml/2011/10/23/163

Avi Kivity (8):
KVM: Expose kvm_lapic_local_deliver()
KVM: Expose a version 2 architectural PMU to a guests
KVM: Add generic RDPMC support
KVM: SVM: Intercept RDPMC
KVM: VMX: Intercept RDPMC
KVM: Expose the architectural performance monitoring CPUID leaf
KVM: x86 emulator: fix RDPMC privilege check
KVM: x86 emulator: implement RDPMC (0F 33)

Gleb Natapov (1):
perf: expose perf capability to other modules.

 arch/x86/include/asm/kvm_emulate.h     |    1 +
 arch/x86/include/asm/kvm_host.h        |   44 +++
 arch/x86/include/asm/perf_event.h      |   11 +
 arch/x86/kernel/cpu/perf_event.c       |   11 +
 arch/x86/kernel/cpu/perf_event.h       |    2 +
 arch/x86/kernel/cpu/perf_event_intel.c |    3 +
 arch/x86/kvm/Makefile                  |    2 +-
 arch/x86/kvm/emulate.c                 |   13 +-
 arch/x86/kvm/lapic.c                   |    2 +-
 arch/x86/kvm/lapic.h                   |    1 +
 arch/x86/kvm/pmu.c                     |  513 ++++++++++++++++++++++++++++++++
 arch/x86/kvm/svm.c                     |   15 +
 arch/x86/kvm/vmx.c                     |   15 +-
 arch/x86/kvm/x86.c                     |   65 ++++-
 include/linux/kvm_host.h               |    1 +
 15 files changed, 686 insertions(+), 13 deletions(-)
 create mode 100644 arch/x86/kvm/pmu.c

target-i386/cpuid.c +14 -5

index f179999..ff2a0ca 100644
@@ -1178,11 +1178,20 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count,
         *edx = 0;
         break;
     case 0xA:
-        /* Architectural Performance Monitoring Leaf */
-        *eax = 0;
-        *ebx = 0;
-        *ecx = 0;
-        *edx = 0;
+	if (kvm_enabled()) {
+            KVMState *s = env->kvm_state;
+
+            *eax = kvm_arch_get_supported_cpuid(s, 0xA, count, R_EAX);
+            *ebx = kvm_arch_get_supported_cpuid(s, 0xA, count, R_EBX);
+            *ecx = kvm_arch_get_supported_cpuid(s, 0xA, count, R_ECX);
+            *edx = kvm_arch_get_supported_cpuid(s, 0xA, count, R_EDX);
+	} else {
+		/* Architectural Performance Monitoring Leaf */
+		*eax = 0; //0x07280402;
+		*ebx = 0;
+		*ecx = 0;
+		*edx = 0; //0x00000503;
+	}
         break;
     case 0xD:
         /* Processor Extended State */

Signature · 6 lines

1.7.5.3

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html