From owner-freebsd-hackers@FreeBSD.ORG Sun May 18 15:47:50 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 C488C106564A for ; Sun, 18 May 2008 15:47:50 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by mx1.freebsd.org (Postfix) with ESMTP id 512458FC32 for ; Sun, 18 May 2008 15:47:49 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by ug-out-1314.google.com with SMTP id q2so330111uge.37 for ; Sun, 18 May 2008 08:47:49 -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=phSUhfO/nd8LhOnFMi7ebyTkrisMeGuvskZ7ezUm93Y=; b=dOUHRvaZdSF/9zw5PI1jk73wSEAlwyuAZV+F7nFU3QGn83s6SumrhL14cy+fpwFV/CZVL1nRJ6u1URJgiLUqNpMYwpDGMwpbbTImMcfjUn5l5QqXrLWI7sTczLjrNwyGwoXH6NvPfD/A4kBwKqGVlJxsmE95x4SrTQEfZaQ4VVQ= 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=xC2i3Bwvs82hHWFfIRN5gjUn8oTtPx5b84PYi5AzsO9IxsSIF4ZcHyOKSaJtqKVs4zNk7T2YBNRaKtQfBfK5glXc57pqvxUeNJzZiDIvvsUEBn2kDigLJIJVtVKHCZe/HuV0/EkjUun78CDvr4dyJQm0LDpYvISJ89pg2dvUBXU= Received: by 10.67.106.19 with SMTP id i19mr2570899ugm.86.1211125668943; Sun, 18 May 2008 08:47:48 -0700 (PDT) Received: from epsilon.local ( [89.214.185.160]) by mx.google.com with ESMTPS id i6sm12731857gve.4.2008.05.18.08.47.46 (version=SSLv3 cipher=RC4-MD5); Sun, 18 May 2008 08:47:48 -0700 (PDT) Message-ID: <48304F9D.9030406@FreeBSD.org> Date: Sun, 18 May 2008 16:47:41 +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> In-Reply-To: <20080517175312.GM18958@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 15:47:50 -0000 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. Regards, -- Rui Paulo