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 B11ABE77188 for ; Fri, 10 Jan 2025 21:04:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3CC0B8D0005; Fri, 10 Jan 2025 16:04:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 352618D0001; Fri, 10 Jan 2025 16:04:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1A4A08D0005; Fri, 10 Jan 2025 16:04:13 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id EB4228D0001 for ; Fri, 10 Jan 2025 16:04:12 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id A2E13C0F3D for ; Fri, 10 Jan 2025 21:04:12 +0000 (UTC) X-FDA: 82992769944.27.459544C Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2066.outbound.protection.outlook.com [40.107.236.66]) by imf19.hostedemail.com (Postfix) with ESMTP id 75D371A0022 for ; Fri, 10 Jan 2025 21:04:09 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=Nvidia.com header.s=selector2 header.b=rB5Rx2Eb; arc=pass ("microsoft.com:s=arcselector10001:i=1"); spf=pass (imf19.hostedemail.com: domain of ankita@nvidia.com designates 40.107.236.66 as permitted sender) smtp.mailfrom=ankita@nvidia.com; dmarc=pass (policy=reject) header.from=nvidia.com ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736543049; 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=DcDHt+iH8LMg+eXhtJ63HunM1FQy0MLLHA+JCCh54Zg=; b=mIcjou5CTuyGpczc+eHEHJ2iwRINS81/HBTaDXtUPiwXtVs1wTZn08uSZZqKT9rCgEdpgD UQ/3HlhjpHYpU1GbJVeX8Nq2109R2vb1tGLiYXvxyOEyDOL8dGcSd9B3cleQSQ4WwRLDs2 5MQT2yzfHZ2c6Sz/H09lVddP1z4CHTw= ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1736543049; a=rsa-sha256; cv=pass; b=DB2VCoWvtK9QjM4t6UqI/CfNFiBvLLs2mnlCJAsdsTy5plPjoEHvyU36BUYbH43QxgPPQM Ob3uWRQr19stcU9T5swRt0MDkJiBeB9FewjcWC2H9ST6RHIXw7wUm+gM5ipOWBTLnCr+lV ogL7hsi4lelKzUxQt0OYjnbG5WYsxMI= ARC-Authentication-Results: i=2; imf19.hostedemail.com; dkim=pass header.d=Nvidia.com header.s=selector2 header.b=rB5Rx2Eb; arc=pass ("microsoft.com:s=arcselector10001:i=1"); spf=pass (imf19.hostedemail.com: domain of ankita@nvidia.com designates 40.107.236.66 as permitted sender) smtp.mailfrom=ankita@nvidia.com; dmarc=pass (policy=reject) header.from=nvidia.com ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=h6k7CWckVZsJL5hHHxzTaNVjwSoS18F8BHEXhF5qCaZ3V29qniiGindxdMKbXyihwy3Mce1Yrb4fch7tCmKPwZVDt5yNvq/E730CdcXG4h6xAM2q18Wi3qMSb+nVuAtqchznkd4oD5G0y1zvrlamarKBEcp0ii7wS6iiTn9PlAU332dTqTfmq5Y+geDRRT6xNlgf7qevROnNqMD+YJ8eq/ziuzC2RS5KV98/JVkIwka5Xhw1/6TBQ4u6rIeCitxedoV+FUOk/bIsCXVd014SrB9fB7P3VqnJ61EiaLBIowFSK2mE5CsDSLMxCskhluukxGG2w0UdQu8XGWNyowSnbw== 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=DcDHt+iH8LMg+eXhtJ63HunM1FQy0MLLHA+JCCh54Zg=; b=FMMTPbk9sya6F1RyUQHrHQG5tFC4BdNU8nZxueMeZpL/IdOT0GH9MoJIYvoDu93zVdrb58sz99Fu3MJts/wQz0oQJSPqseq1R40kUHpZU2jJSX7XPtXpxftjQJ4ZhWotCmLlKL7CDUscCjwwzclGnDQd1pcEu9Fva629V5PggqliR3CySYnIWpTUc0idTSmpURdfMEibSi8yybr9/4LCjz3vA1b/wI0OF0GyN/3lZGnc2c5PoUx0J971XNkCR+Zq26sTGTx+AQiNl6bw+vhK7Wo47d+r1Bm6N1PdLaKcg64uRvSAhKG4XTjtZnCcEPz8IxifS/yWx9f1PSQ3smWqPA== 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=DcDHt+iH8LMg+eXhtJ63HunM1FQy0MLLHA+JCCh54Zg=; b=rB5Rx2EbNJLckdTAhgYP7RE0F+6msNkNrbKCk/xKVTlIoiSZPF7V3dmd8AdrLHQrPnXYCVlF7NdXY8uefGhe1v8Zb8jbcQVF0pVLU4RPXaXyUuMy5FMELALYPXqquTKlzNPuOqZmTb9z7ppzidg7aUM75lYyrPJbr/s/yeiElDOD0x4EMigWer2TMatAcKucCFK/nUyuDPmnZvby3t24Vvb8srZ+cBIGVMkWOEPnvehfXESAbxXvWhhrHB17ioj79nJtO4G6fXj4XgNwOhOBLIJsv93vAYogWJxXRFV9uVzXUJD4oEw1kOm4tuWjwbQ8qQEh+4PKzaV4kM1b9hi3VQ== Received: from SA1PR12MB7199.namprd12.prod.outlook.com (2603:10b6:806:2bc::21) by DM6PR12MB4060.namprd12.prod.outlook.com (2603:10b6:5:216::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8314.14; Fri, 10 Jan 2025 21:04:06 +0000 Received: from SA1PR12MB7199.namprd12.prod.outlook.com ([fe80::ae1b:d89a:dfb6:37c2]) by SA1PR12MB7199.namprd12.prod.outlook.com ([fe80::ae1b:d89a:dfb6:37c2%4]) with mapi id 15.20.8335.010; Fri, 10 Jan 2025 21:04:06 +0000 From: Ankit Agrawal To: Catalin Marinas CC: Jason Gunthorpe , "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 Thread-Topic: [PATCH v2 1/1] KVM: arm64: Allow cacheable stage 2 mapping using VMA flags Thread-Index: AQHbObyY4gofHx3CJE6tGYAUqrUkhLLhvSCAgC7sTkE= Date: Fri, 10 Jan 2025 21:04:06 +0000 Message-ID: References: <20241118131958.4609-1-ankita@nvidia.com> <20241118131958.4609-2-ankita@nvidia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: SA1PR12MB7199:EE_|DM6PR12MB4060:EE_ x-ms-office365-filtering-correlation-id: 8234d61a-4a62-4f34-c7e1-08dd31ba51c8 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|7416014|1800799024|376014|366016|38070700018; x-microsoft-antispam-message-info: =?iso-8859-1?Q?nLUH98J6SAzXtOx7U8Sz3WdxRoijR2Lh407f/F2VT1rhMFjFmOFJfCDJKb?= =?iso-8859-1?Q?FO9wCDz+D42CTQMMr7eM38i+DmJVYGJ80ayXvOQctIusNT7a+h5cl+ZRcu?= =?iso-8859-1?Q?xHv6guqeeH2+St6HaZclNg2d7jCYNoNdC+ECxKeCqvY/2V+mons5u2/5PY?= =?iso-8859-1?Q?ECbjfH0ka5iuiQ2YlbQOt/u9JsSJQHH6wAG6+xB5YY/94MyNii6/qabZu+?= =?iso-8859-1?Q?62r4Y6SKkxFgw5wAXMzVbNizPs74UWI/SqPknZlI9y6BVodKE/cpuj55F1?= =?iso-8859-1?Q?wDGRbq63f3aN+jwJyzcj60c2LzR5jVhxyZ4GCvhB+7m/iNUJDVKPLaCaML?= =?iso-8859-1?Q?Y5T82y06YvIsgKviKMLOJYth/wWWUxcWDueA932KlgZAegxL1NAQrdYMTa?= =?iso-8859-1?Q?rPJMYRitMb+6etc2FPVs57bbii5qlRr+EiT9X+WZlQ7fIhsRqWMRy7Rigx?= =?iso-8859-1?Q?T+vKzGfPCLnvdCfpxQR3PFiE51lnc29Pv+mQDPpSIq/NKhNsUGgfytP/Lb?= =?iso-8859-1?Q?571zeBd83SMeu/VOlpcLi7ZKhosMN2hgj94LDvPXPXzBUDjUYe91cUitS1?= =?iso-8859-1?Q?5x8LqL1QEvhQUHdWKrB+Tg/BIIHkBmJ6YNC6hyC5vnQwWHJ0wglYbwHBEf?= =?iso-8859-1?Q?2RP5U/vIZy/AWhgsmZUMV1fpclaukQkKDgtzaTXnk0ZRYfspz4TysJH2Vq?= =?iso-8859-1?Q?tUFPbO3UDBg92LlaBQ8Y/VwjKZRGSdKxW9BA8Wg7LCldmxM90ZX6TPKPPb?= =?iso-8859-1?Q?cyGRuGfz7ZhlVTW5XRgboJz59UyW4XsqzyKup28UTNgu0TR++GzPiv7VQw?= =?iso-8859-1?Q?39F5+hpCJE7yD5/lrqAndSeyjqnKDclGkjGShKdwPV4vUHp41H8u/J3qaj?= =?iso-8859-1?Q?iR6IdoiZGatbKFKBny6ZhToT68aut/DOmbVso8wfZ44MBt6I6Fp8uWHTNw?= =?iso-8859-1?Q?I62MYWlUr3G/gu5F4YEmxx08B4dtGL3b47RtMWzeiiJb7jUGKKn8V4ekSf?= =?iso-8859-1?Q?QkaI3hqJH7iMWZLjkE0JghkKqrgu4YAvsySMHr2JmkDSGHhzjZG3OItp9C?= =?iso-8859-1?Q?Nrr0jhn3H586EpJmVnM0X0SSnRLqYW4sr31vCV7h/1SsOQJNZXJz+TUJIN?= =?iso-8859-1?Q?5Fbc2uv3ynn8zaLFiWgB5idLHRu3oYWUbF/pDL5ISJU4FnjY2Z5TxHl9/p?= =?iso-8859-1?Q?/XydCAFyxT/ZXnR7RA21/tmLaBip4ebXLGDe50nIdcOzrv7KBETKCkeDw6?= =?iso-8859-1?Q?M8NirgBtzJMWhYfdfRTjb/G/ylbJUDU0Hm9xlwH5cR/A/YpfmqGtvJ5FTP?= =?iso-8859-1?Q?pUKinyCD7t/QPU6X/00cBl/t15I05zTeh2eOeFwi0ZLR4ad84B0v4jmG4E?= =?iso-8859-1?Q?7BPAGu/glIb+yKZG8EpXPswyJmXOl0frun1zMYqKm2OwqHwDQvddLjQgnh?= =?iso-8859-1?Q?fjljKdPjcqhfwPMCLtq+i5SjyBheM/SQKiossN2Y879ZzK6q+4hOsSJLdG?= =?iso-8859-1?Q?Akjlt+9CS7EjrdlmYYMSd3?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SA1PR12MB7199.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(1800799024)(376014)(366016)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?WtkAmijE2lkL94XPoLhZoXZ7OTXRFy2Ss+SfiF+AnwgVzKUHC/zh/w+8XC?= =?iso-8859-1?Q?63D/530B9CjNGZmwK038OD7dnS+cJaktoxAXlCYmzj0N4Sy8g6AA7jdoXX?= =?iso-8859-1?Q?fhxapjupiSe7TREixJWdIu29rFCNO2O3rTKgnjaYF90FJeuA+WMZebv1yv?= =?iso-8859-1?Q?JDd2nysfrlCM5ewwneuoJuHr8fp4oe3eu0N8AdEUV6KatwfZMN4CMPwD+I?= =?iso-8859-1?Q?eFZ3PhF3gugwWH6HxdKJHsuJCK7izqBjsC3j95dHna6OK4iLbm06Jw0Ukp?= =?iso-8859-1?Q?S1SG1z/cH24ScXaI20i3apf+I1aMK7KrZozadeEMxhK/+4LSmQHlIb7VMc?= =?iso-8859-1?Q?+lofUHhXOydj2XHOZgotwi1owF1bfoitoVHXRgLTrtQWxRJkoY2Dax15dE?= =?iso-8859-1?Q?qrOdcDN19NAemL8NnYKcupvws330zEadknd2BiSW5+E9+ROypyjh6Twc+a?= =?iso-8859-1?Q?7JIa/uFHwhNBn2z/uEY+5lDdbcIdgPuMUUnGSgjkO8nEhdA11cD/gnymIm?= =?iso-8859-1?Q?vYMmNc/5efHWWEccnMwwZOAjPwtAVpabmMKG6LJPEV0ia3ii+Izs06df0w?= =?iso-8859-1?Q?ZOSGED1dU+3tXTzbahCrHlVnwj9c4c2TY/wGfcwP3/9DALqt3nGO1tZAUg?= =?iso-8859-1?Q?olzW4N5+g5EaMWU+SnQlGbY0OY+RvnpWaKNvH+UBeay+uV9jMW+CbVgNRl?= =?iso-8859-1?Q?wlK0ENMgpqhj6OGyhywZTrTQJlDr7mlNpFqoTcl2bme+5gHj0RfnxPpeEJ?= =?iso-8859-1?Q?AMMlhM1eZ56RyAUktAEsER9UrWPuj4F6v2KfuPuVPNeh9cilPvdQt3dW9J?= =?iso-8859-1?Q?MyjDhJttZeRImeSt8BDO317+lUESbtzbxSMiQxZXWY7YQDIes/DCFnQee5?= =?iso-8859-1?Q?ONA9/HNg6U9fEAVcwNzw7CasR1tkDv/DDii/pts+2DMqNWxeKAGX0ord46?= =?iso-8859-1?Q?2SR1d4Q8k2JJetT9cFtbt/O0IkZLYRJ0v8JkxMwtiuG/FXBaLcNh109XUN?= =?iso-8859-1?Q?Ord0mDL9hEnW4oZZR60kpuSRsU6Pg1smUwEw/EhYztvQbTP9qr/SnRgHrQ?= =?iso-8859-1?Q?BqwNBgxaVz6mCR31aI30sNvW/gOG7mfiCVNRjYwgKHHZnuEuvfZNP78Nml?= =?iso-8859-1?Q?E9F4jYgelbjlrJ2/SH/1L4NGqzXBfaXOl2tr1f+9TWrzZAjzr8CtP3oAZE?= =?iso-8859-1?Q?3wrNGxMxlRSISbUOY1+yvFTHuE5tpYhuisyOh3eaUNg81Dsc1fOS//RWf5?= =?iso-8859-1?Q?Zbe9Ot/7YKzRJ2D2gFIntCr1ZiPIinfOmrfjrZEa+xR1NK0xqzzN+C2DiY?= =?iso-8859-1?Q?t1FK0zulVSeRJJZjfo6Z+B+29SsHouFcbf0dCJ+R3rjKbe7yPjXhzYvHJr?= =?iso-8859-1?Q?mP5/KEx6eLXqXiKhColf7jFyr0v4ObZvEL0N6AfPodGC3Y3j17H5Tk1942?= =?iso-8859-1?Q?X3Sz/iAGOdQQyHGZnb3hCPSOVFttWx0EkZ+YUHSf9o6cSDu3Sy6+cVYU9M?= =?iso-8859-1?Q?65boIY0uiRcEe0at7EWBFDmb0tbVmFF1USFN8youRFUJaRB778nZ8CZ+Ds?= =?iso-8859-1?Q?7m++BQA7NtA8xO0EWbu2T6PSozPd3YYESSHbi1NlFd4h1Uiad77eTuDcfa?= =?iso-8859-1?Q?dc64+vHWSzWPI=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA1PR12MB7199.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8234d61a-4a62-4f34-c7e1-08dd31ba51c8 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2025 21:04:06.2072 (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: mw9RiQPGgjgHi4fgMRXuRMBokisKeAEkm8AKJ/jVPEIrGEDEmeGrCQLtJvSVb+ppiZRzVlEqzTgDZkRgZQjZ7w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4060 X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 75D371A0022 X-Stat-Signature: g4hrwsm5ntix5aeytbbz87bmm7xxqgmm X-Rspam-User: X-HE-Tag: 1736543049-202108 X-HE-Meta: U2FsdGVkX19wsKi6mv9boBNFqrmtk7k7kk+2WA4MFVydz3NCxf/uBDLTsh+7P63FZTFpfovq1eCB6KSx5W0ZChli+OePskKhHeV9+p8WhPvxEd2xbatWsYxD7emzRsJg+IxcikgvWDyKLOC2niCQzxLWb28vuoeZl+qsghSI8zygAzQBvLG9qdOy5C6CqiwrfQcdAGvLDRU1/1cZXgpqkhdM9UNklKaj3kL3L/C4jW8l4oWx/V1sZyQhVjj6QAwlDrhRTaJviRunnyXevSBoloTSOyrnD6XYpyF5Z2rOs9YUwL6oLxWsPiFQeKQkMspjh88F8+UKlMTRzUDsoa3Y2OtCYxiKmb7Rb5sLr8tvgbE33JkLWmMVlE8vDM0LiXXp2lbGJUqduxSvlgYH6hCBs77JJB7CeOsy2XEU/2DTbMiOMIlMghZEkVeWKtZCgQqzn1wTQeNA7AN7kPfmh0qRegZfi+337GIi6cJKZkBuq66tTfvPWeH9SyTQUpk2ZcV71yEtKFgxshGLM6F9nFD0tNympj5vRsdFIgaiUpWwf7UC+bRYUc8slv/8GlfOODKNlv8vaXqu5ayseq4CxYPhbmxvOO4su0r8p9bE1b1DyB0x1/er9eQCHuujWaKG0U6l1SKgcR/JiEfSE2lY2tk7imUx3HI8dyzN+aFEanzPxifRI6v6gdPyCBy3mI9+3T8fV4qk5TGm9QStH/3JIlAqqgKB4sPQi94/Z5ssicDmQ3q+JVu9wJGCw002yWC9eoIdSQFgN8etMpkr4OSzqIxiqRCf5R5NhXWgXy+bP+0d5xaltt1tRMSsY0bc2P4DYwcJNSRCXHA/22tnxIr9yRR1kUqrsNlwaKc9Pm1ETd6ukBzL+3MKC9drJgFIGu6WN5/BR4Asz6tBY8zy6eG8Xzdhmwhk6jqWXSJQOFmYFEsK6EyPy+p8+VE6v/mq1GDLqo8X6dU5mgAQ7S0MXXO3UUz w+qMWruJ +vmcwvpf++Pc2xkisQysYg+vYv8W+nYuWclBBPeRlejx1KVlwx0HduAWoh4vSvEThTQP8f+IziyFQsUj+OM7q9bsyM+j6iOqLTqEpzER5KJ3Vw3tn5q8DVuNHEzXzNZxGfAswBZs1/iizxOfkWAaPV1IqNvHC7+d1jJRsQ6pzdDvbEq4VNiU+u3ifE+HdAVxqZ4OcOOVO+Yb/6sEdlZ54ljECRYIV9woIkRKb6v8ZcI4hP50TuOLlMtlMp8LZJjJaItenl6VNmkwCdQIg1mWSkEcIDQ/ZwwkyMXZOFN8oPF9Iynn9W6xp4Z8effsMHDEwSQ6Ubj/ooPSSAqFrtSSsOP0BwHIxwDySl5pQx7Kfkrb7qA1PNPnUBGyoH+8khvmaD43faL2u0brVj1JLcXKBj5sezW2XWCjgJIUFlEGSBNVb0OuyG9sf0POylrWm+3QFU5/gvmAKzFNFF3Y= 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: Thanks Catalin for the review. Comments inline.=0A= =0A= > Please note that a pfn_valid() does not imply the memory is in the=0A= > linear map, only that there's a struct page. Some cache maintenance you= =0A= > do later in the patch may fail. kvm_is_device_pfn() was changed by=0A= > commit 873ba463914c ("arm64: decouple check whether pfn is in linear map= =0A= > from pfn_valid()"), see the log for some explanation.=0A= =0A= Thanks for the clarification. So, it appears that the original pfn_is_map_m= emory()=0A= need to be kept. I am getting the impression from the comments that we shou= ld=0A= only add the change to extend the cacheability for the very specific case t= hat we=0A= are trying to address. i.e. all of the following is true:=0A= - type is VM_PFNMAP=0A= - user mapping is cacheable (MT_NORMAL or MT_NORMAL_TAGGED)=0A= - The suggested VM_FORCE_CACHED is set.=0A= =0A= >> Also take care of the following two cases that prevents the memory to=0A= >> be safely mapped as cacheable:=0A= >> 1. The VMA pgprot have VM_IO set alongwith MT_NORMAL or=0A= >>=A0=A0=A0 MT_NORMAL_TAGGED. Although unexpected and wrong, presence of su= ch=0A= >>=A0=A0=A0 configuration cannot be ruled out.=0A= >> 2. Configurations where VM_MTE_ALLOWED is not set and KVM_CAP_ARM_MTE=0A= >>=A0=A0=A0 is enabled. Otherwise a malicious guest can enable MTE at stage= 1=0A= >>=A0=A0=A0 without the hypervisor being able to tell. This could cause ext= ernal=0A= >>=A0=A0=A0 aborts.=0A= >=0A= > A first point I'd make - we can simplify this a bit and only allow such= =0A= > configuration if FWB is present. Do you have a platform without FWB that= =0A= > needs such feature?=0A= =0A= No, we don't have a platform without FWB. So I'll check for FWB presence.= =0A= =0A= > Another reason for the above is my second point - I don't like relying=0A= > on the user mapping memory type for this (at some point we may have=0A= > device pass-through without a VMM mapping). Can we use something like a= =0A= > new VM_FORCE_CACHED flag instead? There's precedent for this with=0A= > VM_ALLOW_ANY_UNCACHED.=0A= =0A= Ack, this will help better control the affected configurations. I'll introd= uce=0A= this flag in the next version.=0A= =0A= >> Note when FWB is not enabled, the kernel expects to trivially do=0A= >> cache management by flushing the memory by linearly converting a=0A= >> kvm_pte to phys_addr to a KVA, see kvm_flush_dcache_to_poc(). This is=0A= >> only possibile for struct page backed memory. Do not allow non-struct=0A= >> page memory to be cachable without FWB.=0A= >=0A= > I want to be sure we actually have a real case for this for the !FWB=0A= > case. One issue is that it introduces a mismatch between the VMM and the= =0A= > guest mappings I'd rather not have to have to deal with. Another is that= =0A= > we can't guarantee it is mapped in the kernel linear map, pfn_valid()=0A= > does not imply this (I'll say this a few times through this patch).=0A= =0A= I am not aware of such case. I'll restrict the changes to FWB then.=0A= =0A= >> The device memory such as on the Grace Hopper systems is interchangeable= =0A= >> with DDR memory and retains its properties. Allow executable faults=0A= >> on the memory determined as Normal cacheable.=0A= >=0A= > As Will said, please introduce the exec handling separately, it will be= =0A= > easier to follow the patches.=0A= >=0A= > The exec fault would require cache maintenance in certain conditions=0A= > (depending on CTR_EL0.{DIC,IDC}). Since you introduce some conditions on= =0A= > pfn_valid() w.r.t. D-cache maintenance, I assume we have similar=0A= > restrictions for I/D cache coherency.=0A= =0A= I suppose if we only do the change to extend to the aforementioned case=0A= of the following being true, the check for exec fault could safely be as it= is=0A= in the patch (albeit it has to be moved to a separate patch).=0A= - type is VM_PFNMAP=0A= - user mapping is cacheable (MT_NORMAL or MT_NORMAL_TAGGED)=0A= - The suggested VM_FORCE_CACHED is set.=0A= =0A= >> +static bool mapping_type_normal_cacheable(unsigned long mt)=0A= >> +{=0A= >> +=A0=A0=A0=A0 return (mt =3D=3D MT_NORMAL || mt =3D=3D MT_NORMAL_TAGGED)= ;=0A= >> +}=0A= >=0A= > Personally I'd not use this at all, maybe at most as a safety check and= =0A= > warn but I'd rather have an opt-in from the host driver (which could=0A= > also ensure that the user mapping is cached).=0A= =0A= Understood, will make it part of the check as mentioned above.=0A= =0A= >> +=A0=A0=A0=A0=A0 * pfn_valid() indicates to the code if there is a struc= t page, or=0A= >> +=A0=A0=A0=A0=A0 * if the memory is in the kernel map. Any memory region= otherwise=0A= >> +=A0=A0=A0=A0=A0 * is unsafe to be cacheable.=0A= >> +=A0=A0=A0=A0=A0 */=0A= >> +=A0=A0=A0=A0 if (!pfn_valid(pfn))=0A= >> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 noncacheable =3D true;=0A= >=0A= > The assumptions here are wrong. pfn_valid() does not imply the memory is= =0A= > in the kernel map.=0A= =0A= Understood, thanks for the clarification.=0A= =0A= >> +=A0=A0=A0=A0 if (!mapping_type_normal_cacheable(mt)) {=0A= >>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 if (vfio_allow_any_uc)=0A= >>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 prot |= =3D KVM_PGTABLE_PROT_NORMAL_NC;=0A= >>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 else=0A= >> @@ -1684,6 +1725,20 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, = phys_addr_t fault_ipa,=0A= >>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 prot |=3D KVM_PGTABLE_PROT_X;= =0A= >>=A0=A0=A0=A0=A0=A0 }=0A= >=0A= > I'd leave the device check in place, maybe rename it to something else=0A= > to distinguish from linear map memory (e.g. !pfn_is_map_memory()) and=0A= > only deal with the attributes for this device pfn which could be Device,= =0A= > Normal-NC or Normal-WB depending on the presence of some VM_* flags.=0A= > Deny execution in the first patch, introduce it subsequently.=0A= =0A= Ack.=0A= =0A= >> +=A0=A0=A0=A0 /*=0A= >> +=A0=A0=A0=A0=A0 *=A0 When FWB is unsupported KVM needs to do cache flus= hes=0A= >> +=A0=A0=A0=A0=A0 *=A0 (via dcache_clean_inval_poc()) of the underlying m= emory. This is=0A= >> +=A0=A0=A0=A0=A0 *=A0 only possible if the memory is already mapped into= the kernel map=0A= >> +=A0=A0=A0=A0=A0 *=A0 at the usual spot.=0A= >> +=A0=A0=A0=A0=A0 *=0A= >> +=A0=A0=A0=A0=A0 *=A0 Validate that there is a struct page for the PFN w= hich maps=0A= >> +=A0=A0=A0=A0=A0 *=A0 to the KVA that the flushing code expects.=0A= >> +=A0=A0=A0=A0=A0 */=0A= >> +=A0=A0=A0=A0 if (!stage2_has_fwb(pgt) && !(pfn_valid(pfn))) {=0A= >> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ret =3D -EINVAL;=0A= >> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 goto out_unlock;=0A= >> +=A0=A0=A0=A0 }=0A= >=0A= > Cache maintenance relies on memory being mapped. That's what=0A= > memblock_is_map_memory() gives us. Hotplugged memory ends up in memblock= =0A= > as arm64 selects ARCH_KEEP_MEMBLOCK.=0A= =0A= Ok, so will replace the pfn_valid with pfn_is_map_memory. Did I get that ri= ght?=0A= =0A= Apologies for being slow in getting back.=0A= =0A= - Ankit Agrawal=