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 F36AEE7717D for ; Mon, 9 Dec 2024 15:31:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F14768D007D; Mon, 9 Dec 2024 10:31:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E02B48D0058; Mon, 9 Dec 2024 10:31:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B434B8D007D; Mon, 9 Dec 2024 10:31:26 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 7BB558D0058 for ; Mon, 9 Dec 2024 10:31:26 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 215AE160509 for ; Mon, 9 Dec 2024 15:31:26 +0000 (UTC) X-FDA: 82875809520.28.1D6F77E Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) by imf03.hostedemail.com (Postfix) with ESMTP id 0CE8C2001A for ; Mon, 9 Dec 2024 15:31:09 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=ffwll.ch header.s=google header.b=P5Cpihs+; spf=none (imf03.hostedemail.com: domain of simona.vetter@ffwll.ch has no SPF policy when checking 209.85.128.41) smtp.mailfrom=simona.vetter@ffwll.ch; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1733758266; 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=rRrwKagbDkhwxnLFjd7MS7qeMP3V5ZX0pRGxISFGQGY=; b=lkzMCjXFKWLpWHD25Uev8bloWmhzDgs9Z0GyR8w2usj7ALBtLFuYCYwQY9Epm6SJrDdF/i 9UTx4g52nwknwYeeP0AYntCa+PF6WpCaUST91UhEvI+LgLMw/ALOFH/+z84OsEIOxh2Lzm 1I2xT93ZTT58nhWmSZITjIQn/M8tFPk= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=ffwll.ch header.s=google header.b=P5Cpihs+; spf=none (imf03.hostedemail.com: domain of simona.vetter@ffwll.ch has no SPF policy when checking 209.85.128.41) smtp.mailfrom=simona.vetter@ffwll.ch; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1733758266; a=rsa-sha256; cv=none; b=BH0qc/HnbaiUaHxTMjnHTA9lTFrHbmwPQOnY8eCKg5At56F3K3JGLlSAuiqBsISikckaug MDmAfevUoEn+J4FKFJX4RhVoVAdizoUvrMvUtAPRW7giYNyGT6QhZTSzw2+rZwB9kbgNr6 h49EI3l/xodYMgjEKzdkCpasz7ZjMeQ= Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-434a852bb6eso43874985e9.3 for ; Mon, 09 Dec 2024 07:31:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; t=1733758276; x=1734363076; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:mail-followup-to:message-id:subject:cc:to :from:date:from:to:cc:subject:date:message-id:reply-to; bh=rRrwKagbDkhwxnLFjd7MS7qeMP3V5ZX0pRGxISFGQGY=; b=P5Cpihs+sodueo0r1w2lmJFrEnONepFUpeVYQtMeesAD0Lp8W2NNImAcniw1uWiRQg gRc9x1HSFVGkWyorlofa92iyA5CxPfGAiq1B3S5qgz+OhkWDJVRF39GxflKQ3vpSWC07 xrE/Aaqp+eJFuRNCXbkjjdng87UdvygGJAxIg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733758276; x=1734363076; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:mail-followup-to:message-id:subject:cc:to :from:date:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=rRrwKagbDkhwxnLFjd7MS7qeMP3V5ZX0pRGxISFGQGY=; b=O3nfDWW06ezcS1/UeKmE+nGbcN9jryO0SJpxxi/aYlvevEioVPCzWN+GJo1qF9C0PN SDGaPM8a4LIP+RZnah17jHBAOoMgX3tUkJSopJ5TedP96ES5klbWA2NLdwMXjRByesQY qJDYQ4kJsGdsFGHi1HIco8yPA5HOhgULeUrjHXBiYpOwgYdKy+wrLAgxFD7O1q/hLByk EHI5nWl3qBIxSOudWt3XxFYCTuLqSIxDhK+BaiAu6MFUOijMtMl9bnqdVE+yt6FSvAbr z4Jfj24Ww/k30OGHYBCkJfs6Tc1y7YFNztpnsmp4sSy9iB9HlfZ8LUBV1XtkxSDkH8Ov 74ug== X-Forwarded-Encrypted: i=1; AJvYcCUdRX5LjUBx98UpAfhCDK+fi3eTiTU8XqKVGw+YYl7W3hN1Hs5oLja2Ht9atFBZH7flKA2yY7KrYA==@kvack.org X-Gm-Message-State: AOJu0YxasWLK8tyi8NcTlJ8bTk88Apea6Q7vXviowJur6ggQTslhhexR PKrYzWbSkh/kAHd+5Kk0tC5h17+p2P0c/qyS15BrXXP6ShJaKuzbMTPeqrgDm+M= X-Gm-Gg: ASbGnctTN46xBBJaq6VM4JEYo4LNY1SLPkPArPfDsEI2FRedkZcA2shR/aVxSkd+EwG TID6DwjbAFXsgVdXPZwXsw9WXWfcx8vSX6TAvjg7G+iUY604UvvZKnWic+aN0p/dpdPX825IYqE yeX2atE3Iq1H/HfQ2O0kchovapw0q2xMTVvKtSLpo4DhdSrYWhUadaKlEYN92Qx5QpiVwayngqq 5UMckz+YpFWabHYtvOwKud8CmiJvElm5klciZ9NE4TeNl9XYehJO3dDwYEX5Q== X-Google-Smtp-Source: AGHT+IEa2hI71BSfv72l6DzkdT7Sj5cETKMQ7Bq7s1zyr891Bbd+K0P9g6YcWBCA6YUOOgULQ7HHrw== X-Received: by 2002:a5d:5f45:0:b0:385:f2a5:ef6a with SMTP id ffacd0b85a97d-386453d6876mr751537f8f.15.1733758276345; Mon, 09 Dec 2024 07:31:16 -0800 (PST) Received: from phenom.ffwll.local ([2a02:168:57f4:0:5485:d4b2:c087:b497]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38637a0c6dfsm6814580f8f.93.2024.12.09.07.31.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Dec 2024 07:31:15 -0800 (PST) Date: Mon, 9 Dec 2024 16:31:13 +0100 From: Simona Vetter To: Christian =?iso-8859-1?Q?K=F6nig?= Cc: Mika Kuoppala , intel-xe@lists.freedesktop.org, lkml , Linux MM , dri-devel@lists.freedesktop.org, Andrzej Hajda , Maciej Patelczyk , Jonathan Cavitt Subject: Re: [PATCH 14/26] drm/xe/eudebug: implement userptr_vma access Message-ID: Mail-Followup-To: Christian =?iso-8859-1?Q?K=F6nig?= , Mika Kuoppala , intel-xe@lists.freedesktop.org, lkml , Linux MM , dri-devel@lists.freedesktop.org, Andrzej Hajda , Maciej Patelczyk , Jonathan Cavitt References: <20241209133318.1806472-1-mika.kuoppala@linux.intel.com> <20241209133318.1806472-15-mika.kuoppala@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: Linux phenom 6.11.6-amd64 X-Rspamd-Server: rspam05 X-Stat-Signature: ni8tqegw4x6oxso8qoqzxw3rhergjeh7 X-Rspamd-Queue-Id: 0CE8C2001A X-Rspam-User: X-HE-Tag: 1733758269-551317 X-HE-Meta: U2FsdGVkX199ee1EArAT8onXhdKL4NVDdrQ11zie+wTPdgvxRWGBF/NK6y0l4qImifisnSz6j7fmxX3jUqCod01mb4AWMDD8sW29z2oxqpXtYoLrPL2g27wsFKn2dBsxiscR03IY3Ik38QHPy1u6wsMdw724apahGnhhgtK1QTBp4AfrcYdJApkRPauG0IAaaGqgeqJXRUkVy1DulGFv8V9W7mAYFuDhPYNZ0MzmxVzDKU07pn9ryTmpFj0SdCHOubsMhp0wmf9rtOsI11iJWSwkXIbe6sb2uiyOoBivjZAzzT6suLwa5VziuJaY8aGkqQuFxWUX8IOthG9um3KW/3NoEFzlflOR+uNiNPNrhON3fl2w0BqPOTeLf6MXaTGHnAcnIxHoa1+3VDCMDvEkrTv+zxnViyRBjx4eP/L+B/kKQ8qzGVz/ZaU4oLTN2tz2ANROX1V3/t2gwquncgSXXvTrWbZGnI9mC71ToMQsvDqHhpzYSVmZrbT5ujZvl8Qd3pHwixpnepRurKC+tlKYfxSdMXMe+PMoi/2lCaoKMPpxxX07AroOCUC3DYtuk9n9cme1xPf2DCw9x+dTE0PnmGsdFPI3pxld/kGPzn33w8aj/cXG4LZbDcS21Dw+FHhE/FWmssQ8OrmaVG3g1KMNyu/cQqUhLVdRLtAMvIYlX17zyF+p9SexKV+LfkRtE+dbSXRG82ka5x7011uCCgXhuDM57xRrv4T/UUqGTOFjuQ+jI+hqR9DgmzWo5OjIzLnhifhRGkYLBxazJv3EWBLx/qRGgh1pth87gHDLfoLwNQrMQFswBV8b5CfnIyVIMcWk+eoX1DYlquh1UBA11Yw7Ujz8ZS9M5Kk7rVwz4VkGmtEPQ4v0bnTaQZ4NId+++5QxTRtnhgjmjElNHncKCeqWUYZDrzty4Nda9Je2Pt8Y0RhuvsWKgeGcTyD4oBf6dctCIm5uuLe+2rLsyvwYH3O OhwxrZzP fJ+Ng5P0QkdNzXgxhL7JxExGO3RgvyXdzvjRcicOX/OPfWTjfYBmxJUdF8bQZRzvBp6QrEgrpsHF0oqbt9PHxna1DG5BoZGPt+2iTHHTH7NjQwq/39MM09Qnm8JVxM1J2eOh1ci9OMgFtHa7JyJmXIPYiVwcctyxE4vQ+PlVUEiTr2nvyBqlVrabpJFtrwCj1mzHQ8DDZTK98ykOrmA8kKaiV9uTkQJ10HmB0hL5qKsSOk1SM/XchBTQDTDWGFtNmPMNN4ZfikawtOkzLMoZuLTHSuHjaJREYzoLwPgPwbhLId7bgmbn/QvSg2LZQw652bYTUv0bprsXAjdor9VeC3aTACSCH7NlMMpCQFjKLvsEfPNJ22eooS+D9D7KQr6UUvVpfIjIU7qARFxc= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000015, 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 Mon, Dec 09, 2024 at 03:03:04PM +0100, Christian König wrote: > Am 09.12.24 um 14:33 schrieb Mika Kuoppala: > > From: Andrzej Hajda > > > > Debugger needs to read/write program's vmas including userptr_vma. > > Since hmm_range_fault is used to pin userptr vmas, it is possible > > to map those vmas from debugger context. > > Oh, this implementation is extremely questionable as well. Adding the LKML > and the MM list as well. > > First of all hmm_range_fault() does *not* pin anything! > > In other words you don't have a page reference when the function returns, > but rather just a sequence number you can check for modifications. I think it's all there, holds the invalidation lock during the critical access/section, drops it when reacquiring pages, retries until it works. I think the issue is more that everyone hand-rolls userptr. Probably time we standardize that and put it into gpuvm as an optional part, with consistent locking, naming (like not calling it _pin_pages when it's unpinnged userptr), kerneldoc and all the nice things so that we stop consistently getting confused by other driver's userptr code. I think that was on the plan originally as an eventual step, I guess time to pump that up. Matt/Thomas, thoughts? -Sima > > > v2: pin pages vs notifier, move to vm.c (Matthew) > > v3: - iterate over system pages instead of DMA, fixes iommu enabled > > - s/xe_uvma_access/xe_vm_uvma_access/ (Matt) > > > > Signed-off-by: Andrzej Hajda > > Signed-off-by: Maciej Patelczyk > > Signed-off-by: Mika Kuoppala > > Reviewed-by: Jonathan Cavitt #v1 > > --- > > drivers/gpu/drm/xe/xe_eudebug.c | 3 ++- > > drivers/gpu/drm/xe/xe_vm.c | 47 +++++++++++++++++++++++++++++++++ > > drivers/gpu/drm/xe/xe_vm.h | 3 +++ > > 3 files changed, 52 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/xe/xe_eudebug.c b/drivers/gpu/drm/xe/xe_eudebug.c > > index 9d87df75348b..e5949e4dcad8 100644 > > --- a/drivers/gpu/drm/xe/xe_eudebug.c > > +++ b/drivers/gpu/drm/xe/xe_eudebug.c > > @@ -3076,7 +3076,8 @@ static int xe_eudebug_vma_access(struct xe_vma *vma, u64 offset_in_vma, > > return ret; > > } > > - return -EINVAL; > > + return xe_vm_userptr_access(to_userptr_vma(vma), offset_in_vma, > > + buf, bytes, write); > > } > > static int xe_eudebug_vm_access(struct xe_vm *vm, u64 offset, > > diff --git a/drivers/gpu/drm/xe/xe_vm.c b/drivers/gpu/drm/xe/xe_vm.c > > index 0f17bc8b627b..224ff9e16941 100644 > > --- a/drivers/gpu/drm/xe/xe_vm.c > > +++ b/drivers/gpu/drm/xe/xe_vm.c > > @@ -3414,3 +3414,50 @@ void xe_vm_snapshot_free(struct xe_vm_snapshot *snap) > > } > > kvfree(snap); > > } > > + > > +int xe_vm_userptr_access(struct xe_userptr_vma *uvma, u64 offset, > > + void *buf, u64 len, bool write) > > +{ > > + struct xe_vm *vm = xe_vma_vm(&uvma->vma); > > + struct xe_userptr *up = &uvma->userptr; > > + struct xe_res_cursor cur = {}; > > + int cur_len, ret = 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 = xe_vma_userptr_pin_pages(uvma); > > + if (ret) > > + return ret; > > + } > > + > > + if (!up->sg) { > > + ret = -EINVAL; > > + goto out_unlock_notifier; > > + } > > + > > + for (xe_res_first_sg_system(up->sg, offset, len, &cur); cur.remaining; > > + xe_res_next(&cur, cur_len)) { > > + void *ptr = kmap_local_page(sg_page(cur.sgl)) + cur.start; > > The interface basically creates a side channel to access userptrs in the way > an userspace application would do without actually going through userspace. > > That is generally not something a device driver should ever do as far as I > can see. > > > + > > + cur_len = min(cur.size, cur.remaining); > > + if (write) > > + memcpy(ptr, buf, cur_len); > > + else > > + memcpy(buf, ptr, cur_len); > > + kunmap_local(ptr); > > + buf += cur_len; > > + } > > + ret = len; > > + > > +out_unlock_notifier: > > + up_read(&vm->userptr.notifier_lock); > > I just strongly hope that this will prevent the mapping from changing. > > Regards, > Christian. > > > + return ret; > > +} > > diff --git a/drivers/gpu/drm/xe/xe_vm.h b/drivers/gpu/drm/xe/xe_vm.h > > index 23adb7442881..372ad40ad67f 100644 > > --- a/drivers/gpu/drm/xe/xe_vm.h > > +++ b/drivers/gpu/drm/xe/xe_vm.h > > @@ -280,3 +280,6 @@ struct xe_vm_snapshot *xe_vm_snapshot_capture(struct xe_vm *vm); > > void xe_vm_snapshot_capture_delayed(struct xe_vm_snapshot *snap); > > void xe_vm_snapshot_print(struct xe_vm_snapshot *snap, struct drm_printer *p); > > void xe_vm_snapshot_free(struct xe_vm_snapshot *snap); > > + > > +int xe_vm_userptr_access(struct xe_userptr_vma *uvma, u64 offset, > > + void *buf, u64 len, bool write); > -- Simona Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch