From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: perf uncore & lkvm woes Date: Wed, 22 Aug 2012 11:53:20 +0300 Message-ID: <50349E00.5070502@redhat.com> References: <1345101585.31459.112.camel@twins> <502CA368.8050404@linux.intel.com> <502CB1F6.4010204@redhat.com> <502CD444.5020807@redhat.com> <1345115846.29668.16.camel@twins> <502CD891.5030102@redhat.com> <502DA115.1090907@linux.intel.com> <1345186574.29668.56.camel@twins> <5030B82C.5000106@redhat.com> <1345533096.23018.83.camel@twins> <50334827.6010906@redhat.com> <1345545325.23018.98.camel@twins> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Yan, Zheng" , Pekka Enberg , Sasha Levin , Asias He , Cyrill Gorcunov , Ingo Molnar , KVM General , Gleb Natapov To: Peter Zijlstra Return-path: Received: from mx1.redhat.com ([209.132.183.28]:32578 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753275Ab2HVIxp (ORCPT ); Wed, 22 Aug 2012 04:53:45 -0400 In-Reply-To: <1345545325.23018.98.camel@twins> Sender: kvm-owner@vger.kernel.org List-ID: On 08/21/2012 01:35 PM, Peter Zijlstra wrote: > On Tue, 2012-08-21 at 11:34 +0300, Avi Kivity wrote: >> On 08/21/2012 10:11 AM, Peter Zijlstra wrote: >> > On Sun, 2012-08-19 at 12:55 +0300, Avi Kivity wrote: >> >> > I think Avi prefers the method where KVM 'fakes' the MSRs and we have to >> >> > detect if the MSRs actually work or not. >> >> >> >> s/we have/we don't have/. >> > >> > So for the 'normal' PMU we actually do check to see if the MSRs are >> > being faked and bail if they are. >> >> That was because earlier versions of kvm did not virtualize the pmu. >> >> The approaches are not mutually exclusive. We can check in the guest, >> and fake it in the host. > > This is actually what I proposed. Ah, I misunderstood you. > >> The problem with faking it in the host is if someone actually relies on >> the pmu for something, not just instrumentation. We do that for the >> watchdog, but I don't see it happening with the uncore pmu. > > Agreed, although from a usability POV its nicer to refuse the > device/events than to pretend it works while it doesn't. If/when we virtualize this pmu we can expose a flag that says "the pmu actually works even though this is a virtual machine". > Anyway, for now I've taken Zheng Yan's cpu_has_hypervisor patch, we can > always revisit this. Yup. -- error compiling committee.c: too many arguments to function