Re: [PATCH] x86, msr: Allow read access to /dev/cpu/X/msr

[Prarit Bhargava <prarit@redhat.com>]

The MSR exposure seems to be okay with the following statements:

- complete read of /dev/cpu/X/msr is bad, whitelist instead
- needs to be dependent on either CPU version or reading MSRs for support.
  IIRC the Intel documentaton on the MSRs indicated that there are ways to
  check to see if a particular MSR is supported by a processor.  That doesn't
  seem difficult to do IMO.

Here are the options that have been discussed in this thread, as well as a
third that I'm proposing:

1.  Andy's PMU driver suggestion (eventually exposed via sysfs)
2.  Standalone driver (LLNL) which exposes values in sysfs (one value per
sysfs file)
3.  Make /dev/cpu/X/msr readable for those addresses in the whitelist.
ie) Allow read access to address for IA32_MPERF, etc.

I find exposing MSRs via sysfs difficult to maintain as we move forward.
I suppose we could name them according to their MSR names in the Intel
documentation, however from a userspace point of view I still find it
cumbersome to code that way.  Doing this in the existing /dev/ space has the
benefit that we wouldn't have to change any userspace code. For
those users who did (in some crazy situation) want full read access, they can
still do 'setcap' on that particular executable.

Using Henrique's list of packages that use /dev/cpu/X/msr,

* cpufrequtils
* flashrom
* i7z
* intel-gpu-tools
* inteltool
* mcelog
* msrtool, msr-tools
* PAPI (can use msr_safe)
* powertop
* qemu
* slurm-llnl  (maybe this can also use msr_safe?)
* stressapptest
* turbostat
* wmlongrun, longrun
* x86info
* xserver-xorg-video-geode

it seems like visiting changes on each of these packages (and the other
packages that I'm sure I've missed) will be moderately difficult.

Thoughts?

P.