Commit Graph

5 Commits

Author SHA1 Message Date
stas
9a7ae64d55 - Add support to atomically set/clear individual bits of a MSR register
via cpuctl(4) driver.  Two new CPUCTL_MSRSBIT and CPUCTL_MSRCBIT ioctl(2)
  calls treat the data field of the argument struct passed as a mask
  and set/clear bits of the MSR register according to the mask value.
- Allow user to perform atomic bitwise AND and OR operaions on MSR registers
  via cpucontrol(8) utility.  Two new operations ("&=" and "|=") have been
  added.  The first one applies bitwise AND operaion between the current
  contents of the MSR register and the mask, and the second performs bitwise
  OR.  The argument can be optionally prefixed with "~" inversion operator.
  This allows one to mimic the "clear bit" behavior by using the command
  like this:
      cpucontrol -m 0x10&=~0x02		# clear the second bit of TSC MSR

  Inversion operator support in all modes (assignment, OR, AND).

Approved by:	re (kib)
MFC after:	1 month
2009-06-30 12:35:47 +00:00
stas
c7738de5e3 - Don't zero data field in case of MSR write operation. Before this change
the value written to MSR register was always 0 regardless of value passed
  by user.
- Use proper data pointer when performing AMD microcode update.  Previously,
  the pointer to user-space data has been provided instead, which is totally
  incorrect.

Approved by:	re (kib)
MFC after:	1 week
2009-06-26 22:13:15 +00:00
ed
4efdef565f Replace all calls to minor() with dev2unit().
After I removed all the unit2minor()/minor2unit() calls from the kernel
yesterday, I realised calling minor() everywhere is quite confusing.
Character devices now only have the ability to store a unit number, not
a minor number. Remove the confusion by using dev2unit() everywhere.

This commit could also be considered as a bug fix. A lot of drivers call
minor(), while they should actually be calling dev2unit(). In -CURRENT
this isn't a problem, but it turns out we never had any problem reports
related to that issue in the past. I suspect not many people connect
more than 256 pieces of the same hardware.

Reviewed by:	kib
2008-09-27 08:51:18 +00:00
ed
3758c00f64 Remove unneeded D_NEEDMINOR from cpuctl(4).
The D_NEEDMINOR flag was introduced for drivers that do not actually
depend on storing a device unit/minor number, but require the ability to
address the cdevs by this number, which is used by clone_create().

The cpuctl(4) driver sets D_NEEDMINOR, even though it doesn't use the
clone_create() API. Remove the flag, because maybe we want to get rid of
it somewhere in the far future.
2008-09-01 18:56:01 +00:00
stas
a782fc10fe - Add cpuctl(4) pseudo-device driver to provide access to some low-level
features of CPUs like reading/writing machine-specific registers,
  retrieving cpuid data, and updating microcode.
- Add cpucontrol(8) utility, that provides userland access to
  the features of cpuctl(4).
- Add subsequent manpages.

The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX
is created for each cpu present in the systems. The pseudo-device minor
number corresponds to the cpu number in the system. The cpuctl(4) pseudo-
device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID
and UPDATE. The first pair alows the caller to read/write machine-specific
registers from the correspondent CPU. cpuid data could be retrieved using
the CPUID call, and microcode updates are applied via UPDATE.

The permissions are inforced based on the pseudo-device file permissions.
RDMSR/CPUID will be allowed when the caller has read access to the device
node, while WRMSR/UPDATE will be granted only when the node is opened
for writing. There're also a number of priv(9) checks.

The cpucontrol(8) utility is intened to provide userland access to
the cpuctl(4) device features. The utility also allows one to apply
cpu microcode updates.

Currently only Intel and AMD cpus are supported and were tested.

Approved by:	kib
Reviewed by:	rpaulo, cokane, Peter Jeremy
MFC after:	1 month
2008-08-08 16:26:53 +00:00