On Mon, Feb 29, 2016 at 10:35:12PM +0000, Mcfadden, Marty Jay wrote: > The examples provided were to address why bit-level access granularity > was needed. They were not intended to be, nor are they, a comprehensive list > of scenarios.
So which scenarios cannot be satisfied by proper implementation of userspace APIs (sysfs, procfs, etc) and direct access to MSRs is the only way? > What is being proposed is to make msr.ko better with a whitelist which > does not allow access to any MSRs be default unless you are root or > are a user with the appropriate capability (which is how it works > today). That doesn't protect you from mistakenly configuring the wrong mask, as root. A well-defined userspace interface does. Also, as I hinted at before, you have cases where other drivers and modules access the same MSRs as msr.ko and for that you need synchronization. Which would then need to be added. But we're going to be stuck with this wrong interface already and we then would be *extending* that wrong interface. No thanks. > System Administrators can then selectively add entries to the whitelist > to allow userspace applications access to specified bits of specific MSRs > of interest. This can all be done on emerging hardware before new > updates or interfaces are added to the kernel. Emerging hardware uses specialized hw bringup software - not the upstream kernel. Or it is a heavily patched beyond recognition ancient upstream kernel. And to that kernel people can do whatever they want. > Keeping msr.ko around and adding a whitelist mechanism will provide a > safe means for developers to experiment with MSR sets in their to > squeeze out performance and power and possibly inform future features > of modules like the rapl driver. This can be done with msr.ko now too. So no one is removing msr.ko. I'm saying extending it is the wrong approach. msr.ko is a simple debugging module. Nothing more. Everything else which is going to be user-visible and widely used, needs to be safe and clean. Exposing MSRs directly is not. It might be useful for some niche HPC use cases but is not nearly clean, safe and generic enough for a userspace API which we will have to support forever. And the fact that a bunch of tools are already using it is wrong. They shouldn't. They should use proper, safe user APIs and not poke at MSRs directly. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.