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
update microcode.
The later is done as a whole operation, with the microcode blob supplied
by the userspace.
Yes, but I still don't like having everything mixed up in one driver. At
the very least, I would like us to have two drivers. One for the
microcode update and the other driver for the rest.
I would like to see a microcode update utility (driver + something to
parse Intel's file aka devcpu-data) in the base system, but not "the
rest", though.
Regards,
--
Rui Paulo
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
