rdmsr from userspace

[Mike Meyer]

On Sun, 18 May 2008 16:50:28 +0100
Rui Paulo <rpaulo at FreeBSD.org> wrote:

> Mike Meyer wrote:
> > On Sat, 17 May 2008 11:13:52 +0300
> > Andriy Gapon <avg at icyb.net.ua> wrote:
> >> It seems that rdmsr instruction can be executed only at the highest 
> >> privilege level and thus is not permitted from userland. Maybe we should 
> >> provide something like Linux /dev/cpu/msr?
> >> I don't like interface of that device, I think that ioctl approach would 
> >> be preferable in this case.
> >> Something like create /dev/cpuN and allow some ioctls on it: 
> >> ioctl(cpu_fd, CPU_RDMSR, arg).
> >> What do you think?
> > 
> > Ok, this points directly at a question I've been wondering about, but
> > haven't been able to find an answer in the google.
> > 
> > I've been mucking about with general access to sysctl's (a sysctl
> > plugin for gkrellm, and a python module for accessing sysctls), and
> > with that hammer in my hand, the nail for this problem is obviously a
> > dev.cpu.#.msr sysctl.
> 
> How can you request a rdmsr within the sysctl tree? I don't think sysctl 
> is appropriate here either.

Reading (or writing) a sysctl mib can trigger a sysctl handler, which
can do pretty much anything. In particular, there are already examples
in the kernel where sysctl handlers use devices that don't have /dev
entries to get & set their values. Look through kern/kern_cpu.c and
i386/cpufreq/p4tcc.c to see the two ends of that kind of
connection. In fact, the cpu frequency sysctls would seem to be an
excellent model for something like the msr.

ioctl, open+read/write, sysctl - they're all just interfaces to kernel
handlers.

     <mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org