From: Juergen Gross <jgross@suse.com>
To: Sean Christopherson <seanjc@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
linux-kernel@vger.kernel.org, x86@kernel.org,
linux-perf-users@vger.kernel.org, linux-edac@vger.kernel.org,
"H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
Adrian Hunter <adrian.hunter@intel.com>,
James Clark <james.clark@linaro.org>,
Tony Luck <tony.luck@intel.com>
Subject: Re: [PATCH RFC 0/6] x86/msr: Rename MSR access functions
Date: Wed, 22 Apr 2026 09:11:21 +0200 [thread overview]
Message-ID: <0f0e5ba5-e6af-45ca-98b8-ea3bcbcede59@suse.com> (raw)
In-Reply-To: <aeYty5kU8Rp44USr@google.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 2326 bytes --]
On 20.04.26 15:44, Sean Christopherson wrote:
> On Mon, Apr 20, 2026, Jürgen Groß wrote:
>> On 20.04.26 13:41, Peter Zijlstra wrote:
>>> On Mon, Apr 20, 2026 at 01:35:12PM +0200, Peter Zijlstra wrote:
>>>> On Mon, Apr 20, 2026 at 11:16:28AM +0200, Juergen Gross wrote:
>>>>
>>>>> - Use functions instead of macros for accessing MSRs, which will drop
>>>>> modifying variables passed as a parameter.
>>>>>
>>>>> - Eliminate multiple accessors doing exactly the same thing (e.g.
>>>>> rdmsrl() and rdmsrq()).
>>>>
>>>> So far so sane.
>>>>
>>>>> - Instead of having function names based on the underlying instruction
>>>>> mnemonics, have functions of a common name space (msr_*()).
>>>>
>>>> Not sure on this one. The whole msr_{read,write}_{safe,noser}() thing is
>>>> a royal pain. Also 'noser' reads to me as the noun that goes with 'to
>>>> nose' [he that noses (around), like baker: he that bakes].
>>>>
>>>> I would much rather we just stick to the mnemonics here. All of this
>>>> really is about wrapping single instructions, no need to make it an
>>>> unreadable mess.
>>>
>>> Also, the _safe suffix should just go away. All MSR accessors should be
>>> 'safe'.
>>
>> That would be fine by me, but I'd like to have some confirmation this is
>> really the route to go.
>
> I don't care what the suffix is called, or if there is even a suffix, but there
> needs to be a way for the caller to communicate that it wants to handle faults,
> so that the "caller isn't going to handle a fault" case generates a WARN if the
> access does #GP.
So this calls for keeping the *_safe() variants (keeping the name or not).
Using the label based error handling for those is a no-go IMHO, as we are
trying to inline all MSR accesses as much as possible in order to avoid
calls and the associated possible retpoline stuff (request by Thomas Gleixner
IIRC). Doing the WARN inline will bloat code more than necessary, especially
as we already have the central WARN today when fixing up the #GP.
In order not having to modify the logic for current use cases it would be
best to keep the main interface of the *_safe() functions (let them return
0/-errno, use a pointer for the value returned by rdmsr_safe()).
We can add label variants on top using macros.
Juergen
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3743 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]
next prev parent reply other threads:[~2026-04-22 7:11 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-20 9:16 [PATCH RFC 0/6] x86/msr: Rename MSR access functions Juergen Gross
2026-04-20 9:16 ` [PATCH RFC 6/6] x86/cpu/mce: Switch code to use new " Juergen Gross
2026-04-20 11:35 ` [PATCH RFC 0/6] x86/msr: Rename " Peter Zijlstra
2026-04-20 11:41 ` Peter Zijlstra
2026-04-20 11:51 ` Jürgen Groß
2026-04-20 13:44 ` Sean Christopherson
2026-04-20 14:04 ` Jürgen Groß
2026-04-20 15:34 ` H. Peter Anvin
2026-04-22 7:11 ` Juergen Gross [this message]
2026-04-20 11:49 ` Jürgen Groß
2026-04-20 12:33 ` Peter Zijlstra
2026-04-20 13:01 ` Jürgen Groß
2026-04-20 13:10 ` Peter Zijlstra
2026-04-20 13:23 ` Jürgen Groß
2026-04-20 13:36 ` Sean Christopherson
2026-04-20 13:57 ` Jürgen Groß
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0f0e5ba5-e6af-45ca-98b8-ea3bcbcede59@suse.com \
--to=jgross@suse.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=irogers@google.com \
--cc=james.clark@linaro.org \
--cc=jolsa@kernel.org \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=seanjc@google.com \
--cc=tglx@kernel.org \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox