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 5C8C5C02182 for ; Tue, 21 Jan 2025 17:14:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C6FB46B0085; Tue, 21 Jan 2025 12:14:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BF8826B0088; Tue, 21 Jan 2025 12:14:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A4C4F6B0089; Tue, 21 Jan 2025 12:14:37 -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 8480A6B0085 for ; Tue, 21 Jan 2025 12:14:37 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 3CABC46992 for ; Tue, 21 Jan 2025 17:14:37 +0000 (UTC) X-FDA: 83032108194.21.22E7F12 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.15]) by imf03.hostedemail.com (Postfix) with ESMTP id 847D72000C for ; Tue, 21 Jan 2025 17:14:34 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=f6E8gzF4; spf=pass (imf03.hostedemail.com: domain of dave.hansen@intel.com designates 192.198.163.15 as permitted sender) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1737479675; h=from:from: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:dkim-signature; bh=DeoSeimc9tkIzxIcqLWLnZiP8dnCmwdA276i/I2b4do=; b=8DnGdtV9faCLghO27yEiS0yLTUZl86fGVwf/pJuvZJULDk42UwAwO4ZjbCBsL6qE92yb2N LH7JrP5E2wcD7fnKbTjGQDI67CgbDkoZqOQXkzIRp3Ed3HW+D61GkSKt8Jnb9xfv0HwiVf OEp/3ls3rvzSKreb12ufm3Fdb3W9ESY= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=f6E8gzF4; spf=pass (imf03.hostedemail.com: domain of dave.hansen@intel.com designates 192.198.163.15 as permitted sender) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1737479675; a=rsa-sha256; cv=none; b=1xgMf70u6qrIlpj1BDXJznhCRMFhZn//27zemEsXU8TbY3ez0tagrvQTEf6u1cYKSNLxey O1yQOSIVQWktlnh42s1MJt6YRikacVH3bx+qxKt0DWQkuF6mPqutTeH6v+rlORnK97Vy4z ZAHG8s28QJg05x80UfDyhZhm/Yb1TPc= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1737479675; x=1769015675; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=DeoSeimc9tkIzxIcqLWLnZiP8dnCmwdA276i/I2b4do=; b=f6E8gzF4LlgdK2h7fMD3tnBBTm0rKGE36oXknbaRMQzuUNIWWiZti8f9 Y2lSnjOtf+E5v1yRDMougMTErNHrar+lJzB7TJijtlCZZIvkvxEWK3xgl FN0uLehdGAQ3ZYi8KCud+5GLAhdSxkS7n9Gqf0/gWpT3RcpY131y+ttDs oXUw+lZP/tWtLrRi3pq1yUjJfB/WC9EjlY9uonoG1QeXU7hv2s5Co7WYF V+vm+25fO/UvwVyNuq4Nrqd6x55jq86zUEdzR8Ofx2GqSZu2XIE1u97pU QkD/vdQgrT+83TJeZ7M3sj++nmEsn1Xcz2VrqYLcNvfgJHvCVA0xz/guS A==; X-CSE-ConnectionGUID: JdiP4ROPTGyvXyjLGlRdHQ== X-CSE-MsgGUID: I3kbSdGaQ8igyKIw3Ut12g== X-IronPort-AV: E=McAfee;i="6700,10204,11322"; a="38070862" X-IronPort-AV: E=Sophos;i="6.13,222,1732608000"; d="scan'208";a="38070862" Received: from fmviesa008.fm.intel.com ([10.60.135.148]) by fmvoesa109.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Jan 2025 09:14:33 -0800 X-CSE-ConnectionGUID: Lbc8nTfpQB6esZn9hjwNXQ== X-CSE-MsgGUID: IMmYhpiMRdi7jGiC6o6E5A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.13,222,1732608000"; d="scan'208";a="106978906" Received: from gargmani-mobl1.amr.corp.intel.com (HELO [10.124.222.89]) ([10.124.222.89]) by fmviesa008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Jan 2025 09:14:32 -0800 Message-ID: <01cba8ef-b68f-4074-9a7b-7258eaee3893@intel.com> Date: Tue, 21 Jan 2025 09:14:32 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 00/12] AMD broadcast TLB invalidation To: Michael Kelley , "riel@surriel.com" , "x86@kernel.org" Cc: "linux-kernel@vger.kernel.org" , "bp@alien8.de" , "peterz@infradead.org" , "dave.hansen@linux.intel.com" , "zhengqi.arch@bytedance.com" , "nadav.amit@gmail.com" , "thomas.lendacky@amd.com" , "kernel-team@meta.com" , "linux-mm@kvack.org" , "akpm@linux-foundation.org" , "jannh@google.com" , "andrew.cooper3@citrix.com" References: <20250116023127.1531583-1-riel@surriel.com> From: Dave Hansen Content-Language: en-US Autocrypt: addr=dave.hansen@intel.com; keydata= xsFNBE6HMP0BEADIMA3XYkQfF3dwHlj58Yjsc4E5y5G67cfbt8dvaUq2fx1lR0K9h1bOI6fC oAiUXvGAOxPDsB/P6UEOISPpLl5IuYsSwAeZGkdQ5g6m1xq7AlDJQZddhr/1DC/nMVa/2BoY 2UnKuZuSBu7lgOE193+7Uks3416N2hTkyKUSNkduyoZ9F5twiBhxPJwPtn/wnch6n5RsoXsb ygOEDxLEsSk/7eyFycjE+btUtAWZtx+HseyaGfqkZK0Z9bT1lsaHecmB203xShwCPT49Blxz VOab8668QpaEOdLGhtvrVYVK7x4skyT3nGWcgDCl5/Vp3TWA4K+IofwvXzX2ON/Mj7aQwf5W iC+3nWC7q0uxKwwsddJ0Nu+dpA/UORQWa1NiAftEoSpk5+nUUi0WE+5DRm0H+TXKBWMGNCFn c6+EKg5zQaa8KqymHcOrSXNPmzJuXvDQ8uj2J8XuzCZfK4uy1+YdIr0yyEMI7mdh4KX50LO1 pmowEqDh7dLShTOif/7UtQYrzYq9cPnjU2ZW4qd5Qz2joSGTG9eCXLz5PRe5SqHxv6ljk8mb ApNuY7bOXO/A7T2j5RwXIlcmssqIjBcxsRRoIbpCwWWGjkYjzYCjgsNFL6rt4OL11OUF37wL QcTl7fbCGv53KfKPdYD5hcbguLKi/aCccJK18ZwNjFhqr4MliQARAQABzUVEYXZpZCBDaHJp c3RvcGhlciBIYW5zZW4gKEludGVsIFdvcmsgQWRkcmVzcykgPGRhdmUuaGFuc2VuQGludGVs LmNvbT7CwXgEEwECACIFAlQ+9J0CGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEGg1 lTBwyZKwLZUP/0dnbhDc229u2u6WtK1s1cSd9WsflGXGagkR6liJ4um3XCfYWDHvIdkHYC1t MNcVHFBwmQkawxsYvgO8kXT3SaFZe4ISfB4K4CL2qp4JO+nJdlFUbZI7cz/Td9z8nHjMcWYF IQuTsWOLs/LBMTs+ANumibtw6UkiGVD3dfHJAOPNApjVr+M0P/lVmTeP8w0uVcd2syiaU5jB aht9CYATn+ytFGWZnBEEQFnqcibIaOrmoBLu2b3fKJEd8Jp7NHDSIdrvrMjYynmc6sZKUqH2 I1qOevaa8jUg7wlLJAWGfIqnu85kkqrVOkbNbk4TPub7VOqA6qG5GCNEIv6ZY7HLYd/vAkVY E8Plzq/NwLAuOWxvGrOl7OPuwVeR4hBDfcrNb990MFPpjGgACzAZyjdmYoMu8j3/MAEW4P0z F5+EYJAOZ+z212y1pchNNauehORXgjrNKsZwxwKpPY9qb84E3O9KYpwfATsqOoQ6tTgr+1BR CCwP712H+E9U5HJ0iibN/CDZFVPL1bRerHziuwuQuvE0qWg0+0SChFe9oq0KAwEkVs6ZDMB2 P16MieEEQ6StQRlvy2YBv80L1TMl3T90Bo1UUn6ARXEpcbFE0/aORH/jEXcRteb+vuik5UGY 5TsyLYdPur3TXm7XDBdmmyQVJjnJKYK9AQxj95KlXLVO38lczsFNBFRjzmoBEACyAxbvUEhd GDGNg0JhDdezyTdN8C9BFsdxyTLnSH31NRiyp1QtuxvcqGZjb2trDVuCbIzRrgMZLVgo3upr MIOx1CXEgmn23Zhh0EpdVHM8IKx9Z7V0r+rrpRWFE8/wQZngKYVi49PGoZj50ZEifEJ5qn/H Nsp2+Y+bTUjDdgWMATg9DiFMyv8fvoqgNsNyrrZTnSgoLzdxr89FGHZCoSoAK8gfgFHuO54B lI8QOfPDG9WDPJ66HCodjTlBEr/Cwq6GruxS5i2Y33YVqxvFvDa1tUtl+iJ2SWKS9kCai2DR 3BwVONJEYSDQaven/EHMlY1q8Vln3lGPsS11vSUK3QcNJjmrgYxH5KsVsf6PNRj9mp8Z1kIG qjRx08+nnyStWC0gZH6NrYyS9rpqH3j+hA2WcI7De51L4Rv9pFwzp161mvtc6eC/GxaiUGuH BNAVP0PY0fqvIC68p3rLIAW3f97uv4ce2RSQ7LbsPsimOeCo/5vgS6YQsj83E+AipPr09Caj 0hloj+hFoqiticNpmsxdWKoOsV0PftcQvBCCYuhKbZV9s5hjt9qn8CE86A5g5KqDf83Fxqm/ vXKgHNFHE5zgXGZnrmaf6resQzbvJHO0Fb0CcIohzrpPaL3YepcLDoCCgElGMGQjdCcSQ+Ci FCRl0Bvyj1YZUql+ZkptgGjikQARAQABwsFfBBgBAgAJBQJUY85qAhsMAAoJEGg1lTBwyZKw l4IQAIKHs/9po4spZDFyfDjunimEhVHqlUt7ggR1Hsl/tkvTSze8pI1P6dGp2XW6AnH1iayn yRcoyT0ZJ+Zmm4xAH1zqKjWplzqdb/dO28qk0bPso8+1oPO8oDhLm1+tY+cOvufXkBTm+whm +AyNTjaCRt6aSMnA/QHVGSJ8grrTJCoACVNhnXg/R0g90g8iV8Q+IBZyDkG0tBThaDdw1B2l asInUTeb9EiVfL/Zjdg5VWiF9LL7iS+9hTeVdR09vThQ/DhVbCNxVk+DtyBHsjOKifrVsYep WpRGBIAu3bK8eXtyvrw1igWTNs2wazJ71+0z2jMzbclKAyRHKU9JdN6Hkkgr2nPb561yjcB8 sIq1pFXKyO+nKy6SZYxOvHxCcjk2fkw6UmPU6/j/nQlj2lfOAgNVKuDLothIxzi8pndB8Jju KktE5HJqUUMXePkAYIxEQ0mMc8Po7tuXdejgPMwgP7x65xtfEqI0RuzbUioFltsp1jUaRwQZ MTsCeQDdjpgHsj+P2ZDeEKCbma4m6Ez/YWs4+zDm1X8uZDkZcfQlD9NldbKDJEXLIjYWo1PH hYepSffIWPyvBMBTW2W5FRjJ4vLRrJSUoEfJuPQ3vW9Y73foyo/qFoURHO48AinGPZ7PC7TF vUaNOTjKedrqHkaOcqB185ahG2had0xnFsDPlx5y In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 847D72000C X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: tbmuzyiks6s3sywfjrki9yaatn9psmfa X-HE-Tag: 1737479674-321133 X-HE-Meta: U2FsdGVkX1/2vSoAESra9lSNvkfwz9yMB0FXltyqXdWjD5tKf4DUbW9CT8dVXmisfA1eJOqp4DJGketFn/5z7qJj09SJpEjgqiWwd5GNtKNPdmHvPSKdOWTRJBvG5v0M7lXusiRjbbizP3GfzV+Re8rM3SsasGeAGXBUWjpBNnYsWCzUTjrGnoU8YC90FKtY9RD0UwOSaFZy0K2vAboCrt3uHaapcjIdSRLIY8uMfWEQ69A3S0uBXdj0+lwkyVujxLzrJQzxexQwW7OUv0fDW+WXDQO3Agmup0Lf65h9uJlSy2VR2n5QeQOlArNEnhwY/fUfDS/8FdIGfjVmcUKSq0WzQsEyDq5xiqHXWnpzAAJuHl2AlC0fw0ydR7O7vTLkPA+1GmOTjGVIy9HIamiI65yxB8rj3Q7u2kfnzRytUDbPbKs3o7typTFyxWgij0YI9Lc+ZdyUe7kZU0KniflEHOQXR5gosiJxas2fGfeIlnV+6boXnBosuFqI3KtzwlEXWnWQ1zD0k1tg1ZYr4gWb5rC+SI51zkLx5W8QeUJFhtHCc1wyTqPO7y5X+FhyczisGjAlwgO0mxntHYS4KbQQDrJ0xs+H+ZmHR/bGTlkAHDVPxQJ+ByjXlOsv8SysMCvmxjEPZzLK3CtA1PDWEprIK/gMwpwJYTN7+O8DUEym1Fm89cCnk/TOIjCXzw/FtQ8UdmZ4/a+ulzmEQgGx7TaD8hTY14kMSQE8SJXJgV+dUK6a4wTCtX9wixo8xfXIADiDRfw8pxHt16ltuTytnqWfsZ74qc1DtSx1Gd8WRNi4x7XobuSqRgjkAzl/0GIrVaLUMQLx/EdGjDyWUydqUU7KZtol3p0gI1klwfTocWKOaI9nKJDMnsjUE0iRWJoukYddgayLMIKH36B0AIzWt6xEwebEQcPsGIpEWPCFigVn/VIGAMd21yg4NaT9oilTBokG0rxiQU3uix7/TX/yn/M cjVlqolt 0n7+oDO4wpAatFBRhEG4LuRKPbcE+xHzhZMPjUmhVk4e3DQV0SWiOOgfPD19xl5PbyVDIa4IjRxLxG9FB7PvMIc0ED+4gKZ8SGGPWnIyltsKs/qDg4Py6geDFevOgp+M9nFZwGOqXv+BsIpOyQ21q6pJECcRZJPdoxH/UcVkV1YQ56x8fvEis6UdvOWFl14/lyZ2iVhih+x/YCKAr4CeipXKc6YdBbNIWfoemMel+2r2QAgDercpJMzobXyEiIdl96iqobp9FyLzRJqVtec/nfhUkBA== 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 1/16/25 10:14, Michael Kelley wrote: > So CoCo VMs may still use the paravirtualization that makes > hypercalls to do TLB flushes. It's future work to *always* use > INVLPGB (if available) in a CoCo VM. How would this actually work, though? One of the reasons that we have the whole TLB_NR_DYN_ASIDS mechanism is that picking a PCID to shove in CR3 is an entirely CPU local operation. The PCID is in a CPU-local namespace and nobody else cares what it is. Rik obviously now has a system-wide set of IDs which are globally visible and globally valid. But his mechanism is also a bit choosy so that the global resource management doesn't get to be a choke point. But if we move to INVLPGB-only, we're all of a sudden *forced* to do some kind of wide global resource management, even for single-threaded processes. Rik doesn't have a scheme for that in the current set. So I think this would be a whole separate conversation from this series.