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 B3893C25B74 for ; Tue, 21 May 2024 18:28:03 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 69A5410EC14; Tue, 21 May 2024 18:28:03 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="QAtxdDMS"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.15]) by gabe.freedesktop.org (Postfix) with ESMTPS id 6BAAF10EC14 for ; Tue, 21 May 2024 18:28:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1716316081; x=1747852081; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=jGKLU+atMIi8GY1aFsb6pSjBZ/LlrhAXWkyY4XVaObY=; b=QAtxdDMSunalcmjcUy0OSF5dt/j7mDglI6igR2PNF/yfrh9xtjbN1K11 VrUEcJgtJ1xIbHjGTfcHDl2utYxoaCdGGmkspDN8fv4/na/WyxzJakfWS 72S0x3OURLqeyV4wXesqByZN7puC4eMT2MROv8BM0Rbvnnek5q3KdKk/K 20h8qZesYaCSq7UNgwV1NfmgQc+zUHghWfsABBruVjZS8vnqUb+agn/Wk PwgRd0NIzvY/Xyg1gR8Vv3CDIQIDq59Xu2GvWbD1lvl+7HQMwigekTns5 nUlkLP49mPcPY84xAOpdugwmuZqCftIuhI2I9zkaAjFMjzr28adKpwCua g==; X-CSE-ConnectionGUID: 5LOMX98tTOyEnM6IYGOVow== X-CSE-MsgGUID: HvQxmCaBTlWVrsUX19yZSw== X-IronPort-AV: E=McAfee;i="6600,9927,11079"; a="16319789" X-IronPort-AV: E=Sophos;i="6.08,178,1712646000"; d="scan'208";a="16319789" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by orvoesa107.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 May 2024 11:28:00 -0700 X-CSE-ConnectionGUID: a0IwUmLLQi27iSHrpZIxew== X-CSE-MsgGUID: a2kXb2LqSxC6prEJV/yAWQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.08,178,1712646000"; d="scan'208";a="33446654" Received: from vbkhoo-mobl.amr.corp.intel.com (HELO adixit-arch.intel.com) ([10.124.5.208]) by orviesa006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 May 2024 11:28:00 -0700 Date: Tue, 21 May 2024 11:11:01 -0700 Message-ID: <87v837ox1m.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: "Souza, Jose" Cc: "intel-xe@lists.freedesktop.org" , Umesh Nerlige Ramappa , Robert Krzemien , Lionel Landwerlin Subject: Re: [PATCH 00/17] Add OA functionality to Xe In-Reply-To: <87wmnnoxg8.wl-ashutosh.dixit@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> <85zfsj15gf.wl-ashutosh.dixit@intel.com> <87wmnnoxg8.wl-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/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 Tue, 21 May 2024 11:02:15 -0700, Dixit, Ashutosh wrote: > > On Tue, 21 May 2024 10:39:17 -0700, Souza, Jose wrote: > > > > On Tue, 2024-05-21 at 09:43 -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. > > > > > > > > > > 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: > > > > > > Yes, correct. > > > > > > Above I am using "root" loosely as "CAP_PERFMON or CAP_SYS_ADMIN". > > > > > > So if root sets 'perf_stream_paranoid' to 0, normal users can do OA > > > priviliged operations (as described above). > > > > > > If root sets 'perf_stream_paranoid' to 1, only CAP_PERFMON or CAP_SYS_ADMIN > > > users can do OA priviliged operations. > > > > oh okay so perf_stream_paranoid has a good usage but it do not covers > > CAP_PERFMON, see below. > > > > > > > > > "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 I don't know how this statement follows? > > > > > > root or superuser is the one which gives the permission to non-CAP_PERFMON > > > and non-CAP_SYS_ADMIN users to be able to do priviliged OA operations. > > > > so if I'm running a process with CAP_PERFMON and read > > perf_stream_paranoid and it returns 0 > > 0 if fine, everyone can use all OA calls. The issue is with 1. > > > there is no way for UMD to know > > that process is allowed to use Xe KMD OA feature without do a uAPI call > > that checks for CAP_PERFMON. > > > > That is why I think is better just do a single > > DRM_XE_PERF_OP_REMOVE_CONFIG to detect if feature is present and if > > process is allowed to use it. But it generates a bunch of debug messages. > > A process should be able to find out on its own, without help from Xe > driver, what it's capabilities (CAP_PERFMON or CAP_SYS_ADMIN or neither) > are: > > https://www.google.com/search?q=linux+get+process+capabilities+in+c > https://man7.org/linux/man-pages/man3/libcap.3.html > > And therefore, along with perf_stream_paranoid, determine which OA calls it > can use. Also, could you explain why Mesa has to worry about this? As I see it, Mesa as library can be linked with processes of different capabilities. And depending on perf_stream_paranoid setting on a system, some OA calls might or might not be available, the kernel will handle it. So not sure what Mesa has to do, except pass the return code from the kernel up to the app. So what are we trying to do here in Mesa? Thanks. -- Ashutosh > > > > > 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 > > > > > >