From: Matthew Brost <matthew.brost@intel.com>
To: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Cc: <intel-xe@lists.freedesktop.org>,
<thomas.hellstrom@linux.intel.com>, <stuart.summers@intel.com>,
<arvind.yadav@intel.com>, <tejas.upadhyay@intel.com>
Subject: Re: [RFC 11/15] drm/xe: Add xe_guc_access_counter layer
Date: Thu, 2 Apr 2026 14:27:25 -0700 [thread overview]
Message-ID: <ac7fPY4qvSxS7rE+@gsse-cloud1.jf.intel.com> (raw)
In-Reply-To: <20260318074456.2839499-12-himal.prasad.ghimiray@intel.com>
On Wed, Mar 18, 2026 at 01:14:52PM +0530, Himal Prasad Ghimiray wrote:
> Add GuC to host (G2H) access counter notification handler to parse
> GuC firmware messages into struct xe_access_counter and forward to
> xe_access_counter_handler for processing.
>
> Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
> ---
> drivers/gpu/drm/xe/Makefile | 1 +
> drivers/gpu/drm/xe/xe_guc_access_counter.c | 62 ++++++++++++++++++++++
> drivers/gpu/drm/xe/xe_guc_access_counter.h | 15 ++++++
> drivers/gpu/drm/xe/xe_guc_ct.c | 4 ++
> 4 files changed, 82 insertions(+)
> create mode 100644 drivers/gpu/drm/xe/xe_guc_access_counter.c
> create mode 100644 drivers/gpu/drm/xe/xe_guc_access_counter.h
>
> diff --git a/drivers/gpu/drm/xe/Makefile b/drivers/gpu/drm/xe/Makefile
> index 92d8d6e4a447..296b3cba0b89 100644
> --- a/drivers/gpu/drm/xe/Makefile
> +++ b/drivers/gpu/drm/xe/Makefile
> @@ -74,6 +74,7 @@ xe-y += xe_access_counter.o \
> xe_guc_id_mgr.o \
> xe_guc_klv_helpers.o \
> xe_guc_log.o \
> + xe_guc_access_counter.o \
> xe_guc_pagefault.o \
> xe_guc_pc.o \
> xe_guc_rc.o \
> diff --git a/drivers/gpu/drm/xe/xe_guc_access_counter.c b/drivers/gpu/drm/xe/xe_guc_access_counter.c
> new file mode 100644
> index 000000000000..2158400bc50a
> --- /dev/null
> +++ b/drivers/gpu/drm/xe/xe_guc_access_counter.c
> @@ -0,0 +1,62 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2026 Intel Corporation
> + */
> +
> +#include "xe_guc_access_counter.h"
> +
> +#include "xe_access_counter.h"
> +#include "xe_device.h"
> +#include "xe_gt.h"
> +#include "xe_guc.h"
> +#include "xe_guc_fwif.h"
> +
> +/**
> + * xe_guc_access_counter_handler() - G2H access counter handler
> + * @guc: GuC object
> + * @msg: G2H message
> + * @len: Length of G2H message
> + *
> + * Parse GuC to host (G2H) message into a struct xe_access_counter and forward
> + * onto the Xe access counter layer.
> + *
> + * Return: 0 on success, negative error code on failure
> + */
> +int xe_guc_access_counter_handler(struct xe_guc *guc, u32 *msg, u32 len)
> +{
> + struct xe_access_counter ac;
> + struct xe_device *xe = guc_to_xe(guc);
> + int i;
> +
> +#define GUC_ACC_MSG_LEN_DW \
> + (sizeof(struct xe_guc_acc_desc) / sizeof(u32))
> +
> + BUILD_BUG_ON(GUC_ACC_MSG_LEN_DW > XE_ACCESS_COUNTER_PRODUCER_MSG_LEN_DW);
> +
> + if (len != GUC_ACC_MSG_LEN_DW)
> + return -EPROTO;
> +
> + ac.gt = guc_to_gt(guc);
> +
> + /* Parse access counter descriptor */
> + ac.consumer.granularity = FIELD_GET(ACC_GRANULARITY, msg[2]);
> + ac.consumer.sub_granularity = FIELD_GET(ACC_SUBG_HI, msg[1]) << 31 |
> + FIELD_GET(ACC_SUBG_LO, msg[0]);
Would it be better to move the math in xe_access_counter_get_vma() for
calculating page_va into this layer and simply pass in page_va (and
perhaps a generic length)? That would better isolate the details of the
GuC access counter interface. It would also ensure that, if we wire up a
different hardware access counter interface in the future, the common
access counter layer can remain unchanged.
> + ac.consumer.counter_type = FIELD_GET(ACC_TYPE, msg[0]);
Should we reject bad count types here? I think that makes more sense.
The only reason we don’t reject bad page faults in the G2H handler is
because page faults issue an ACK, whereas we don’t ACK access counters.
> + ac.consumer.va_range_base = ((u64)(msg[3] & ACC_VIRTUAL_ADDR_RANGE_HI) << 32) |
> + (msg[2] & ACC_VIRTUAL_ADDR_RANGE_LO);
> + /* xe3: Use ASID and engine info */
> + ac.consumer.xe3.asid = FIELD_GET(ACC_ASID, msg[1]);
> + ac.consumer.xe3.engine_class = FIELD_GET(ACC_ENG_CLASS, msg[1]);
> + ac.consumer.xe3.engine_instance = FIELD_GET(ACC_ENG_INSTANCE, msg[1]);
> + ac.consumer.xe3.vfid = FIELD_GET(ACC_VFID, msg[2]);
> +
> + /* Store producer message for potential acknowledgment */
> + ac.producer.private = guc;
> + for (i = 0; i < GUC_ACC_MSG_LEN_DW; ++i)
> + ac.producer.msg[i] = msg[i];
Do we need this? That is, we don’t currently ACK access counters—are
there plans to change this? If there no immediate plans, I'd drop this
for now.
Matt
> +
> +#undef GUC_ACC_MSG_LEN_DW
> +
> + return xe_access_counter_handler(xe, &ac);
> +}
> diff --git a/drivers/gpu/drm/xe/xe_guc_access_counter.h b/drivers/gpu/drm/xe/xe_guc_access_counter.h
> new file mode 100644
> index 000000000000..1ac8e76398d2
> --- /dev/null
> +++ b/drivers/gpu/drm/xe/xe_guc_access_counter.h
> @@ -0,0 +1,15 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright © 2025 Intel Corporation
> + */
> +
> +#ifndef _XE_GUC_ACCESS_COUNTER_H_
> +#define _XE_GUC_ACCESS_COUNTER_H_
> +
> +#include <linux/types.h>
> +
> +struct xe_guc;
> +
> +int xe_guc_access_counter_handler(struct xe_guc *guc, u32 *msg, u32 len);
> +
> +#endif
> diff --git a/drivers/gpu/drm/xe/xe_guc_ct.c b/drivers/gpu/drm/xe/xe_guc_ct.c
> index a11cff7a20be..8ac0938f7a28 100644
> --- a/drivers/gpu/drm/xe/xe_guc_ct.c
> +++ b/drivers/gpu/drm/xe/xe_guc_ct.c
> @@ -26,6 +26,7 @@
> #include "xe_gt_sriov_pf_monitor.h"
> #include "xe_guc.h"
> #include "xe_guc_log.h"
> +#include "xe_guc_access_counter.h"
> #include "xe_guc_pagefault.h"
> #include "xe_guc_relay.h"
> #include "xe_guc_submit.h"
> @@ -1630,6 +1631,9 @@ static int process_g2h_msg(struct xe_guc_ct *ct, u32 *msg, u32 len)
> case XE_GUC_ACTION_REPORT_PAGE_FAULT_REQ_DESC:
> ret = xe_guc_pagefault_handler(guc, payload, adj_len);
> break;
> + case XE_GUC_ACTION_ACCESS_COUNTER_NOTIFY:
> + ret = xe_guc_access_counter_handler(guc, payload, adj_len);
> + break;
> case XE_GUC_ACTION_TLB_INVALIDATION_DONE:
> ret = xe_guc_tlb_inval_done_handler(guc, payload, adj_len);
> break;
> --
> 2.34.1
>
next prev parent reply other threads:[~2026-04-02 21:27 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-18 7:44 [RFC 00/15] drm/xe: Access counter consumer layer Himal Prasad Ghimiray
2026-03-18 7:34 ` ✗ CI.checkpatch: warning for " Patchwork
2026-03-18 7:35 ` ✗ CI.KUnit: failure " Patchwork
2026-03-18 7:44 ` [RFC 01/15] drm/xe: Add xe_usm_queue generic USM circular buffer Himal Prasad Ghimiray
2026-04-01 21:28 ` Matthew Brost
2026-04-06 4:46 ` Ghimiray, Himal Prasad
2026-03-18 7:44 ` [RFC 02/15] drm/xe/pagefault: Use xe_usm_queue helpers Himal Prasad Ghimiray
2026-03-18 7:44 ` [RFC 03/15] drm/xe: Stub out new access_counter layer Himal Prasad Ghimiray
2026-04-02 21:46 ` Matthew Brost
2026-04-06 5:28 ` Ghimiray, Himal Prasad
2026-03-18 7:44 ` [RFC 04/15] drm/xe: Implement xe_access_counter_init Himal Prasad Ghimiray
2026-03-18 7:44 ` [RFC 05/15] drm/xe: Implement xe_access_counter_handler Himal Prasad Ghimiray
2026-04-03 2:06 ` Matthew Brost
2026-03-18 7:44 ` [RFC 06/15] drm/xe: Extract xe_vma_lock_and_validate helper Himal Prasad Ghimiray
2026-04-01 22:03 ` Matthew Brost
2026-03-18 7:44 ` [RFC 07/15] drm/xe: Move ASID to FAULT VM lookup to xe_device Himal Prasad Ghimiray
2026-04-02 21:50 ` Matthew Brost
2026-04-07 6:41 ` Ghimiray, Himal Prasad
2026-03-18 7:44 ` [RFC 08/15] drm/xe: Implement xe_access_counter_queue_work Himal Prasad Ghimiray
2026-04-01 21:10 ` Matthew Brost
2026-04-01 22:01 ` Matthew Brost
2026-04-01 22:11 ` Matthew Brost
2026-04-02 22:06 ` Matthew Brost
2026-03-18 7:44 ` [RFC 09/15] drm/xe/trace: Add xe_vma_acc trace event for access counter notifications Himal Prasad Ghimiray
2026-04-03 1:01 ` Matthew Brost
2026-03-18 7:44 ` [RFC 10/15] drm/xe/svm: Handle svm ranges on access ctr trigger Himal Prasad Ghimiray
2026-04-03 0:25 ` Matthew Brost
2026-03-18 7:44 ` [RFC 11/15] drm/xe: Add xe_guc_access_counter layer Himal Prasad Ghimiray
2026-04-02 21:27 ` Matthew Brost [this message]
2026-03-18 7:44 ` [RFC 12/15] drm/xe/uapi: Add access counter parameter extension for exec queue Himal Prasad Ghimiray
2026-03-24 14:25 ` Francois Dugast
2026-04-01 14:46 ` Matthew Brost
2026-04-01 16:36 ` Ghimiray, Himal Prasad
2026-03-18 7:44 ` [RFC 13/15] drm/xe/lrc: Pass exec_queue to xe_lrc_create for access counter params Himal Prasad Ghimiray
2026-03-18 7:44 ` [RFC 14/15] drm/xe/vm: Add xe_vma_supports_access_ctr() helper Himal Prasad Ghimiray
2026-03-18 7:44 ` [RFC 15/15] drm/xe/pt: Set NC PTE bit for VMAs ineligible for access counting Himal Prasad Ghimiray
2026-04-03 0:09 ` Matthew Brost
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ac7fPY4qvSxS7rE+@gsse-cloud1.jf.intel.com \
--to=matthew.brost@intel.com \
--cc=arvind.yadav@intel.com \
--cc=himal.prasad.ghimiray@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=stuart.summers@intel.com \
--cc=tejas.upadhyay@intel.com \
--cc=thomas.hellstrom@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox