From owner-freebsd-hackers@FreeBSD.ORG Mon May 19 15:39:18 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 B6ADD106567D; Mon, 19 May 2008 15:39:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay01.kiev.sovam.com (relay01.kiev.sovam.com [62.64.120.200]) by mx1.freebsd.org (Postfix) with ESMTP id 43ED78FC0C; Mon, 19 May 2008 15:39:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=skuns.kiev.zoral.com.ua) by relay01.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Jy7SF-0006AD-Nk; Mon, 19 May 2008 18:39:16 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m4JFd4iD046128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 May 2008 18:39:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m4JFd2l9065516; Mon, 19 May 2008 18:39:02 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m4JFd28k065515; Mon, 19 May 2008 18:39:02 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 19 May 2008 18:39:02 +0300 From: Kostik Belousov To: John Baldwin Message-ID: <20080519153902.GG18958@deviant.kiev.zoral.com.ua> References: <482E93C0.4070802@icyb.net.ua> <48307700.70304@FreeBSD.org> <20080518152945.60989b9c@bhuda.mired.org> <200805191037.12130.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TG/adJaYDs0AFCGK" Content-Disposition: inline In-Reply-To: <200805191037.12130.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.4 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on skuns.kiev.zoral.com.ua X-Scanner-Signature: 8f05f8c1fbcffa8edf4596457ca31d97 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 2844 [May 13 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0278], KAS30/Release Cc: stas@freebsd.org, freebsd-hackers@freebsd.org, Mike Meyer , Rui Paulo 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: Mon, 19 May 2008 15:39:18 -0000 --TG/adJaYDs0AFCGK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 19, 2008 at 10:37:11AM -0400, John Baldwin wrote: > On Sunday 18 May 2008 03:29:45 pm Mike Meyer wrote: > > On Sun, 18 May 2008 19:35:44 +0100 > > > > Rui Paulo wrote: > > > Mike Meyer wrote: > > > > On Sun, 18 May 2008 16:50:28 +0100 > > > > > > > > Rui Paulo wrote: > > > >> Mike Meyer wrote: > > > >>> On Sat, 17 May 2008 11:13:52 +0300 > > > >>> > > > >>> Andriy Gapon wrote: > > > >>>> It seems that rdmsr instruction can be executed only at the high= est > > > >>>> 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 approa= ch > > > >>>> 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? > > > >>> > > > >>> Ok, this points directly at a question I've been wondering about,= but > > > >>> haven't been able to find an answer in the google. > > > >>> > > > >>> I've been mucking about with general access to sysctl's (a sysctl > > > >>> plugin for gkrellm, and a python module for accessing sysctls), a= nd > > > >>> with that hammer in my hand, the nail for this problem is obvious= ly a > > > >>> dev.cpu.#.msr sysctl. > > > >> > > > >> How can you request a rdmsr within the sysctl tree? I don't think > > > >> sysctl is appropriate here either. > > > > > > > > Reading (or writing) a sysctl mib can trigger a sysctl handler, whi= ch > > > > can do pretty much anything. In particular, there are already examp= les > > > > in the kernel where sysctl handlers use devices that don't have /dev > > > > entries to get & set their values. Look through kern/kern_cpu.c and > > > > i386/cpufreq/p4tcc.c to see the two ends of that kind of > > > > connection. In fact, the cpu frequency sysctls would seem to be an > > > > excellent model for something like the msr. > > > > > > > > ioctl, open+read/write, sysctl - they're all just interfaces to ker= nel > > > > handlers. > > > > > > > > > > > > > Yes, sure, but who do you select the MSR you want to read or write? > > > > > > dev.cpu.N. ? > > > > I don't think that would work - you'd have to register all those > > hexadecimal strings as sysctl names. You could do an interface like > > this, but the calling program would have to use sysctlnametomib to get > > dev.cpu.N.msr, then append the MSR number to the results. Not really > > very pretty. If you want to allow the user to poke at arbitrary msrs, > > this would be a way to do it with sysctls, but the file api is > > probably better. >=20 > Actually, you don't have to register all of them. You can write a node= =20 > handler which parses the next item in the MIB directly. Look at the all = the=20 > proc sysctl's which accept a PID for example. That said, I think if some= one=20 > already has a device driver done that is fine. I also think it is ok to = let=20 > root request arbitrary MSR's from userland using an ioctl() or the like. I started a conversation with Stas about committing the driver. --TG/adJaYDs0AFCGK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkgxnxYACgkQC3+MBN1Mb4iWDgCgtAOhfzbuL1VEJ69e09B8tOjO EVgAoLhCGDgAX31TLHuxtgsBii2YyHBd =ukOk -----END PGP SIGNATURE----- --TG/adJaYDs0AFCGK--