[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AEA6FC45760E2A42897809E8E402EA1E0F2C7639@PRDEXMBX-02.the-lab.llnl.gov>
Date: Sun, 28 Feb 2016 18:54:47 +0000
From: "Mcfadden, Marty Jay" <mcfadden8@...l.gov>
To: Ingo Molnar <mingo@...nel.org>
CC: "ak@...ux.intel.com" <ak@...ux.intel.com>,
"andriy.shevchenko@...ux.intel.com"
<andriy.shevchenko@...ux.intel.com>, "bp@...en8.de" <bp@...en8.de>,
"bp@...e.de" <bp@...e.de>, "brgerst@...il.com" <brgerst@...il.com>,
"dan.j.williams@...el.com" <dan.j.williams@...el.com>,
"dyoung@...hat.com" <dyoung@...hat.com>,
"hpa@...or.com" <hpa@...or.com>,
"linux@...izon.com" <linux@...izon.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"luto@...nel.org" <luto@...nel.org>,
"mingo@...hat.com" <mingo@...hat.com>,
"pavel@....cz" <pavel@....cz>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
"x86@...nel.org" <x86@...nel.org>,
"yu.c.chen@...el.com" <yu.c.chen@...el.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Arnaldo Carvalho de Melo <acme@...radead.org>,
"Jiri Olsa" <jolsa@...hat.com>
Subject: RE: [PATCH 0/4] MSR: MSR: MSR Whitelist and Batch Introduction
> * Ingo Molnar [mailto:mingo.kernel.org@...il.com] wrote:
>
> No, we really don't want to touch the old MSR code - it's a very opaque API with
> various deep limitations.
>
> What I'd like to see instead is to use a modern system monitoring interface - and
> in fact that already happened in the last kernel release, we added the perf MSR
> access methods via:
>
> commit b7b7c7821d932ba18ef6c8eafc8536066b4c2ef4
> Author: Andy Lutomirski <luto@...nel.org>
> Date: Mon Jul 20 11:49:06 2015 -0400
>
> perf/x86: Add an MSR PMU driver
>
> This patch adds an MSR PMU to support free running MSR counters. Such
> as time and freq related counters includes TSC, IA32_APERF, IA32_MPERF
> and IA32_PPERF, but also SMI_COUNT.
>
> The events are exposed in sysfs for use by perf stat and other tools.
> The files are under /sys/devices/msr/events/
>
Thank you Ingo,
Our use case for MSR access is different. In addition to being able to
access free running MSR counters, we also need to monitor (read) and
adjust (write) MSRs that may modify running system configurations.
One example set of MSRs that we need to be able to access are
associated with RAPL.
Further, system administrators need the ability to grant/deny MSR read
and/or write access at bit-level granularity for some of the MSRs in order
to maintain imposed security policies for their respective deployments.
The proposed whitelist approach allows for system administrators to set
a bit mask for the bits in each register where access is to be granted.
The cgroup management does not provide this level of granularity.
Instead it allows for an administrator to give a mode of access to either
all MSRs or none of them.
Thanks again,
Marty
Powered by blists - more mailing lists