From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758224AbcK3SSB (ORCPT ); Wed, 30 Nov 2016 13:18:01 -0500 Received: from merlin.infradead.org ([205.233.59.134]:45772 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754243AbcK3SRr (ORCPT ); Wed, 30 Nov 2016 13:17:47 -0500 Date: Wed, 30 Nov 2016 19:17:42 +0100 From: Peter Zijlstra To: Taylor Andrews Cc: Andi Kleen , "linux-perf-users@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Alok Kataria , Ingo Molnar Subject: Re: Question about Perf's handling of in-use performance counters Message-ID: <20161130181742.GS3092@twins.programming.kicks-ass.net> References: <87r371k6gj.fsf@tassilo.jf.intel.com> <20161027210012.GN3102@twins.programming.kicks-ass.net> <20161028135325.GB26852@two.firstfloor.org> <20161028140354.GH3142@twins.programming.kicks-ass.net> <20161028154012.GC26852@two.firstfloor.org> <20161028162844.GJ3142@twins.programming.kicks-ass.net> <20161028163305.GD26852@two.firstfloor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 30, 2016 at 03:44:57PM +0000, Taylor Andrews wrote: > > No, it was about the (mis)guide-line having fundamental races and the > > belief that the BIOS has no business what so ever using these resources > > to begin with. > > Can you please describe what fundamental races you are talking about? The protocol does a RDMSR to see if the counter is configured or not, if not, then it can proceed with the WRMSR. Since these are two separate instructions, there is nothing that prevents a vCPU preemption or SMI to come in between and invalidate the state we just read. > Why do you believe the BIOS should never be using performance counters? The BIOS's job is to boot the system and then stay the heck away. Runtime services are not what its for. Now I know some hardware vendors like to (ab)use SMM for fail^Wfeature-add, and that is exactly the kind of crap we don't need. BIOS monkeys always get it wrong and BIOS code is _never_ updated, so then you're stuck with wreckage. > Even if you discount the BIOS use case (despite Intel considering it > legitimate), we still have the scenario of a Hypervisor exposing some > virtual performance counters as in-use and unavailable. What was the > rationale that the PMU cooperative sharing guidelines outlined by > Intel should be intentionally ignored, and that perf should attempt to > take over all generic performance counters, regardless of if they are > marked in-use? See the thread here: https://lkml.org/lkml/2011/3/24/608