Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752621AbbGAQjA (ORCPT ); Wed, 1 Jul 2015 12:39:00 -0400 Received: from mga02.intel.com ([134.134.136.20]:14019 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751316AbbGAQix (ORCPT ); Wed, 1 Jul 2015 12:38:53 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,387,1432623600"; d="scan'208";a="517300334" From: "Brown, Len" To: Andy Lutomirski , Ingo Molnar , Prarit Bhargava CC: "linux-kernel@vger.kernel.org" , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , X86 ML , "Chandramouli, Dasaratharaman" , Peter Zijlstra , Borislav Petkov , Andy Lutomirski , Denys Vlasenko , Brian Gerst , Arnaldo Carvalho de Melo Subject: RE: [PATCH] x86, msr: Allow read access to /dev/cpu/X/msr Thread-Topic: [PATCH] x86, msr: Allow read access to /dev/cpu/X/msr Thread-Index: AQHQsDkT3V+G1gkvsU6/VYNX/QP8tZ3AfOiAgAABhYCAAHjpgIAF2J2w Date: Wed, 1 Jul 2015 16:38:37 +0000 Message-ID: <1A7043D5F58CCB44A599DFD55ED4C948468A477B@fmsmsx115.amr.corp.intel.com> References: <1435341131-3279-1-git-send-email-prarit@redhat.com> <20150627083354.GA12834@gmail.com> <20150627083921.GA13074@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.200.106] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id t61Gd3nr018511 Content-Length: 1942 Lines: 43 > This driver only knows how to handle counters, though. I'm not sure > whether all of the MSRs that turbostat needs are counters. turbostat --debug dumps a lot of configuration MSRs that are not counters. "--debug" is not an obscure option, it is the only way that the turbostat is used by advanced users, since it shows not just how fast a system is running, but explains why. turbostat -M or -C 'address' will dump an arbitrary MSR at offset 'address' in hex or counter format. This allows somebody to use yesterday's turbostat application to dump an MSR that didn't exist when the application was written. (and since the MSR driver doesn't have specific MSR addresses hard-coded into it, that is permitted) > I knew that turbostat only did MSR reads FYI, There have been proposals for turbostat to do MSR writes, and I've resisted them because I like that multiple turbostats can run at different intervals and even different users, and not interfere with each other. One of the proposals was due to a short counter that tends to over-flow. That, I think would be better done in a central place in the kernel, though it shouldn't poll unless it is actually being used. The other is to be able to fix configuration bits that are recognized to be incorrect or non-optimal. BTW. I've had a discussion w/ LLNL about their needs, both for security and performance. For security, as concluded by this thread, a white list is the only way to go. I'm thinking a bit-vector of allowed MSR offsets... For performance, they absolutely can not afford a system call for every single MSR access. Here an ioctl to have the msr driver perform a vector of accesses in a single system call seems the way to go. I can prototype both of these using turbostat as the customer. -Len ????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?