The term "unrecognized" in the warning message

  "Write to unrecognized MSR..."

  creates the impression that the MSR access is invalid or
  prohibited, which is not necessarily the case.

  Remove this wording to avoid misleading users about the nature
  of the access.

Signed-off-by: Roman Storozhenko <romeusmeister@gmail.com>
---
Additional context:

A utility that uses direct MSR writes triggered this warning during
post-silicon validation. The message was interpreted as evidence of
incorrect or prohibited MSR access due to the use of the term
"unrecognized".

This led to confusion among validation teams, although the MSR accesses
were intentional and valid.

Clarify the message to avoid misleading users in similar scenarios.
---
 arch/x86/kernel/msr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/msr.c b/arch/x86/kernel/msr.c
index 4469c784eaa0..16f6cde7d471 100644
--- a/arch/x86/kernel/msr.c
+++ b/arch/x86/kernel/msr.c
@@ -98,7 +98,7 @@ static int filter_write(u32 reg)
 	if (!__ratelimit(&fw_rs))
 		return 0;
 
-	pr_warn("Write to unrecognized MSR 0x%x by %s (pid: %d), tainting CPU_OUT_OF_SPEC.\n",
+	pr_warn("Write to MSR 0x%x by %s (pid: %d), tainting CPU_OUT_OF_SPEC.\n",
 	        reg, current->comm, current->pid);
 	pr_warn("See https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/about for details.\n");
 

---
base-commit: 85964cdcad0fac9a0eb7b87a0f9d88cc074b854c
change-id: 20260325-dev_roman_msr_msg-fad98620cc22

Best regards,
-- 
Roman Storozhenko <romeusmeister@gmail.com>

On Wed, Mar 25, 2026 at 06:48:52PM +0100, Roman Storozhenko wrote:
> The term "unrecognized" in the warning message
> 
>   "Write to unrecognized MSR..."
> 
>   creates the impression that the MSR access is invalid or
>   prohibited, which is not necessarily the case.
> 
>   Remove this wording to avoid misleading users about the nature
>   of the access.
> 
> Signed-off-by: Roman Storozhenko <romeusmeister@gmail.com>
> ---
> Additional context:
> 
> A utility that uses direct MSR writes triggered this warning during
> post-silicon validation. The message was interpreted as evidence of
> incorrect or prohibited MSR access due to the use of the term
> "unrecognized".
> 
> This led to confusion among validation teams, although the MSR accesses
> were intentional and valid.
> 
> Clarify the message to avoid misleading users in similar scenarios.
> ---
>  arch/x86/kernel/msr.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kernel/msr.c b/arch/x86/kernel/msr.c
> index 4469c784eaa0..16f6cde7d471 100644
> --- a/arch/x86/kernel/msr.c
> +++ b/arch/x86/kernel/msr.c
> @@ -98,7 +98,7 @@ static int filter_write(u32 reg)
>  	if (!__ratelimit(&fw_rs))
>  		return 0;
>  
> -	pr_warn("Write to unrecognized MSR 0x%x by %s (pid: %d), tainting CPU_OUT_OF_SPEC.\n",
> +	pr_warn("Write to MSR 0x%x by %s (pid: %d), tainting CPU_OUT_OF_SPEC.\n",
>  	        reg, current->comm, current->pid);
>  	pr_warn("See https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/about for details.\n");
>  
> 
> ---

# modprobe msr allow_writes=on
# grep -r . /sys/module/msr/parameters/allow_writes 
on

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

On Mon, Mar 30, 2026 at 4:16 PM Borislav Petkov <bp@alien8.de> wrote:
>
> On Wed, Mar 25, 2026 at 06:48:52PM +0100, Roman Storozhenko wrote:
> > The term "unrecognized" in the warning message
> >
> >   "Write to unrecognized MSR..."
> >
> >   creates the impression that the MSR access is invalid or
> >   prohibited, which is not necessarily the case.
> >
> >   Remove this wording to avoid misleading users about the nature
> >   of the access.
> >
> > Signed-off-by: Roman Storozhenko <romeusmeister@gmail.com>
> > ---
> > Additional context:
> >
> > A utility that uses direct MSR writes triggered this warning during
> > post-silicon validation. The message was interpreted as evidence of
> > incorrect or prohibited MSR access due to the use of the term
> > "unrecognized".
> >
> > This led to confusion among validation teams, although the MSR accesses
> > were intentional and valid.
> >
> > Clarify the message to avoid misleading users in similar scenarios.
> > ---
> >  arch/x86/kernel/msr.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/kernel/msr.c b/arch/x86/kernel/msr.c
> > index 4469c784eaa0..16f6cde7d471 100644
> > --- a/arch/x86/kernel/msr.c
> > +++ b/arch/x86/kernel/msr.c
> > @@ -98,7 +98,7 @@ static int filter_write(u32 reg)
> >       if (!__ratelimit(&fw_rs))
> >               return 0;
> >
> > -     pr_warn("Write to unrecognized MSR 0x%x by %s (pid: %d), tainting CPU_OUT_OF_SPEC.\n",
> > +     pr_warn("Write to MSR 0x%x by %s (pid: %d), tainting CPU_OUT_OF_SPEC.\n",
> >               reg, current->comm, current->pid);
> >       pr_warn("See https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/about for details.\n");
> >
> >
> > ---
>
> # modprobe msr allow_writes=on
> # grep -r . /sys/module/msr/parameters/allow_writes
> on

Hi Boris,

Thanks for the clarification.

If I understand correctly, in this context "unrecognized" does not refer
to the MSR itself being unknown, but rather reflects the driver policy
when writes are disabled (allow_writes=off).

In that case, the current wording can be misleading, as it suggests that
the MSR is invalid or unsupported, while in reality the write is simply
not permitted by policy.

Would it make sense to adjust the message to reflect this more explicitly,
for example:

"Write to MSR 0x%x (writes not enabled) by %s (pid: %d), tainting
CPU_OUT_OF_SPEC.\n"

This would preserve the warning while making the reason clearer.

Thanks,
Roman
>
> --
> Regards/Gruss,
>     Boris.
>
> https://people.kernel.org/tglx/notes-about-netiquette



-- 
Kind regards,
Roman Storozhenko

On Wed, Apr 01, 2026 at 09:18:57PM +0200, Roman Storozhenko wrote:
> Would it make sense to adjust the message to reflect this more explicitly,
> for example:

Only after you answer my question why you cannot use the module parameter
allow_writes?

That's *exactly* why we added it at the time - exactly for such cases.

:-)

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

On Wed, Apr 1, 2026 at 9:27 PM Borislav Petkov <bp@alien8.de> wrote:
>
> On Wed, Apr 01, 2026 at 09:18:57PM +0200, Roman Storozhenko wrote:
> > Would it make sense to adjust the message to reflect this more explicitly,
> > for example:
>
> Only after you answer my question why you cannot use the module parameter
> allow_writes?
>
> That's *exactly* why we added it at the time - exactly for such cases.
>
> :-)

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.

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:
hedin@laptop:~/prj/intel-cmt-cat$ make -j`nproc`
hedin@laptop:~/prj/intel-cmt-cat$ sudo LD_LIBRARY_PATH=lib pqos/pqos
--iface=msr -m all:0-7

to see that 'unrecognized' messages in dmesg periodically.
Of course 'allows_writes' isn't provided in this case (Ubuntu distro):
hedin@laptop:~/prj/intel-cmt-cat$ sudo grep -r .
/sys/module/msr/parameters/allow_writes
default

Both allocation and monitoring use 'msr_write' and 'msr_read'
functions that rely on '/dev/cpu/<X>/msr:
https://github.com/intel/intel-cmt-cat/blob/master/lib/allocation.c
https://github.com/intel/intel-cmt-cat/blob/master/lib/common_monitoring.c
https://github.com/intel/intel-cmt-cat/blob/master/lib/machine.c

Our stakeholders interpret that 'unrecognized' word as a writing to
wrong or non-existing MSR registers.
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.

>
> --
> Regards/Gruss,
>     Boris.
>
> https://people.kernel.org/tglx/notes-about-netiquette

-- 
Kind regards,
Roman Storozhenko

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

On Thu, Apr 02, 2026 at 07:37:14PM +0200, Roman Storozhenko wrote:
> Both allocation and monitoring use 'msr_write' and 'msr_read'
> functions that rely on '/dev/cpu/<X>/msr:
> https://github.com/intel/intel-cmt-cat/blob/master/lib/allocation.c
> https://github.com/intel/intel-cmt-cat/blob/master/lib/common_monitoring.c
> https://github.com/intel/intel-cmt-cat/blob/master/lib/machine.c

This is exactly the problem: Those MSRs belong to the kernel. So if some
userspace tool goes and pokes at them under the kernel's feet, then you get to
keep both pieces.

This is exactly why MSR accesses are filtered. You can read this commit
message carefully: 

a7e1f67ed29f ("x86/msr: Filter MSR writes")

Your tool should work *with* the kernel which should arbitrate accesses and
even better - there should be proper interfaces to the hw facilities you need
- but no tool should poke at MSRs without synchronization and arbitration with
the kernel.

So you should remove *all* msr_*() function calls in your tool and propose
proper interfaces. That's the only viable way forward.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette