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

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

[Roman Storozhenko]

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>

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

[Borislav Petkov]

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

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

[Roman Storozhenko]

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

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

[Borislav Petkov]

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

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

[Roman Storozhenko]

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

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

[Borislav Petkov]

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

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

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

[Roman Storozhenko]

On Thu, Apr 2, 2026 at 10:49 PM Thomas Gleixner <tglx@kernel.org> wrote:
>
> 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.

Exactly, I completely realize this.

>
> > 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.

I am adding Tony and Reinette to this conversation for reference and
possible feedback.
Disclaimer: I propose this patch by my own initiative, not on behalf of Intel.
Any details related to intel-cmt-cat based on publicly available open-source
version of the tool.
Let me add some info on intel-cmt-cat.
Actually our tool supports three interfaces: MSR, OS and MMIO.
OS interface supports the latest version of resctrl available online and we
are in permanent conversation and coordination with Tony related to this.
MMIO interface implements the latest RDT Architecture specification, by
the way using '/dev/mem'. Again userspace access to protected memory )
MSR interface exists not only by historical reasons, but also to enable
our early customers and support non-architectural features that will highly
unlikely find their way to resctrl. Or short-lived, CPU model-specifics
features that are subject to significant change or deprecation in the future.
Good example is IORDT, which implementation you could encounter in our repo.
Summarizing: Our tool has to be able to access appropriate RDT MSRs and
there is no other way to do this conveniently.

>
> > 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?

Definitely not. All this conversation is about the warning message,
but not driver logic justification.

>
> > 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.

Great, is that OK if I propose a v2 patch with one of the options?
1. pr_warn("User space write to MSR 0x%x by %s (pid: %d), tainting
CPU_OUT_OF_SPEC.\n",
reg, current->comm, current->pid);
2. pr_warn("User space write to MSR 0x%x by %s (pid: %d) may be
unsafe, tainting CPU_OUT_OF_SPEC.\n",
reg, current->comm, current->pid);

>
> 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.

OK, got it. Will explain in v2 once we agree on correct message wording.

>
> 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



-- 
Kind regards,
Roman Storozhenko