Date: Sun, 18 May 2008 19:32:56 +0100 From: Rui Paulo <rpaulo@FreeBSD.org> To: Kostik Belousov <kostikbel@gmail.com> Cc: freebsd-hackers@freebsd.org, Andriy Gapon <avg@icyb.net.ua> Subject: Re: rdmsr from userspace Message-ID: <48307658.2080502@FreeBSD.org> In-Reply-To: <20080518181549.GZ18958@deviant.kiev.zoral.com.ua> References: <482E93C0.4070802@icyb.net.ua> <482EFBA0.30107@FreeBSD.org> <482F1191.70709@icyb.net.ua> <482F1529.5080409@FreeBSD.org> <20080517175312.GM18958@deviant.kiev.zoral.com.ua> <48304F9D.9030406@FreeBSD.org> <20080518181549.GZ18958@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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 > update microcode. > > The later is done as a whole operation, with the microcode blob supplied > by the userspace. Yes, but I still don't like having everything mixed up in one driver. At the very least, I would like us to have two drivers. One for the microcode update and the other driver for the rest. I would like to see a microcode update utility (driver + something to parse Intel's file aka devcpu-data) in the base system, but not "the rest", though. Regards, -- Rui Paulo
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48307658.2080502>