[Intel-gfx] [PATCH v9 6/8] drm/i915/uapi/pxp: Add a GET_PARAM for PXP

[Jordan Justen]

On 2023-05-04 22:30:07, Teres Alexis, Alan Previn wrote:
> On Thu, 2023-04-27 at 16:48 -0700, Teres Alexis, Alan Previn wrote:
> > Because of the additional firmware, component-driver and
> > initialization depedencies required on MTL platform before a
> > PXP context can be created, UMD calling for PXP creation as a
> > way to get-caps can take a long time. An actual real world
> > customer stack has seen this happen in the 4-to-8 second range
> > after the kernel starts (which sees MESA's init appear in the
> > middle of this range as the compositor comes up). To avoid
> > unncessary delays experienced by the UMD for get-caps purposes,
> > add a GET_PARAM for I915_PARAM_PXP_SUPPORT.
> > 
> alan:snip.
> Progress update on the UMD side - I'm working on patch for PR here: 
> https://gitlab.freedesktop.org/alan_previn_intel/mesa-alan-previn-features/-/commit/fb9d4fbfbef7dfd3f41df335cd31549fd39ddb57
> but taking time to verify certain code paths

Just to confirm, if I915_PARAM_PXP_STATUS returns 2 ("will be ready
soon"), then it is basically certain that in a production environment,
then it will eventually return 1 meaning it's ready, right?

If this is correct, then I think that the change in
i915_gem_supports_protected_context() is good, and probably we can
skip the change in iris_create_hw_context().

Basically, we're timing out for multiple seconds either way. And, I'm
hoping that the kernel will eventually get the PXP init done and
create the context.

I think there's 2 cases of interest here.

First, and most likely, the application running doesn't care about
protected content. In this case we can quickly advertise the support,
but there will be no consequence because the application won't use the
feature.

Second, the application does care about protected content. In this
case we can quickly advertise the support, but if the feature is used
too quickly, then the context create might take a long time.

If I915_PARAM_PXP_STATUS returning 2 has a reasonable chance in a
production environment of eventually finding out that pxp can't work,
then perhaps more disussion is needed. I guess the worst case scenario
is no worse than today though. (Except it is still somewhat better,
because the common case would not involve protected content being
used by the application.)

Another option besides from the timeout loop in
iris_create_hw_context() might be to check I915_PARAM_PXP_STATUS after
the context create fails to tweak the debug message.

-Jordan