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 8CF8AE77188 for ; Fri, 20 Dec 2024 12:47:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B87E86B007B; Fri, 20 Dec 2024 07:47:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B37896B0083; Fri, 20 Dec 2024 07:47:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9FFF56B0085; Fri, 20 Dec 2024 07:47:51 -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 81FCB6B007B for ; Fri, 20 Dec 2024 07:47:51 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id C3B5FC0A7D for ; Fri, 20 Dec 2024 12:47:10 +0000 (UTC) X-FDA: 82915312242.02.09A45FF Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.15]) by imf09.hostedemail.com (Postfix) with ESMTP id C760214000B for ; Fri, 20 Dec 2024 12:46:44 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=AEh9gXgz; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf09.hostedemail.com: domain of mika.kuoppala@linux.intel.com has no SPF policy when checking 198.175.65.15) smtp.mailfrom=mika.kuoppala@linux.intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1734698812; a=rsa-sha256; cv=none; b=CD80TJmPIpq9ZooMgZIhHIDQQVHw47joQ27GRsgtqrGS3FITqVI++O4J1YUbgMEgHRwxxK 8YZHrb+WBjRQW2xL1j4u2EhttMbNzDqe5iwnW/84Fen78HgCHVR7x2YRPVbrNc2KIkD2Pk evkWOkvDkxdmrLWLoKpn5PQLXAWc7q4= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=AEh9gXgz; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf09.hostedemail.com: domain of mika.kuoppala@linux.intel.com has no SPF policy when checking 198.175.65.15) smtp.mailfrom=mika.kuoppala@linux.intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1734698812; 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=SOg6VJxXg7L7f/2E8680WtIbgff7nwAYHCfPTEAsHb4=; b=2tHmHz+s8qfEsp40xQMCU6cAlO67aJ02+vreydmYnfvAIHLkbUBnt+NUygQ9FYIzwtsiOO LRKT2gHJPF3xcW9ZqLSiWuY+oqquJZj8r17oNzCC1NCyhpUuP5M+VpSdcXC3NbCls0Y8bz 0ewrB4XuyKoANJJQjxc2ri1gkQe4pi4= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1734698829; x=1766234829; h=from:to:subject:in-reply-to:references:date:message-id: mime-version:content-transfer-encoding; bh=5Ocn+jWFBDXcvVZEroyNzYUYmGQOLYPSqU5A1IFsIBA=; b=AEh9gXgz10X/LhYbMlPkFnsmsZE7iQ+dELPRQHHQuMLFYVWMhyn2iBA0 d5n5M8X198yM3oaGpCpcn+f/kRBh27/PCJQQuz2U1DWD6JeXpG1vt4JUp gR8rqD9XlsM1r1dbDLwMG4A+XM50169wMs5EPxjUMrHLsIbNhZ2XvitEz gh88vYncBICXAgWvB6L2B0rz31nnJWHm/Dhl8l74uteAar1yscIhXeTm0 PS87qlT7Klt0iCKBZfYt5dkIb1FPAdrymoZTTd2Zo27n6IYenFtxU6jID x9xbMeQR7af4IjHGz1S92B4gBCazmh/rG0QWfB6xs0SQcQisZvJEYwIEk Q==; X-CSE-ConnectionGUID: FLlXhJWOQCafxN/gz4kuEQ== X-CSE-MsgGUID: 0ThOmdT3TSOYGRCJPvIzYQ== X-IronPort-AV: E=McAfee;i="6700,10204,11292"; a="38930593" X-IronPort-AV: E=Sophos;i="6.12,250,1728975600"; d="scan'208";a="38930593" Received: from fmviesa003.fm.intel.com ([10.60.135.143]) by orvoesa107.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Dec 2024 04:47:07 -0800 X-CSE-ConnectionGUID: 3nxr9j4TQiGTtaDiu+bX2g== X-CSE-MsgGUID: Zn5u0Kx8TyiSvB26rr6IzQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.12,224,1728975600"; d="scan'208";a="102634360" Received: from mkuoppal-desk.fi.intel.com (HELO localhost) ([10.237.72.193]) by fmviesa003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Dec 2024 04:47:04 -0800 From: Mika Kuoppala To: Joonas Lahtinen , Andrzej Hajda , Christian =?utf-8?Q?K=C3=B6nig?= , Christoph Hellwig , Jonathan Cavitt , Linux MM , Maciej Patelczyk , dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org, lkml Subject: Re: [PATCH 14/26] drm/xe/eudebug: implement userptr_vma access In-Reply-To: <173444476233.58433.15197725556816943129@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> <173444476233.58433.15197725556816943129@jlahtine-mobl.ger.corp.intel.com> Date: Fri, 20 Dec 2024 14:47:17 +0200 Message-ID: <87o716bjxm.fsf@mkuoppal-desk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: C760214000B X-Stat-Signature: e89r5n3xbhjb6ff6kjroc9zjchjd45kx X-HE-Tag: 1734698804-469762 X-HE-Meta: U2FsdGVkX180r5YQAIfnthqBNx1s5qozsKPal+U+t0uSGkgE8DGAJnqCh2vFLPrTvxeIZbGKtKCQCv8XYEfM2s7RnpI82aU8yI0cE2Lutg7LyoGUsxsufCV9SQ8I+uS03yoB8JkE6jnaOWEdey1bq1wopG89EBEiaddmP/Hr0c26uOQG2eyYp/VfliFPre/wsJIWeqZUSfhcsKgJMEY4kTRhPDlpZ4YaW55GgUBdJvWRCGrGvHpV+i7L1wN1ucLuQcSW/bOmCVLhbmMAf1H5P362abAEw/aZxzd1t/5//OTU33TLUY35cBDyIdlIiiZyG2RoYHPtNVOlFWLKmE8hUX7kF+SaXH+5S5vXxMh4w8sbM/ZEow0arzZHr8GDuOk8x1sMv3zerqV8BWHCvs2o1dPtASM94Z7naEU3RiELOppqO7hZ12Wy/nx6zePENUILBEh6Ku7yBKpv8+lJeVcyIEAn3p/KqAoWfo8vJzQGHOI9EdgrdYLpDz3TnnkzXreSEo2GEg5nlEyr9rGbM1+kwhnDVwp9xVdr2zdhiaZzbXf3mHWDQTlDOfg6sm4+/K8wjZrty4Pt6DQtjnDCE08emkWIWzjKXfJrk01XhoiR1Bv0NOnGXilGSUjbUkuqhss10xR9HkM2obf39tKGTcGJtxpqCJ0FQSF66xQeRHlcSGnrYAISV/xfHWvgIwPLMWo39OZfrT1l7BntymkLXZIdd+1c86/ckE/P5kzgspNE4ZFPac2NK31XhE4z930DM77D4hUfU/QUltHt2wuqHySXyQ3XJDO+HOURbJEMxzQNgPlS/E3YevmjLDdN/kqQo3NBFODF4QYDTu7quxWeKZJY6BNmwNDLLPQjA/Jk2D8qSvbP0UhtOZe2eixYgt7wdcA8QdAD7q3KnweYb1ANGDCkqpykoyh4FFBHZwIWE8hA2Ia96+R7E5GLRXoJMGglld1pkVGGTTMbenHtRfSGTId FgkKSWV5 5dXfCyU1+kHaYQOubrR8gVHInKY0qalJcrd48Citcdn9V36w+tpBxyRTGiJgAF+n0VduFSqddY1JhcxJFsRMYkrXc3izpDIqa2MFM5g+DbwCtPe7Ulve7VC4gbARkmwRUJIzZRBFbsvt28fk7t18UrqkCXzfmPdu/qti5lmaDZeWRrIk2NP1yKW9xAYXN5thLPkoiog44GVGUZtJHzubfHkr9AYjFCrGFaimk/uBWqhlr7+QqUp3QN4MBIlLPJWI1wETbSaGZIeowAO0tQd/4cR83Ig== 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: Joonas Lahtinen writes: > 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 the= n memcpy >> > to/from it then you absolutely *must* run that by guys like Christoph = Hellwig, >> > 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 overhea= d of >> > setting up a transfer per data word and going over the PCI bus twi= ce >> > compared to accessing the memory directly by CPU when it trivially= can. >> >=20 >> >=20 >> > Understandable, but that will create another way of accessing process = memory. > > Based on this feedback and some further discussion, we now have an altern= ative > implementation for this interface via access_process_vm function posted b= y Mika: > > https://lore.kernel.org/dri-devel/20241216141721.2051279-1-mika.kuoppala@= linux.intel.com/ v2: https://lore.kernel.org/dri-devel/20241220113108.2386842-1-mika.kuoppala@li= nux.intel.com/ -Mika > > It's a couple of dozen lines don't need to do any open-coded kmapping, on= ly 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.