From owner-cvs-src@FreeBSD.ORG Fri Aug 8 21:02:22 2008 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9E7B106566B for ; Fri, 8 Aug 2008 21:02:21 +0000 (UTC) (envelope-from peter@wemm.org) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by mx1.freebsd.org (Postfix) with ESMTP id A96B48FC1C for ; Fri, 8 Aug 2008 21:02:21 +0000 (UTC) (envelope-from peter@wemm.org) Received: by yx-out-2324.google.com with SMTP id 8so299397yxb.13 for ; Fri, 08 Aug 2008 14:02:20 -0700 (PDT) Received: by 10.142.11.2 with SMTP id 2mr1115834wfk.1.1218229339316; Fri, 08 Aug 2008 14:02:19 -0700 (PDT) Received: by 10.142.76.14 with HTTP; Fri, 8 Aug 2008 14:02:19 -0700 (PDT) Message-ID: Date: Fri, 8 Aug 2008 14:02:19 -0700 From: "Peter Wemm" To: "John Baldwin" In-Reply-To: <200808081459.54735.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200808081631.m78GVG9i088754@repoman.freebsd.org> <200808081427.42536.jhb@freebsd.org> <20080808185133.GG97161@deviant.kiev.zoral.com.ua> <200808081459.54735.jhb@freebsd.org> Cc: Kostik Belousov , Stanislav Sedov , src-committers@freebsd.org, cvs-all@freebsd.org, cvs-src@freebsd.org Subject: Re: cvs commit: src/share/man/man4 Makefile cpuctl.4 src/sys/amd64/amd64 support.S src/sys/amd64/conf NOTES src/sys/amd64/include cpufunc.h specialreg.h src/sys/conf files.amd64 files.i386 src/sys/dev/cpuctl cpuctl.c ... X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2008 21:02:22 -0000 On Fri, Aug 8, 2008 at 11:59 AM, John Baldwin wrote: > On Friday 08 August 2008 02:51:33 pm Kostik Belousov wrote: >> On Fri, Aug 08, 2008 at 02:27:42PM -0400, John Baldwin wrote: >> > On Friday 08 August 2008 02:10:52 pm Kostik Belousov wrote: >> > > On Fri, Aug 08, 2008 at 12:51:17PM -0400, John Baldwin wrote: >> > > > On Friday 08 August 2008 12:26:53 pm Stanislav Sedov wrote: >> > > > > stas 2008-08-08 16:26:53 UTC >> > > > > >> > > > > FreeBSD src repository >> > > > > >> > > > > Modified files: >> > > > > share/man/man4 Makefile >> > > > > sys/amd64/amd64 support.S >> > > > > sys/amd64/conf NOTES >> > > > > sys/amd64/include cpufunc.h specialreg.h >> > > > > sys/conf files.amd64 files.i386 >> > > > > sys/i386/conf NOTES >> > > > > sys/i386/i386 support.s >> > > > > sys/i386/include cpufunc.h specialreg.h >> > > > > sys/modules Makefile >> > > > > sys/sys priv.h >> > > > > usr.sbin Makefile >> > > > > Added files: >> > > > > share/man/man4 cpuctl.4 >> > > > > sys/dev/cpuctl cpuctl.c >> > > > > sys/modules/cpuctl Makefile >> > > > > sys/sys cpuctl.h >> > > > > usr.sbin/cpucontrol Makefile amd.c amd.h cpucontrol.8 >> > > > > cpucontrol.c cpucontrol.h intel.c intel.h >> > > > > Log: >> > > > > SVN rev 181430 on 2008-08-08 16:26:53Z by stas >> > > > > >> > > > > - Add cpuctl(4) pseudo-device driver to provide access to some >> > low-level >> > > > > features of CPUs like reading/writing machine-specific > registers, >> > > > > retrieving cpuid data, and updating microcode. >> > > > > - Add cpucontrol(8) utility, that provides userland access to >> > > > > the features of cpuctl(4). >> > > > > - Add subsequent manpages. >> > > > > >> > > > > The cpuctl(4) device operates as follows. The pseudo-device node >> > cpuctlX >> > > > > is created for each cpu present in the systems. The pseudo-device >> > minor >> > > > > number corresponds to the cpu number in the system. The cpuctl(4) >> > pseudo- >> > > > > device allows a number of ioctl to be preformed, namely >> > RDMSR/WRMSR/CPUID >> > > > > and UPDATE. The first pair alows the caller to read/write >> > machine-specific >> > > > > registers from the correspondent CPU. cpuid data could be > retrieved >> > using >> > > > > the CPUID call, and microcode updates are applied via UPDATE. >> > > > > >> > > > > The permissions are inforced based on the pseudo-device file >> > permissions. >> > > > > RDMSR/CPUID will be allowed when the caller has read access to the >> > device >> > > > > node, while WRMSR/UPDATE will be granted only when the node is > opened >> > > > > for writing. There're also a number of priv(9) checks. >> > > > > >> > > > > The cpucontrol(8) utility is intened to provide userland access to >> > > > > the cpuctl(4) device features. The utility also allows one to > apply >> > > > > cpu microcode updates. >> > > > > >> > > > > Currently only Intel and AMD cpus are supported and were tested. >> > > > >> > > > Note that cpuid isn't a privileged instruction, so I'm not sure it's >> > really >> > > > worth having an ioctl for that particular case. >> > > >> > > It was discussed when patch was reviewed on current@. The ioctl allows >> > > to get cpuid information for specific processor, as opposed to some >> > > random core curthread happens to run ATM. >> > >> > You can achieve that now with cpuset. :) (See my ping-pong test program >> > recently which used cpuid to fetch the APIC ID to test for ping-ponging in >> > the scheduler.) >> >> If this is a backout request (for cpuid functionality) then we will do it. >> >> But I considered it much easier and cleaner to do >> fd = open("/dev/cpuctlN", O_RDWR); >> ioctl(fd, CPUCTL_CPUID, &x); >> if (x.y) >> ioctl(fd, CPUCTL_WRMSR, ...); >> close(fd); >> then >> fd = open("/dev/cpuctlN", O_RDWR); >> cpuset(...); /* bind to cpu */ >> __asm__("cpuid" : =0 (x)); >> if (x.y) >> ioctl(fd, CPUCTL_WRMSR, ...); >> cpuset(...); /* restore prev mask */ >> close(fd); > > You can leave it. It is useful to specify the CPU I suppose. I just don't think it is particularly useful to add a restriction / priv check for information that is available in an unprivileged fashion by other means. I think the priv check should go away since it doesn't achieve anything. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell