From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 54B302B2CF for ; Sun, 22 Dec 2024 21:25:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=96.67.55.147 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734902770; cv=none; b=hVVYEo2DJP8ybiFwifB9UPF33L1yPktcs1SBInb/f74lihoMu3YsXMFjTzMrQdOs32DaQvjoqoq5FPxufOTqHrRQk0nNdfpwD+99GMAc8ug2ps6/sOZNVdEjkymucadole41DwmImPFlqgKZ3od/zxbQcTg87HexEXajiBm4xUc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734902770; c=relaxed/simple; bh=S0cjTEL4bZpqqb2+9K3KhNS6tKGjczG8brwVMBhh918=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=LPB3mYj6ola1M+BOhowl3Fd67Xe/AaXKyVIj+H6sXc15JL4UNm6ZeEEjAkj/jhezF7XAZJn40Qcv6pE4VEKKrfbV2Lkzsfur9ogmKE9++NTi7IlYuKW8tl8lJR2gv/eK89C2W62wAm8PqvlIfsqL2tzI7KKANgbWP0L3Yj3R6gM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=surriel.com; spf=pass smtp.mailfrom=shelob.surriel.com; arc=none smtp.client-ip=96.67.55.147 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=surriel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=shelob.surriel.com Received: from fangorn.home.surriel.com ([10.0.13.7]) by shelob.surriel.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.97.1) (envelope-from ) id 1tPTQz-000000005rp-0rn8; Sun, 22 Dec 2024 16:24:21 -0500 Message-ID: <4b0e7c3b91c5d59f8081c56485cfec79b2ea5a92.camel@surriel.com> Subject: Re: [PATCH 03/10] x86,mm: add INVLPGB support code From: Rik van Riel To: Peter Zijlstra Cc: x86@kernel.org, linux-kernel@vger.kernel.org, kernel-team@meta.com, dave.hansen@linux.intel.com, luto@kernel.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, hpa@zytor.com, akpm@linux-foundation.org Date: Sun, 22 Dec 2024 16:24:20 -0500 In-Reply-To: <20241222110509.GS11133@noisy.programming.kicks-ass.net> References: <20241222040717.3096835-1-riel@surriel.com> <20241222040717.3096835-4-riel@surriel.com> <20241222110509.GS11133@noisy.programming.kicks-ass.net> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.54.1 (3.54.1-1.fc41) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Sender: riel@surriel.com On Sun, 2024-12-22 at 12:05 +0100, Peter Zijlstra wrote: > On Sat, Dec 21, 2024 at 11:06:35PM -0500, Rik van Riel wrote: >=20 > > +static inline void __invlpgb(unsigned long asid, unsigned long > > pcid, unsigned long addr, > > + =C2=A0=C2=A0=C2=A0 int extra_count, bool pmd_stride, > > unsigned long flags) > > +{ > > + u64 rax =3D addr | flags; > > + u32 ecx =3D (pmd_stride << 31) | extra_count; > > + u32 edx =3D (pcid << 16) | asid; > > + > > + /* > > + * The memory clobber is because the whole point is to > > invalidate > > + * stale TLB entries and, especially if we're flushing > > global > > + * mappings, we don't want the compiler to reorder any > > subsequent > > + * memory accesses before the TLB flush. > > + */ > > + asm volatile("invlpgb" : : "a" (rax), "c" (ecx), "d" > > (edx)); >=20 > What memory clobber? Is "memory" gone missing? I'm not even sure where that comment came from any more. We do not need any barriers here, because one of the big points of INVLPGB is that the flush is kicked off asynchronously, and flushes may end up being done out of order, many can be pending simultaneously, etc. The sync point is the TLBSYNC instruction. I removed that comment. --=20 All Rights Reversed.