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 update microcode. The later is done as a whole operation, with the microcode blob supplied by the userspace.
pgpRrH9sEDzUO.pgp
Description: PGP signature
