Date: Fri, 8 Aug 2008 14:02:19 -0700 From: "Peter Wemm" <peter@wemm.org> To: "John Baldwin" <jhb@freebsd.org> Cc: Kostik Belousov <kostikbel@gmail.com>, Stanislav Sedov <stas@freebsd.org>, 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 ... Message-ID: <e7db6d980808081402w676f91n8570df2e83b1c65d@mail.gmail.com> In-Reply-To: <200808081459.54735.jhb@freebsd.org> References: <200808081631.m78GVG9i088754@repoman.freebsd.org> <200808081427.42536.jhb@freebsd.org> <20080808185133.GG97161@deviant.kiev.zoral.com.ua> <200808081459.54735.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Aug 8, 2008 at 11:59 AM, John Baldwin <jhb@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e7db6d980808081402w676f91n8570df2e83b1c65d>