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