From owner-freebsd-hackers@FreeBSD.ORG Sun May 18 20:05:56 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45F59106564A; Sun, 18 May 2008 20:05:56 +0000 (UTC) (envelope-from ssouhlal@FreeBSD.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 315F98FC1F; Sun, 18 May 2008 20:05:56 +0000 (UTC) (envelope-from ssouhlal@FreeBSD.org) Received: from [192.168.0.100] (c-76-21-32-5.hsd1.ca.comcast.net [76.21.32.5]) by elvis.mu.org (Postfix) with ESMTP id 91BD21A4D7C; Sun, 18 May 2008 12:47:11 -0700 (PDT) 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> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <821D2BD4-4C79-49B6-ADD9-2C5EA16B852A@FreeBSD.org> Content-Transfer-Encoding: 7bit From: Suleiman Souhlal Date: Sun, 18 May 2008 12:47:07 -0700 To: Kostik Belousov X-Mailer: Apple Mail (2.753) Cc: freebsd-hackers@freebsd.org, Rui Paulo , Andriy Gapon Subject: Re: rdmsr from userspace X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2008 20:05:56 -0000 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