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 643CCC25B78 for ; Wed, 22 May 2024 18:56:18 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id C186D10E339; Wed, 22 May 2024 18:56:17 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="nR2CVW2U"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.13]) by gabe.freedesktop.org (Postfix) with ESMTPS id 0D62310E339 for ; Wed, 22 May 2024 18:56:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1716404174; x=1747940174; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=kzCZzVRIdYTmx2hQ1I44zrxUVFSLHLhonS52y/nb7Lc=; b=nR2CVW2U3cvH+MQFqUP+peADC7AzulCs2HvkwpwQSuZ/RhVncIJxaZkz fbhPmrvR/THmdeJkBzyLVQPmsVBlpT6qwyQe9EWirP69iiQTcxqkdbjGD BJnoEklnhBU0fbi03V1Cb21THTerwpZiIB0DW4Qt4FI6ij8gLjNPhOYmO Io5qRwbESdSUSfHWiSALsNq4hLHPoNCZe4PE0QFN8IdGMxD5Am6E+TZ86 y8EVIRG8+lynswDIwSDir/4ImWWDHByDuMyNjmFSMu+vvrqzjnFcTK6yR 3jUPP0XmnTcs7q0Z+QnuCUhR5iqwuZlFOZonRD+kVqzOVMQC3Ye0aT7BS Q==; X-CSE-ConnectionGUID: c5nNi/zuTe6hWyB+/Rca6w== X-CSE-MsgGUID: JW19jKzxRyqU8lW0nIe4ug== X-IronPort-AV: E=McAfee;i="6600,9927,11080"; a="15630742" X-IronPort-AV: E=Sophos;i="6.08,181,1712646000"; d="scan'208";a="15630742" Received: from orviesa010.jf.intel.com ([10.64.159.150]) by fmvoesa107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 May 2024 11:56:13 -0700 X-CSE-ConnectionGUID: S72iTklLRY+Ss3NyDVKaEA== X-CSE-MsgGUID: /ehCBQq4QwKcA+7h97fLTA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.08,181,1712646000"; d="scan'208";a="33243232" Received: from vbkhoo-mobl.amr.corp.intel.com (HELO adixit-arch.intel.com) ([10.124.5.208]) by orviesa010-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 May 2024 11:56:12 -0700 Date: Wed, 22 May 2024 11:50:33 -0700 Message-ID: <87r0dtwuiu.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: "Souza, Jose" Cc: "intel-xe@lists.freedesktop.org" , "Nerlige Ramappa, Umesh" , "Landwerlin,\ Lionel G" Subject: Re: [PATCH 00/17] Add OA functionality to Xe In-Reply-To: <9657eea004738e979978e4790c310bb1489b793a.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> <85v8361mpi.wl-ashutosh.dixit@intel.com> <9657eea004738e979978e4790c310bb1489b793a.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/29.3 (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, 22 May 2024 09:13:48 -0700, Souza, Jose wrote: > > On Tue, 2024-05-21 at 21:42 -0700, Dixit, Ashutosh wrote: > > 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? > > KMD logs are also important for UMD debug. What about the answer to the first question: "what exactly is the issue if dmesg is getting flooded when runing tests"? How many lines are added per test? Why is it an issue? > > > > > 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). > > I don't think I'm asking much, I just asking to remove 2 debug messages > to implement it in a Unix portable way that supports both capabilities. > > > > > 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 > > > >