From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755958AbbLDKlL (ORCPT ); Fri, 4 Dec 2015 05:41:11 -0500 Received: from mx1.redhat.com ([209.132.183.28]:60332 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755405AbbLDKlJ (ORCPT ); Fri, 4 Dec 2015 05:41:09 -0500 Subject: Re: [PATCH] x86/rapl: Do not load in a guest To: Borislav Petkov , Ingo Molnar , "H. Peter Anvin" 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> Cc: Peter Zijlstra , Amy Wiles , "Rafael J. Wysocki" , LKML , Arnaldo Carvalho de Melo , Ingo Molnar , Jacob Pan , Thomas Gleixner From: Paolo Bonzini Message-ID: <56616DBF.8040900@redhat.com> Date: Fri, 4 Dec 2015 11:41:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151204101954.GA21177@pd.tnic> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/12/2015 11:19, Borislav Petkov wrote: > + 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. Yup, this is an issue with RAPL. > 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. 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. Paolo > 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? >