On May 18, 2008, at 11:15 AM, Kostik Belousov wrote:
On Sun, May 18, 2008 at 04:47:41PM +0100, Rui Paulo wrote:
Kostik Belousov wrote:
On Sat, May 17, 2008 at 06:26:01PM +0100, Rui Paulo wrote:
Andriy Gapon wrote:
on 17/05/2008 18:37 Rui Paulo said the following:
Andriy Gapon 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?
While I think this (devcpu) is good for testing and
development, I
prefer having a device driver to handle that specific MSR than a
generic /dev/cpuN where you can issue MSRs.
Both for security and reliability reasons.
What about /dev/pci, /dev/io? Aren't they a precedent?
They are, but, IMHO, we should no longer continue to create this
type of
interfaces.
Why ? Are developers some kind of the second-class users ?
I would have no opinion on providing /dev/cpu by the loadable
module, not
compiled into GENERIC. But the interface itself is useful at
least for
three things:
- CPU identification (see x86info or whatever it is called);
- CPU tweaking for bugs workaround without patching the kernel;
- updating the CPU microcode.
None of these is limited to the developers only.
Input validation is my main concern here. Regarding to your two last
points, I would prefer to have a microcode driver than a microcode
userland utility that relies on devcpu.
Did you looked at the code ? It does exactly what you described.
Driver has four basic operations:
read/write msr
perform cpu id work
For what it's worth, CPUID is not a privileged instruction, so this
doesn't need to be done in the kernel (as long as you have a way to
pin a userland thread to a cpu, which I believe we have, now).
I would personally would *really* to see stas's driver committed as
well, as it's really useful.
(I had a similar driver (but only for MSRs) that I was about to
commit to 7.0 a few months ago, but re@ asked that I add a manpage,
and I never got around to doing it:
http://people.freebsd.org/~ssouhlal/testing/msr-20070707.diff
It's slightly different from devcpu in that it works with lseek +
read/write instead of ioctl).
-- Suleiman
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
