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 9C647C25B77 for ; Wed, 22 May 2024 04:42:57 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id C634D10E098; Wed, 22 May 2024 04:42:56 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="V60iYRut"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.20]) by gabe.freedesktop.org (Postfix) with ESMTPS id DF8D010E379 for ; Wed, 22 May 2024 04:42:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1716352971; x=1747888971; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=oDbmRJTxadVXQQAENKx56HzJ7EikpOb/2QmL0KIAohM=; b=V60iYRutVO+uTxvssPoUDNxpLHAzNT/PnxtST9zOEm6nz0U0tNCUzSjF dHGRvzp2yTZhJwrwjUV7XvelWMYNbNSj+DP8/K0Tw6zFZQUHMpIpwVrxM Xm8lVFaTujLQp+KtbkG1bGqs/ifaqJ5WD0pWe4GJhyPp+fwkJe34Gh3UD I/gpvnuamtmsQl4DLNL9FMYhIXSkjpXaFvoKBcP3Is7S0u8eAlqVSsHuV Bd6yHdn8tjRRrvNtKXk2W21BNpZdNs2fGywU8qHxaqBFavI2UlnRjyN5i YJQ0R2h8GnGy6Eex6Prk/ZHfZlAHikhJp1AFiMazDlK2+vU3R6ULejS/v g==; X-CSE-ConnectionGUID: dJyNmr2KR3WmWf2zlZUDnQ== X-CSE-MsgGUID: s2qGVGfnT5S/E3jPARnxfw== X-IronPort-AV: E=McAfee;i="6600,9927,11079"; a="12432767" X-IronPort-AV: E=Sophos;i="6.08,179,1712646000"; d="scan'208";a="12432767" Received: from fmviesa007.fm.intel.com ([10.60.135.147]) by orvoesa112.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 May 2024 21:42:50 -0700 X-CSE-ConnectionGUID: +gzANFDwT7WzC7lp6T1NXQ== X-CSE-MsgGUID: V4ES+BJeTSCV9UAy2xzyGQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.08,179,1712646000"; d="scan'208";a="33075612" Received: from orsosgc001.jf.intel.com (HELO orsosgc001.intel.com) ([10.165.21.138]) by fmviesa007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 May 2024 21:42:49 -0700 Date: Tue, 21 May 2024 21:42:49 -0700 Message-ID: <85v8361mpi.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: "Souza, Jose" Cc: "intel-xe@lists.freedesktop.org" , Umesh Nerlige Ramappa , Lionel Landwerlin Subject: Re: [PATCH 00/17] Add OA functionality to Xe In-Reply-To: <8f86d8ea1d555e8261aab25bda0011ff96698522.camel@intel.com> References: <20240315013518.2848986-1-ashutosh.dixit@intel.com> <438b276a653bf56fe1e0e131709d615dec86ae3e.camel@intel.com> <87frufuc96.wl-ashutosh.dixit@intel.com> <96d03111d07e8182e7ecb3c0ca1942c7fef22e6f.camel@intel.com> <595ea35d63cd92777b36f6ab87cd1f6483a4b38f.camel@intel.com> <851q5v2ljw.wl-ashutosh.dixit@intel.com> <8f86d8ea1d555e8261aab25bda0011ff96698522.camel@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 Tue, 21 May 2024 09:29:51 -0700, Souza, Jose wrote: > > On Tue, 2024-05-21 at 09:10 -0700, Dixit, Ashutosh wrote: > > On Tue, 21 May 2024 07:47:58 -0700, Souza, Jose wrote: > > > > Hi Jose, > > > > > > Other ask, can you remove this 'Failed to remove unknown OA config' > > > > debug message from xe_oa_remove_config_ioctl()? > > > > > > Missed 'Insufficient privileges to remove xe OA config', that need to be > > > removed too from xe_oa_remove_config_ioctl(). > > > > > > > Mesa will be using DRM_XE_PERF_OP_REMOVE_CONFIG with config id set to > > > > UINT64_MAX to detect if Xe KMD supports OA counters and if application > > > > has enough permissions to use it. So it causes dmesg to be flooded > > > > with 'xe 0000:00:02.0: [drm:xe_oa_remove_config_ioctl [xe]] Failed to > > > > remove unknown OA config' messages when running tests suites. > > > > > > > > Or do you have other suggestion of uAPI that I can use. Also, to return to the original issue, what exactly is the issue if dmesg is getting flooded when runing tests? Maybe it's ok? Or if it is not, why don't you turn off particular debug messages using /sys/module/drm/parameters/debug? So basically I don't want to tell you what to do or how to implement your stuff (as long as you reciprocally don't ask us to make changes either). The Xe uapi is exposed and userspace if free to use it however they want. So anyway, the discussion in this thread has come up with a few options, which I can quickly summarize here: * Live with the debug messages * Turn debug messages off with /sys/module/drm/parameters/debug * Query the OS for process capabilities or privileges * Refactor the code to not need oa_metrics_available() * Anything else? Another idea e.g. is to eventually convert debug messages into dynamic debug which can be controlled at lower granularity iirc (so e.g. you can turn off OA debug messages only but this needs some work). So let's see where this goes :) Thanks. -- Ashutosh > > > > OK, so you are relying on ENODEV and EACCES errno's from > > DRM_XE_PERF_OP_REMOVE_CONFIG to find out (a) if OA is present and (b) if > > you need to be root (actually CAP_PERFMON or CAP_SYS_ADMIN). > > yep > > > > > This logic in Xe should be close to what we have in i915? What does Mesa do > > for i915, or what doesn't work in Xe? > > > > Here are some pointers: > > > > * You can execute DRM_XE_DEVICE_QUERY_OA_UNITS to see if OA is present > > > > * Add/remove OA configs and using the global OAG buffer (time based > > sampling or DRM_XE_OA_PROPERTY_SAMPLE_OA set) are priviliged operations > > (need root). Operations which only need OAR/OAC (OA queries, without > > DRM_XE_OA_PROPERTY_SAMPLE_OA) can be executed by non-root. > > > > * If "/proc/sys/dev/xe/perf_stream_paranoid" is 0, all operations can be > > executed by non-root users. Otherwise, as I described in the previous > > point. > > It is possible that process not started by root has CAP_PERFMON: > > "Unprivileged processes with enabled CAP_PERFMON capability are treated > as privileged processes with respect to perf_events performance > monitoring and observability operations,..." > > And from what I understood only root can write to perf_stream_paranoid, so I don't see a point in having this file... > > > > > So basically I think you just need to check for the perf_stream_paranoid > > file above. It will tell you both (a) if OA is present (because we are > > going to merge the code which creates this file together with OA) and (b) > > if you need to be root for particular operations. > > > > Thanks. > > -- > > Ashutosh >