From: Dave Hansen <dave.hansen@intel.com>
To: Kevin Loughlin <kevinloughlin@google.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
linux-kernel@vger.kernel.org, tglx@linutronix.de,
mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
x86@kernel.org, hpa@zytor.com, seanjc@google.com,
pbonzini@redhat.com, kai.huang@intel.com, ubizjak@gmail.com,
jgross@suse.com, kvm@vger.kernel.org, pgonda@google.com,
sidtelang@google.com, mizhang@google.com, rientjes@google.com,
manalinandan@google.com, szy0127@sjtu.edu.cn
Subject: Re: [PATCH v4 1/2] x86, lib: Add WBNOINVD helper functions
Date: Wed, 22 Jan 2025 16:33:04 -0800 [thread overview]
Message-ID: <3dd183fa-df95-487e-a2e9-73579fa160be@intel.com> (raw)
In-Reply-To: <CAGdbjm+syon_W0W_oEiDJBKu4s5q9JS9cKyPmPoqDAzeyMJf3Q@mail.gmail.com>
On 1/22/25 16:06, Kevin Loughlin wrote:
>> BTW, I don't think you should be compelled to use alternative() as
>> opposed to a good old:
>>
>> if (cpu_feature_enabled(X86_FEATURE_WBNOINVD))
>> ...
> Agreed, though I'm leaving as alternative() for now (both because it
> results in fewer checks and because that's what is used in the rest of
> the file); please holler if you prefer otherwise. If so, my slight
> preference in that case would be to update the whole file
> stylistically in a separate commit.
alternative() can make a _lot_ of sense. It's extremely compact in the
code it generates. It messes with compiler optimization, of course, just
like any assembly. But, overall, it's great.
In this case, though, we don't care one bit about code generation or
performance. We're running the world's slowest instruction from an IPI.
As for consistency, special_insns.h is gloriously inconsistent. But only
two instructions use alternatives, and they *need* the asm syntax
because they're passing registers and meaningful constraints in.
The wbinvds don't get passed registers and their constraints are
trivial. This conditional:
alternative_io(".byte 0x3e; clflush %0",
".byte 0x66; clflush %0",
X86_FEATURE_CLFLUSHOPT,
"+m" (*(volatile char __force *)__p));
could be written like this:
if (cpu_feature_enabled(X86_FEATURE_CLFLUSHOPT))
asm volatile(".byte 0x3e; clflush %0",
"+m" (*(volatile char __force *)__p));
else
asm volatile(".byte 0x66; clflush %0",
"+m" (*(volatile char __force *)__p));
But that's _actively_ ugly. alternative() syntax there makes sense.
Here, it's not ugly at all:
if (cpu_feature_enabled(X86_FEATURE_WBNOINVD))
asm volatile(".byte 0xf3,0x0f,0x09\n\t": : :"memory");
else
wbinvd();
and it's actually more readable with alternative() syntax.
So, please just do what makes the code look most readable. Performance
and consistency aren't important. I see absolutely nothing wrong with:
static __always_inline void raw_wbnoinvd(void)
{
asm volatile(".byte 0xf3,0x0f,0x09\n\t": : :"memory");
}
void wbnoinvd(void)
{
if (cpu_feature_enabled(X86_FEATURE_WBNOINVD))
raw_wbnoinvd();
else
wbinvd();
}
... except the fact that cpu_feature_enabled() kinda sucks and needs
some work, but that's a whole other can of worms we can leave closed today.
next prev parent reply other threads:[~2025-01-23 0:33 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-09 22:55 [PATCH v2 0/2] KVM: SEV: Prefer WBNOINVD over WBINVD for cache maintenance efficiency Kevin Loughlin
2025-01-09 22:55 ` [PATCH v2 1/2] x86, lib: Add WBNOINVD helper functions Kevin Loughlin
2025-01-09 22:55 ` [PATCH v2 2/2] KVM: SEV: Prefer WBNOINVD over WBINVD for cache maintenance efficiency Kevin Loughlin
2025-01-10 8:23 ` Kirill A. Shutemov
2025-01-13 18:47 ` Kevin Loughlin
2025-01-14 7:50 ` Kirill A. Shutemov
2025-01-14 16:12 ` Sean Christopherson
2025-01-17 22:20 ` Kevin Loughlin
2025-01-13 21:46 ` Mingwei Zhang
2025-01-22 0:13 ` [PATCH v3 0/2] " Kevin Loughlin
2025-01-22 0:13 ` [PATCH v3 1/2] x86, lib: Add WBNOINVD helper functions Kevin Loughlin
2025-01-22 0:30 ` Dave Hansen
2025-01-22 0:30 ` Dave Hansen
2025-01-22 1:14 ` Kevin Loughlin
2025-01-22 0:13 ` [PATCH v3 2/2] KVM: SEV: Prefer WBNOINVD over WBINVD for cache maintenance efficiency Kevin Loughlin
2025-01-22 1:34 ` [PATCH v4 0/2] " Kevin Loughlin
2025-01-22 1:34 ` [PATCH v4 1/2] x86, lib: Add WBNOINVD helper functions Kevin Loughlin
2025-01-22 7:32 ` Kirill A. Shutemov
2025-01-22 19:39 ` Tom Lendacky
2025-01-22 23:16 ` Dave Hansen
2025-01-23 0:06 ` Kevin Loughlin
2025-01-23 0:33 ` Dave Hansen [this message]
2025-01-23 0:58 ` Kevin Loughlin
2025-01-23 1:17 ` Kevin Loughlin
2025-01-22 1:34 ` [PATCH v4 2/2] KVM: SEV: Prefer WBNOINVD over WBINVD for cache maintenance efficiency Kevin Loughlin
2025-01-23 0:24 ` [PATCH v5 0/2] " Kevin Loughlin
2025-01-23 0:24 ` [PATCH v5 1/2] x86, lib: Add WBNOINVD helper functions Kevin Loughlin
2025-01-23 0:36 ` Dave Hansen
2025-01-23 0:55 ` Kevin Loughlin
2025-01-23 0:24 ` [PATCH v5 2/2] KVM: SEV: Prefer WBNOINVD over WBINVD for cache maintenance efficiency Kevin Loughlin
2025-02-26 1:30 ` Sean Christopherson
2025-02-01 0:02 ` [PATCH v6 0/2] " Kevin Loughlin
2025-02-01 0:02 ` [PATCH v6 1/2] x86, lib: Add WBNOINVD helper functions Kevin Loughlin
2025-02-04 16:59 ` Tom Lendacky
2025-02-26 1:26 ` Sean Christopherson
2025-02-26 14:22 ` Borislav Petkov
2025-02-01 0:02 ` [PATCH v6 2/2] KVM: SEV: Prefer WBNOINVD over WBINVD for cache maintenance efficiency Kevin Loughlin
2025-02-04 17:00 ` Tom Lendacky
2025-02-26 1:35 ` [PATCH v5 0/2] " Sean Christopherson
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=3dd183fa-df95-487e-a2e9-73579fa160be@intel.com \
--to=dave.hansen@intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=kai.huang@intel.com \
--cc=kevinloughlin@google.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=manalinandan@google.com \
--cc=mingo@redhat.com \
--cc=mizhang@google.com \
--cc=pbonzini@redhat.com \
--cc=pgonda@google.com \
--cc=rientjes@google.com \
--cc=seanjc@google.com \
--cc=sidtelang@google.com \
--cc=szy0127@sjtu.edu.cn \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=ubizjak@gmail.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