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 E0BDEE7717F for ; Tue, 17 Dec 2024 14:12:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5E0736B0085; Tue, 17 Dec 2024 09:12:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 590656B00A2; Tue, 17 Dec 2024 09:12:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 458A86B00A3; Tue, 17 Dec 2024 09:12:53 -0500 (EST) 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 256EE6B0085 for ; Tue, 17 Dec 2024 09:12:53 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id CCF001407AF for ; Tue, 17 Dec 2024 14:12:52 +0000 (UTC) X-FDA: 82904641596.11.E8C49DA Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) by imf07.hostedemail.com (Postfix) with ESMTP id 7397340007 for ; Tue, 17 Dec 2024 14:12:06 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="QG/XTX+e"; spf=none (imf07.hostedemail.com: domain of joonas.lahtinen@linux.intel.com has no SPF policy when checking 192.198.163.9) smtp.mailfrom=joonas.lahtinen@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1734444742; a=rsa-sha256; cv=none; b=EmQctyJy8wAmezE9L7qbua0XbdHzYBsDeJAKt3/R7u02vto5AJV8U6Akm+Q8GLbvD+N7Cf CnJtE+Q9ghtyVXwir1d79XWH5ZfN5Ap5+FK5n8OQamvZuSfjZXzjVhMnPR7N4Nkx6KCMfU 0XWBlx5JUUA6uuIud4k9yShQxOefAdo= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="QG/XTX+e"; spf=none (imf07.hostedemail.com: domain of joonas.lahtinen@linux.intel.com has no SPF policy when checking 192.198.163.9) smtp.mailfrom=joonas.lahtinen@linux.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=1734444742; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=WQeDsBG8Xb60fbsVJMF44Ap7714U+AgkDvuRAXju284=; b=n4jzZoc/c25UiDbW/lbyjvE7IUXSn36/4zCUoLiV4upOi7t7wF43GW6GYUCscHcH9wGCgd Cx7G4AQpYIn4lc9qtQwkj3KdiENGuEkJQk2QhZf2CgodyhtHcDw9VcKSyjueoSW4zVrjBn lY6E0iHy39QeQQlcJkIikZS0NglTcGs= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1734444770; x=1765980770; h=mime-version:content-transfer-encoding:in-reply-to: references:subject:from:to:date:message-id; bh=CaJltsNoeXmQRM5tsrufBanE2Qh55lz8mcyu1kKLRZI=; b=QG/XTX+eAThC7/3HonoWBVCrtW2JsBOuSdUxJoC0eBa6Xl7XMZ2/DdvW 1gUAvIlJjwrOeimifG0VYvLActud1v90005KM99GZLG1EOcoQKnc/2BLC H8VkkVYGl2jSSLpjkK+JwpF8a23lZ+Bbs+1spt8b/drPc+ZZbClvxAdx/ s/gGYgyGz/CRk2dh8f0jH3JZEquTnHbRkQru+b7+CWefRUeO5X8ANMduL QO/TYi0ShW9cmoSKCUwNJ+V4Qs3i3vgPIS2MLISAXO6zGxQG1YZUegr3x jZXL8Xvye3zCWv9rBc5sK19bk8N15KjWwliz7DWf2353CMYFpD3U1zZRi A==; X-CSE-ConnectionGUID: uY4TqEusTDKls40U88dmdA== X-CSE-MsgGUID: TK8eWWHuR9usqAgE1JWP/g== X-IronPort-AV: E=McAfee;i="6700,10204,11288"; a="45565580" X-IronPort-AV: E=Sophos;i="6.12,242,1728975600"; d="scan'208";a="45565580" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Dec 2024 06:12:49 -0800 X-CSE-ConnectionGUID: 6xIGBbAZRg24d1z6RCCp5w== X-CSE-MsgGUID: 7t8X2hqiRQ2+hLjYJM4LUA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.12,242,1728975600"; d="scan'208";a="97588802" Received: from johunt-mobl9.ger.corp.intel.com (HELO localhost) ([10.245.245.114]) by orviesa006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Dec 2024 06:12:46 -0800 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: <173392197322.40386.12252741494998606453@jlahtine-mobl.ger.corp.intel.com> References: <20241209133318.1806472-1-mika.kuoppala@linux.intel.com> <20241209133318.1806472-15-mika.kuoppala@linux.intel.com> <173382321353.8959.8314520413901294535@jlahtine-mobl.ger.corp.intel.com> <173383187817.17709.7100544929981970614@jlahtine-mobl.ger.corp.intel.com> <173392197322.40386.12252741494998606453@jlahtine-mobl.ger.corp.intel.com> Subject: Re: [PATCH 14/26] drm/xe/eudebug: implement userptr_vma access From: Joonas Lahtinen To: Andrzej Hajda , Christian =?utf-8?q?K=C3=B6nig?= , Christoph Hellwig , Jonathan Cavitt , Linux MM , Maciej Patelczyk , Mika Kuoppala , dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org, lkml Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Date: Tue, 17 Dec 2024 16:12:42 +0200 Message-ID: <173444476233.58433.15197725556816943129@jlahtine-mobl.ger.corp.intel.com> User-Agent: alot/0.10 X-Rspamd-Queue-Id: 7397340007 X-Stat-Signature: wj9h9xqor5ackmq9gjdcjoskn5w16o5j X-Rspam-User: X-Rspamd-Server: rspam09 X-HE-Tag: 1734444726-560860 X-HE-Meta: U2FsdGVkX1+Yk3bJfdj3UU8SSEKDRyS8ZIhZtmoyNvVLQmSRFIG3986Tjp13qFAKWbDha8t1abcvISfDkAkWJ/5TtKbM0IrhEtGqjRx+Ia4OkJHOMY3VZmCESB+YQnU84WwWp8qsxGoBOBO+k5zJWbzF5MtZe0R33klXvL0QT30fQBjUEeZW+qFqLlpF1tBFktrbIBJpQHglK1ohDRW+tjnKyjjvyauaNrIflthMNPgNcHb+j2i6GSuS/KwHSNC7ZVSLDUriVE42xZXHGfrXT2QgW7grlv1vPMQDHPREAJnyJZ75UekAsbkzXSNA53+UmwigYEECzYtOYoTOUmQExmh5P8Ycv25AnhGI2+kg+lltyI1dHksdIajcqZtqVQYsDSNvbMUEl32U5AEfcopyKIuAtgBeof7STzTG6ouErMBkVxk78tHLc+nmpu7YstZFESa+r1Lb8YB2SFVMCTtarmwZsfritAnn7DfJPG/j0tHGM43Hnu0RcL5yNfN+4DJNi3jJnhAoGrp0JHEpA7TjR/FYo6sxKYRUOmU3kg9V+LjGs9ReVYV/DywGqWbMKNEWecEBPWLe4giNDnpU4WR0t9e6L+mHP1OCrRu26Ar/z46lXPaaaTo/ajjNRQHs+Y8XydUjUP89Z6C0Xzh73ip/3eAV1g5qXw+mYDTe6DjXVui0rovYQM4xbaa0ipb2UhR+as4peTclVwvMf2OC6C/LF+do7SKR5X8UNp97hrE4fZJHS3ZiEH+iY1AKw2aipCd/k7c9xYc6UfinSUP7CrLlIp2WLY9I+sB/zoEOdjlBPMc1mnlCZv0uNhetN8upWzvXsJ56oPRcOye/wN0TXhsekYNlo19Hn/bR8Rz83WvXZ7rXvFRdsfUDtmAB9Djm2S8OvzM/U/OFLHqqddW3hhUwLM46W4sG6LRG55oqTzVtyV6xKynVI9x8XfANd6AFWg7W8YlvF0ce7oYL4WlpWZ7 7gwMOA3U RdQcBUdexDJwlH+f1X4QrK0JR5tiOP+/f985gxq38JoC3HZ4SshLeZeSMymvQl+8/KTsDj8SEJiYOn98xoSBte7ROwb5HZh/OS13Yg24JMtOTMh0QJRfTGBMtXww0/ALDbO1MaaslRdpEuhUzXBut65WdZpCUZpRfkzswAyzyyseMex8Ezo5dNSR6t/49xkXPEbG1VUH9wxgt7Wf9NPPPppeZ6NUxw2nLl5I+oj0bL3nPbHMiwaLb8/W8TJiv0YDiR+nSS/OcQORQegNKkgS52yfYJg== 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: Quoting Joonas Lahtinen (2024-12-11 14:59:33) > Quoting Christian K=C3=B6nig (2024-12-10 16:03:14) > > If you really want to expose an interface to userspace which walks the = process > > page table, installs an MMU notifier, kmaps the resulting page and then= memcpy > > to/from it then you absolutely *must* run that by guys like Christoph H= ellwig, > > Andrew and even Linus. > > I'm pretty sure that those guys will note that a device driver should > > absolutely not mess with such stuff. > > But that seems like a high-overhead thing to do due to the overhead= of > > setting up a transfer per data word and going over the PCI bus twice > > compared to accessing the memory directly by CPU when it trivially = can. > >=20 > >=20 > > Understandable, but that will create another way of accessing process m= emory. Based on this feedback and some further discussion, we now have an alternat= ive implementation for this interface via access_process_vm function posted by = Mika: https://lore.kernel.org/dri-devel/20241216141721.2051279-1-mika.kuoppala@li= nux.intel.com/ It's a couple of dozen lines don't need to do any open-coded kmapping, only= utilizing the pre-existing memory access functions. Hopefully that would address the above concerns? Regards, Joonas PS. It could still be optimized further to directly use the struct mm from within the mm notifier, and go with access_remote_vm using that, but would require new symbol export. For demonstration it is implemented by grabbing the task_struct and using the already exported access_process_vm function.