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 9E4D8C02183 for ; Fri, 17 Jan 2025 14:01:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0F8596B0085; Fri, 17 Jan 2025 09:01:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0D0266B0088; Fri, 17 Jan 2025 09:01:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E3D5B6B0089; Fri, 17 Jan 2025 09:00:59 -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 C35C46B0085 for ; Fri, 17 Jan 2025 09:00:59 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 31B631C9058 for ; Fri, 17 Jan 2025 14:00:59 +0000 (UTC) X-FDA: 83017105038.23.036FEAB Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2040.outbound.protection.outlook.com [40.107.237.40]) by imf05.hostedemail.com (Postfix) with ESMTP id 240EE10001A for ; Fri, 17 Jan 2025 14:00:55 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=Nvidia.com header.s=selector2 header.b=UBsF8TPr; spf=pass (imf05.hostedemail.com: domain of jgg@nvidia.com designates 40.107.237.40 as permitted sender) smtp.mailfrom=jgg@nvidia.com; dmarc=pass (policy=reject) header.from=nvidia.com; arc=pass ("microsoft.com:s=arcselector10001:i=1") ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1737122456; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=IpOSIhRVZ87Q/TNV6Hbw2Br500R0LtxYlQTdNITClds=; b=k63rVSro+c+7JBTHY5UWcpKJ6jTV5amIzZTiTY2CJQipeloiZH3dXeNeoil7JWXfpYMmcO r2WGz4KVLxputtRpR0N4Gb30fkVBBw7P4+nQri7fV+H5DUI0fPq4b66iWX1HMFsiRXr79c g7T73EXU/b6/ISGW/6g2QyJ3OVGw9Cg= ARC-Authentication-Results: i=2; imf05.hostedemail.com; dkim=pass header.d=Nvidia.com header.s=selector2 header.b=UBsF8TPr; spf=pass (imf05.hostedemail.com: domain of jgg@nvidia.com designates 40.107.237.40 as permitted sender) smtp.mailfrom=jgg@nvidia.com; dmarc=pass (policy=reject) header.from=nvidia.com; arc=pass ("microsoft.com:s=arcselector10001:i=1") ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1737122456; a=rsa-sha256; cv=pass; b=RKb9rWcIpUmtOLcCNb/bUocKzFzvENLaAkCOBXquyGOPt8fBBs5671Q4JMMmOGnXGq2Ydu 9wvOH8ar/UP4kzMm1MdOVJj14PzaZ13CafGhOlkmr5rWpI0Co35Qwxa6TRknPOCXYhT1rp 0ALtdOtx1enGagNZxztO+yXy1LFExlI= ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=B4eRhOvhk0h52buDjCvL0gTcXi6EdAgA5+nub2whZq1/j7qABUTnSGfW0kDchPtPtbiUE545QhCTTgAR+8fEB0sGpGTokI9tXmrKQXDMido/L5lW6Vqz3IXEZPq7qoFJEJaeLDZ1+N/rMuq7yUZKJ6BAyX0STFOU7JjKJEBWrv9xucrYPj4QP40ieARA7JtldkWsUyBqGRKNFqeKD28dpThB8vJ1Zv1ARHL/cZU2yUvJy2BfaM1CUWJ8HEPBvp1H4guDlor0lcXZioSQVlZBX9YiLN9LFege1XxYS3RXhcrGnLpaNGvYu0HYgGVX8V56XxKu5gIFu02fDChPADVr3Q== 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=IpOSIhRVZ87Q/TNV6Hbw2Br500R0LtxYlQTdNITClds=; b=ycNkMpl0PYtsKqfNKxzswtde7UBMxHXnG1Koxi65CIQk2Lx3zKz4W3j6wzEz1120vp7LqnXs0DBE9CuEk6C0eMZJ70T3UWlYfFmKnPVX6VADaDYvGYBTHv+dgSxPJNPthgkG9aefs1RuKbubPixrIecXvNa7znymyKtw5IKB59uIOpQbClLfasvtWYel3t+EFq8e07iYFFQ7Rbh3MCFeLlKwGHKgNoMrwz4AbI8va3YUQ52en4wOs3GbVdoZ1byjmKEm9d7J9IDhP4HRdgKrOZyqpLBkblXpRt/uxO+qs7RB5ypiqM+bOr+K+H37BJx5O/kM6+mnEzOk9sbPH0fKqg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IpOSIhRVZ87Q/TNV6Hbw2Br500R0LtxYlQTdNITClds=; b=UBsF8TPrZU4RyZQWjIBo9GNi2Gnc6R6EkZKQj4eSSmx3TkS06aUPmT4Sk2qIGwF9g/b1e8P7Is2CmBFhwmepsshuX6SaBCyyGkRnj63hg9rYDGRJdqQSPe/x+ZbN9UT8e6HfMN800INiYiLkg2awqFwacF/+gK5XwVs6oAgms1+ivNE6cLGj9n5QWyviCbvEGjTgYdN1hCl6vpfwFUEwAzYTW92JXZPPJbeSOnj4jyCvlNHZOSigZ13tDrNf/i4rZO/hj8RVi0/S6Ofeyw0kOptNscDgbhVI2qJaNl1ODAYSDmrRAgikUer4G/tygPTpyyhIHFWXZI4k+S2OK98QXQ== Received: from CH3PR12MB8659.namprd12.prod.outlook.com (2603:10b6:610:17c::13) by LV8PR12MB9110.namprd12.prod.outlook.com (2603:10b6:408:18b::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8356.13; Fri, 17 Jan 2025 14:00:52 +0000 Received: from CH3PR12MB8659.namprd12.prod.outlook.com ([fe80::6eb6:7d37:7b4b:1732]) by CH3PR12MB8659.namprd12.prod.outlook.com ([fe80::6eb6:7d37:7b4b:1732%5]) with mapi id 15.20.8356.010; Fri, 17 Jan 2025 14:00:52 +0000 Date: Fri, 17 Jan 2025 10:00:50 -0400 From: Jason Gunthorpe To: Catalin Marinas Cc: Ankit Agrawal , David Hildenbrand , "maz@kernel.org" , "oliver.upton@linux.dev" , "joey.gouly@arm.com" , "suzuki.poulose@arm.com" , "yuzenghui@huawei.com" , "will@kernel.org" , "ryan.roberts@arm.com" , "shahuang@redhat.com" , "lpieralisi@kernel.org" , Aniket Agashe , Neo Jia , Kirti Wankhede , "Tarun Gupta (SW-GPU)" , Vikram Sethi , Andy Currid , Alistair Popple , John Hubbard , Dan Williams , Zhi Wang , Matt Ochs , Uday Dhoke , Dheeraj Nigam , "alex.williamson@redhat.com" , "sebastianene@google.com" , "coltonlewis@google.com" , "kevin.tian@intel.com" , "yi.l.liu@intel.com" , "ardb@kernel.org" , "akpm@linux-foundation.org" , "gshan@redhat.com" , "linux-mm@kvack.org" , "kvmarm@lists.linux.dev" , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH v2 1/1] KVM: arm64: Allow cacheable stage 2 mapping using VMA flags Message-ID: <20250117140050.GC5556@nvidia.com> References: <20250106165159.GJ5556@nvidia.com> <20250113162749.GN5556@nvidia.com> <0743193c-80a0-4ef8-9cd7-cb732f3761ab@redhat.com> <20250114133145.GA5556@nvidia.com> <20250115143213.GQ5556@nvidia.com> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: MN2PR15CA0047.namprd15.prod.outlook.com (2603:10b6:208:237::16) To CH3PR12MB8659.namprd12.prod.outlook.com (2603:10b6:610:17c::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH3PR12MB8659:EE_|LV8PR12MB9110:EE_ X-MS-Office365-Filtering-Correlation-Id: 46b68104-35c8-45b9-9c01-08dd36ff5a6b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|7416014|376014; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?pT8lspFztMkx1UyM6r52SQp0+G8mdmIvXvofEeXJ1Tf0RU4qV8Mext1Xghzf?= =?us-ascii?Q?lXfUwCRx8w2dzdRzoc7HPrxVv5JnnYFBgvWXnuw3S2gZXs4DcxlVlt2xCnxY?= =?us-ascii?Q?dgKPDY2r4z/AOXP3hAKT7X1Y5s4ssui/bfMbEw3sw5jToARa7AHs+gIzaDat?= =?us-ascii?Q?vuI4wkOFzaeq1hVFC4W7MK5goUhIKROWYhhbZcbjJK4mnCOV52I54l4NgwfI?= =?us-ascii?Q?+xL39P4fm6QVy/T2PCpfa7rXcxtPwoBPjyr4HvQlnIT+qBUe/fOmAHrkJkxL?= =?us-ascii?Q?dfmSrd7qm4WmIm+4XRo3gJ5/YWeOdCrHiVHv8SbwSQsIxinke15ru/3pUAuz?= =?us-ascii?Q?eo1wJKIPv8RQfNqIelf91tfi9KkFzS5ZrVCIK9KLbN93ZFHaAkkezCZoTM9s?= =?us-ascii?Q?8B7zvvHupNlhjB89fzYRC5uutxhkMGUtBQ8BbOPSN8ODOMyOPAc5T3tWw4QF?= =?us-ascii?Q?923xec/nMgKBh/1qPAZYZJrsMnrJ3v0xJfJLpDAt7Dy6LJf3EPg6j3v9yRFu?= =?us-ascii?Q?YKga9+xsNwfJTT9Y7I2Iy+yOl9Joolr0H9B+aBnrSm3mPruksukpA8VVPic1?= =?us-ascii?Q?iUbQhTsxPITDrQqTf5WKIhIjiuDW4UgDQyRTMISI83i1gKmYBJYiI/ZEGtIL?= =?us-ascii?Q?CWvA9vaMgxN13q1tsWCGaUdlUOYes2N8NWYaC9p8dZlSahUYrtCp9gMhM8AT?= =?us-ascii?Q?giV6QuAfquDyZCtc8JlKGMdHfsL3gVRVP+EBlD3kQo8q9QL7z5H02ln0t64W?= =?us-ascii?Q?pSIcG8CJWb6nQKFjHo/TTU4MMSRmrb+SKhF3H5nK6PCxV7EbmKZuusl3SfPQ?= =?us-ascii?Q?5gxiCgI7BxQY6+v0zM+Krc2d/xo5Xn/Qnl2n4DhLBgUBS/R21LWK6haw/1zj?= =?us-ascii?Q?AgfbjR5IDo5aHmt6TVeWRYrCgifeKmdK9GxRAPQnmxb+g/3NeZ5IA3DtHIxu?= =?us-ascii?Q?UtjkHQyeNs/QCxDu6yCrNrpX8lz7WSDpdyeSjWTmEitUkiG3PHlt6Pyg6R/i?= =?us-ascii?Q?kiPZhHaJD73aTyise93UUuRW3WwjbA5U211eRfMv0U8JNUsODLr/ygWqRzFW?= =?us-ascii?Q?PLrlQ+iVQdx5qGwApAy2q1VBQoX5tmEWryl3onGgycsjb7c+JcOE7AqimZ/w?= =?us-ascii?Q?DNPyTEygXAEtP0bi1x9mDlEhnDfBsXj1tluFi+1Pkgr/A7hS3FQGfRZ7AQ2h?= =?us-ascii?Q?2aMdMLjSawkQE09MbCRItDoaoTKvyY8dDctfbgvNhLoXmLBgbgrSxA1mexgv?= =?us-ascii?Q?iF6/E0BRIHZruesaPDZvsJe1+484nlkewqiJdc4eE0DCbt+lWlUR3dzlp1+y?= =?us-ascii?Q?964UD0geClul5xIXOlTmXGGyP8Z5/46RxrtFzD82CZV+KiSWB/o0MXHXALkL?= =?us-ascii?Q?NWOvuIvT1mVfzFabyEVULMvY7p36?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH3PR12MB8659.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(7416014)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?f79iYav8f5oe5kfkCoFpnU6AyWaAjgIGQN64JI02qGwjbH3wvJTM+kh51Mux?= =?us-ascii?Q?3CPBesmc3FxhimIVU0LChXdJMTuQKLp5RQewX+qayiFDqT0mu86H2HFnQf4w?= =?us-ascii?Q?uKmb47AE4ixiYKHHrt922Rva7s/5EQRm/U2ZemDKiDGgUZhvCieKdV7BGWwU?= =?us-ascii?Q?WJHZ4gIiETthtCsF3c8wEyZaqDPXO6Ev1c32yve+44tCBzZQYph1yVdZSJt5?= =?us-ascii?Q?t8rMZ7b7HhHVQfdSKVNJ1F8GayHiAKGVQoILXMi0DZ3OolaDpAsBsEiOuuIS?= =?us-ascii?Q?ZAIpSO/APtY8xr+LIMGYXz/0yCnZy5hD9KBV5dA9UPzvs7H/V2gzGZaCvipi?= =?us-ascii?Q?c448T5N+hYBD2gZJO//YzhjfRNn+46nYUuUSHbi+ll1mrhftUC/bhvvXA0RU?= =?us-ascii?Q?S3k8KUqEijtrzntBk5ux4KhnZhmRaOStwpHu8bT79O++gBuANlTWG0vmQ16X?= =?us-ascii?Q?witgWd/nLr4/9tj0UXsxS8UlqnHl1BzWCh2MmBg+SrK5IVPu8yU9tq8nuNwL?= =?us-ascii?Q?DZN2AhydmEjv9UDjapIOyMAmYzY8UcaAWDXGl6hUHPm1Q5JIVPjdDEm+MiXv?= =?us-ascii?Q?o49DP+Dq3gZyJSIomLVTqawnto+CG/y42S0PH++wGBZJJbvdh20BMC2ueSIB?= =?us-ascii?Q?6tsHTBkA9FbO/BLT8F9b4APb1xACk/uenYTQS/Ye41ojRRmRBzWTlRl+V4eZ?= =?us-ascii?Q?o9neqErrg72eYvCOXAR9d3D3f72Dt7fxb/61vDMx+p+AvwhUTzlcipJqdl7Y?= =?us-ascii?Q?OLLcb692Cw/du19cBIbYP5/gOcQxFKXrNaANlUyGByW1DAVuh+zZBVjL6zYv?= =?us-ascii?Q?hPxFBrHtj7mjzUdvj+ryVufB3D+PQwnjBXiGAmd7OTaRGN0pTYg0vemOueRg?= =?us-ascii?Q?hjNa2ekrkpia71p+eEjG1FrXyVUSezTK4ZAj9n6U/jlGS4I0f8gYkEqBh+oT?= =?us-ascii?Q?CImf+YImjx/XwuzIuE17TSTXzs2FbbVPrgYS/SKZcQQ7sW8BOtms2ZO2Wj4X?= =?us-ascii?Q?lTS+J2EnzE9DdRRYyiConVqX433carlKLq+T8lXQUR1bnaUMMmxnCTbuSuDm?= =?us-ascii?Q?J88EBaa/7WBxRYnleHjaAF40i0jJzQjLrtNZz51eoAdQKXSat08DCdPitdro?= =?us-ascii?Q?ARgc52BO/hzAiMoEcQxoTEY7yNMp5zCRQ2R1vnKwoPE9suioX+UUDXb+dszB?= =?us-ascii?Q?r2ghdBfsx9A8G9gzAuwgKlKVrx5JgHddE1Mo592L8C5r/kJMugnkR6vcLvUb?= =?us-ascii?Q?YCcUhA252Cf7+GgFDnaiDVKkwv7ZDVBdBGXYJP0hgoJ4kujUEgtl69t5c6Nr?= =?us-ascii?Q?XPAwSsm+UWbUBK2cHYpO6Cwmw2bgu/vHvKrWLZarjWBfn7N1kPf8MbjxkXsU?= =?us-ascii?Q?wcMiSGlLpd9oNy9mzt7GryFksYd9wT4BDAv0M7DKI4uNiBPn706OL/S5aJgG?= =?us-ascii?Q?+NUgYiQh1uTMfEUp1tf0Tkm/melZOksP0UVT53Whb7BM77JxnVXoVzXK2UFU?= =?us-ascii?Q?gPTFPO7lZrdGUTyB6BUwgNUbyMcO7zupCJgwwXLOAyk57abuAQW/pGPNoXMr?= =?us-ascii?Q?CU5VRijGTSN1wCJqJXHmlOOv4bAzNwzYdIfjlDoe?= X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 46b68104-35c8-45b9-9c01-08dd36ff5a6b X-MS-Exchange-CrossTenant-AuthSource: CH3PR12MB8659.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jan 2025 14:00:52.0449 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: yRCTAY8r5aE1A+HkofBsduWzJ8yhRSihpWjpb/gM5oLoqcrdksVFOXH1hO/w4RHS X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV8PR12MB9110 X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 240EE10001A X-Stat-Signature: zz6danoh9ipbs1r4n8d3obqka9piieux X-Rspam-User: X-HE-Tag: 1737122455-733267 X-HE-Meta: U2FsdGVkX1+Qsx0gJmHUp1p35VJUWdR96ah2I1vuNTeNSRDC8aW4BOgcTrzABQbgPDuStS7tvkUh/lQ81J6sAsrss8rXA2iD+4mChE3kolQth68OawK8SCX2BoVSYIuN/Il1Zzbf/J9Xfax7CxPT7UptndBisMFiN6s3iJZuCBkjkNUG96GKqIHlSK/nUMKwhueB7qESgAfZZzonI4xu9PuWjZ0lEQnzzQs8N2Mp0ue1iI9q1EGcUxlOPUBKO/Suvy2cvGPXTur6EhO70kQgglk085yoOw4RRyFTSclt0AfU8ZogwgxpK5dTx5tG4+fYtMKTop2EThiD5F1wF6PLwEml4sLx3NATDEucNgh3nFf2SbTYsMhr6WaXfl4jMn5muvZct9/yJNwfzbpfWj6p/BA3TenYWD48VO246amkqv8tzgBoVQcGNzTu27rM4Hnx6BcHJfpXoBMoepd9JmYYxd9H8Atf4sO2jKOuUuE7369ikzbPYRM3KCOskUHrX9WrzZn192I9Bq8ER0I+j7QjuZ/nQGNu+QaruFPEUv07+x1SgNuPoFptrlJPcXL/5ocQ6sImKpubuXKMyO7qtto/T6+pUWRsY0dX73VkhvJDZSKMtaS5pdFT9sYLU06NqaEjD6olbObczwr/i9NRcI/WBX6cgsrTVAA4sgKhyN2ynrvQLNTf5VbEJcfkBPjbOQ98+XkdhVlvYNE8JpmhCmzYUmQ4Xdq7CnDYotYm5p/c/+UKx+Pac0pVL1x/27SNMb1BW6P7NZnmQijMlIL25DJBjHld6VSG7dMHk0Zdx3QIoEDPKEfZE6h4stVO6xoHyuOAAOcXPg/p6tfVjWgBWoDDWvfdEIkAG8z6dSh+02hEHR4pO/qcUhje9DzxkAkBrZzbBgBb1XPxdDA2dc3Q+f+akyZHF3OCX0IgD7hrx9Z2megipGmh6ASYzVEdvuvtrM0/rmlnKfj6u+XxLZd/Hdc WMSkjQkv ozyXuj5NxbLywmRAOqVxVrgbuOqyZkdx1XpR0Wvzp+tYjF759/DUolCiY+NOSSXu8OLack1mmy9M2yGQlkj8Bav0QL+1oLKf2VSkjsCo1wUx7CGQ3q8yXyCZUxz2vmhOXG4wNOknYaG0BENCWsxEbQLQwe48KjqjeixO4J0aK5r7dtcJQ0p/+0wI0H2u1Xz3x75dmz5I2pwqsa2S7heg5OEoUeb/QoDsytKhn/jxPnJaRb3VK4wP2xZy33/C7uD0w8WMrJKg4AeYc8B0sIGafqqpItPc7Jzw/GkIt2lFed6ojcXDn7ee5vEWGcXFfOayCkMIgxzTJLL0vOp3UXnofW3jU/DqvTscslTkmTnYmuzpEX/OmwzSBQ2DKgSI6be9daLoZj7z8PIqy3YwvzHcwT5y3QQ== 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 Thu, Jan 16, 2025 at 10:28:48PM +0000, Catalin Marinas wrote: > Basically I don't care whether MTE is supported on such vma, I doubt > you'd want to enable MTE anyway. But the way MTE was designed in the Arm > architecture, prior to FEAT_MTE_PERM, it allows a guest to enable MTE at > Stage 1 when Stage 2 is Normal WB Cacheable. We have no idea what enable > MTE at Stage 1 means if the memory range doesn't support it. I'm reading Aneesh's cover letter (Add support for NoTagAccess memory attribute) and it seems like we already have exactly the behavior we want. If MTE is enabled in the KVM then memory types, like from VFIO, are not permitted - this looks like it happens during memslot creation, not in the fault handler. So I think at this point Ankit's series should rely on that. We never have a fault on a PFNMAP VMA in a MTE enabled KVM in the first place because you can't even create a memslot. After Aneesh's series it would make the memory NoTagAccess (though I don't understand from the cover letter how this works for MMIO) amd faults will be fully contained. > with FEAT_MTE_PERM (patches from Aneesh on the list). Or, a bigger > happen, disable MTE in guests (well, not that big, not many platforms > supporting MTE, especially in the enterprise space). As above, it seems we already effectively disable MTE in guests to use VFIO. > A second problem, similar to relaxing to Normal NC we merged last year, > we can't tell what allowing Stage 2 cacheable means (SError etc). That was a very different argument. On that series KVM was upgrading a VM with pgprot noncached to Normal NC, that upgrade was what triggered the discussions about SError. For this case the VMA is already pgprot cache. KVM is not changing anything. The KVM S2 will have the same Normal NC memory type as the VMA has in the S1. Thus KVM has no additional responsibility for safety here. If using Normal Cachable on this memory is unsafe then VFIO must not create such a VMA in the first place. Today the vfio-grace driver is the only place that creates cachable VMAs in VFIO and it is doing so with platform specific knowledge that this memory is fully cachable safe. > information. Checking vm_page_prot instead of a VM_* flag may work if > it's mapped in user space but this might not always be the case. For this series it is only about mapping VMAs. Some future FD based mapping for CC is going to also need similar metadata.. I have another thread about that :) > I don't see how VM_PFNMAP alone can tell us anything about the > access properties supported by a device address range. Either way, > it's the driver setting vm_page_prot or some VM_* flag. KVM has no > clue, it's just a memory slot. I think David's point about VM_PFNMAP was to avoid some of the pfn_valid() logic. If we get VM_PFNMAP we just assume it is non-struct page and follow the VMA's pgprot. > A third aspect, more of a simplification when reasoning about this, was > to use FWB at Stage 2 to force cacheability and not care about cache > maintenance, especially when such range might be mapped both in user > space and in the guest. Yes, I thought we needed this anyhow as KVM can't cache invalidate non-struct page memory.. Jason