Re: [PATCH v2 9/9] drm/xe/multi_queue: Whitelist QUEUE_TIMESTAMP register

[Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>]

On Tue, May 05, 2026 at 11:34:38AM -0700, Niranjana Vishwanathapura wrote:
>On Tue, May 05, 2026 at 10:58:42AM -0700, Umesh Nerlige Ramappa wrote:
>>On Mon, May 04, 2026 at 09:25:29PM -0700, Niranjana Vishwanathapura wrote:
>>>On Fri, May 01, 2026 at 05:53:42PM -0700, Umesh Nerlige Ramappa wrote:
>>>>In a multi-queue use case, when a job is running on the secondary queue,
>>>>the CTX_TIMESTAMP does not reflect the queues run ticks. Instead, we use
>>>>the QUEUE TIMESTAMP to check how long the job ran. For user space to see
>>>>the run ticks for a secondary queue, whitelist the QUEUE_TIMESTAMP
>>>>register.
>>>>
>>>>Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
>>>>---
>>>>v2: Whitelist QUEUE_TIMESTAMP only for copy and compute engines (Niranjana)
>>>>---
>>>>drivers/gpu/drm/xe/xe_reg_whitelist.c | 14 ++++++++++++++
>>>>1 file changed, 14 insertions(+)
>>>>
>>>>diff --git a/drivers/gpu/drm/xe/xe_reg_whitelist.c b/drivers/gpu/drm/xe/xe_reg_whitelist.c
>>>>index 80577e4b7437..37d6ac720d5c 100644
>>>>--- a/drivers/gpu/drm/xe/xe_reg_whitelist.c
>>>>+++ b/drivers/gpu/drm/xe/xe_reg_whitelist.c
>>>>@@ -33,6 +33,14 @@ static bool match_has_mert(const struct xe_device *xe,
>>>>	return xe_device_has_mert((struct xe_device *)xe);
>>>>}
>>>>
>>>>+static bool match_multiq_class(const struct xe_device *xe,
>>>>+			       const struct xe_gt *gt,
>>>>+			       const struct xe_hw_engine *hwe)
>>>
>>>To be consistent, we have used 'multi_queue' as naming convention
>>>and avoided 'multiq'. It would be good to keep that consistency
>>>everywhere.
>>
>>sure, will change that
>>>
>>>>+{
>>>>+	return hwe->class == XE_ENGINE_CLASS_COMPUTE ||
>>>>+	       hwe->class == XE_ENGINE_CLASS_COPY;
>>>
>>>We already have xe_exec_queue_supports_multi_queue() function 
>>>which does similar check. I think we need to abstract it out to a 
>>>single
>>>function and use that instead of multiple places in code that
>>>determine whether a class supports multi-queue or not.
>>
>>The whitelist is applied during engine init at driver load, so we 
>>don't have any exec queues yet. Instead, should we derive supported 
>>engines from xe_graphics_desc.multi_queue_engine_class_mask and 
>>check?
>>
>
>Yah, xe_exec_queue_supports_multi_queue() also uses it. So, may be add a
>xe_gt_supports_multi_queue(struct xe_gt *gt, enum xe_engine_class class)
>in xe_gt.h and use that both here and in xe_exec_queue_supports_multi_queue().

Oh, I didn't read your comment right earlier. That's what you were 
already suggesting. Will do.

Umesh

>
>Niranjana
>
>>Umesh
>>
>>>
>>>Niranjana
>>>
>>>>+}
>>>>+
>>>>static const struct xe_rtp_entry_sr register_whitelist[] = {
>>>>	{ XE_RTP_NAME("WaAllowPMDepthAndInvocationCountAccessFromUMD, 1408556865"),
>>>>	  XE_RTP_RULES(GRAPHICS_VERSION_RANGE(1200, 1210), ENGINE_CLASS(RENDER)),
>>>>@@ -54,6 +62,12 @@ static const struct xe_rtp_entry_sr register_whitelist[] = {
>>>>				RING_FORCE_TO_NONPRIV_ACCESS_RD,
>>>>				XE_RTP_ACTION_FLAG(ENGINE_BASE)))
>>>>	},
>>>>+	{ XE_RTP_NAME("allow_read_queue_timestamp"),
>>>>+	  XE_RTP_RULES(GRAPHICS_VERSION_RANGE(3500, 3511), FUNC(match_multiq_class)),
>>>>+	  XE_RTP_ACTIONS(WHITELIST(RING_QUEUE_TIMESTAMP(0),
>>>>+				   RING_FORCE_TO_NONPRIV_ACCESS_RD,
>>>>+				   XE_RTP_ACTION_FLAG(ENGINE_BASE)))
>>>>+	},
>>>>	{ XE_RTP_NAME("16014440446"),
>>>>	  XE_RTP_RULES(PLATFORM(PVC)),
>>>>	  XE_RTP_ACTIONS(WHITELIST(XE_REG(0x4400),
>>>>-- 
>>>>2.43.0
>>>>