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 B3DD2E77188 for ; Mon, 6 Jan 2025 17:33:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 36BFA6B0092; Mon, 6 Jan 2025 12:33:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 31C4F6B0093; Mon, 6 Jan 2025 12:33:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 20AA46B0095; Mon, 6 Jan 2025 12:33:41 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 0374B6B0092 for ; Mon, 6 Jan 2025 12:33:40 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id AA5C91A014F for ; Mon, 6 Jan 2025 17:33:40 +0000 (UTC) X-FDA: 82977724200.10.55FCF68 Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) by imf24.hostedemail.com (Postfix) with ESMTP id EC82018000C for ; Mon, 6 Jan 2025 17:33:38 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf24.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=1736184819; 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=0hztYLeYjpC6L/I0xwyI5UZj4Xg7xj6HZ9oaX45yCn0=; b=kpTNs6tT8uz6C8usSaoCis9ixpf413ofQFgk24dQEbSiT611qTBYLx5W1oI84U2VojCtBh eDoWzeBkvByOs7If5yw4k9l7C/hlXsqJWV2BsQ/FVs2khgfLn4Pkujo4eLxl9gSGpcuUpD RjE+g3hyv3R05qfjaJhQDdqrfWNNfqQ= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf24.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=1736184819; a=rsa-sha256; cv=none; b=vWbZHel9dopckmJ6Vw6jkF/j+NkNv/U0bxggEWOEGZnFWbWG3vFn63GMRKZGRUKJcr04qb cLfl5W67ylZ3WzeGSZw1wOdF61PUvQLL9d+k+l3/YnuucJbX/DjEEZWLxG+Mvr0weo44qa 9n9O652MGGtXUCxvlinU2s3kyGk68ag= 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 1tUqxy-000000004C7-3kDw; Mon, 06 Jan 2025 12:32:38 -0500 Message-ID: Subject: Re: [PATCH 05/12] x86/mm: add INVLPGB support code From: Rik van Riel To: Dave Hansen , Borislav Petkov Cc: x86@kernel.org, linux-kernel@vger.kernel.org, kernel-team@meta.com, dave.hansen@linux.intel.com, luto@kernel.org, peterz@infradead.org, tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com, akpm@linux-foundation.org, nadav.amit@gmail.com, zhengqi.arch@bytedance.com, linux-mm@kvack.org Date: Mon, 06 Jan 2025 12:32:38 -0500 In-Reply-To: <0de32bbc-66e9-4875-af87-7a2fa2e03e39@intel.com> References: <20241230175550.4046587-1-riel@surriel.com> <20241230175550.4046587-6-riel@surriel.com> <20250102124247.GPZ3aJx8JTJa6PcaOW@fat_crate.local> <0de32bbc-66e9-4875-af87-7a2fa2e03e39@intel.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-Queue-Id: EC82018000C X-Stat-Signature: ydh4we47fypsyx37fzwan7jb6yoms7b8 X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1736184818-997473 X-HE-Meta: U2FsdGVkX1+T4e4Xrx/weTGgzBRRCY4vX/PvaMbscSVsX/n9XvLYOAk/HcHSxUARc7PQyijFXztn5nrL7aN+G1WJutjCt8b7wCmriLTJvCU4AQfwPz8zYAjcBpyQfoERtr57O4b6e7rg6TlZXV0f/baTPY0oPSyjUh/QvuTwuh9/Ul8cuVsymiolxl/qfdOC647AOQSJ/RdNRH/rtbH1UVB71/cWkexV7URcJT0Re546rKdErt9/9DQzeOkHd0r0HTe5RBZ7LM/bnC+nj9FFkzUBpItr/eKB8wUbqDw+9gzJ4fZ+VSCTX5cQldNVMnoX2ynqRX/0RP//r1Dtn/ej1/eQE7QDFCxZbJ8Hn9iBxnGCsohtpNgWWRKKiAgLWg8YqI72tzTYr9A5RU115onjr/BuSbRDE0dqhQ0eblrBgQei40lyqNHRgw3g2xw1IGCD3VuEi+fxwRncQ4J7ao56UcPy4MTrqLGud/LKPyOEGJF7qLtvlP5G5ohbcgmpjK2ichFMW1B6H1rpjOh3P4aalj9UOcjm/rypB12bWzVJwyJs/kFVF6egvPZ0u4+y198cBKXa0lhZ3vFMiY174UDhiP6DBsk7eCRYxMUSjKW39zrqS7Qvgo83yx0k7+U4BZ41FFX7edtuutkyEQlFzkt969zf2mBRNEwp148EcoyZNOmwSkcsHIsE+qbu8BHOL2aCnbYemsrqYqGw6xlkZKUDl+Y6pV/CVdwQHMDgqhn2TFLwwO+o73SRvLa+oVm5MuaUbtQQjNv8JEmbRTO3ml3Qfb1Nq8omq6Wf9wqmYnzZghQT618wz37R0dn15nKnIHN+teyikeJWjr0WvcPi74gdBX/UjQDzsM7J/rVlRZ1WpfgCwzRzll4+yI2U8wGLGm0OPtYJ6sFsCnslPbEcLoTT3FT1FRgMSlXihlucc0VwLnSbpn45s6VDiwBMYGLSHG+zNY1VuvQ3zD9SEhxN6SR odyvk3u+ lCEwGQdvWzZ15Ax+EF/TtBl/ViPgSmd8OUzt6vJNS+jjC3ZmLHmBYk1Qo9KiQ0Cb+Rvm99r09NaD5RT6aRjqKZgMCOPRIgYGjWSYY6pDboocYISpw3v5qX4wOrC0Mc3s9DhWSA255FW4AqsKlA96jwT9jEAxAMkrZjgdbhGKr13mU+ZyduJ7zL/TtJExNXG5gkYVZYLoUULVuCtH19iuSx2NfPQskx+deTPxCW56NPRr+fYtSM9e5b0lB3B1Yfgh2ihboLZGGPGpqbLpLkhQuhd6tjXFyX2yRHoWoIeELXE0k/OSQXp95kxSTHDLB1j2Ai3WqmS99Dmm5WpwvzmH53iMTfg== 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-06 at 08:50 -0800, Dave Hansen wrote: > On 1/2/25 04:42, Borislav Petkov wrote: > > > +#define INVLPGB_VA BIT(0) > > > +#define INVLPGB_PCID BIT(1) > > > +#define INVLPGB_ASID BIT(2) > > > +#define INVLPGB_INCLUDE_GLOBAL BIT(3) > > > +#define INVLPGB_FINAL_ONLY BIT(4) > > > +#define INVLPGB_INCLUDE_NESTED BIT(5) > > Please add only the defines which are actually being used. Ditto > > for the > > functions. >=20 > There's some precedent for defining them all up front, like we did > for > invpcid_flush_*(). >=20 > For INVPCID, there are four variants and two of them got used up > front. > But I get that it's a balancing act between having untested code that > might bitrot and introducing helpers at a time when someone (Rik) is > very likely to get all the variants coded up correctly. >=20 > Rik, how many of these end up being used by the end of the series? >=20 Only invlpgb_flush_single_asid is unused at the end of the series. I'll remove that one. As for the bit flags, those are a hardware interface. I can remove the unused ones, but would like to know why :) --=20 All Rights Reversed.