From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755283AbbLDRrp (ORCPT ); Fri, 4 Dec 2015 12:47:45 -0500 Received: from mga14.intel.com ([192.55.52.115]:11086 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755091AbbLDRrh (ORCPT ); Fri, 4 Dec 2015 12:47:37 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,380,1444719600"; d="scan'208";a="864811523" Date: Fri, 4 Dec 2015 09:46:42 -0800 From: Jacob Pan To: Ingo Molnar Cc: Borislav Petkov , Paolo Bonzini , "H. Peter Anvin" , Peter Zijlstra , Amy Wiles , "Rafael J. Wysocki" , LKML , Arnaldo Carvalho de Melo , Ingo Molnar , Thomas Gleixner , jacob.jun.pan@linux.intel.com Subject: Re: [PATCH] x86/rapl: Do not load in a guest Message-ID: <20151204094642.4c5e63e0@icelake> In-Reply-To: <20151204115335.GB15308@gmail.com> References: <1449167222-17562-1-git-send-email-bp@alien8.de> <20151204074206.GB24827@gmail.com> <20151204082256.GC17308@twins.programming.kicks-ass.net> <20151204082823.GA31591@gmail.com> <20151204101954.GA21177@pd.tnic> <56616DBF.8040900@redhat.com> <20151204105617.GB21177@pd.tnic> <20151204115335.GB15308@gmail.com> Organization: OTC X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.23; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 4 Dec 2015 12:53:35 +0100 Ingo Molnar wrote: > > * Borislav Petkov wrote: > > > On Fri, Dec 04, 2015 at 11:41:03AM +0100, Paolo Bonzini wrote: > > > No, please don't. Why do you need a wrmsr instead of a rdmsr? If > > > there's no RAPL domains, the device doesn't load. On hypervisors, > > > reading random MSRs is generally safe. > > > > Well, we could not do anything, sure, that's an option too. It would > > only be the annoying error message. Which is > > > > pr_err("no valid rapl domains found in package %d\n", > > rp->id); > > > > I guess we can tone that down as apparently it is not an error to > > not have valid rapl domains anymore. Maybe kill it altogether: > > rapl_detect_topology() will propagate the error and the driver won't > > load... > Since RAPL is not architectural, consistency of hw support needs lots of improvement at the least. This error message is valid in other than VM. Domain detection error already propagated. > So given than nothing really tells us in a clear way whether RAPL is > supported or not on that kernel, it might be better to just > centralize the 'detect RAPL' function, and print "x86/rapl: Feature > detected" on bootup. That function can also install a synthetic CPUID > bit, which all other code could use in a clean fashion. > > Since it will be an __init function, there's not much of an overhead > argument against it. > This is good for the first level RAPL detection. The only way is to base detection on known CPU models. But I still think hypervisor check is sufficient. I don't there will ever be a use case for VM to control platform level power. A disaster for sure. > This way it becomes part of the CPUID infrastructure - and eventually > it might even grow a real CPUID bit in future CPU models. > > and we'll have a lot less RAPL detection muck all around. Win-win. > True, RAPL is not architectural today but it is supported by all Intel CPUs since SNB. > Thanks, > > Ingo