From owner-freebsd-hackers@FreeBSD.ORG Sun May 18 18:33:04 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 A72301065690 for ; Sun, 18 May 2008 18:33:04 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by mx1.freebsd.org (Postfix) with ESMTP id A22F98FC0C for ; Sun, 18 May 2008 18:33:03 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by ug-out-1314.google.com with SMTP id q2so382044uge.37 for ; Sun, 18 May 2008 11:33:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; bh=xgXno9Z/7p450r+6czwbiLGk2OJUE4mHqrIVLzltw8g=; b=P27yPXqe2inm4K6IAmfgtxVMYPoeOVjd5YdWJNcoywQdFA5GSDG/iRw1wOX0yNfEFPemgodBN6zpD8lksLT8R+ufLp3S9VMpDaP1sOWIRsHS+vKqvbFoGtD37Ch9dV52UjtpotjFiaihP/fx+LnzaxXmpfD6a0XamFR/nZxWM7Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=BI2/jIpyHbNq1SfEJ2DztoUj0crIpQu46/FLxVFd9Kxo4vg9DoDO3yWsaOJDxM4Ha6TUMlq3nDXNcf7duRF91R/8Qqx9mQ/+rokxeOg2Wu1QMQezMnyZXGpJe/dD+mDjiYRkyqkjflogORxWbZhajTocVRjSQgWGttDVGjuec2U= Received: by 10.67.116.2 with SMTP id t2mr2765639ugm.52.1211135582207; Sun, 18 May 2008 11:33:02 -0700 (PDT) Received: from epsilon.local ( [89.214.185.160]) by mx.google.com with ESMTPS id m38sm1056830ugd.44.2008.05.18.11.32.59 (version=SSLv3 cipher=RC4-MD5); Sun, 18 May 2008 11:33:01 -0700 (PDT) Message-ID: <48307658.2080502@FreeBSD.org> Date: Sun, 18 May 2008 19:32:56 +0100 From: Rui Paulo User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Kostik Belousov 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> In-Reply-To: <20080518181549.GZ18958@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: Rui Paulo Cc: freebsd-hackers@freebsd.org, 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 18:33:04 -0000 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