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 B4027C46CD2 for ; Tue, 9 Jan 2024 05:14:44 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 700CB10E01F; Tue, 9 Jan 2024 05:14:44 +0000 (UTC) Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.31]) by gabe.freedesktop.org (Postfix) with ESMTPS id 66C6B10E01F for ; Tue, 9 Jan 2024 05:14:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1704777283; x=1736313283; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version:content-transfer-encoding; bh=IbH5as31e7P9qnpi0QIDTLfxGoeeLYW/ZmF7GPXAO+s=; b=Hg/R8aFgwloXjjvZEmgWKZaem/ibmyQ3BRaL0Axo9GgGHCHwuMqgCnjL r8TpPXP/aRFPhnWSfQ1GPZvv1wyUfKrT789yUq1LGUt4nsNCdXVbomvSS 1HTtRMrjUnBOTloei/+PryObQzUtbKzrHcoXIHwZ+UhUcaZzYYwQki0C4 od4FgADlJXgY9SXmHOIzFc3EoQJcOd207Mn3PK/TQrYfFnyuXl3GiYDhL grb6SqmrkpTcacSc4+lFRTil1h/njkr5lyA/AglUo2tGFdLhmkdho8j0C zt0WnX/EcA7dzugrNohe9r+NFJ9wNv1gEX9d1eqVkrjm83cHcCKM8JsAj w==; X-IronPort-AV: E=McAfee;i="6600,9927,10947"; a="462365912" X-IronPort-AV: E=Sophos;i="6.04,181,1695711600"; d="scan'208";a="462365912" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jan 2024 21:14:43 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10947"; a="954889083" X-IronPort-AV: E=Sophos;i="6.04,181,1695711600"; d="scan'208";a="954889083" Received: from orsosgc001.jf.intel.com (HELO unerlige-ril.intel.com) ([10.165.21.138]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jan 2024 21:14:43 -0800 Date: Mon, 08 Jan 2024 21:14:42 -0800 Message-ID: <85wmsjccl9.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Umesh Nerlige Ramappa Subject: Re: [PATCH 15/17] drm/xe/oa/uapi: OA buffer mmap In-Reply-To: References: <20231208064329.2387604-1-ashutosh.dixit@intel.com> <20231208064329.2387604-16-ashutosh.dixit@intel.com> <464d71dd195eac4145cc5dde4ee4e8d04899387b.camel@linux.intel.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/28.2 (x86_64-redhat-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: , Cc: intel-xe@lists.freedesktop.org Errors-To: intel-xe-bounces@lists.freedesktop.org Sender: "Intel-xe" On Mon, 08 Jan 2024 11:50:40 -0800, Umesh Nerlige Ramappa wrote: > Hi Thomas/Umesh, > On Tue, Jan 02, 2024 at 12:16:12PM +0100, Thomas Hellstr=F6m wrote: > > On Thu, 2023-12-07 at 22:43 -0800, Ashutosh Dixit wrote: > >> Allow the OA buffer to be mmap'd to userspace. This is needed for the > >> MMIO > >> trigger use case. Even otherwise, with whitelisted OA head/tail ptr > >> registers, userspace can receive/interpret OA data from the mmap'd > >> buffer > >> without issuing read()'s on the OA stream fd. > >> > >> Suggested-by: Umesh Nerlige Ramappa > >> Signed-off-by: Ashutosh Dixit > >> --- > >> =A0drivers/gpu/drm/xe/xe_oa.c | 53 > >> ++++++++++++++++++++++++++++++++++++++ > >> =A01 file changed, 53 insertions(+) > >> > >> diff --git a/drivers/gpu/drm/xe/xe_oa.c b/drivers/gpu/drm/xe/xe_oa.c > >> index 42f32d4359f2c..97779cbb83ee8 100644 > >> --- a/drivers/gpu/drm/xe/xe_oa.c > >> +++ b/drivers/gpu/drm/xe/xe_oa.c > >> @@ -898,6 +898,8 @@ static int xe_oa_alloc_oa_buffer(struct > >> xe_oa_stream *stream) > >> =A0 return PTR_ERR(bo); > >> > >> =A0 stream->oa_buffer.bo =3D bo; > >> + /* mmap implementation requires OA buffer to be in system > >> memory */ > >> + xe_assert(stream->oa->xe, bo->vmap.is_iomem =3D=3D 0); > >> =A0 stream->oa_buffer.vaddr =3D bo->vmap.vaddr; > >> =A0 return 0; > >> =A0} > >> @@ -1174,6 +1176,9 @@ static int xe_oa_release(struct inode *inode, > >> struct file *file) > >> =A0 struct xe_oa_stream *stream =3D file->private_data; > >> =A0 struct xe_gt *gt =3D stream->gt; > >> > >> + /* Zap mmap's */ > >> + unmap_mapping_range(file->f_mapping, 0, -1, 1); > >> + > > > > Can release() get called at all if there is a live mapping()? Meaning > > the unmap_mapping_range() shouldn't be needed? > > If user closes the fd, but has not called unmap, then release will not get > called. If unmap_mapping_range() doesn't do anything extra compared to > unmap(), then I agree that we coud drop this. I am removing unmap_mapping_range. I checked and found that: * If munmap is not called and fd is closed, release is not called * However, release is called (even in the above case) when the process exits. But at process exit, I think we can safely assume that resources allocated for the process will be automatically freed. So there seems to be no reason to retain unmap_mapping_range. * Also, in general, I am not seeing unmap_mapping_range being called in other places in the kernel which use remap_pfn_range. So removing unmap_mapping_range because of the above reasons. Thanks. -- Ashutosh