> What exactly could go wrong with which MSR read?
Show me a pair of Intel and AMD architecture documents guaranteeing all
undefined, undocumented, and documented MSR reads for all processors have
no side effects.
> I just picked some MSRs I found in turbostat and cpupower.
> Len: It would be great if you could contribute to cpupower.
> It can do exactly the same than turbostat (but for all archs)
> and the fixups you send for turbostat are very easy to integrate
> into cpupower as well.
I suspect the number you need is very smal fortunately (and that they
could be properly exposed by a kernel interface that knows the CPU type
and what is needed for each - be that a chopped down msr driver or
something saner)
> > I would also look at MTRRs because mis-setting MTRRs
> > allows you to get firmware to do interesting things in certain
> > situations because the commands being issued to stuff like the GPU may
> > get corrupted.
> I am not aware of a mtrr interface to userspace.
/proc/mtrr
> +static u32 msr_intel_wl[] =
> + {
> + 0x198, /* MSR_IA32_PERF_STATUS */
> + 0x1a0, /* MSR_IA32_MISC_ENABLES */
> + 0x1b0, /* MSR_IA32_ENERGY_PERF_BIAS */
> + 0xce, /* MSR_NEHALEM_PLATFORM_INFO */
> + 0x1ad, /* MSR_NEHALEM_TURBO_RATIO_LIMIT */
> + 0x3f8, /* MSR_PKG_C3_RESIDENCY */
> + 0x3f9, /* MSR_PKG_C6_RESIDENCY */
> + 0x3fc, /* MSR_CORE_C3_RESIDENCY */
> + 0x3fd, /* MSR_CORE_C6_RESIDENCY */
I believe you need to verify precisely which processor each is
architecturally defined for and whitelist according to a CPU match.
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
