Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 19 May 2008 18:39:02 +0300
From:      Kostik Belousov <kostikbel@gmail.com>
To:        John Baldwin <jhb@freebsd.org>
Cc:        stas@freebsd.org, freebsd-hackers@freebsd.org, Mike Meyer <mwm-keyword-freebsdhackers2.e313df@mired.org>, Rui Paulo <rpaulo@freebsd.org>
Subject:   Re: rdmsr from userspace
Message-ID:  <20080519153902.GG18958@deviant.kiev.zoral.com.ua>
In-Reply-To: <200805191037.12130.jhb@freebsd.org>
References:  <482E93C0.4070802@icyb.net.ua> <48307700.70304@FreeBSD.org> <20080518152945.60989b9c@bhuda.mired.org> <200805191037.12130.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--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 <rpaulo@FreeBSD.org> wrote:
> > > Mike Meyer wrote:
> > > > On Sun, 18 May 2008 16:50:28 +0100
> > > >
> > > > Rui Paulo <rpaulo@FreeBSD.org> wrote:
> > > >> Mike Meyer wrote:
> > > >>> On Sat, 17 May 2008 11:13:52 +0300
> > > >>>
> > > >>> Andriy Gapon <avg@icyb.net.ua> 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.
> > > >
> > > >      <mike
> > >
> > > Yes, sure, but who do you select the MSR you want to read or write?
> > >
> > > dev.cpu.N.<insert MSR number in hexadecimal here> ?
> >
> > 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--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080519153902.GG18958>