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 3BB87E77180 for ; Mon, 9 Dec 2024 14:56:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A954E8D0074; Mon, 9 Dec 2024 09:56:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A45368D0058; Mon, 9 Dec 2024 09:56:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 90D7F8D0074; Mon, 9 Dec 2024 09:56:39 -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 7157B8D0058 for ; Mon, 9 Dec 2024 09:56:39 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id F061B413FA for ; Mon, 9 Dec 2024 14:56:38 +0000 (UTC) X-FDA: 82875721908.29.2A089F7 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.19]) by imf12.hostedemail.com (Postfix) with ESMTP id 1B61B4000C for ; Mon, 9 Dec 2024 14:56:26 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=isIj14d8; spf=none (imf12.hostedemail.com: domain of joonas.lahtinen@linux.intel.com has no SPF policy when checking 192.198.163.19) 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=1733756182; 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=ncan0i9FwcxOUNgfxLQ003Y5QRVaSUmRIH1Mp+TCpfE=; b=LW8bFJkkygxRQlEyoR3HV6ASPZ2YAMPk2G1OJAMhy3D/QVIPi+Redxo/LxeDMVx0BXMEmr xOM5Lj1bHlUPtfBRtO8LwPNBdu6eiQc4D6Dwd98cN3Vkosqb2Z2sZ4Ut34L+RnZfxJfDq3 AlBagjww7YRYxhnvcLHWaGLxV2p0kTk= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=isIj14d8; spf=none (imf12.hostedemail.com: domain of joonas.lahtinen@linux.intel.com has no SPF policy when checking 192.198.163.19) 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=1733756182; a=rsa-sha256; cv=none; b=3d0p4j4EapbhIanitwGc6KJT5GOAYtf86qEcPOrPbI09a0vETg/USvpEkhY6RlMYymvlwg JSetTjVZD6tpNiHtJ4d+LSFumsuy1+xrDmgb9hdFpetgHPBYz8KAIrYZZHRi7h6gCCxh5J XQIC17BqI7HWqqSWTSovUOWkO23upj8= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1733756196; x=1765292196; h=mime-version:content-transfer-encoding:in-reply-to: references:subject:from:cc:to:date:message-id; bh=M821XkMANGnBdOvsES314MxDQe7jNUJxNR/3OnCtFkY=; b=isIj14d8FlISjOvcKUyOYU8fVX1qWZTNPmU7lhENgaIVZ5jUz/u9wEaj u+K023vTsZJ8yCvBWZHC39LvtLFrRHEOdMzN84j0tKxNfntwq6Na8OnKj WnW9cIljGwQ+BQN87AmuBBPfPucVwMkvEwcoXMpDZ2abL7uCbkfWeQtJe SY6+gdXDWTtAiwwKWBk8ZK/l6AQnEBNYGV9hYtxNbB5uvFoM9SmATRm5X 4rfmub/ML6lnEHY/mpshcw72OXyT4xQUdq7ofOgQXd0QZ0FJqYVkqIZOq 9P6X/uy2Dta6QkKLi7Y/tkgIllKtibJWAIl/Tp/U2lREgzPmNLnFlX5nE w==; X-CSE-ConnectionGUID: Bg40S+M5R2abxcamZbDYwg== X-CSE-MsgGUID: 4Fxcc7pMQa+LxP84UN86mA== X-IronPort-AV: E=McAfee;i="6700,10204,11281"; a="33400351" X-IronPort-AV: E=Sophos;i="6.12,219,1728975600"; d="scan'208";a="33400351" Received: from fmviesa003.fm.intel.com ([10.60.135.143]) by fmvoesa113.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Dec 2024 06:56:35 -0800 X-CSE-ConnectionGUID: Q0zMiV15TV2gVhc8JYz50w== X-CSE-MsgGUID: /uSc00CUQ5iCx4fLum23xg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.12,219,1728975600"; d="scan'208";a="99153215" Received: from bergbenj-mobl1.ger.corp.intel.com (HELO localhost) ([10.245.245.68]) by fmviesa003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Dec 2024 06:56:32 -0800 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: References: <20241209133318.1806472-1-mika.kuoppala@linux.intel.com> <20241209133318.1806472-15-mika.kuoppala@linux.intel.com> Subject: Re: [PATCH 14/26] drm/xe/eudebug: implement userptr_vma access From: Joonas Lahtinen Cc: dri-devel@lists.freedesktop.org, Andrzej Hajda , Maciej Patelczyk , Jonathan Cavitt , Thomas Hellstrom , Matthew Brost To: Christian =?utf-8?q?K=C3=B6nig?= , Linux MM , Mika Kuoppala , intel-xe@lists.freedesktop.org, lkml Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Date: Mon, 09 Dec 2024 16:56:28 +0200 Message-ID: <173375618882.78106.6396051881160152426@jlahtine-mobl.ger.corp.intel.com> User-Agent: alot/0.10 X-Rspamd-Server: rspam05 X-Stat-Signature: ewwr6wtdw3z5z8iaj3yhaucq6d6o19my X-Rspamd-Queue-Id: 1B61B4000C X-Rspam-User: X-HE-Tag: 1733756186-34510 X-HE-Meta: U2FsdGVkX19gZjAt4EKkJzYHgRUpRADqI8vhsI1OR5RJZZdm0kj88a9UHdeS76T2AE/Wt6ptyD65mk22WVOL3hFmpPy4F+j4TyZITT5aXiT0itdkY/Eq6CTfRUFxqZ82EMg/0WIgDKquz+0FPAZYtQvbGUkVCJ75AKNjWfhZMWbvpPJN4d+zC/NMHmRXQLt1l7B2qhBmz6BevzVY81CwaMGC7uOyBhzVPg0tZ/hTzCT3fVyszLlsBd5eKsnCrd/Yg5kwbrJMgdNw+7zNRGLkVoPIqqmqrVxVlET81NNkpQ6MuBkLt0Dm2ISUzRUTvaep7KgMb9/fY7K+Hd5dtgUU3/PARS8a3pojax1BIQSADy1BeOni90IjHis0tX8q5wn+zOhNdi8nD6oWZmRHReLoulvydpqobKQGKIwa5oK4TQurVUg8BlWL/GxA20/f561qhW9FzUPnIlN8R/MzW3YNsnDtbAXxkQiOPkRo0NN3GsMUe0wo/4zR05ZjP1wD7I69uDGbdwd6oB+RJH/Qbqor/EyZer2ZoQR06ky87GMPYog3tcmGFVYVF6GSCwf7pfctgw6YKHmZuyMA1yM1S/0WikSFqB1lnd05iWWGBTQkx4vndajCACYQnEbZ10Q2nsK2IwN7Q18FZX2QiUVnWKB4W0HaTYWBelfqddKePtV6cxqQLjii5amggyfvbKWpCVOLPyFAyOfvsV2EAirUxsB7I/xWEL5k74mKCcGmlf12U3jQmMKW9RxKq0YEmt77KqukVhBfrSCfTgeeMiG9G89sC05ID2tLDyPJ5ty+NBlX3n/7WRPZjp3xwrTDXRJPdHHa2maBrwb+C6/fhv60ShLDtRbYkZ6wrZb3qRV+LI+IjMOTeJGWbnZ+HIJTX115peybwV+aEXnfK+uVmTjxhPYsuTKuJrQwMyq5sW6M/6mnii3iO8juOI2tXQd25Cju5pm0D0innDSrKRXLnZdaCSc 5YIsQmP2 IOH3wczTpis8xIj/7N2I4V8KRz98/OsoZYDCmM/hDicnIug3YI5jnhw5dJ7egzrqhsgiggScq2pgB59dVLVzkVvFumoJ436ivCXCTqbsdw8ygjKLQ1i6tKz+VCjmRPAfCnruC4UPjNEnDObbiAvur9lYSHTqe2DvziMX0yb9/6CetBDBPkK3itADXzoF0glBEg7ND69jP6bpXJilUHcr/4zzoerHYyaNjdskYWtgxw7qAX9U= 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: (+ Thomas and Matt B who this was reviewed with as a concept) Quoting Christian K=C3=B6nig (2024-12-09 16:03:04) > Am 09.12.24 um 14:33 schrieb Mika Kuoppala: > > +int xe_vm_userptr_access(struct xe_userptr_vma *uvma, u64 offset, > > + void *buf, u64 len, bool write) > > +{ > > + struct xe_vm *vm =3D xe_vma_vm(&uvma->vma); > > + struct xe_userptr *up =3D &uvma->userptr; > > + struct xe_res_cursor cur =3D {}; > > + int cur_len, ret =3D 0; > > + > > + while (true) { > > + down_read(&vm->userptr.notifier_lock); > > + if (!xe_vma_userptr_check_repin(uvma)) > > + break; > > + > > + spin_lock(&vm->userptr.invalidated_lock); > > + list_del_init(&uvma->userptr.invalidate_link); > > + spin_unlock(&vm->userptr.invalidated_lock); > > + > > + up_read(&vm->userptr.notifier_lock); > > + ret =3D xe_vma_userptr_pin_pages(uvma); > > + if (ret) > > + return ret; > > + } > > + > > + if (!up->sg) { > > + ret =3D -EINVAL; > > + goto out_unlock_notifier; > > + } > > + > > + for (xe_res_first_sg_system(up->sg, offset, len, &cur); cur.remai= ning; > > + xe_res_next(&cur, cur_len)) { > > + void *ptr =3D kmap_local_page(sg_page(cur.sgl)) + cur.sta= rt; >=20 > The interface basically creates a side channel to access userptrs in the = > way an userspace application would do without actually going through=20 > userspace. That's not quite the case here. The whole point of the debugger ability to access memory is to access any VMA in the GPU VM emulating as much as possible like the EUs themselves would do the access. As mentioned in the other threads, that also involves special cache flushes to make sure the contents has been flushed in and out of the EU caches in c= ase we're modifying instruction code for breakpoints as an example. What the memory access function should do is to establish a temporary pinning situation where the memory would be accessible just like it would be for a short batchbuffer, but without interfering with the command stream= ers. If this should be established in a different way from this patch, then we should adapt of course. > That is generally not something a device driver should ever do as far as = > I can see. Given above explanation, does it make more sense? For debugging purposes, we try to emulate the EU threads themselves accessing the memory, not the userspace at all. Regards, Joonas