Date: Sun, 18 May 2008 15:29:37 -0400 From: Mike Meyer <mwm-keyword-freebsdhackers2.e313df@mired.org> To: Rui Paulo <rpaulo@FreeBSD.org> Cc: freebsd-hackers@freebsd.org, Mike Meyer <mwm-keyword-freebsdhackers2.e313df@mired.org> Subject: Re: rdmsr from userspace Message-ID: <20080518152937.774cf492@bhuda.mired.org> In-Reply-To: <48307700.70304@FreeBSD.org> References: <482E93C0.4070802@icyb.net.ua> <20080517133037.3a3935db@bhuda.mired.org> <48305044.7000007@FreeBSD.org> <20080518140650.2691af1c@bhuda.mired.org> <48307700.70304@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 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?
> >>> 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), and
> >>> with that hammer in my hand, the nail for this problem is obviously 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, which
> > can do pretty much anything. In particular, there are already examples
> > 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 kernel
> > 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.
On the other hand, if you want to allow access to the fixed set of
documented msr's (for each cpu model, anyway), then handing back that
fixed set as an array would be a better approach, and would have the
advantage of not having to deal with invalid requests (non-existent
MSRs, 1-byte reads/writes of multi-byte MSRs, etc).
On the other hand, it might be more useful - *especially* if the MSRs
move around depending on processor types (I honestly don't know) - to
provide a "named" interface:
dev.cpu.0.msr.mtrr
dev.cpu.0.msr.arr
dev.cpu.0.msr.efer
and so on. You'd register the names when the module was initialized,
and would only register the ones that actually existed. You'd then
never have to deal with a request for a non-existent MSR, because the
sysctl call would return an error to the calling program without ever
calling your handler.
Of course, you can *combine* these two approaches, and have:
dev.cpu.0.msr.all # returns an array of all available msrs
dev.cpu.0.msr.have # an array of the available msrs
but at this point it's just blue sky speculation...
> I'll have to think about whether or not I like this interface.
Actually, I'm more interested in why there seems to be a dislike
of file-based interfaces in favor of sysctls in the freebsd
community. Exploring this has been enlightening. Thank you.
<mike
--
Mike Meyer <mwm@mired.org> http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080518152937.774cf492>