All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Xin Li <xin@zytor.com>
Cc: "Jürgen Groß" <jgross@suse.com>,
	"Dave Hansen" <dave.hansen@intel.com>,
	linux-kernel@vger.kernel.org, x86@kernel.org,
	kvm@vger.kernel.org, llvm@lists.linux.dev,
	"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>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Nathan Chancellor" <nathan@kernel.org>,
	"Nick Desaulniers" <nick.desaulniers+lkml@gmail.com>,
	"Bill Wendling" <morbo@google.com>,
	"Justin Stitt" <justinstitt@google.com>
Subject: Re: [PATCH v3 09/16] x86/msr: Use the alternatives mechanism for WRMSR
Date: Fri, 20 Feb 2026 09:32:34 -0800	[thread overview]
Message-ID: <aZiasvKpOHSaNuQ5@google.com> (raw)
In-Reply-To: <437EC937-24B7-4E69-B369-F9FAFC46F1B1@zytor.com>

On Fri, Feb 20, 2026, Xin Li wrote:
> 
> > On Feb 18, 2026, at 10:44 PM, Jürgen Groß <jgross@suse.com> wrote:
> > 
> > On 18.02.26 22:37, Dave Hansen wrote:
> >> On 2/18/26 13:00, Sean Christopherson wrote:
> >>> On Wed, Feb 18, 2026, Juergen Gross wrote:
> >>>> When available use one of the non-serializing WRMSR variants (WRMSRNS
> >>>> with or without an immediate operand specifying the MSR register) in
> >>>> __wrmsrq().
> >>> Silently using a non-serializing version (or not) seems dangerous (not for KVM,
> >>> but for the kernel at-large), unless the rule is going to be that MSR writes need
> >>> to be treated as non-serializing by default.
> >> Yeah, there's no way we can do this in general. It'll work for 99% of
> >> the MSRs on 99% of the systems for a long time. Then the one new system
> >> with WRMSRNS is going to have one hell of a heisenbug that'll take years
> >> off some poor schmuck's life.
> > 
> > I _really_ thought this was discussed upfront by Xin before he sent out his
> > first version of the series.
> 
> I actually reached out to the Intel architects about this before I started
> coding. Turns out, if the CPU supports WRMSRNS, you can use it across the
> board.  The hardware is smart enough to perform a serialized write whenever
> a non-serialized one isn't proper, so there’s no risk.

How can hardware possibly know what's "proper"?  E.g. I don't see how hardware
can reason about safety if there's a software sequence that is subtly relying on
the serialization of WRMSR to provide some form of ordering.

And if that's the _architectural_ behavior, then what's the point of WRMSRNS?
If it's not architectural, then I don't see how the kernel can rely on it. 

  reply	other threads:[~2026-02-20 17:32 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-18  8:21 [PATCH v3 00/16] x86/msr: Inline rdmsr/wrmsr instructions Juergen Gross
2026-02-18  8:21 ` [PATCH v3 01/16] x86/alternative: Support alt_replace_call() with instructions after call Juergen Gross
2026-04-02 13:58   ` Juergen Gross
2026-02-18  8:21 ` [PATCH v3 02/16] coco/tdx: Rename MSR access helpers Juergen Gross
2026-02-18 14:11   ` Edgecombe, Rick P
2026-02-18  8:21 ` [PATCH v3 03/16] x86/sev: Replace call of native_wrmsr() with native_wrmsrq() Juergen Gross
2026-02-18  8:21 ` [PATCH v3 04/16] KVM: x86: Remove the KVM private read_msr() function Juergen Gross
2026-02-18 14:21   ` Edgecombe, Rick P
2026-02-18 14:29     ` Sean Christopherson
2026-02-18  8:21 ` [PATCH v3 05/16] x86/msr: Minimize usage of native_*() msr access functions Juergen Gross
2026-02-18  8:21 ` [PATCH v3 06/16] x86/msr: Move MSR trace calls one function level up Juergen Gross
2026-02-18  8:21 ` [PATCH v3 07/16] x86/opcode: Add immediate form MSR instructions Juergen Gross
2026-02-18  8:21 ` [PATCH v3 08/16] x86/extable: Add support for " Juergen Gross
2026-02-18 15:48   ` Andrew Cooper
2026-02-18 16:28     ` Jürgen Groß
2026-02-18  8:21 ` [PATCH v3 09/16] x86/msr: Use the alternatives mechanism for WRMSR Juergen Gross
2026-02-18 21:00   ` Sean Christopherson
2026-02-18 21:37     ` Dave Hansen
2026-02-18 23:36       ` H. Peter Anvin
2026-02-19  6:41         ` Jürgen Groß
2026-02-19  6:44       ` Jürgen Groß
2026-02-20 17:12         ` Xin Li
2026-02-20 17:32           ` Sean Christopherson [this message]
2026-02-20 17:40           ` Dave Hansen
2026-02-23 17:56             ` Xin Li
2026-02-23 21:34               ` H. Peter Anvin
2026-02-18  8:21 ` [PATCH v3 10/16] x86/msr: Use the alternatives mechanism for RDMSR Juergen Gross
2026-02-18 15:12   ` kernel test robot
2026-02-18 15:48     ` Juergen Gross
2026-02-18  8:21 ` [PATCH v3 11/16] x86/alternatives: Add ALTERNATIVE_4() Juergen Gross
2026-02-18  8:21 ` [PATCH v3 12/16] x86/paravirt: Split off MSR related hooks into new header Juergen Gross
2026-02-18  8:21 ` [PATCH v3 13/16] x86/paravirt: Prepare support of MSR instruction interfaces Juergen Gross
2026-02-18  8:21 ` [PATCH v3 14/16] x86/paravirt: Switch MSR access pv_ops functions to " Juergen Gross
2026-02-18  8:21 ` [PATCH v3 15/16] x86/msr: Reduce number of low level MSR access helpers Juergen Gross
2026-02-18  8:21 ` [PATCH v3 16/16] x86/paravirt: Use alternatives for MSR access with paravirt Juergen Gross
2026-02-18 13:49   ` kernel test robot
2026-02-18 15:49     ` Juergen Gross
2026-02-18 20:37 ` [PATCH v3 00/16] x86/msr: Inline rdmsr/wrmsr instructions H. Peter Anvin
2026-02-19  6:28   ` 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=aZiasvKpOHSaNuQ5@google.com \
    --to=seanjc@google.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jgross@suse.com \
    --cc=justinstitt@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=llvm@lists.linux.dev \
    --cc=mingo@redhat.com \
    --cc=morbo@google.com \
    --cc=nathan@kernel.org \
    --cc=nick.desaulniers+lkml@gmail.com \
    --cc=pbonzini@redhat.com \
    --cc=tglx@kernel.org \
    --cc=x86@kernel.org \
    --cc=xin@zytor.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.