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 0603AD60D09 for ; Tue, 19 Nov 2024 01:35:25 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id CBBF710E598; Tue, 19 Nov 2024 01:35:24 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="bg1SYaWx"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.20]) by gabe.freedesktop.org (Postfix) with ESMTPS id EF7D510E598 for ; Tue, 19 Nov 2024 01:35:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1731980124; x=1763516124; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=MXoavAyGvqoZuizqk4P9s14xy+snf25TwTSYOG6TIps=; b=bg1SYaWxG0eTBWlllMS9YEGHm+u26XbsCOhA42q4ENtiTG/H3TcUqFnv ypscwS0WaKhNjc0l1BRcFiwMIr7ofUWKO1ch5NaSHsLWm7f/ql3OZw5sH YiGxmL0APy9NXns/xCR9zSL5pCzp95ZmdfG7sV0M2CfCU4P7/BJ4Z+kOU iq7BwSnHnXxA422EUKMykcX2tGTOFM5mOQ3SZcICWIEEBc11VLEyeFDrr KVIq/2Zwj9k1M9jEwb014GLJMV2Ab1AmyVNQOeT5Fz5cYPlyemkLd4dby xitWsAAsLR7WPulwSr65rLUU8+U5Mw0IC+298Z3ZwBWKP8O96n6+R7SoN Q==; X-CSE-ConnectionGUID: bhFycYp9QrWfZ9C1fNu6Sg== X-CSE-MsgGUID: xleLknktTCKqgBcHA/nGog== X-IronPort-AV: E=McAfee;i="6700,10204,11260"; a="31713226" X-IronPort-AV: E=Sophos;i="6.12,165,1728975600"; d="scan'208";a="31713226" Received: from fmviesa003.fm.intel.com ([10.60.135.143]) by orvoesa112.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Nov 2024 17:35:23 -0800 X-CSE-ConnectionGUID: nhPoIz7xQZGtYwqLBjgDRA== X-CSE-MsgGUID: 6VMYkPtoSAKLC4JvHfkhBQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.12,165,1728975600"; d="scan'208";a="93475741" Received: from orsosgc001.jf.intel.com (HELO orsosgc001.intel.com) ([10.165.21.142]) by fmviesa003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Nov 2024 17:35:23 -0800 Date: Mon, 18 Nov 2024 17:35:23 -0800 Message-ID: <85ttc4vwdg.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Matthew Brost Cc: intel-xe@lists.freedesktop.org, Umesh Nerlige Ramappa Subject: Re: [PATCH 1/2] drm/xe/oa: Disallow OA from being enabled on active exec_queue's In-Reply-To: References: <20241108230602.2984959-1-ashutosh.dixit@intel.com> <20241108230602.2984959-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/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=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 Fri, 08 Nov 2024 15:14:46 -0800, Matthew Brost wrote: > > On Fri, Nov 08, 2024 at 03:06:00PM -0800, Ashutosh Dixit wrote: > > Enabling OA on an exec_queue toggles the OAC_CONTEXT_ENABLE bit in > > CTXT_SR_CTL register. Toggling this bit changes the size and layout of the > > underlying HW context image. Therefore, enabling OA on an already active > > exec_queue (as currently implemented in xe) is an invalid operation and can > > cause hangs. Therefore, disallow OA from being enabled on active > > exec_queue's (here by active we mean a context on which submissions have > > previously happened). > > > > Transition from 1 -> 0 for this bit was disallowed in > > '0c8650b09a36 ("drm/xe/oa: Don't reset OAC_CONTEXT_ENABLE on OA stream > > close")'. Here we disallow the 0 -> 1 transition on active contexts. > > > > Bspec: 60314 > > Fixes: 2f4a730fcd2d ("drm/xe/oa: Add OAR support") > > Cc: stable@vger.kernel.org > > Signed-off-by: Ashutosh Dixit > > --- > > drivers/gpu/drm/xe/xe_guc_submit.c | 2 +- > > drivers/gpu/drm/xe/xe_guc_submit.h | 1 + > > drivers/gpu/drm/xe/xe_oa.c | 11 +++++++++++ > > 3 files changed, 13 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/xe/xe_guc_submit.c b/drivers/gpu/drm/xe/xe_guc_submit.c > > index 9e0f86f3778b2..5c285d966fd5c 100644 > > --- a/drivers/gpu/drm/xe/xe_guc_submit.c > > +++ b/drivers/gpu/drm/xe/xe_guc_submit.c > > @@ -83,7 +83,7 @@ static void clear_exec_queue_registered(struct xe_exec_queue *q) > > atomic_and(~EXEC_QUEUE_STATE_REGISTERED, &q->guc->state); > > } > > > > -static bool exec_queue_enabled(struct xe_exec_queue *q) > > +bool exec_queue_enabled(struct xe_exec_queue *q) > > Don't export this. Use a xe_exec_queue_ops vfunc. Current vfunc > 'reset_status' would kinda similar to this. A vfunc protects use against > baking in submission backend specifics into other layers. We only really > have 1 ATM that works (execlists backend is still here for some reason) > but this is the best practice. Done in v2, thanks for the suggestion, Matt. I've only added the vfunc to GuC though, since OA is disabled for execlists.