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 C7FE3E7718B for ; Wed, 25 Dec 2024 14:50:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 97B9C6B007B; Wed, 25 Dec 2024 09:50:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 92B0E6B0083; Wed, 25 Dec 2024 09:50:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7F2806B0085; Wed, 25 Dec 2024 09:50:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 615336B007B for ; Wed, 25 Dec 2024 09:50:37 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 0EEC51C6C0D for ; Wed, 25 Dec 2024 14:50:37 +0000 (UTC) X-FDA: 82933766412.30.12AA036 Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) by imf13.hostedemail.com (Postfix) with ESMTP id 486CA20007 for ; Wed, 25 Dec 2024 14:49:56 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf13.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=1735138216; a=rsa-sha256; cv=none; b=lo47RUA74FgQqFLKfI8glBj0mY0HiMcB0C+K6nki+Q0HExlDCYOLMyDd5cwHjESkMnqQv/ f8NHACSmKUrOR9UrHaVXDRsUVyJ3ihQx/L9A3PCd/RZq/lJFk3e79HSErubb+Cnqnb3hV4 rkH8fbOzrO/eng+jzO3fX0/wMTXL6Dw= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf13.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=1735138216; 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=lkCm6LOsNRpKndVyxEkkdsl82NHdGOxAh0Rgqb3XKTU=; b=5gYoOwRO9aaSIDZ9g0E/y2OfAZ3tcBxrS3ExhIE/KqaBuJNGBDt0UKiyLYwr5aipxrl8v/ aG+20ei7c4MJWY4FUBNwB6bywbGCbKY4ZBZgTe+182aLXCcLZ1VVBtpfdKXuVyvdwt71Bf MYNb3qJVGQidH3Jq4qy/7NcpWQOZZnk= 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 1tQSga-000000006fM-3AIy; Wed, 25 Dec 2024 09:48:32 -0500 Message-ID: Subject: Re: [RFC PATCH v2 00/11] AMD broadcast TLB invalidation From: Rik van Riel To: Michael Kelley , "x86@kernel.org" Cc: "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" , "bp@alien8.de" , "hpa@zytor.com" , "akpm@linux-foundation.org" , "linux-mm@kvack.org" Date: Wed, 25 Dec 2024 09:48:32 -0500 In-Reply-To: References: <20241223025751.3268975-1-riel@surriel.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-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 486CA20007 X-Stat-Signature: 3p9pcjj68ud18drhc91zqyfmd6cijhrd X-HE-Tag: 1735138196-259568 X-HE-Meta: U2FsdGVkX18VWH/Q8H0+URZYPdNpYgal0kIg/7KuX9pq0nX6mMKb6asZ32wZNuwNw7pYcPina7K6RrPJ0pJ9g31WuoHHhTzAVnginxq/4pDM8h2p4bR6sbNCCEKHLaZQEfIch4/n0NOfkjTCfyWNle309uhoV3+gfOkZ0V21nfr4lii+6ZxlZtu3htThY5nbc6Ca2SXhBYXyV24azRqwOudnYGcUXgZwdtw6mt7zDPi8a3ipM1Hrps++rDqg4HavwatNz2DQe9g5JIAYq7Xfs4nP88SC4TgDc8GjRohuh7pgcOTBX7Oo1841GpYt2ZFh7SZmSx8Pxceji/nth91fkvzxjypV5hD8VqBrK1KwWkPgBa7lo0x3EERh6Vpl1BcqJIiGdnpvVD6Udj7Q/oMgtezgPdMhx4byFlrvqWs5j3Rxbxr7dS+uDmarrKeniXUVYiX/iZ3OuQ1wEQNIUaK2cuFY18bT3TDm56TMGfJJySCL2uNVE95F/ObhD4q4JaZdFSmoIYN70rIrmHYF2ZrpcWrPkI4dz78av6UlkzWtiaHhr+Sa/rag4iCTmX/SHuYynwJ0yv3zLjLqsN4TT4t/M+iYtctbXc1MaceWdFxWoZw7SskQWLrNtQA/lPOu6CmCVCmPZCgBEc7F4Z4aUJAaCflcvqcOonDYiWqEKa6Ripv/eYfCAeycmJc2+8gU6/vnMH93m+OoBZr9HuH2N2jII14jxGCmJi3SGkemyPSuvHbH3s9ch0a0Qdig4esXQtWNcuS39HSGFKGiEQ++3lX28wkg92dT/5G7WiG9mLRWLeQ8y96Py6ut0c8qKCJrorNbmwyQjthFNWT2bO1NHcAlHKfY9S6mVpxNpUwEQbQGMFDTQcDk+fYuBzc3ZNY9ml+8eZo5s9Hc1UVXuL8Q1QIOhvvl6faEEp9716rHhh9vyyILMVcuciPqvhExSCYtKQgPP86esEYfnzL/N7W2p68 M2vCIXLi /6euBncbJ/qwzUgHdU8S9oyI8oB8dek6b46z3nPE6WWiQz97ZrWtOZPTYP0sQJRmad0P/cOfKPQZ5WYsVoYN3g6S67S29UT2lpsby/DfyGKqgv36XoyKX32Jh2ee+o+AYe9QfA0a4AwZcCX7i1RarW+GGt+5ln1itmghE2B7UUVhcg4zG/bsmER0o0Y/JH7AUaT9FIq86wW5us40bT53Fp8i0fzCkSnf4/lMRiY9AjrYvTYI37HE8vqhKMmxAoIX83eLjsT/sR6RlwLM4GAldxrAyr/k/B9/zQCJ/XGM8BAo6MmELF/xlkthB/YLfzbY1uETq6GU1a9+ndLC7UwC7ObVKrZe/zne6RyFLRrK5xErIE1U= 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 Tue, 2024-12-24 at 18:08 +0000, Michael Kelley wrote: > From: riel@surriel.com=C2=A0 Sent: Sunday, December 22, > 2024 6:55 PM >=20 > >=20 > > Add support for broadcast TLB invalidation using AMD's INVLPGB > > instruction. >=20 > > This allows the kernel to invalidate TLB entries on remote CPUs > > without > > needing to send IPIs, without having to wait for remote CPUs to > > handle > > those interrupts, and with less interruption to what was running on > > those CPUs. > >=20 > > Because x86 PCID space is limited, and there are some very large > > systems out there, broadcast TLB invalidation is only used for > > processes that are active on 3 or more CPUs, with the threshold > > being gradually increased the more the PCID space gets exhausted. >=20 > Rik -- >=20 > What is this patch set's expectation about INVLPGB and TLBSYNC > availability and usage in a VM? I see that INVLPGB and TLBYSNC > behavior in a VM is spec'ed in the AMD Programmer's Manual, but > I wonder about their impact in a multi-tenant host like in a public > cloud environment. And given what this patch set does in assigning > global ASIDs, should X86_FEATURE_INVLPGB be disabled if > running in a VM where the hypervisor for whatever reason has > enabled INVLPGB/TLBSYNC in its VMs? >=20 This patch series enables bare metal INVLPGB functionality. Virtual machines should probably not expose the INVPLGB CPUID feature bit to guests, since virtual machine invalidation seems to work differently than bare metal invalidation. For one, the ASID seems to actually mean something in SVM context, while trying to use the ASID in bare metal blows up :) --=20 All Rights Reversed.