From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756108AbbLDKUl (ORCPT ); Fri, 4 Dec 2015 05:20:41 -0500 Received: from mail.skyhub.de ([78.46.96.112]:42379 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756054AbbLDKUB (ORCPT ); Fri, 4 Dec 2015 05:20:01 -0500 Date: Fri, 4 Dec 2015 11:19:54 +0100 From: Borislav Petkov To: Ingo Molnar , "H. Peter Anvin" Cc: Peter Zijlstra , Amy Wiles , "Rafael J. Wysocki" , LKML , Arnaldo Carvalho de Melo , Ingo Molnar , Jacob Pan , Thomas Gleixner , Paolo Bonzini Subject: Re: [PATCH] x86/rapl: Do not load in a guest Message-ID: <20151204101954.GA21177@pd.tnic> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20151204082823.GA31591@gmail.com> 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 + Paolo. On Fri, Dec 04, 2015 at 09:28:23AM +0100, Ingo Molnar wrote: > > > 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. Well, looks like someone dropped the ball at the CPUID registrar. Other features have more than one CPUID bit allocated to them, this one doesn't have a single one. And since there's no CPUID bit, I don't see any other way to detect the RAPL presence. Poking at MSRs is a bad idea. I wonder if we could go and allocate a bit in the kvm-emulated CPUID leafs which says whether RAPL is supported or not. Then we can go and check for that leaf on baremetal - if it is not there, we do the vendor + fms check and if it is there, we know we're in a guest and whether the guest supports it or not. Dunno. On the one hand, it looks like a bit too much to me. On the other, it could be useful for other future feature checks where we want baremetal and kvm to be synchronized wrt features and a single method to be used by the kernel for checking features presence works both on baremetal and virt. Just a thought, anyway... hpa, thoughts? -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.