From: Dave Hansen <dave.hansen@intel.com>
To: Tom Lendacky <thomas.lendacky@amd.com>,
linux-kernel@vger.kernel.org, x86@kernel.org
Cc: Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Nadav Amit <nadav.amit@gmail.com>,
Rik van Riel <riel@surriel.com>
Subject: Re: [PATCH] x86/mm: Skip global ASID broadcast TLB flush when PCID is disabled
Date: Wed, 13 May 2026 11:29:39 -0700 [thread overview]
Message-ID: <c71ab05a-f02d-466b-8007-5b5c5f344249@intel.com> (raw)
In-Reply-To: <6d67675458bfe4ac1ed792beec3ad93dd45848c7.1778695885.git.thomas.lendacky@amd.com>
On 5/13/26 11:11, Tom Lendacky wrote:
> Booting with "nopcid" clears X86_FEATURE_PCID in x86_nopcid_setup(),
> but X86_FEATURE_INVLPGB is left intact. On AMD CPUs that support
> INVLPGB, broadcast TLB flushing remains active even though CR4.PCIDE
> is off.
>
> There are two checks that decide whether the global ASID code runs,
> mm_global_asid() and consider_global_asid(), that key off of the
> X86_FEATURE_INVLPGB feature. Once an mm becomes active on more than
> three CPUs, consider_global_asid() assigns it a global ASID, after which
> flush_tlb_mm_range() takes the broadcast_tlb_flush() path. The
> broadcast_tlb_flush() function calls invlpgb_flush_single_pcid_nosync() or
> invlpgb_flush_user_nr_nosync() with kern_pcid(asid), which expands to
> (asid + 1). Both helpers set INVLPGB_FLAG_PCID and place the non-zero
> PCID into EDX[31:16] of the INVLPGB instruction. Issuing INVLPGB with
> INVLPGB_FLAG_PCID (RAX[1]) and a non-zero PCID (RDX[27:16]) while
> CR4.PCIDE is not set results in a #GP:
Just to be clear, the APM says there's a #GP if: "CR4.PCID =0 and
EDX[PCID] is not zero." I don't think INVLPGB_FLAG_PCID (RAX[1]) is
supposed to play a role.
Although the architecture doesn't care, it's also at least a _little_
funky to be setting INVLPGB_FLAG_PCID here:
u8 flags = INVLPGB_FLAG_PCID | INVLPGB_FLAG_VA;
when PCIDs are disabled.
How about we add a:
static const struct cpuid_dep cpuid_deps[] = {
...
{ X86_FEATURE_INVLPGB, X86_FEATURE_PCID },
and be done with it?
If you don't have PCIDs, you don't get INVLPGB at all. Yes, you could
theoretically use INVLPGB for kernel mappings without PCIDs. But all
actual CPUs that have INVLPGB presumably also have PCID support.
Then we never have to worry about cases where INVLPGB==1, but PCID==0 at
*all*.
next prev parent reply other threads:[~2026-05-13 18:29 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-13 18:11 Tom Lendacky
2026-05-13 18:13 ` Tom Lendacky
2026-05-13 18:29 ` Dave Hansen [this message]
2026-05-14 20:24 ` Tom Lendacky
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=c71ab05a-f02d-466b-8007-5b5c5f344249@intel.com \
--to=dave.hansen@intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=nadav.amit@gmail.com \
--cc=peterz@infradead.org \
--cc=riel@surriel.com \
--cc=tglx@kernel.org \
--cc=thomas.lendacky@amd.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
all inboxes | Powered by JetHome®