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 79810C83030 for ; Thu, 3 Jul 2025 06:36:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1712E6B0108; Thu, 3 Jul 2025 02:36:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 122116B012C; Thu, 3 Jul 2025 02:36:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F04086B012D; Thu, 3 Jul 2025 02:36:38 -0400 (EDT) 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 DC17D6B0108 for ; Thu, 3 Jul 2025 02:36:38 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 96AC7806CD for ; Thu, 3 Jul 2025 06:36:38 +0000 (UTC) X-FDA: 83621994876.01.AB04F63 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.12]) by imf23.hostedemail.com (Postfix) with ESMTP id 08EA1140007 for ; Thu, 3 Jul 2025 06:36:34 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=dUEz+Ghz; arc=reject ("signature check failed: fail, {[1] = sig:microsoft.com:reject}"); spf=pass (imf23.hostedemail.com: domain of yan.y.zhao@intel.com designates 198.175.65.12 as permitted sender) smtp.mailfrom=yan.y.zhao@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751524595; h=from:from:sender:reply-to: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=MinwbpYG/PGwnx924vKkhQVkSpdZK6Z79WS3XiNJTjM=; b=PvSdc4ppSYkPETDWUWcYWdu2L+hWy2kFolIst/Bg13gT9C+PtGK1Y6MDW8QYzp9oVFJSFb FqidhWDWZ5D09NwYz9rrYaTRIW5DmvEm59HEl80+e4xTv+YdqORPme8qoNJI96+ZiP1S4K MnZSHZ7VEP2fvEf1tpgnNG3v94aKQ/c= ARC-Authentication-Results: i=2; imf23.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=dUEz+Ghz; arc=reject ("signature check failed: fail, {[1] = sig:microsoft.com:reject}"); spf=pass (imf23.hostedemail.com: domain of yan.y.zhao@intel.com designates 198.175.65.12 as permitted sender) smtp.mailfrom=yan.y.zhao@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1751524595; a=rsa-sha256; cv=fail; b=hVlWf6p/r3LpE7x/LiQF5P9QjrRB62uSeCXsjusobir52Lrg8GzD/FFQQSqOhc3zzK35fp lXVrhXijfVktIYa9OUskuEh708AvR+WBkfNL+G8xk1C+qXNHOGt69HO4mv/qSeF9WeGCDZ eLZa0kIiWe7PuPz58hGR1akoYc/4JaY= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1751524595; x=1783060595; h=date:from:to:cc:subject:message-id:reply-to:references: content-transfer-encoding:in-reply-to:mime-version; bh=IHN5fESVlMJzHxm2BlZU7Rg4rkWGJmB0BhmWHT64PHI=; b=dUEz+GhzR6UV2UgGHqlcOvSvrItqFejifKTccbeyVxqNmzAFpi5WOAZX 5zMLo3ewO+MElZ/9C6uGuO3esv+/qrg74H4u6ElB2M+Yd+BroWIBJdhDU GU6zDha0pgC2u7wJAwYP4sqpGOZOqXqAh2f6cSifGU2y/rVJkf5zKBoiU jeG05buHBi5BPoCyk6gxhAQ2+H181IfENSndEmxjrQP7e7hOvhpyXNTTp ttaCOHdK5Ap+f5qQodwvIO78305vZrtCJlIXZkMiRON2OntANMk1WB4gU zrATW1iJTu0Im9grK7fqcFbDUncRV5GNRGdrKF7Hj3iqB2rS8oVYKVagC w==; X-CSE-ConnectionGUID: SAlvxDaRSNSaHiDUVzUijg== X-CSE-MsgGUID: wQXGXZdETJWsa8dxcQkjzA== X-IronPort-AV: E=McAfee;i="6800,10657,11482"; a="65293746" X-IronPort-AV: E=Sophos;i="6.16,283,1744095600"; d="scan'208";a="65293746" Received: from orviesa010.jf.intel.com ([10.64.159.150]) by orvoesa104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Jul 2025 23:36:33 -0700 X-CSE-ConnectionGUID: 0PFAUQ3fRQWBA8qOKa5OMQ== X-CSE-MsgGUID: tLnpm+bVTq2+LOtBqVoL6A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,283,1744095600"; d="scan'208";a="153694726" Received: from orsmsx901.amr.corp.intel.com ([10.22.229.23]) by orviesa010.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Jul 2025 23:36:33 -0700 Received: from ORSMSX903.amr.corp.intel.com (10.22.229.25) by ORSMSX901.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.25; Wed, 2 Jul 2025 23:36:32 -0700 Received: from ORSEDG902.ED.cps.intel.com (10.7.248.12) by ORSMSX903.amr.corp.intel.com (10.22.229.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.25 via Frontend Transport; Wed, 2 Jul 2025 23:36:32 -0700 Received: from NAM02-DM3-obe.outbound.protection.outlook.com (40.107.95.86) by edgegateway.intel.com (134.134.137.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.25; Wed, 2 Jul 2025 23:36:32 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Nms/ko73tA+XW0h+zCHKpsvSWaTJ1e+QjAf1voIL+4c6Al0yXcbTsGVCKLeQDps4HtqG1B6tCxy77MyYd3OfYARq/56ReYwpdZxYjpicBsv/7yWz+1kvTZd3ydrio08DNkXEzVdtugjrE0LVGhVbUUKz2ACUO0Ys8Nro3b6jcxwoKREtpQZYIZA9vl1fJ/0d6uUboEnufZaqFTIgo1oSmjoitAFDeUGp1n1dgLPtda5kvEWBPi8DLolsD+eY88DRhTKentqRRy+UbD7Vm8c4KUWNFOSxnBUtn/QMcCe8iGVUfNJz8gmOXCnedJlHtBc3lfVwoVKOD1Wwsrv1HSTbUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=MinwbpYG/PGwnx924vKkhQVkSpdZK6Z79WS3XiNJTjM=; b=om4VjVMPHGs6UQgOMGVh4oL7R84BD8VzeJcKRJ0xbeiqwDIn8LNHEm/Eq4/t2rKauw4eyWmNx5T1X8c9pWKFKxoVdZigIefHoh+WrmLiZXEcU2Tyocykg1qq/ubr/he/oidpkafih/IMbE+TJFc0svDyHqRV3uBH+Q1FwYkPbCmmlAJBq8SWDPURSHAiDEOMrVldnn6PM/uwCFOPYc6TW0QVY3gkQvIPcOUXHIDa6tvyF3DRkMuFnpxH6EMzqrK861dZlH+BQVEk5rQ8OcGJJMSWngCUNNeC8Kj0M6cAHHvQs/rnN0YUuUqdMyZ/yV5KzS+NqLNZpZAueF6nqv59Bg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Received: from DS7PR11MB5966.namprd11.prod.outlook.com (2603:10b6:8:71::6) by IA1PR11MB7855.namprd11.prod.outlook.com (2603:10b6:208:3f8::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8901.20; Thu, 3 Jul 2025 06:36:29 +0000 Received: from DS7PR11MB5966.namprd11.prod.outlook.com ([fe80::e971:d8f4:66c4:12ca]) by DS7PR11MB5966.namprd11.prod.outlook.com ([fe80::e971:d8f4:66c4:12ca%5]) with mapi id 15.20.8901.018; Thu, 3 Jul 2025 06:36:29 +0000 Date: Thu, 3 Jul 2025 14:33:54 +0800 From: Yan Zhao To: Michael Roth CC: Vishal Annapurve , Ackerley Tng , , , , , , , , , , , , , , , Subject: Re: [PATCH 3/5] KVM: gmem: Hold filemap invalidate lock while allocating/preparing folios Message-ID: Reply-To: Yan Zhao References: <20250613180418.bo4vqveigxsq2ouu@amd.com> Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20250613180418.bo4vqveigxsq2ouu@amd.com> X-ClientProxiedBy: SI2PR02CA0019.apcprd02.prod.outlook.com (2603:1096:4:195::13) To DS7PR11MB5966.namprd11.prod.outlook.com (2603:10b6:8:71::6) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS7PR11MB5966:EE_|IA1PR11MB7855:EE_ X-MS-Office365-Filtering-Correlation-Id: 1b5f69d8-1c82-4a1f-f95f-08ddb9fbf186 X-LD-Processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|7416014|376014|1800799024|366016; X-Microsoft-Antispam-Message-Info: =?utf-8?B?aE05c3dsSkYvQjdERS9jclBtcUhtaHozNUtjdzQwVnphRVhKRHVCYklZMHB3?= =?utf-8?B?MWRNRGlXWmpIdW5GS1UyNzB1b1Q4ZFRpMmRUL1dGb0hCVmpwSE5BNUNPNXJm?= =?utf-8?B?WG85K3pmOHVkVG1VdXo1UHNhblE5a21jaHdqY0o1aVZwNWliY2FpbzZXTGcr?= =?utf-8?B?VWhtNVNuNVJ4MXlpejN3OVVzN2tNbFl1RHhscS9pUUhXRDl4T2dUL3F5MkxV?= =?utf-8?B?NXBMdHhrZzhhR1ZTZGt4NVhONHV0aitSWWs2Q1N2cG15cXR1ZG9kc3YrK1RZ?= =?utf-8?B?aUtETkJ6aEVNRE9oQ2s3d0ZmTHBRc1BTRzQzYUcra1hWZUlzMHRCbVJ6ZHMv?= =?utf-8?B?ZVFjeVErQ01Cb3kyYy9iT0htQnd2dzNucnY5N0QvWVo4dis0dG9XWGZpbHUw?= =?utf-8?B?dU1jTWhVRXpFT1JyZE9MaUhPS1huMkdVZUdCc2p4ZjVTVU9NY1U1MzZVbWFF?= =?utf-8?B?RU9veHhtZEJGeWwrZUYyTlF1RlloOUREZUxvY3M1RWRqT0ZkNTZtbGlpSzEx?= =?utf-8?B?TE5XYzhhcUd0cVFOci9FTXMyWjg3b3dhMDNIcGQrMEpvcmljQjViaWFWeTIr?= =?utf-8?B?Ykp4TEJqK0xlSVdIQXNQMXgzQ1puWlJJWkFmamFXb3g0V3JkUkE2bjg3U1B5?= =?utf-8?B?OUFtUW55bjV1MXUxb1drNGcyYU9YQWZMK1MraGhaZUtvWStrR2o1dEZyQnAz?= =?utf-8?B?eU1oYlpVWjVFbFZJV0hZODhZQ0V5YXFtTzQ3UWgraU9wenJwY3ZBQmtzTDZY?= =?utf-8?B?YWd2dUZ0eEpMZ0xDaHVhVHlvUnY5L3FFSUZoL0RSVklUeVpOdlpmT3FmbGo0?= =?utf-8?B?MjRHcmpQRE9hVHY2TjBscVB1Snd6V25QL3VVZ2h6cmJpdzMyeE1BZWhvOGU1?= =?utf-8?B?RFVNUFpSaFRod3AxZTVrVWF2MkJLRTlpaGdyUGxVQS9hSDZXSmpsZUlMc0Ew?= =?utf-8?B?dXlob3ZwOG8xMWpPMFEySkdsNTVrNFI1Si9mK0tXNUF0ZU1sMG45TWZ2ZDFM?= =?utf-8?B?TEwvNlVVMHFBQ2tYelRRZzl3aTZuV1RMcFRIL29UZlVQV0tnSDlhYks4NzFo?= =?utf-8?B?UHdDZk1pSC9tR3BLOTZHS005akNKcFFuK1BRb1ZOUk51NGRCSXdWWXVCSUR2?= =?utf-8?B?QlFvM3JvaTNJbjBLU1VlUCtsMGhVVk1OcWJQK0Zhd3NUay9MRVR5U1IwcS91?= =?utf-8?B?MnVmMldVZjE5VWJHTlFTZmtMNk15THNxemxodThCRS9WNWhhT2hERFZBak5T?= =?utf-8?B?TDQ3R3NUMkt0TWZnU09IajhzK0szNFpIdTYrK2VVdWNCK21iS1l0Y2RzLzB2?= =?utf-8?B?N1BHTkJrM2Fqc3ZSTDZ6UUxwZ21oc2NHNWZnemRSTExSV3VmcWdOTDRNMmxs?= =?utf-8?B?TERkYmJvNjBMVmZuQytoN3RsRzdXTU50R1J6MHYxMUpmdEJJeXUvNUNjV0xZ?= =?utf-8?B?alF2MlZvMXpEaitpL0djMHJRTDJLQlF6R093cTQvTkdHNzNZWWtrRDZvYUFq?= =?utf-8?B?WUZldE1oSmpJa09uU256alZtOFRkWXpGSEgyWEJpMlJMWjZaaDlkbmFrRGFG?= =?utf-8?B?b01JeHhJbzdGaXp1MjZqVEZxd3hVWGs0WEhNTXIzSjA3VUV6TTJWOWd1M09l?= =?utf-8?B?VEZPWWR5WHQ2MEw5WWMrVVlSOWxCdUpFWkNrZjV6QkdCWmdmSU1laitsNnVz?= =?utf-8?B?bWtmbzB3emREOTNRa1k0d2JpZlErcTNnWFB2dG94TW1jajErN2xGN0ZmL2U4?= =?utf-8?B?cmhhSTN6MzQwNGZzVjlLUFVPdDFLYVpzOHMxcjRudnlQRjlvTkxRY3pwSjRD?= =?utf-8?B?cVIxMm84R2xpYU5HdGJVTGlFdlovMlc0eTlNUVRtb2lDdnNvd2k4YnBwMXUz?= =?utf-8?B?OEtXaXRjb1dzbXp5VVF2eExsVis3TEFCU0pnKzhybFRRSDdQNHN4Nnc0QkNu?= =?utf-8?Q?R51fWVNS5kY=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS7PR11MB5966.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(376014)(1800799024)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?LzBKeHF6d0V3T0FhWmNHZ2swWUFqWHdmdTE4cnc5S3pTeEdMaCsrM2RNT0RR?= =?utf-8?B?TG95RkNxTDlyWHc2TkhrZEhCTlE2U2JyUytoSTZEaVJza05rbzZhSmdyUUln?= =?utf-8?B?ak85d1NOOUtjZlh5OSs2THEycjYzc0xKa3Bnb2hGRHI1QnNHNmcvZEJTYkJx?= =?utf-8?B?MXl5VmdqR3RLOEdnSVVCVlYxMWxFdnZURkE0c0k2bHlUMHhZUFFHdmxuSnZ2?= =?utf-8?B?bDRodXliSkxlS3REZnFDNkxkdFk2N1M5dnVZUkJLVHFwV0hYa3ZDaE93ZCtq?= =?utf-8?B?bGVvSmVKRVd5aDl6cHdIa1FGajd1azJlclFhVGU2TG5RbjIycGNNYUlmSGJ3?= =?utf-8?B?NEhHNGRFcERkak45d2ZlblpuTllCdkdzd1NaS0MyUVRpQkg0d1FOL0lUbGtE?= =?utf-8?B?cGJJY2FGRkdYRWFYc2l5NEFjUWtPN05LMGp0SXd2OWhqVnpOdjJFdlB4d2dl?= =?utf-8?B?ckhZaFYrd2JlTXM4ZTBjY2I0cVVGQWhlaVJjbWVoVWFFWWxyOGJ6dFB4V2kw?= =?utf-8?B?clVRUUFzNjZ3Y2wvbTdhczU4RkJXV2xDOFpWdG1oY2VkVXBxZWI3NWpYVlB1?= =?utf-8?B?YjBGbTRHSFJBVFUxdkt2NGtRSFdTUUFEVjJmakdzMmIvdWdwNWJ1RVh3Nnls?= =?utf-8?B?Z05NdHZUbGo4YTNEQ3BDMmZkQjJ1WVdXU1dNRTVVKzdsbW8zNkljSWVoNXVP?= =?utf-8?B?TXlnSDBhNnQyaGdmTnYrTzQ1RXoxbmtQcHFKSGV6UUZ6ZDMvbk9pWXQzQkp0?= =?utf-8?B?RnhXUVI1eE9iNE1zZ0V2TzJtSVNaRGhpQ2xHL1NUTkNFWUZBNU5YYjJSNTZz?= =?utf-8?B?bFNhdXVKdyttNDM5SkFzMTdpTjRKMFVUYWlUeTV6V3dSOU1NTm1ORHFEY1JE?= =?utf-8?B?U0Y1Qm1hVEk0Rjc3cTF0Z3FpbExlNDNyVVVTUnBJSEJTZTErM04rdW10K2ZU?= =?utf-8?B?aUEycHdkMGNLb0xRZkphTFJnSjRIWW1sUEQ5YldiVmRBWkNxakJtL1FESUtV?= =?utf-8?B?R1hEdDRMZzQ0SW4vcFJrRFYrUmJCS1dqL1JIcVJmUGd1RlpPNG5rV1E5b1cx?= =?utf-8?B?NFR0YzBWZGtYWGI5WjZQbE40Z3dQZlB1WGdUbEsvTWg2UCt4QjdIYUhDeEt3?= =?utf-8?B?b1ZyN0FpUUdpWUlHRDNsWm1wdFNFTGt6Zk9uYTY2WlhKSlBFdFJXVWhsRDRZ?= =?utf-8?B?UXhFNm0wMlV2azhXSm0rZU0wNjVFYnVTMUUvLzRIaHJBRFMxYjNXWlpINW15?= =?utf-8?B?OG5RVE5wNFBtbHFMUEZwNnphUXBSQzd4bWk1Yk5DcTdzTXlnNThZNGhtSURs?= =?utf-8?B?WXB5Y09wOGxJRUd5Y3Rha3d1RVVibTl0WlplK3FLNE1lcXJWTHFuUWV6a2ZS?= =?utf-8?B?T0NwQVZVV0F6bmE2UDVycTdlWkZVZGdVOU9QRW8vZDhGR1I5emJ3cVlFR0gx?= =?utf-8?B?Uml6UDhST1luSnk0Mlo5WTRuNTBRbmhDNFBmOFlRM0dVUHdVeWxscFQyQi9R?= =?utf-8?B?Umsva3poZW1SWjAzK2tmNkE0SFlMUU5UME5taVprWUVJSDdLU2YwVGdQZTBj?= =?utf-8?B?SDNrUkhlODZlUEFhcEdzYllsOGdWWmV3SEVDSlNKS0M2bEZmTDVYSTBMM0Z1?= =?utf-8?B?VVNyU1IwVHdXMjBlaDhVZGpFb0RwMnFwMTlQbVIwNmRDTGNhRkg1RVNTUyts?= =?utf-8?B?VWhFZng2MjZDTUlQS01xcUFuK0c4ZGtGSEM0MmdHdnB2NFR1YkNQQkdLUWxS?= =?utf-8?B?MEI3Q0lkR3ZoaGE3cmpDcklHbkhsVjZ2ZkNPRVBHTnEvaDNZWVhXdmZPZFpY?= =?utf-8?B?TWtKWTh6MFRWOW9IMi9HTTVPc2NiWW82WWpKclZ3bHpBcEdWVXVpdTlLeXMx?= =?utf-8?B?UldDSEN2dHQ0NnBRc1N6eHdSdTVMRkY1UFNNOTI1VkF6VndTMlM2TkZFMlVw?= =?utf-8?B?b1Q5ajRhVzY4VnRvZG1LNG9NaWNMcFR0U0pQdFBBRHY2NFRLNi9CWmZTdGNH?= =?utf-8?B?aFFOVUJxamJYVVU2N1dlbVdnMkRPMzVKSnNYWGJNZmxBM2hmdm9uSFdscFFw?= =?utf-8?B?V0pINUJOSHZxdndKQXNWNkNVTmowNHpRTWEydFh3OThjYTBPT2xnbmdhRHBY?= =?utf-8?Q?fLnxjzIUCdb/CgLCJCq6I2Icq?= X-MS-Exchange-CrossTenant-Network-Message-Id: 1b5f69d8-1c82-4a1f-f95f-08ddb9fbf186 X-MS-Exchange-CrossTenant-AuthSource: DS7PR11MB5966.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jul 2025 06:36:29.7708 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: xJKv3/W1WexY+pNTtSw5fwwyBZ5xRPHyHDi7WmIO1t29S7LKbKLiuQOgy9HEVGGP8r0y7czAtz62hY4XUMnUSw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR11MB7855 X-OriginatorOrg: intel.com X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 08EA1140007 X-Stat-Signature: w5bb8p1y895kxz9n7s3gaw89zze59nuh X-Rspam-User: X-HE-Tag: 1751524594-855471 X-HE-Meta: U2FsdGVkX1/XMBxTMnQHGzMP9KH9u+KUe/r43mvm1Z4tYnlRQmfmePQTnIoEC+r26gfLxjRsTNOBesXAvu2u6tc5msCbjMqG1aHUNCGb1/awowQ3m3E5dEBoPdh81SF7qJOliYYcKkGjPaC3uk6llLJqfuMwWyDSh2z61Rx3blJtUD4pFCCmvrn28OFBFVUx2mBtQUBSXrO1LsxAzKntDlKj6u2ZCIb+5epO2lz+Epir5C2GOFQ962jUIToFDw23HejEqdldvH3sAZJerojODG6JME2UtCFJdTQc1LBubg3d3GWhiK8H+JL2DkZhjQVju98DkwFrdEfUBU6Y19gNFFI8D011z/qKPdo9nQRJKAPQaYrWq53g6esLzFJZl7Qbq8vxplOgGXVrOyFuvvC6ku6Dz3/xt/qTxp/fDpNq7SM3ip1zE7oqJ4vUzTQE92ZN2GWwWpaD1cNwbQhGP0YCLwL/+g6KohXTRJZqqyJi2VDOwq3YNdxDE/12ojMI4BkNbnDJxfAplwGCsp5f5FvQyf6NUCZ487NPJDneNsy8u18tVuEjg5hao9jie3RhPgEKTuC54zIqkqSRm8iGdY6q/54VypT0aMI66cNuKH9YQabkS9dXxqRysP9/lgYLTFOzA4hiV0be62UQoEV5EpjkExIkiFgLIiRhXzXydGWMYCfmh9Kn4cgl7QPIphMMr29klx8dcGIKFsBY/RhsPFQQ54WJtxlJrFejh0zm4ZCdKpzoxeqE3nOIrrF5nqqGf92AOFq1D9xuUN4o7kqUnHByN4jMZ8TP4/tVQXvgqrNZEbrmW2kjnYYGZLgDb0AhIKzxYip6r2EE1QixRDAcuuBsrXvIt6eUV2IQypXg1+yFV2Qb7lNKSY5Og+W43WQd2kY7vCmX1e2CyTcexgCilkp4EunxGhE+nNaMrGIlw98OcCdQUTjSznK2KJWLhqR+ewYutts6KLHWp/9HT5komtW Bq/p0LPs WcacBNyTg5g5alRo2KoVMPs1MGWctYLDHl629FkvjF8fcWDdJi8JfsbMXjy9iRfGZA/ivBW3eISjnLy/JIet9zXL78SlVjn3ZMFdjeM+C02ryRBRa2nmteSxmaVOIPMbfuVNC7H6D/jZEp/XaxIl8eN8OGdm0wlwBlyjmXbBynQqLZxWThgOrx+JhawZFsPK/5UKNIl0uDT5kfC6n8fQVdtEyaUDrbHeFDGq055ZTyD0HsdSXM5yLrJZbyOoq2m4zkTrjCLW3fmS6kP8qr0vggWFord/z59prySPh8emUF5hFd3BDWcDMql5U/liuE/Y77A0cH5xUDDNyFYPc5WE69hxYrDeQtr8etSSd2Nao28HwIw8NlDQITjCbI0S+yDS5TRaYMyi92A0dNM10EsL3Mc4DK+4Qc8w0Je0WcHPcq3RyiADE0b9OdFHrLkuFlfQ1MSp+1ADMCFx7GV9jHT14MIBwq0rtBrIMN3j7KyskT9GxEwxB/ZUHs/UbdxBf/KMohTbGovht8HgZRLNMM5/M6IOM9QHX+Z3BFV2uuKg7uWRca0cZQpBX2G2PvKIOdPeH5r50JdNnslWJuyaXu39ma8uBtpT6GOPu1Ka4+7UxwA9zqVJ/LTryJHDVpQfOW66A+qz/ExZokNsRYlOpj4OUtVumBXONxdf4OsHoFH3Hx+2cp64= 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 Fri, Jun 13, 2025 at 01:04:18PM -0500, Michael Roth wrote: > On Thu, Jun 12, 2025 at 08:40:59PM +0800, Yan Zhao wrote: > > On Tue, Jun 03, 2025 at 11:28:35PM -0700, Vishal Annapurve wrote: > > > On Mon, Jun 2, 2025 at 6:34 PM Yan Zhao wrote: > > > > > > > > On Mon, Jun 02, 2025 at 06:05:32PM -0700, Vishal Annapurve wrote: > > > > > On Tue, May 20, 2025 at 11:49 PM Yan Zhao wrote: > > > > > > > > > > > > On Mon, May 19, 2025 at 10:04:45AM -0700, Ackerley Tng wrote: > > > > > > > Ackerley Tng writes: > > > > > > > > > > > > > > > Yan Zhao writes: > > > > > > > > > > > > > > > >> On Fri, Mar 14, 2025 at 05:20:21PM +0800, Yan Zhao wrote: > > > > > > > >>> This patch would cause host deadlock when booting up a TDX VM even if huge page > > > > > > > >>> is turned off. I currently reverted this patch. No further debug yet. > > > > > > > >> This is because kvm_gmem_populate() takes filemap invalidation lock, and for > > > > > > > >> TDX, kvm_gmem_populate() further invokes kvm_gmem_get_pfn(), causing deadlock. > > > > > > > >> > > > > > > > >> kvm_gmem_populate > > > > > > > >> filemap_invalidate_lock > > > > > > > >> post_populate > > > > > > > >> tdx_gmem_post_populate > > > > > > > >> kvm_tdp_map_page > > > > > > > >> kvm_mmu_do_page_fault > > > > > > > >> kvm_tdp_page_fault > > > > > > > >> kvm_tdp_mmu_page_fault > > > > > > > >> kvm_mmu_faultin_pfn > > > > > > > >> __kvm_mmu_faultin_pfn > > > > > > > >> kvm_mmu_faultin_pfn_private > > > > > > > >> kvm_gmem_get_pfn > > > > > > > >> filemap_invalidate_lock_shared > > > > > > > >> > > > > > > > >> Though, kvm_gmem_populate() is able to take shared filemap invalidation lock, > > > > > > > >> (then no deadlock), lockdep would still warn "Possible unsafe locking scenario: > > > > > > > >> ...DEADLOCK" due to the recursive shared lock, since commit e918188611f0 > > > > > > > >> ("locking: More accurate annotations for read_lock()"). > > > > > > > >> > > > > > > > > > > > > > > > > Thank you for investigating. This should be fixed in the next revision. > > > > > > > > > > > > > > > > > > > > > > This was not fixed in v2 [1], I misunderstood this locking issue. > > > > > > > > > > > > > > IIUC kvm_gmem_populate() gets a pfn via __kvm_gmem_get_pfn(), then calls > > > > > > > part of the KVM fault handler to map the pfn into secure EPTs, then > > > > > > > calls the TDX module for the copy+encrypt. > > > > > > > > > > > > > > Regarding this lock, seems like KVM'S MMU lock is already held while TDX > > > > > > > does the copy+encrypt. Why must the filemap_invalidate_lock() also be > > > > > > > held throughout the process? > > > > > > If kvm_gmem_populate() does not hold filemap invalidate lock around all > > > > > > requested pages, what value should it return after kvm_gmem_punch_hole() zaps a > > > > > > mapping it just successfully installed? > > > > > > > > > > > > TDX currently only holds the read kvm->mmu_lock in tdx_gmem_post_populate() when > > > > > > CONFIG_KVM_PROVE_MMU is enabled, due to both slots_lock and the filemap > > > > > > invalidate lock being taken in kvm_gmem_populate(). > > > > > > > > > > Does TDX need kvm_gmem_populate path just to ensure SEPT ranges are > > > > > not zapped during tdh_mem_page_add and tdh_mr_extend operations? Would > > > > > holding KVM MMU read lock during these operations sufficient to avoid > > > > > having to do this back and forth between TDX and gmem layers? > > > > I think the problem here is because in kvm_gmem_populate(), > > > > "__kvm_gmem_get_pfn(), post_populate(), and kvm_gmem_mark_prepared()" > > > > must be wrapped in filemap invalidate lock (shared or exclusive), right? > > > > > > > > Then, in TDX's post_populate() callback, the filemap invalidate lock is held > > > > again by kvm_tdp_map_page() --> ... ->kvm_gmem_get_pfn(). > > > > > > I am contesting the need of kvm_gmem_populate path altogether for TDX. > > > Can you help me understand what problem does kvm_gmem_populate path > > > help with for TDX? > > There is a long discussion on the list about this. > > > > Basically TDX needs 3 steps for KVM_TDX_INIT_MEM_REGION. > > 1. Get the PFN > > 2. map the mirror page table > > 3. invoking tdh_mem_page_add(). > > Holding filemap invalidation lock around the 3 steps helps ensure that the PFN > > passed to tdh_mem_page_add() is a valid one. > > Since those requirements are already satisfied with kvm_gmem_populate(), > then maybe this issue is more with the fact that tdh_mem_page_add() is > making a separate call to kvm_gmem_get_pfn() even though the callback > has been handed a stable PFN that's protected with the filemap > invalidate lock. > > Maybe some variant of kvm_tdp_map_page()/kvm_mmu_do_page_fault() that > can be handed the PFN and related fields up-front rather than grabbing > them later would be a more direct way to solve this? That would give us > more flexibility on the approaches I mentioned in my other response for > how to protect shareability state. I prefer Vishal's proposal over this one. > This also seems more correct in the sense that the current path triggers: > > tdx_gmem_post_populate > kvm_tdp_mmu_page_fault > kvm_gmem_get_pfn > kvm_gmem_prepare_folio > > even the kvm_gmem_populate() intentially avoids call kvm_gmem_get_pfn() in > favor of __kvm_gmem_get_pfn() specifically to avoid triggering the preparation > hooks, since kvm_gmem_populate() is a special case of preparation that needs > to be handled seperately/differently from the fault-time hooks. > > This probably doesn't affect TDX because TDX doesn't make use of prepare > hooks, but since it's complicating things here it seems like we should address > it directly rather than work around it. Maybe it could even be floated as a > patch directly against kvm/next? Posted an RFC for discussion. https://lore.kernel.org/lkml/20250703062641.3247-1-yan.y.zhao@intel.com/ Thanks Yan