mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Hou Wenlong <houwenlong.hwl@antgroup.com>
To: linux-kernel@vger.kernel.org
Cc: Hou Wenlong <houwenlong.hwl@antgroup.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Andy Lutomirski <luto@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	Rik van Riel <riel@surriel.com>
Subject: [PATCH v2 0/4] x86/mm: Some fixes about global ASID allocation
Date: Tue, 20 Jan 2026 21:44:26 +0800	[thread overview]
Message-ID: <cover.1768900340.git.houwenlong.hwl@antgroup.com> (raw)

During the backporting of the global ASID allocation, I found some
issues with the ASID range size calculations, and I'm not sure if I
misread them.

Firstly, it's just a mathematical calculation. When we describe a range
[a,b] as a closed interval, the size of the range should be 'b - a + 1'.
As noted in the comment, the range for global ASIDs is [TLB_NR_DYN_SIZE,
MAX_ASID_AVAILABLE-1], and the size of the bitmap is also defined as
'MAX_ASID_AVAILABL', Therefore, the size of the range should be
'MAX_ASID_AVAILABLE - TLB_NR_DYN_SIZE'. However, 'global_asid_available'
is assigned the value of 'MAX_ASID_AVAILABLE - TLB_NR_DYN_SIZE - 1',
which means one ASID will never be allocated.

The macro 'MAX_ASID_AVAILABLE', as I understand it, is used to represent
the maximum valid ASID. Thus the available ASID range described in the
comments is [0,MAX_ASID_AVAILABLE], which is a close interval too. So
the acutal size of the range is 'MAX_ASID_AVAILABLE + 1'. But it is
incorrectly used as the size of the bitmap in global ASID allocation,
leading to the maximum ASID being excluded from global ASID allocation.

As referenced in [1], there is an issue: when a smaller ASID is freed
and last_global_asid is not equal to 'MAX_ASID_AVAILABLE-1', the
allocation will fail because the ASID space cannot be reset. This can be
fixed by resetting the ASID space when an ASID rollover occurs,
regardless of the value of 'last_global_asid'.

Additionally, I found that when PTI is off but
'CONFIG_MITIGATION_PAGE_TABLE_ISOLATION' is enabled (which should be
true for broadcast TLB-capable hardware), only half of the ASID space is
available because 'MAX_ASID_AVAILABLE' is defined as 2046. I have made
some changes to expand the entire ASID space for global ASID allocation
when PTI is off, but I haven't covered this in this patchset. I am
considering whether we can align ASID and PCID to make the code clearer
as Rik said in [0].

Note, I have only conducted some basic tests (running the 4096
tlb_flush2_threads tests to trigger ASID rollover) on the AMD platform.

v1: https://lore.kernel.org/lkml/cover.1743250122.git.houwenlong.hwl@antgroup.com

[0]: https://lore.kernel.org/lkml/df4f0ce855b7acd6fc9777457b89359e075a5cbb.camel@surriel.com

v1 -> v2:
  - Add a new patch to fix the allocation failure.
  - Rewrite the commit message and add Reviwed-by tag.

Hou Wenlong (4):
  x86/mm: Correct the actual size of available global ASID range
  x86/mm: Fix wrong judgement in allocate_global_asid()
  x86/mm: Correct the actual size of ASID range
  x86/mm: Reset global ASID space when ASID rollover

 arch/x86/mm/tlb.c | 25 +++++++++++++------------
 1 file changed, 13 insertions(+), 12 deletions(-)


base-commit: d613f96096e48b3646217f006bcccc6ff973c428
--
2.31.1


             reply	other threads:[~2026-01-20 13:44 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-20 13:44 Hou Wenlong [this message]
2026-01-20 13:44 ` [PATCH v2 1/4] x86/mm: Correct the actual size of available global ASID range Hou Wenlong
2026-01-20 17:16   ` Rik van Riel
2026-01-20 13:44 ` [PATCH v2 2/4] x86/mm: Fix wrong judgement in allocate_global_asid() Hou Wenlong
2026-01-20 13:44 ` [PATCH v2 3/4] x86/mm: Correct the actual size of ASID range Hou Wenlong
2026-01-20 13:44 ` [PATCH v2 4/4] x86/mm: Reset global ASID space when ASID rollover Hou Wenlong
2026-01-20 17:24   ` Rik van Riel

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=cover.1768900340.git.houwenlong.hwl@antgroup.com \
    --to=houwenlong.hwl@antgroup.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=peterz@infradead.org \
    --cc=riel@surriel.com \
    --cc=tglx@kernel.org \
    --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

Powered by JetHome