Re: [PATCH 00/17] Add OA functionality to Xe

["Dixit, Ashutosh" <ashutosh.dixit@intel.com>]

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
>