Re: [PATCH] x86/msr: Remove misleading "unrecognized" wording in write warning

[Thomas Gleixner]

Roman!

On Thu, Apr 02 2026 at 19:37, Roman Storozhenko wrote:

> I can use 'allow_writes', but userland SW uses "/dev/cpu/<X>/msr"
> relies on default msr driver behaviour. Indeed, it would be strange if
> such SW reloads a kernel driver (if it is possible) to make sure that
> this message doesn't appear. Most distributions don't pass that
> parameter.

Sane distributions use allow_writes=off because allowing user space to
write to random MSRs is a system stability issue even if the interface
is restricted to root.

> Let's take a SW I work on as an example:
> https://github.com/intel/intel-cmt-cat
>
> If your CPU supports Intel RDT you could build and run it:

If my CPU supports RDT, I use RESCTRL in the kernel. It provides a
proper interface, monitoring with all bells and whistels and is fully
integrated into the kernel task and process management.

RESCTRL has been around for almost a decade. Your colleagues Reinette
and Tony spent a lot of time to make this work in a sane way, so the
real question is why you need a seperate tool which works around the
provided and sane interfaces.

> to see that 'unrecognized' messages in dmesg periodically.

We don't need your tool for that at all. wrmsr(1) is sufficient.

> Both allocation and monitoring use 'msr_write' and 'msr_read'
> functions that rely on '/dev/cpu/<X>/msr:

Which is wrong to begin with because the kernel provides full support
for it.

> Our stakeholders interpret that 'unrecognized' word as a writing to
> wrong or non-existing MSR registers.

Your stakeholders seem not to care about the way worse CPU_OUT_OF_SPEC
taint. Are you going to remove that next?

> To be honest I interpreted this in this way too, unless I read msr
> driver code.  That is why I posted this patch. My intention is to
> align this message with what is really happening in the driver, that
> is writing to a valid register, but against the current policy.

I kinda agree with you that the 'unrecognized' wording is suboptimal and
it should rather be explicit about user space [ab]use of the interface,
i.e.:

       "User space write to MSR ...., tainting ..."

or something like that.

The changelog surely should explain that 'unrecognized' is not the
appropriate word, but without a lame justification why such tools exists
in the first place and need to be supported gracefully.

The only justification for them is experimentation and people who do
that should know what they are doing. If they get confused by the
message then they should not touch CPU MSRs in the first place.

Thanks,

        tglx