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 00C80E9A04D for ; Wed, 18 Feb 2026 22:55:34 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id B123410E04A; Wed, 18 Feb 2026 22:55:34 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="bVqWe591"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.11]) by gabe.freedesktop.org (Postfix) with ESMTPS id C924B10E04A for ; Wed, 18 Feb 2026 22:55:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1771455334; x=1802991334; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=YbkAlhWzGlnnOsaWRINA4+5UbwU+89Bk4BLzMgl05zU=; b=bVqWe591Vh5rzW0EBbmWvg4HJmxmNTKyFGz9aWdjqwmPky7nqCf+Zo+l 5Q6c1epBaGK0BsD+Fgly/oTfLAAARveCmD0hIigbBoDmm6tw+t4icAU8o 8G6JK0tBauIZmbfNQaF+7vFvf8dB+BZaLyqL8A76UX3Z4ju2v8NTQhdNZ nSk+eG2vLw2f3/Y/B3NOijdaIyQRgdpbAgqgNFBwduPtwQqX5eDNM+Gio Q8R7kYfLh2iHN+cQ9rzTl94xAHhXJzaXBDBX6Cl6+CfzVV2+xqxD2n4gG uB412/6iV1j3J9zd//xf9yyuzzJc46Vy/crDo5kKcSsF9DHmmf0I9WHI/ A==; X-CSE-ConnectionGUID: M9P3OooJTgK9r755JySDoA== X-CSE-MsgGUID: xZJ1n9cDSgenr2ucm7le3Q== X-IronPort-AV: E=McAfee;i="6800,10657,11705"; a="82867257" X-IronPort-AV: E=Sophos;i="6.21,299,1763452800"; d="scan'208";a="82867257" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by orvoesa103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Feb 2026 14:55:33 -0800 X-CSE-ConnectionGUID: DX3rh9IXSAincu4ZbzhbFg== X-CSE-MsgGUID: Qn4QXVYJRY2n76a5qQWsFw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,299,1763452800"; d="scan'208";a="244930118" Received: from unknown (HELO adixit-MOBL3.intel.com) ([10.241.243.117]) by orviesa002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Feb 2026 14:55:33 -0800 Date: Wed, 18 Feb 2026 14:55:32 -0800 Message-ID: <87ldgpwtjv.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Matt Roper Cc: , Michal Wajdeczko , Harish Chegondi Subject: Re: [PATCH v4 1/4] drm/xe/reg_sr: Don't process gt/hwe lists in VF In-Reply-To: <20260218-sr_verify-v4-1-35d6deeb3421@intel.com> References: <20260218-sr_verify-v4-0-35d6deeb3421@intel.com> <20260218-sr_verify-v4-1-35d6deeb3421@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 Wed, 18 Feb 2026 14:09:12 -0800, Matt Roper wrote: > > diff --git a/drivers/gpu/drm/xe/xe_rtp.c b/drivers/gpu/drm/xe/xe_rtp.c > index b7c26e2fb411ea75fbd484b55f48019fc09f0581..7bfdc6795ce6fd3d2c8c9d1398c7b72ff476b96d 100644 > --- a/drivers/gpu/drm/xe/xe_rtp.c > +++ b/drivers/gpu/drm/xe/xe_rtp.c > @@ -270,6 +270,8 @@ static void rtp_mark_active(struct xe_device *xe, > * @sr: Save-restore struct where matching rules execute the action. This can be > * viewed as the "coalesced view" of multiple the tables. The bits for each > * register set are expected not to collide with previously added entries > + * @process_in_vf: Whether this RTP table should get processed for SR-IOV VF > + * devices. Should generally only be 'true' for LRC tables. > * > * Walk the table pointed by @entries (with an empty sentinel) and add all > * entries with matching rules to @sr. If @hwe is not NULL, its mmio_base is > @@ -278,7 +280,8 @@ static void rtp_mark_active(struct xe_device *xe, > void xe_rtp_process_to_sr(struct xe_rtp_process_ctx *ctx, > const struct xe_rtp_entry_sr *entries, > size_t n_entries, > - struct xe_reg_sr *sr) > + struct xe_reg_sr *sr, > + bool process_in_vf) Another idea would be to change 'process_in_vf' to something like 'is_lrc'. But otherwise ok as is too (specially if some non-lrc cases need to be processed in VF's in the future): Reviewed-by: Ashutosh Dixit > { > const struct xe_rtp_entry_sr *entry; > struct xe_hw_engine *hwe = NULL; > @@ -287,6 +290,9 @@ void xe_rtp_process_to_sr(struct xe_rtp_process_ctx *ctx, > > rtp_get_context(ctx, &hwe, >, &xe); > > + if (!process_in_vf && IS_SRIOV_VF(xe)) > + return; > +