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 AEEF210F994F for ; Wed, 8 Apr 2026 15:32:56 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 6CD2B10E51A; Wed, 8 Apr 2026 15:32:56 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="A0ZgEG6x"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.14]) by gabe.freedesktop.org (Postfix) with ESMTPS id D9AF910E51A for ; Wed, 8 Apr 2026 15:32:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1775662375; x=1807198375; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=V8I+XbRgpeu0eOf8e33JZfLj72WtxNJkYtmhLOvCuSg=; b=A0ZgEG6xOSI1w46Ll+7sJwMF1xU6C76UfHgHACfVJEAYjfMrGtAdti+i TddcLlFRlETMJSa2QEs5Z5nXGANXX5YHNbkOYCWhnOU9Hux3yEQ2n8BCo qMTz+QfK4zTA4q85hniJUCDb/xqGCG+GX9CVMF+xmjjWAyt6TC864WvVd yiQD5gv6N2/440tbyghgMV5JJgx5fVDkiz0spFCElJRD6vEDM6F1U3Dme ERqsVtpFARZfCl5xn/TR021BNWz3rFuYetxhJkEeeb4Gctx0leZpSG+oI 3PMiAtQmqRzGLeTyQVvcvbtw2e/8zsa91xLH7N2TIn4M7lgKAhusJoPvx Q==; X-CSE-ConnectionGUID: RxN3H8D9Sjuc1yiPHsJWjg== X-CSE-MsgGUID: HfVhPGg4SluRRHseme2IfQ== X-IronPort-AV: E=McAfee;i="6800,10657,11753"; a="80509111" X-IronPort-AV: E=Sophos;i="6.23,167,1770624000"; d="scan'208";a="80509111" Received: from orviesa003.jf.intel.com ([10.64.159.143]) by orvoesa106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Apr 2026 08:32:54 -0700 X-CSE-ConnectionGUID: 17w22wzcSGu/Dj9Roc7fKA== X-CSE-MsgGUID: jzF62hKRQaOqzPN0bncZGw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,167,1770624000"; d="scan'208";a="232538847" Received: from johnjgar-mobl1.amr.corp.intel.com (HELO adixit-MOBL3.intel.com) ([10.125.41.211]) by ORVIESA003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Apr 2026 08:32:53 -0700 Date: Wed, 08 Apr 2026 08:32:50 -0700 Message-ID: <87o6jtzcv1.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Umesh Nerlige Ramappa Cc: Subject: Re: [PATCH 1/3] drm/xe/oa: Use xe_map layer In-Reply-To: References: <20260407030219.444060-1-ashutosh.dixit@intel.com> <20260407030219.444060-2-ashutosh.dixit@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/30.2 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII 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 Tue, 07 Apr 2026 15:49:27 -0700, Umesh Nerlige Ramappa wrote: > Hi Umesh, > On Mon, Apr 06, 2026 at 08:02:17PM -0700, Ashutosh Dixit wrote: > > @@ -311,30 +317,37 @@ static enum hrtimer_restart xe_oa_poll_check_timer_cb(struct hrtimer *hrtimer) > > return HRTIMER_RESTART; > > } > > > > +static inline unsigned long > > +xe_oa_copy_to_user(void __user *dst, const struct iosys_map *src, size_t src_offset, size_t len) > > +{ > > + if (src->is_iomem) > > + return copy_to_user(dst, src->vaddr_iomem + src_offset, len); > > I think this requires xe_map_memcpy_from for the iomem case. > > > + else > > + return copy_to_user(dst, src->vaddr + src_offset, len); > > +} > > + Yes, you have certainly spotted the iffy part of this patch. However, this situation is not that simple: * xe_map_memcpy_from or iosys_map_memcpy_from copies from iomem to kernel memory (potentially using special accessors for iomem), not to user memory * copy_to_user copies from kernel memory to user memory (using special checks), not from iomem So in the kernel we don't have functions which copy directly from iomem to user memory. That is, functions like iosys_map_copy_to_user() or copy_to_user_from_iomem() do not exist, because they would need to combine iomem access and copy_to_user (likely copy_to_user will need to be rewritten with iomem accessors, if such a function were to be implemented). There may be a reason why such functions don't exist in the kernel. Another way might be to copy from iomem to kernel memory and from kernel to user memory (that is have both iosys_map_memcpy_from and copy_to_user calls), but this would entail an extra copy into a bounce buffer in kernel memory. Something like this: static inline unsigned long xe_oa_copy_to_user(void __user *dst, const struct iosys_map *src, size_t src_offset, size_t len) { void *tmp = kmalloc(len, GFP_KERNEL); // kmalloc or statically allocated tmp buffer xe_map_memcpy_from(xe, tmp, src, src_offset, len); // extra copy return copy_to_user(dst, tmp, len); } In our case, xe_map_memcpy_from or iosys_map_memcpy_from are basically a memcpy (because vram bar is ioremapped, special accessors for iomem are not needed). Therefore, to avoid the extra copy, I decided to drop the iomem access part (since the copy_to_user part cannot be dropped). Hence I end up with the xe_oa_copy_to_user() above. The function was tested on BMG with OA buffer in vram and works as expected. I did think about renaming the above function xe_map_copy_to_user() and moving it to xe_map.h, so that is possible. But since there are no other users (and none are expected) at this point of xe_map_copy_to_user() apart from OA because of this workaround (other observation stream buffers are in system memory, not vram), I left the function as specific to OA. Let me know what you think. Thanks.