rdmsr from userspace

[Suleiman Souhlal]

On May 18, 2008, at 11:15 AM, Kostik Belousov wrote:
> On Sun, May 18, 2008 at 04:47:41PM +0100, Rui Paulo wrote:
>> Kostik Belousov wrote:
>>> On Sat, May 17, 2008 at 06:26:01PM +0100, Rui Paulo wrote:
>>>> Andriy Gapon wrote:
>>>>> on 17/05/2008 18:37 Rui Paulo said the following:
>>>>>> Andriy Gapon 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?
>>>>>>>
>>>>>> While I think this (devcpu) is good for testing and  
>>>>>> development, I
>>>>>> prefer having a device driver to handle that specific MSR than a
>>>>>> generic /dev/cpuN where you can issue MSRs.
>>>>>> Both for security and reliability reasons.
>>>>> What about /dev/pci, /dev/io? Aren't they a precedent?
>>>> They are, but, IMHO, we should no longer continue to create this  
>>>> type of
>>>> interfaces.
>>>
>>> Why ? Are developers some kind of the second-class users ?
>>>
>>> I would have no opinion on providing /dev/cpu by the loadable  
>>> module, not
>>> compiled into GENERIC. But the interface itself is useful at  
>>> least for
>>> three things:
>>> - CPU identification (see x86info or whatever it is called);
>>> - CPU tweaking for bugs workaround without patching the kernel;
>>> - updating the CPU microcode.
>>> None of these is limited to the developers only.
>>
>> Input validation is my main concern here. Regarding to your two last
>> points, I would prefer to have a microcode driver than a microcode
>> userland utility that relies on devcpu.
> Did you looked at the code ? It does exactly what you described.
>
> Driver has four basic operations:
> read/write msr
> perform cpu id work

For what it's worth, CPUID is not a privileged instruction, so this  
doesn't need to be done in the kernel (as long as you have a way to  
pin a userland thread to a cpu, which I believe we have, now).

I would personally would *really* to see stas's driver committed as  
well, as it's really useful.

(I had a similar driver (but only for MSRs) that I was about to  
commit to 7.0 a few months ago, but re@ asked that I add a manpage,  
and I never got around to doing it:

http://people.freebsd.org/~ssouhlal/testing/msr-20070707.diff

It's slightly different from devcpu in that it works with lseek +  
read/write instead of ioctl).

-- Suleiman