From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: [PATCH 7/9] KVM: Expose the architectural performance monitoring CPUID leaf Date: Tue, 1 Nov 2011 18:40:52 +0200 Message-ID: <20111101164052.GC16539@redhat.com> References: <1319993624-20247-1-git-send-email-gleb@redhat.com> <1319993624-20247-8-git-send-email-gleb@redhat.com> <4EB01507.1020607@gmail.com> <20111101161815.GB16539@redhat.com> <4EB01D49.6010309@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm@vger.kernel.org, avi@redhat.com, mtosatti@redhat.com, linux-kernel@redhat.com, mingo@elte.hu, a.p.zijlstra@chello.nl, acme@ghostprotocols.net To: David Ahern Return-path: Received: from mx1.redhat.com ([209.132.183.28]:25834 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755679Ab1KAQ4A (ORCPT ); Tue, 1 Nov 2011 12:56:00 -0400 Content-Disposition: inline In-Reply-To: <4EB01D49.6010309@gmail.com> Sender: kvm-owner@vger.kernel.org List-ID: On Tue, Nov 01, 2011 at 10:24:41AM -0600, David Ahern wrote: > > > On 11/01/2011 10:18 AM, Gleb Natapov wrote: > > On Tue, Nov 01, 2011 at 09:49:27AM -0600, David Ahern wrote: > >> On 10/30/2011 10:53 AM, Gleb Natapov wrote: > >>> From: Avi Kivity > >>> > >>> Provide a CPUID leaf that describes the emulated PMU. > >>> > >>> Signed-off-by: Avi Kivity > >>> Signed-off-by: Gleb Natapov > >>> --- > >>> arch/x86/kvm/x86.c | 23 ++++++++++++++++++++++- > >>> 1 files changed, 22 insertions(+), 1 deletions(-) > >>> > >>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > >>> index 5ea4cb8..56153a9 100644 > >>> --- a/arch/x86/kvm/x86.c > >>> +++ b/arch/x86/kvm/x86.c > >>> @@ -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; > >>> + 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. > > 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. -- Gleb.