From mboxrd@z Thu Jan  1 00:00:00 1970
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: perf uncore & lkvm woes
Date: Tue, 21 Aug 2012 12:35:25 +0200
Message-ID: <1345545325.23018.98.camel@twins>
References: <CAOJsxLHg2idOMTcy_GsSwm8RBt9o1LFMA7KUSCh=Zs=RnvUQXA@mail.gmail.com>
	    <1345101585.31459.112.camel@twins> <502CA368.8050404@linux.intel.com>
	    <CAOJsxLFyvvzXgHkuEC=sy8X-Mq8Mp0oc8vDK-uLZeQGVRjvzAA@mail.gmail.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>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Cc: "Yan, Zheng" <zheng.z.yan@linux.intel.com>,
	Pekka Enberg <penberg@kernel.org>,
	Sasha Levin <levinsasha928@gmail.com>,
	Asias He <asias.hejun@gmail.com>,
	Cyrill Gorcunov <gorcunov@gmail.com>,
	Ingo Molnar <mingo@elte.hu>, KVM General <kvm@vger.kernel.org>,
	Gleb Natapov <gleb@redhat.com>
To: Avi Kivity <avi@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from merlin.infradead.org ([205.233.59.134]:38561 "EHLO
	merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1756413Ab2HUKfv convert rfc822-to-8bit (ORCPT
	<rfc822;kvm@vger.kernel.org>); Tue, 21 Aug 2012 06:35:51 -0400
In-Reply-To: <50334827.6010906@redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

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.

> 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.

Anyway, for now I've taken Zheng Yan's cpu_has_hypervisor patch, we can
always revisit this.