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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 24EBDC28B30 for ; Thu, 20 Mar 2025 19:29:48 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id DCCF610E6B3; Thu, 20 Mar 2025 19:29:47 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="hPp4puOk"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.8]) by gabe.freedesktop.org (Postfix) with ESMTPS id E920A10E6B0; Thu, 20 Mar 2025 19:29:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1742498987; x=1774034987; h=message-id:subject:from:to:cc:date:in-reply-to: references:content-transfer-encoding:mime-version; bh=rWhT5e4wUN+vIYdXQfH5TJ3iOjFn7lYa5rH6h+S8j90=; b=hPp4puOkrc2vZEWWeS9Y4pzjIlsofBXpxkQ6aq0Xytubuku0vNdisWcR opbtGRntu1DRk1xvGt+wg/UtxbsSDvUs7ws1y+GzWWlPbUOKtZoa6LWGs rRwNV+4zCVYZSM0/tm8E/8rjj6lgnKgzVM5Gg2LaLrQ+lns78MgIXmoZe KB3lnrRzIAmGVIuStuW+Z31TIdwZP0WeNvBLpI9MD4jESOeT1ij7E+Cqw 1+V07ripCuIxGzfhbNLJudR9fpzwSQbquCfZsqjawg8Xc5i7UMkBU4n4M CaREVXKxsglETUnNiGn16QaF3uDuvcAItlM8i0cOt2WvbMt0NlW5IPR/x A==; X-CSE-ConnectionGUID: p6XbJPePR0yWMtHwve/PYw== X-CSE-MsgGUID: f/w/m1GqQJ+lxCbcXLO4Bw== X-IronPort-AV: E=McAfee;i="6700,10204,11379"; a="61275903" X-IronPort-AV: E=Sophos;i="6.14,262,1736841600"; d="scan'208";a="61275903" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by fmvoesa102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Mar 2025 12:29:46 -0700 X-CSE-ConnectionGUID: t/YxO+VjQ++s8kWosdKYtw== X-CSE-MsgGUID: kDjXBW7tTamvIk70yASFEA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.14,262,1736841600"; d="scan'208";a="154082586" Received: from vpanait-mobl.ger.corp.intel.com (HELO [10.245.246.115]) ([10.245.246.115]) by orviesa002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Mar 2025 12:29:44 -0700 Message-ID: Subject: Re: [PATCH 3/7] drm/gpusvm: mark pages as dirty From: Thomas =?ISO-8859-1?Q?Hellstr=F6m?= To: Matthew Auld , intel-xe@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org, Matthew Brost Date: Thu, 20 Mar 2025 20:29:42 +0100 In-Reply-To: <20250320172956.168358-12-matthew.auld@intel.com> References: <20250320172956.168358-9-matthew.auld@intel.com> <20250320172956.168358-12-matthew.auld@intel.com> Organization: Intel Sweden AB, Registration Number: 556189-6027 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.54.3 (3.54.3-1.fc41) MIME-Version: 1.0 X-BeenThere: intel-xe@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel Xe graphics driver List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-xe-bounces@lists.freedesktop.org Sender: "Intel-xe" On Thu, 2025-03-20 at 17:30 +0000, Matthew Auld wrote: > If the memory is going to be accessed by the device, make sure we > mark > the pages accordingly such that the kernel knows this. This aligns > with > the xe-userptr code. >=20 > Signed-off-by: Matthew Auld > Cc: Thomas Hellstr=C3=B6m > Cc: Matthew Brost > --- > =C2=A0drivers/gpu/drm/drm_gpusvm.c | 9 +++++++++ > =C2=A01 file changed, 9 insertions(+) >=20 > diff --git a/drivers/gpu/drm/drm_gpusvm.c > b/drivers/gpu/drm/drm_gpusvm.c > index 7f1cf5492bba..5b4ecd36dff1 100644 > --- a/drivers/gpu/drm/drm_gpusvm.c > +++ b/drivers/gpu/drm/drm_gpusvm.c > @@ -1471,6 +1471,7 @@ int drm_gpusvm_range_get_pages(struct > drm_gpusvm *gpusvm, > =C2=A0 pages[i] =3D page; > =C2=A0 } else { > =C2=A0 dma_addr_t addr; > + unsigned int k; > =C2=A0 > =C2=A0 if (is_zone_device_page(page) || zdd) { > =C2=A0 err =3D -EOPNOTSUPP; > @@ -1489,6 +1490,14 @@ int drm_gpusvm_range_get_pages(struct > drm_gpusvm *gpusvm, > =C2=A0 range->dma_addr[j] =3D > drm_pagemap_device_addr_encode > =C2=A0 (addr, DRM_INTERCONNECT_SYSTEM, > order, > =C2=A0 dma_dir); > + > + for (k =3D 0; k < 1u << order; k++) { > + if (!ctx->read_only) > + set_page_dirty_lock(page); > + > + mark_page_accessed(page); > + page++; > + } Actually I think the userptr code did this unnecessarily. This is done in the CPU page-fault handler, which means it's taken care of during hmm_range_fault(). Now if the CPU PTE happens to be present and writeable there will be no fault, but that was done when the page was faulted in anyway. If there was a page cleaning event in between so the dirty flag was dropped, then my understanding is that in addition to an invalidation notifier, also the CPU PTE is zapped, so that it will be dirtied again on the next write access, either by the CPU faulting the page or hmm_range_fault() if there is a GPU page-fault. So I think we're good without this patch. /Thomas > =C2=A0 } > =C2=A0 i +=3D 1 << order; > =C2=A0 num_dma_mapped =3D i;