Re: [RFC v6 1/1] drm/xe/pf: Restrict device query responses in admin-only PF mode

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

On Wed, 25 Mar 2026 01:38:51 -0700, Michal Wajdeczko wrote:
>

Hi Michal,

> On 3/24/2026 10:17 PM, Dixit, Ashutosh wrote:
> > On Sun, 15 Mar 2026 23:41:02 -0700, Satyanarayana K V P wrote:
> >>
> >> ---
> >> V5 -> V6:
> >> - Updated commit message.
> >> - Return number of engines and memory regions as zero instead of returning
> >> query size as zero (Michal Wajdeczko).
> >> - Allow all other query IOCTLs excepts query_engines and query_mem_regions
> >> (Michal Wajdeczko).
> >
> > Can someone explain the reason to move away from the approach in v5? Afais
> > v6 has issues of this sort:
> >
> > * query_engines will return 0 engines but query_hwconfig will return > 0
> >   engines
>
> but those are separate queries on purpose, right?
> and I guess that even today there could be a mismatch between these numbers:
>
> * query_engines = engines available for use by the user software
> * query_hwconfig.engines = report engines present on the hardware

OK, agreed.

>
> > * query_engines will return 0 engines but query_oa_units will list out the
> >   engines
>
> and that IMO should be considered as a desired outcome, as I guess (again)
> that this will allow us to do some OA reporting, even if PF alone is not
> submitting any workloads and we want to monitor how VFs are doing
>
> > * query_oa_units will return valid oa support but observation ioctl will
> >   fail
>
> my initial idea [1] was to expose observation ioctl as well, maybe we need
> to add it back?
>
> [1]
> https://patchwork.freedesktop.org/patch/706445/?series=160349&rev=2#comment_1299475

OK, maybe I am thinking, we can expose the observation ioctl, though there
are both pros and cons to doing this.

Pros: get some OA reporting out of the box. Though the tools etc. will
      likely not work out of the box because of other missing
      queries/ioctl's.

Cons: Not sure if it is ok to "snoop" on VF information out of the
      box. Customers might insist this is not ok and insist on the
      observation ioctl be removed. Also, on platforms on which OA is
      supported in VF, there might be a conflict between OA in PF vs VF.

Also, even if we add the observation ioctl, only the base OA feature will
work. But there are other OA features which require other ioctl's (say
exec) which will not work in the admin-only-pf mode.

The other option is not add the OA ioctl. And insist that to get regular OA
reporting/tools to work, the device must be unbound and rebound in the
normal (non-admin-only) mode.

So we could go with either of these approaches. I am ok either way. Maybe
just add the observation ioctl for now and revisit after feedback from
customers/UMD's?

Thanks.
--
Ashutosh



>
> >
> > v5 seems to have avoided contradictions of this sort. Or this doesn't
> > matter? Thanks.
>
> but since I'm not using any of those ioctls on daily basis, I might be wrong
>