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 9FB12C02193 for ; Mon, 3 Feb 2025 21:06:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 143486B007B; Mon, 3 Feb 2025 16:06:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0CA606B0082; Mon, 3 Feb 2025 16:06:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E372D6B0085; Mon, 3 Feb 2025 16:05:59 -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 BC53C6B007B for ; Mon, 3 Feb 2025 16:05:59 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 6EBECB0046 for ; Mon, 3 Feb 2025 21:05:59 +0000 (UTC) X-FDA: 83079865638.06.E3EE7A8 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on2047.outbound.protection.outlook.com [40.107.96.47]) by imf27.hostedemail.com (Postfix) with ESMTP id 5902840009 for ; Mon, 3 Feb 2025 21:05:56 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=Nvidia.com header.s=selector2 header.b=dsXTJaHi; spf=pass (imf27.hostedemail.com: domain of ziy@nvidia.com designates 40.107.96.47 as permitted sender) smtp.mailfrom=ziy@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=1738616756; 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=dC18PVYx92wZJlw/sJZzVJZC4rMoIFAv3m7iMcM2MeU=; b=VloTB0OY7M8W0CUjYmhvLgwQSFFS7GZO1GlziWcVfds6OpN7eXsl5Mr04Xqc+iTqHzgDci rqiQh5Kzf+B2xEIvsV4N7WxUvhCsaXFczdjAM4hjU/HrIJ0qRta7HL9zcUVO8ndD+T7Z4G uapYbYdeDmxCOngso1ziJylwOSuL0lw= ARC-Authentication-Results: i=2; imf27.hostedemail.com; dkim=pass header.d=Nvidia.com header.s=selector2 header.b=dsXTJaHi; spf=pass (imf27.hostedemail.com: domain of ziy@nvidia.com designates 40.107.96.47 as permitted sender) smtp.mailfrom=ziy@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=1738616756; a=rsa-sha256; cv=pass; b=csw4KkwrSV/5ptaSQfWYZED2vEynF1VwNHOou54JVTy36F0lCOlc0KH2a3SrZAO8rolFcD Qvam/mMEL2ForyHYWLFfoJ0fIFYoF/18u6/9Rzofkjb+sPWCP6t5xboINhfRaZYNdFlRc4 F9R0zlpJ2riGjy2lKekBqltz3wij2Hc= ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Ad0CWkVqIOfR7S4C0PdndoUHIJhWR9J4F/DiaqdSOppa+ivAG6FPZZ3EOpKjlH/mSnIEG2lb/o4F4BrzIwBodQ7Bp7Fu5x6Sd0B6GiKxCb7+hNkSCscAXMtyteJn238et9djaG/txEAiCHDXLWVVBNw301wbIcT3o3DL7gs9xhR1qtqcM3/LWqN9eZCRWrpsc9QTUBLxx5dzAarfD/18+ljZWvENglu3Cj3mIOnIvnnTX79244jmxlrtaV13Rdq49ADkI663m5kT1uIT6YAs5+B1tIC2g5u5THXZfe3BkCXgvfxPP8ZRsCb/SLzL0llYAkN9V7H1IY4VxZb4YNwrFA== 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=dC18PVYx92wZJlw/sJZzVJZC4rMoIFAv3m7iMcM2MeU=; b=aiB7YhC63r/uUw4uDkfhKfIScP5Z7M4742CeLKezl8NDE7OpUqJ9hFJ52gYRM6XfLaPFsqaY9mJ8JD6sGnTyCg6V+PYyAwExAaSQJslgv+IZsDA8FbdyaQYDHWdowxOjeHSR84OSNJNMEz17qJi+mMEGvodtFRVgUUeXQzdZT6jfwgbJNZ/RTrEswC2Yskqbyv6TemDeQcIJipv1R3cHpGJ5hmTRRU63Efz6PGsMXQgGrZ96afRJ3jXGbP1jX+Nh+tpQEBiabnI0UueqBeVUM6UGrpMfc5uOWp0K+AvPpfIufGvlq7sx22qlRc8KFR8jnqjND/Ke0WgcMiApMr2XMw== 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=dC18PVYx92wZJlw/sJZzVJZC4rMoIFAv3m7iMcM2MeU=; b=dsXTJaHiEVele2pqGV8QgIP/vvUBkQK6UX+iTllmr6zViwa+OEDqFu0ArGGp7ObWRTdF/JGEkt+C6ECOiRuCfXywFLgFU9EOhFotxyrd7QbECsULFXhZF7nuE1wCXhjV+g37N+vOyoyu50NJn40pcHoY7U4MI+Dwl9gVw9YdguuPgvr0uOYXpw7FNlE6PIB9AXco2oXZFkF7jZBbcYI4Suy/X6DR95Ow70Q/+M4Vsr/TAALieB47tkbzmGdOXclhh8M0/T7xUn3B4plYciFRutcMcVEz03Q9XMauEVrwXd2T7ZuV54U5J/dFcYPECnsOX2bhU5KvOOEMA3UDcKvvxg== Received: from DS7PR12MB9473.namprd12.prod.outlook.com (2603:10b6:8:252::5) by SJ2PR12MB8782.namprd12.prod.outlook.com (2603:10b6:a03:4d0::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8398.23; Mon, 3 Feb 2025 21:05:52 +0000 Received: from DS7PR12MB9473.namprd12.prod.outlook.com ([fe80::5189:ecec:d84a:133a]) by DS7PR12MB9473.namprd12.prod.outlook.com ([fe80::5189:ecec:d84a:133a%6]) with mapi id 15.20.8398.021; Mon, 3 Feb 2025 21:05:52 +0000 From: Zi Yan To: Asahi Lina Cc: Miguel Ojeda , Alex Gaynor , Boqun Feng , Gary Guo , =?utf-8?q?Bj=C3=B6rn_Roy_Baron?= , Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross , Jann Horn , Matthew Wilcox , Paolo Bonzini , Danilo Krummrich , Wedson Almeida Filho , Valentin Obst , Andrew Morton , linux-mm@kvack.org, airlied@redhat.com, Abdiel Janulgue , rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, asahi@lists.linux.dev, David Hildenbrand , Oscar Salvador , Muchun Song Subject: Re: [PATCH 0/6] rust: page: Support borrowing `struct page` and physaddr conversion Date: Mon, 03 Feb 2025 16:05:49 -0500 X-Mailer: MailMate (2.0r6222) Message-ID: <37A0729B-A711-4D45-B9F0-328FDB9ADD28@nvidia.com> In-Reply-To: <41ca3445-80cd-43c1-8f9e-634c195c9187@asahilina.net> References: <20250202-rust-page-v1-0-e3170d7fe55e@asahilina.net> <41ca3445-80cd-43c1-8f9e-634c195c9187@asahilina.net> Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: BN9PR03CA0455.namprd03.prod.outlook.com (2603:10b6:408:139::10) To DS7PR12MB9473.namprd12.prod.outlook.com (2603:10b6:8:252::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS7PR12MB9473:EE_|SJ2PR12MB8782:EE_ X-MS-Office365-Filtering-Correlation-Id: 4b2ab35b-b59d-401a-89cf-08dd44968aa4 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|7416014|376014|366016|1800799024; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?voqeQ6snkHSJ+nkld2i0deSFIrtzjezhyW6cH9hhFwzTfWewDKl9aJ6oJbb8?= =?us-ascii?Q?UinnEDTVDu2T86R0dpuuIEyfnZ6KC6ceRrqMVH9/D0T2ykdGRlWYM4LGETTl?= =?us-ascii?Q?9rM1eW4Q+69U3B8V+NQv1eCtYhf3hQNGil+YVnIEpY8fb5SWoTzppBdOeSLV?= =?us-ascii?Q?EOt60hlS0KgPR3H/CmfqfF9PwyFlv0Hq1tnS/9LobMu6xe93fdpoUt1asCnL?= =?us-ascii?Q?peuQ9RyJP7e9IcQ1eTZSIyBXN12ZIT3Z1yasji1B9iJyXBLGiRBAJEZBrCzS?= =?us-ascii?Q?h8z2EHEhmBzSze1yZxsDpkRxBv0GJH+lycnpmO11WYtgJch8AKnAcM21qbvk?= =?us-ascii?Q?hvuFF8oD3LlauDEl5vIxBmkBsIJjbyPUbWufZf+ysnj/V0ug3ST1ELGWXcmt?= =?us-ascii?Q?wLbq+nCMtK+D3AyABuXXvHcT/Sxhb+q58Q2STg7Kkr48AErSziWT01r7Um76?= =?us-ascii?Q?iEBTaTJliw8VR5CvRxTcmAFynLOpnvOkemRb5nHXc2ksXyOp89njkDEh11aL?= =?us-ascii?Q?1DLdIhdEvu+SKLetXzZZin5UExG84BzIKyr7lvPHZTCDt2PYjSIh9aPxGZKN?= =?us-ascii?Q?VV9mkLCyekOkGnEYjZ5qPQkTzE3Glf2NJ6TPuq+5Z94XwYr1y2XPS9ZKfFK9?= =?us-ascii?Q?UAkYpP6UALWEuJVVg4OWmOH1fEZimhUe18Dit6X4ZhWVMWPyKv+t0RBumzXB?= =?us-ascii?Q?fYsgDneHkzCDXXjIxET0FW3cGDt29IVlLpqo6CYY9yvt/bfc5K1m/IS49FaY?= =?us-ascii?Q?GDm5aeXC00URRipWljq5n1jcl/3k2YS47sKLHe47w4Uf8yIyo3+EA87aeeLT?= =?us-ascii?Q?wTef8rzS0JUzG5VSZJIgYaa6xcNlVFCrnkZeAlA+inrcAL3M8brF1rZnjQYv?= =?us-ascii?Q?0iJTzve4F59vboRu5PORhS3VWHBN2dBGAnFkqdV4V2i8V7D3DvB4DMiElVsh?= =?us-ascii?Q?OvpIVHy2TlQ87hJOX9vIFZHpXWrgXwP7gYv5BdWI8ujnBH7IfVbP34qti1to?= =?us-ascii?Q?sApjsRSN08GIWaDpqdDXzjckL6gt1l2QzslCBTd2abXuJpgXatBR1st9CkSd?= =?us-ascii?Q?61I8gkQLNz+Tq8SZDvFhLsh0mdjV+hVeQHqDLbilvEhXDPdikkCW6FeMidMv?= =?us-ascii?Q?b/BpcrmgJqNWVNmY/9exDILLaxgen1q7cEhYzox0gjPk9Am6qBkNwEpcr7fC?= =?us-ascii?Q?dIeaou+vDgeFRsWDh0o2O634PgWv0E+ZqlduZ1iYnPIWmLoMSqyQxSEpE/CS?= =?us-ascii?Q?N284J6cmITHthRdZTM5xaULqKd622Lpwi54+OFQhZmVWv1zfwzWuz5XWjLfT?= =?us-ascii?Q?2Q3Q0aKykwbqZZhOObvYa4V1VHqqBnRcJJbHmLpzFsiJKlZrifaGv5mr4BXh?= =?us-ascii?Q?/EQFshcHdlvim7roco8BPdck8jl3?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS7PR12MB9473.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(376014)(366016)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?9Wer04Sq3W0WAVqxGdAZEq7tuatwzDVcuQ2dHt9m4d/WNDIjLu0qIuHDMe7F?= =?us-ascii?Q?7NexMyQ7WgnGBriSe6wgV2UCQ1zYxcOIc7+fYY+8SEHvbkHEVTcQqdgVU8Ex?= =?us-ascii?Q?DOBLvqH/UxJzbJFbbBnPhWKXUQEYN/kaeIPZrLDzGYfAgdurd5vJR77LB5B6?= =?us-ascii?Q?3TXtIoF9qEDiGyLqzF3TECmg41lQPu2U85ZxadZHXrSWwwQ6+Orx1ugkcij1?= =?us-ascii?Q?39Yedebov7Lt8A2E5GYoc+jKzIZHJir5DwxjHkFGPNczvzsturm36VxUJ7Ps?= =?us-ascii?Q?ZgqsnYvLkDHmqGAtd/RQ8Ji1xb5MDWllrQGqnMlYfJAt6UcS6Na9czzQ5xxD?= =?us-ascii?Q?KKURSn5xxNtorpAYRh7DNOMEnR6e6kjnHwO+pMV3YJEfDbx1Nf4avSQRm8JA?= =?us-ascii?Q?wTyt9yydrQoeiUl/rmtPspOL7Dr6YEhxxTMJzZNlwvG7z6USuBN+oR4nZH7a?= =?us-ascii?Q?FCzjpw/jFI8Xg7kfgHwzsUg8p2462Bj/Y4llC9A/wXIdq14xCwPV1DhiiGp1?= =?us-ascii?Q?w63A1Lm1L0Hyx7DrKUWppWUf3a3tLxk6dOj9p/t8++ykT9ziEu/8BfoH096m?= =?us-ascii?Q?Toi8O3fAz7/hBI89VLWGaSUXJst9cqt3r0VT7F07rAwTj1u9BxnNVl6gTNV4?= =?us-ascii?Q?cPYk4eKsPnweGkT15C4va4XI65oFr7alHVc5VVHTQDON8SLPHpgB8/pPKJHM?= =?us-ascii?Q?vi/UOw2CHHahTCnv2abOWuJS1wN+4fuT7eUkifHsrdIdbC0YUJU++587WPqS?= =?us-ascii?Q?ejOOPbTaEqGEfIfVh8OfaXP7haMPKu5Q1Fv7m5SHLsdkdJZxMW5hO9ygRniW?= =?us-ascii?Q?svEyMPFhyewLbKjp85yWy9ftB1Lz0BBZxQs/2ZJw/wXCwYY/OENzFUbS8hfs?= =?us-ascii?Q?HdWA5G1gk0Ak9KEuL2ymDahEQMV34Z2Jy4yywjp/iny2C7vDoxlraFibt3DI?= =?us-ascii?Q?EZWuJsxLc9cQoGLMCAdlhfgBQl8ORVZBRDhEcDe0iXMWgyDoKZDiI5LAccyh?= =?us-ascii?Q?VGK+XZe3JDnFmXiedDoffbhgwBCpdV1FCQoi1096ZPlVXY61WXQIwgyW3f5N?= =?us-ascii?Q?gUFcmiBui9bOrELZvxenIYsqrCX4gPPIhWP44DNibyqYlT4BEUX+CVYfcABP?= =?us-ascii?Q?geG9qbCPTBYNPGbtpYioF1D+0Y5km5Lfbbg4yg0HZf19m58EPqnNlsBxiZqh?= =?us-ascii?Q?KbAca6nM+86Dnxgbj0VjuZJaWUq8jLPRF+85yIjGrLqTgJm++8EFYtjBKiFt?= =?us-ascii?Q?LMN7X3GGp5Eon1w/HhSuPtjLp+JrFNlWEmqX0/1fFf/3N0v4Pe5TZalI/2yp?= =?us-ascii?Q?eCyHVuhaGqaqjdOqpzBNzqfFugPo8dcEN7CyT9DcS1MKYLbiXfDYqOnaPJ4S?= =?us-ascii?Q?ltta5IseLiLf9naw9rDKq1AAskFCaxCMGHZn0kd100NIASJxjmr7wEt3gM5X?= =?us-ascii?Q?CWJW2pq4IBhLwsZFLqyhClV841QUIkOS3vwj7VOZPdHJuUIrbNVv6gbXKqP6?= =?us-ascii?Q?jrLLaS2Fo9KaFrd4dvI0UmN4OIKLOgIOY+QrefrZSL58PRRzV8UkPCF5TWvp?= =?us-ascii?Q?xkPwI9u7UuCLqyMYYvU=3D?= X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4b2ab35b-b59d-401a-89cf-08dd44968aa4 X-MS-Exchange-CrossTenant-AuthSource: DS7PR12MB9473.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Feb 2025 21:05:51.9602 (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: 2rTbP8aowZhgxvKvNWw4uaPCUDIKhTKZ9fx0AwIah+K4Fa4+yJoJuFe/+iBm5zia X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB8782 X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 5902840009 X-Stat-Signature: 7ayrbygsx47qsa59hkmkiw9ib6wqfuna X-Rspam-User: X-HE-Tag: 1738616756-591647 X-HE-Meta: U2FsdGVkX1/uNinkP1ZbHMfyvd2mFeAR3nZZ2t4JBjjHzqfbB4rdSX95G2/wx0Uelh8Y4h89Z3fbcn10XL27ca5YCDE8iu6IPOBxHQg/Uxw/2JWo3+Kudq71ep32vbc//0Nbn/rK/QcwF5sTPa8yjUR0NVIDJzMdkGKKnMpKkrAh1/GamdoFE/wJbX/XbQq9n5TyHmDfnR3j6hYL4SGbdGGCgKajSHnZyaJwCcynzlm2py0JQi5EoBwNdmORTawdKce3qQnOx/Bt0RP6FH26NYmGlGtn0UsD1XtwTiYz20PtWh7xNcdJw8QyIa+sWIO+KZWRmvhytVPTUjOv2lJolxMPd8g6ox60kEjXIhmnGfRB3JEJw4oKSuzIFc2KEwsSugxzMbhD0ee1KXM7a+4Blz58cFXA9XDCcqJrbHjQmK0HG9uKNAKcMYnUhmDL2aAYJCYx/BWJvTZqp2YQqCaRL1ocVzictk36hyKb5S4tbOpzEtLafn/aWJbU24g3sM1JNOFxQj4zJekZmVA9wNMGJlwDjq3MxOt659EdB+or4l0p6qck9fm0zGBJl7HFMYow3eBWdSySH/ZP5FxBajJBhfmb0gBB08XWRcN56jSPoMKtXgfJRXQU3cdUJm5Lk464b6drIKTdma04nyHtbuHW3juA5pGst4ZdKNd21xM7tVhlDaLuNASze/4tGzgZav8laWVBRvXDlmPv045h41FkX5QPI5WfOKLaEaKq2mxzX/E6aW0/PKgunEDhZFJQ2FXWP4tI1SFmE39fK2nMRH2eDpYj5W4zwEQbwHGOtpCiuOvsL7RN/6DwLY1gmI4cQZaQk8M+t6KHV6lWlHl9jHVIzCKEfTYHTSD8JzKWqYLHdq+wbAILAN4VNoJpugc3Xbz+czoj2FuYjrFHfhewNvm8+gMGYKnFWJzfXXR24/1ssLB3I68DoJML3t+ctAyOpTWMgTmBxKohu4QxSBInUQT 3QTddAym 30khqlTURtfVHskCxASy99+PPHxXUhfUQrdoocewlKXYTWMnkM1yIJ0FXb1yzFzB9/Hul+8T7H5NQ3iYx4MPrs3OlHSp0OMPh6xC/oulIp+XDQJl3zUqqraz765psH78V2XNPyVFnMYVJ0HDt29kFId5cN8TxPPDcSrhj98icPk1Vykd7WgMrRMqLWs/1NdJXWpMk2cX2f1zHVSIh/Fb7ttaJ6RoJyi0sBbpZ9bdr4UJAhV4L6wkG8Gl5voJEbUiSMoiPxLUDfezomo6Us/KgXrvpjrAITmvuj012Bboispl/JZ1JmXNNP2WMojiP21Tn2e1uijBwqmUlC6+U3yeZPjt6/XukqteSFh0B4tH+73EoSZ1fRI9RFQ8IO5iYpleqjpLg+0+JweOmSrxBbC0lAgtQ5/8M4LXbRw5+eiGM2T/FrIcEJjcimPqf2I2FhM7wLEd5QQIZfot/bsfFwMYMbB7G2CFutGHoXUJXNa2GmqQccbBMo6otts8Qi5FR1OLUUfmweBxiHM7ru35FItXVd2/y6Bu4AMnzE2C/t+dsGml4jz8= X-Bogosity: Ham, tests=bogofilter, spamicity=0.328600, 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 3 Feb 2025, at 9:32, Asahi Lina wrote: > On 2/3/25 6:58 PM, Simona Vetter wrote: >> On Sun, Feb 02, 2025 at 10:05:42PM +0900, Asahi Lina wrote: >>> This series refactors the existing Page wrapper to support borrowing >>> `struct page` objects without ownership on the Rust side, and convert= ing >>> page references to/from physical memory addresses. >>> >>> The series overlaps with the earlier submission in [1] and follows a >>> different approach, based on the discussion that happened there. >>> >>> The primary use case for this is implementing IOMMU-style page table >>> management in Rust. This allows drivers for IOMMUs and MMU-containing= >>> SoC devices to be written in Rust (such as embedded GPUs). The intend= ed >>> logic is similar to how ARM SMMU page tables are managed in the >>> drivers/iommu tree. >>> >>> First, introduce a concept of Owned and an Ownable trait. These ar= e >>> similar to ARef and AlwaysRefCounted, but are used for types which= >>> are not ref counted but rather have a single intended owner. >>> >>> Then, refactor the existing Page support to use the new mechanism. Pa= ges >>> returned from the page allocator are not intended to be ref counted b= y >>> consumers (see previous discussion in [1]), so this keeps Rust's view= of >>> page ownership as a simple "owned or not". Of course, this is still >>> composable as Arc> if Rust code needs to reference count = its >>> own Page allocations for whatever reason. >> >> I think there's a bit a potential mess here because the conversion to >> folios isn't far enough yet that we can entirely ignore page refcounts= and >> just use folio refcounts. But I guess we can deal with that oddity if = we >> hit it (maybe folio conversion moves fast enough), since this only rea= lly >> starts to become relevant for hmm/svm gpu stuff. >> >> iow I think anticipating the future where struct page really doesn't h= ave >> a refcount is the right move. Aside from that it's really not a refcou= nt >> that works in the rust ARef sense, since struct page cannot disappear = for >> system memory, and for dev_pagemap memory it's an entirely different >> reference you need (and then there's a few more special cases). > > Right, as far as this abstraction is concerned, all that needs to hold > is that: > > - alloc_pages() and __free_pages() work as intended, however that may > be, to reserve and return one page (for now, though I think extending > the Rust abstraction to handle higher-order folios is pretty easy, but > that can happen later). > - Whatever borrows pages knows what it's doing. In this case there's > only support for borrowing pages by physaddr, and it's only going to be= > used in a driver for a platform without memory hot remove (so far) and > only for pages which have known usage (in principle) and are either > explicitly allocated or known pinned or reserved, so it's not a problem= > right now. Future abstractions that return borrowed pages can do their > own locking/bookkeeping/whatever is necessary to keep it safe. > > I would like to hear how memory hot-remove is supposed to work though, > to see if we should be doing something to make the abstraction safer > (though it's still unsafe and always will be). Is there a chance a > `struct page` could vanish out from under us under some conditions? Add DavidH and OscarS for memory hot-remove questions. IIUC, struct page could be freed if a chunk of memory is hot-removed. Another case struct page can be freed is when hugetlb vmemmap optimizatio= n is used. Muchun (cc'd) is the maintainer of hugetlbfs. > > For dev_pagemap memory I imagine we'd have an entirely different > abstraction wrapping that, that can just return a borrowed &Page to giv= e > the user access to page operations without going through Owned. > >> For dma/iommu stuff there's also a push to move towards pfn + metadata= >> model, so that p2pdma doesn't need struct page. But I haven't looked i= nto >> that much yet. > > Yeah, I don't know how that stuff works... > >> >> Cheers, Sima >> >>> Then, make some existing private methods public, since this is needed= to >>> reasonably use allocated pages as IOMMU page tables. >>> >>> Along the way we also add a small module to represent a core kernel >>> address types (PhysicalAddr, DmaAddr, ResourceSize, Pfn). In the futu= re, >>> this might grow with helpers to make address math safer and more >>> Rust-like. >>> >>> Finally, add methods to: >>> - Get a page's physical address >>> - Convert an owned Page into its physical address >>> - Convert a physical address back to its owned Page >>> - Borrow a Page from a physical address, in both checked (with checks= >>> that a struct page exists and is accessible as regular RAM) and not= >>> checked forms (useful when the user knows the physaddr is valid, >>> for example because it got it from Page::into_phys()). >>> >>> Of course, all but the first two have to be `unsafe` by nature, but t= hat >>> comes with the territory of writing low level memory management code.= >>> >>> These methods allow page table code to know the physical address of >>> pages (needed to build intermediate level PTEs) and to essentially >>> transfer ownership of the pages into the page table structure itself,= >>> and back into Page objects when freeing page tables. Without that, th= e >>> code would have to keep track of page allocations in duplicate, once = in >>> Rust code and once in the page table structure itself, which is less >>> desirable. >>> >>> For Apple GPUs, the address space shared between firmware and the dri= ver >>> is actually pre-allocated by the bootloader, with the top level page >>> table already pre-allocated, and the firmware owning some PTEs within= it >>> while the kernel populates others. This cooperation works well when t= he >>> kernel can reference this top level page table by physical address. T= he >>> only thing the driver needs to ensure is that it never attempts to fr= ee >>> it in this case, nor the page tables corresponding to virtual address= >>> ranges it doesn't own. Without the ability to just borrow the >>> pre-allocated top level page and access it, the driver would have to >>> special-case this and manually manage the top level PTEs outside the >>> main page table code, as well as introduce different page table >>> configurations with different numbers of levels so the kernel's view = is >>> one lever shallower. >>> >>> The physical address borrow feature is also useful to generate virtua= l >>> address space dumps for crash dumps, including firmware pages. The >>> intent is that firmware pages are configured in the Device Tree as >>> reserved System RAM (without no-map), which creates struct page objec= ts >>> for them and makes them available in the kernel's direct map. Then th= e >>> driver's page table code can walk the page tables and make a snapshot= of >>> the entire address space, including firmware code and data pages, >>> pre-allocated shared segments, and driver-allocated objects (which ar= e >>> GEM objects), again without special casing anything. The checks in >>> `Page::borrow_phys()` should ensure that the page is safe to access a= s >>> RAM, so this will skip MMIO pages and anything that wasn't declared t= o >>> the kernel in the DT. >>> >>> Example usage: >>> https://github.com/AsahiLinux/linux/blob/gpu/rust-wip/drivers/gpu/drm= /asahi/pgtable.rs >>> >>> The last patch is a minor cleanup to the Page abstraction noticed whi= le >>> preparing this series. >>> >>> [1] https://lore.kernel.org/lkml/20241119112408.779243-1-abdiel.janul= gue@gmail.com/T/#u >>> >>> Signed-off-by: Asahi Lina >>> --- >>> Asahi Lina (6): >>> rust: types: Add Ownable/Owned types >>> rust: page: Convert to Ownable >>> rust: page: Make with_page_mapped() and with_pointer_into_page(= ) public >>> rust: addr: Add a module to declare core address types >>> rust: page: Add physical address conversion functions >>> rust: page: Make Page::as_ptr() pub(crate) >>> >>> rust/helpers/page.c | 26 ++++++++++++ >>> rust/kernel/addr.rs | 15 +++++++ >>> rust/kernel/lib.rs | 1 + >>> rust/kernel/page.rs | 101 ++++++++++++++++++++++++++++++++++++++---= ----- >>> rust/kernel/types.rs | 110 +++++++++++++++++++++++++++++++++++++++++= ++++++++++ >>> 5 files changed, 236 insertions(+), 17 deletions(-) >>> --- >>> base-commit: ffd294d346d185b70e28b1a28abe367bbfe53c04 >>> change-id: 20250202-rust-page-80892069fc78 >>> >>> Cheers, >>> ~~ Lina >>> >> > > ~~ Lina -- Best Regards, Yan, Zi