From: Dave Hansen <dave.hansen@intel.com>
To: Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>
Cc: linux-kernel@vger.kernel.org, Thomas Gleixner <tglx@kernel.org>,
Ingo Molnar <mingo@redhat.com>,
x86@kernel.org, Juergen Gross <jgross@suse.com>,
virtualization@lists.linux.dev
Subject: Re: [PATCH 0/8] x86/msr: Consolidate native/paravirt MSR functions
Date: Tue, 31 Mar 2026 14:37:38 -0700 [thread overview]
Message-ID: <8f630a58-d12a-4e70-8770-c2b51aff50a9@intel.com> (raw)
In-Reply-To: <20260320233319.GZab3ZP1lTfxOmQ4YF@fat_crate.local>
On 3/20/26 16:33, Borislav Petkov wrote:
> I *think* this is only a naming issue and with "raw_" you probably wanna say
> "native_or_paravirt_" depending on the ifdeffery... but shorter...
>
> If so, I wouldn't call it "raw". I'd say
>
> xx_read_msr()
> xx_write_msr()
How about we just stick with the paravirt naming?
We're completely used to having stubs that do nothing for paravirt.
We're also used to paravirt_foo() ending up *eventually* doing
native_foo(). So, why not just short-circuit that at the compiler and do:
/* Short-circuit the paravirt infrastructure when it is disabled: */
#define paravirt_read_msr native_read_msr
#define paravirt_read_msr_safe native_read_msr_safe
#define paravirt_write_msr native_write_msr
#define paravirt_write_msr_safe native_write_msr_safe
I'll hack something together and see if I hate it.
prev parent reply other threads:[~2026-03-31 21:37 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-20 19:03 [PATCH 0/8] x86/msr: Consolidate native/paravirt MSR functions Dave Hansen
2026-03-20 19:03 ` [PATCH 1/8] x86/msr: Use "raw_" names for calls to native_* functions Dave Hansen
2026-03-20 19:03 ` [PATCH 2/8] x86/msr: Consolidate rdmsr() definitions Dave Hansen
2026-03-20 19:03 ` [PATCH 3/8] x86/msr: Consolidate rdmsr_safe() implementations Dave Hansen
2026-03-20 19:03 ` [PATCH 4/8] x86/msr: Consolidate rdmsrq() implementations Dave Hansen
2026-03-20 19:03 ` [PATCH 5/8] x86/msr: Consolidate {rd,wr}msr[q]_safe() implementations Dave Hansen
2026-03-20 19:03 ` [PATCH 6/8] x86/msr: Consolidate rdpmc() implementations Dave Hansen
2026-03-20 19:03 ` [PATCH 7/8] x86/msr: Remove old crusty comment Dave Hansen
2026-03-20 19:03 ` [PATCH 8/8] x86/msr: Remove duplicate #include Dave Hansen
2026-03-20 23:33 ` [PATCH 0/8] x86/msr: Consolidate native/paravirt MSR functions Borislav Petkov
2026-03-20 23:39 ` Dave Hansen
2026-03-21 6:23 ` Jürgen Groß
2026-03-23 15:22 ` Juergen Gross
2026-03-31 21:41 ` Dave Hansen
2026-04-01 6:12 ` Jürgen Groß
2026-03-31 21:37 ` Dave Hansen [this message]
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=8f630a58-d12a-4e70-8770-c2b51aff50a9@intel.com \
--to=dave.hansen@intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=jgross@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@kernel.org \
--cc=virtualization@lists.linux.dev \
--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 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.