rdmsr from userspace

[Rui Paulo]

Mike Meyer wrote:
> 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

Yes, sure, but who do you select the MSR you want to read or write?

dev.cpu.N.<insert MSR number in hexadecimal here> ?

I'll have to think about whether or not I like this interface.

Regards,
-- 
Rui Paulo