From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6CEF8C02183 for ; Tue, 14 Jan 2025 01:30:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 02DCC6B0085; Mon, 13 Jan 2025 20:30:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EF8926B008A; Mon, 13 Jan 2025 20:30:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D996A6B008C; Mon, 13 Jan 2025 20:30:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id BA95B6B0085 for ; Mon, 13 Jan 2025 20:30:55 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 45CCFA0442 for ; Tue, 14 Jan 2025 01:30:55 +0000 (UTC) X-FDA: 83004328470.20.C9152DA Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) by imf01.hostedemail.com (Postfix) with ESMTP id 88CDB4000E for ; Tue, 14 Jan 2025 01:30:52 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf01.hostedemail.com: domain of riel@shelob.surriel.com designates 96.67.55.147 as permitted sender) smtp.mailfrom=riel@shelob.surriel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736818253; a=rsa-sha256; cv=none; b=3Pd0z+Omq5QqoznjWLEXGiIz2QBTRKDYOg+NljpKyk6fdB4l2FfIZPJGJx8gbWNEgRxel5 RtMWfzMaoeJ3fbjMxblOXLIpYDc4NFutSMRbteCNJKensdExgLtfwFEH71PsR29Auunukb YEF2kLTXd3CzyrL4t+ZncS4S8PgttK8= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf01.hostedemail.com: domain of riel@shelob.surriel.com designates 96.67.55.147 as permitted sender) smtp.mailfrom=riel@shelob.surriel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736818253; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=D/BGdYLtFom1SSSWcZyzpIpPpsBlR3xHeYgtsHi5K0Q=; b=OPxvdR6ZgziSbKLlNn1BmMNiyLUfHlnqA+p0CwWI7hr8GagGYW8HpkjxCuM50Nd7jFjEMG tKr6z1M8kwpOHfVywM7Nuq3kwrt1uVgeksSN4LGXDeBqHh19GS/1C7hULWH8lloNwBYAPk SEXb/nKzQkkAH4B4v95e5+wFXBySuek= 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 1tXVjl-000000003mF-0N49; Mon, 13 Jan 2025 20:28:57 -0500 Message-ID: <6856727624fe88dd4cca3343f6fe8d2919939a2d.camel@surriel.com> Subject: Re: [PATCH v4 11/12] x86/mm: enable AMD translation cache extensions From: Rik van Riel To: Andrew Cooper Cc: akpm@linux-foundation.org, bp@alien8.de, dave.hansen@linux.intel.com, jannh@google.com, kernel-team@meta.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, nadav.amit@gmail.com, peterz@infradead.org, thomas.lendacky@amd.com, x86@kernel.org, zhengqi.arch@bytedance.com Date: Mon, 13 Jan 2025 20:28:57 -0500 In-Reply-To: <09807556-46fe-46ae-ae3f-7083a1b12253@citrix.com> References: <20250112155453.1104139-12-riel@surriel.com> <09807556-46fe-46ae-ae3f-7083a1b12253@citrix.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.54.1 (3.54.1-1.fc41) MIME-Version: 1.0 X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 88CDB4000E X-Stat-Signature: 6jut6rqkiqcuc9a174kh1odx9h9k1qf4 X-Rspam-User: X-HE-Tag: 1736818252-290743 X-HE-Meta: U2FsdGVkX19LnVX2hYNMRFGbOK9k+K+QWoNE0qcWI3Q1hWC4uZVTSMjSz+9o9StdgJKIAHwNPLAXR5zu/AzvlNyk4NhPgiFN1J2nyk9qK1Ch52u/Qr2gW4LAR2YXiyuSAPF3nMYufR9BEDTRmICnDJqc+YJYIZNI9DDFVqZyYMwWUs3fppuVUx43iMOei2ZuUSzNEJ3xF7D4idg+KHf1bVGlvR6iGqd6IHFt6mUvn1e1nLkx/1V7oE/DBPNviVmPOZUpXL9T5r5JkQlMrMSRWbLRGCi/hji70hNlxOYTBw3HNhvttyem0OlYdx/ESs+0ZVTReu1oFpJfKKrj/BBPzEU4ubl08dz82cL52tytKm0si28Qy0JOdQycCRR0WiqWHHtMuDMayHbRg1TSgxQP8P3et+Jgidf2teQ1p+/BROChREqrLyCKKxrCtqw80dfQx9a6rY0ff6DmMelLxoX5LHi2c7H5GUHtQa0SQ2CAt+P50PlsxSjxM5hNp6zPCwHZONaKFypEsy6et+w9ZRvNqAPd084Oc6f0T8oIpm4jjhGFtuAaYeibkMLprD0YE3eL3z1KQti9UQCpgjZNghvzBXPwHPHvNR4UZpHBdLNKBlTUSIgFHhCXzkzWWP/xMeY9ftNpBRyB2r53OUvgbbG15TwArCHb7U49EXI6p119XSXP2VXNr/Mzmk359/w2wqdMEQp8lMUXPQv9FKQxYRH0Mtqe+GCd3hwHyGztuxxJ3uo6A69ITe56y28iowHCrZbhuogrUMZM+gp89DyEDxvxXII7GxxGEry4BSR5UvfGvwNx3GtJKL6fRJbYdqdd7dQRGaOGtUnXK0E1Wcx1SpfE/1FICYtKa397hSiwob6JB8j4A/Yg/Xwq0mC1HVTxgys7T9pM6GjdOKfUCbWZif5XcHToZs0qmTN2eo2GlcS/vm5UYvpzlBF9XEpR2Tpglg/QFJepNpHtvAjQ+JVEVtw 2g4r2uTH 9wMIVDy7PCqBplhCTFAa0wFIi4RE/4P/pSstR/dQsxsEW3hGJ0NkhsmHeFMX5wC4DLuP0mlCmEFa09PPFnVb9qM7Jgmqde/piqKBk/xPRB36ik6aRDRqFPR/OG+uRI/MNe3pzhZ7yBqKG0w1mzwioNId/siMTOCxNTh5h+agKrk8zJcu9I1XFlA82VRPMjPYaPzU3ocrG/c/svYmTp1/MjbXH+GGnP3KHF+Z4i/Uoifc5R2ddMmGs/Zu4Rh2eswTdhxbhnzsz4koozrBc4OhcJ+c8mk9mSdVvoJ52hoYzbYpy7DlsA3TbdgKj71xK8YnxxF2KdStrm4Lyne6kgtGz6sw+5g== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Mon, 2025-01-13 at 11:32 +0000, Andrew Cooper wrote: > > +++ > > b/arch/x86/kernel/cpu/amd.c @@ -1071,6 +1071,9 @@ static void > > init_amd(struct cpuinfo_x86 *c)=C2=A0=20 > > =C2=A0 /* AMD CPUs don't need fencing after x2APIC/TSC_DEADLINE > > MSR writes. */ > > =C2=A0 clear_cpu_cap(c, X86_FEATURE_APIC_MSRS_FENCE); > > + + if (cpu_feature_enabled(X86_FEATURE_INVLPGB)) + > > msr_set_bit(MSR_EFER, _EFER_TCE);=C2=A0 } > > =C2=A0 > > =C2=A0#ifdef CONFIG_X86_32 >=20 > I don't think this is wise.=C2=A0 TCE is orthogonal to INVLPGB. >=20 > Either Linux is safe with TCE turned on, and it should be turned on > everywhere (it goes back to Fam10h CPUs IIRC), or Linux isn't safe > with > TCE turned on, and this needs to depend on some other condition. >=20 > Or, is this a typo and did you mean to check the TCE CPUID bit, > rather > than the INVLPGB CPUID bit? You're right, this should just check against X86_FEATURE_TCE, which I did not realize was a separate feature bit. I've changed this for the next version of the series. Thank you! --=20 All Rights Reversed.