MSR_PERF_STATUS voltage reading

[Travis_D_]

On Sandy Bridge CPUs (as well as on later chips, empirically), you can read the "Core Voltage" from bits 47:32 of the MSR_PERF_STATUS MSR (0x198, seems to be the same as IA32_PERF_STATUS, not what the meaning of the different prefixes "MSR" vs "IA32" mean).

SDM volume 4 describes this as (note the typo 37:32, it should be 47:32):

Core Voltage (R/O)
P-state core voltage can be computed by
MSR_PERF_STATUS[37:32] * (float) 1/(2^13).

What isn't clear if this is the VID (voltage requested from the voltage regulator by the CPU), or the measured actual voltage "vcore" or "vcc" at the core. Normally the two will be close, but the not the same.

Various tools refer to it as the VID, while others call it "core voltage". The SDM text would make one lean slightly towards VID as it says "P-state core voltage", where the reference to p-state makes one thing it is the required voltage associated with a p-state (i.e., the VID) rather than a measured, actual voltage.

Note that bits 7:0 of this MSR used to return the VID, but not on any more (on Skylake, they seem to always be zero). Bits 15:8 do seem to return the FID (frequency ID, i.e., an ID which maps directly to the frequency multiplier).

[McCalpinJohn]

For Sandy Bridge, MSR_PERF_STATUS (0x198) has package scope.  

Starting with Haswell, Volume 1 of each (server) processor's data sheet notes:

Individual processor VID values may be calibrated during manufacturing such that two processor units with the same core frequency may have different default VID settings.

Interestingly, none of the mainline processors newer than Sandy Bridge list this MSR in Volume 4.  This is perhaps not surprising since it is "Architectural", but the table of Architectural MSRs does not contain information on the scope of these MSRs.   Obviously bits 15:0 have to have core-scope in processors that support per-core p-states, but that may not imply anything about the scope of the undocumented/reserved bits.  

It should be easy enough to determine whether the reserved bits of this MSR are reporting VCCin (which is intrinsically package scope) or reporting per-core values.  I would try a long-running code with Power License 0 instructions on one core and long-running code with Power License 2 instructions on another core, then comparing each core's MSR values.  (Running in the kernel would certainly help -- I have seen that the kernel crossing is often enough to cause changes in the p-state value in this register.)