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

[Rodrigo Vivi <rodrigo.vivi@intel.com>]

On Thu, Mar 26, 2026 at 10:34:20PM -0700, Dixit, Ashutosh wrote:
> 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?

yes, that's probably the way to go since we still only have the oa in the PF.

In the future we might add a knob to steer where the oa is-or-not available.

> 
> 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
> >