From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755445AbbLDI22 (ORCPT ); Fri, 4 Dec 2015 03:28:28 -0500 Received: from mail-wm0-f42.google.com ([74.125.82.42]:37093 "EHLO mail-wm0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752542AbbLDI21 (ORCPT ); Fri, 4 Dec 2015 03:28:27 -0500 Date: Fri, 4 Dec 2015 09:28:23 +0100 From: Ingo Molnar To: Peter Zijlstra Cc: Borislav Petkov , Amy Wiles , "Rafael J. Wysocki" , LKML , Arnaldo Carvalho de Melo , "H. Peter Anvin" , Ingo Molnar , Jacob Pan , Thomas Gleixner Subject: Re: [PATCH] x86/rapl: Do not load in a guest Message-ID: <20151204082823.GA31591@gmail.com> References: <1449167222-17562-1-git-send-email-bp@alien8.de> <20151204074206.GB24827@gmail.com> <20151204082256.GC17308@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151204082256.GC17308@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Peter Zijlstra wrote: > On Fri, Dec 04, 2015 at 08:42:06AM +0100, Ingo Molnar wrote: > > > > * Borislav Petkov wrote: > > > > > From: Borislav Petkov > > > > > > qemu/kvm doesn't support RAPL and RAPL doesn't have a CPUID feature bit > > > so check whether we're in a guest instead. > > > > So when a hypervisor starts supporting RAPL we'll disable the driver erroneously? > > > > Isn't there any better method to detect RAPL support? > > > > So in particular in drivers/powercap/intel_rapl.c there's an enumerated list of > > CPU models, which is used via a x86_match_cpu() call. That's still not ideal (it > > does not work on hypervisors for example), but even better would be to detect RAPL > > support in some other fashion, that does not rely on us statically enumerating CPU > > models that support it. > > RAPL isn't enumerated, the best we could do is attempt to write to one > of the writable MSRs and see if that 'works'. Hm, bad - writing to MSRs like that is generally dangerous. So we should at least provide a central 'is RAPL available' call instead of spreading multiple X86_FEATURE_HYPERVISOR checks. Thanks, Ingo