Hi Dave, > They run their fortran app. Change the MSRs. Run it again. See if it > simulated the nuclear weapon blast any faster or slower. Rinse. Repeat. > > One thing that is missing from the changelog and cover letter here: On x86, > there's a 'wrmsr(1)' tool. That took pokes at Model Specific Registers (MSRs) > via the /dev/cpu/X/msr interface. That interface is a very, very thinly-veiled > wrapper around the WRMSR (WRite MSR) instruction. > > In other words, on x86, our current interface allows userspace programs to > arbitrarily poke at our most sensitive hardware configuration registers. One of > the most common reasons users have reported doing this (we have > pr_warn()ings about it) is controlling the prefetch hardware. > > This interface would take a good chunk of the x86 wrmsr(1) audience and > convert them over to a less dangerous interface. That's a win on x86. > We don't even *remotely* have line-of-sight for a generic solution for the kernel > to figure out a single "best" value for these registers. Thank you for mentioning wrmsr tool. This is one of the reason why I want to add the sysfs interface. I will add the description that this interface can be used instead of wrmsr tool (or MSR driver) for hardware prefetch control usage to the cover letter. I read below that we should not accesse any MSR directly from userspace without restriction. https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/about/
