From: sashiko-bot@kernel.org
To: "Piórkowski, Piotr" <piotr.piorkowski@intel.com>
Cc: intel-xe@lists.freedesktop.org
Subject: Re: [PATCH v2 4/4] drm/xe/pf: Explicitly use shareable GuC IDs for VFs provisioning
Date: Mon, 17 Aug 2026 09:24:35 +0000 [thread overview]
Message-ID: <20260817092435.BF06D1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260817091013.280173-5-piotr.piorkowski@intel.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The `spare` quota enforcement in `idm_reserve_chunk_shareable_locked` mathematically miscalculates quota and incorrectly rejects allocations.
- [Medium] The `check_quota` kunit test was modified to use non-overlapping pools, completely bypassing the quota enforcement logic it is supposed to test.
--
--- Patch [4]: [PATCH v2 4/4] drm/xe/pf: Explicitly use shareable GuC IDs for VFs provisioning ---
commit 249a1c056e1b8b61fd7f66cd23baf1408b302ed8
Author: Piotr Piórkowski <piotr.piorkowski@intel.com>
drm/xe/pf: Explicitly use shareable GuC IDs for VFs provisioning
Switch PF VF-context provisioning to explicitly allocate IDs from
the dedicated shareable ID pool. Also, lets remove the legacy GuC ID
reservation API now that all VFs provisioning paths use the shareable
allocation helpers.
> diff --git a/drivers/gpu/drm/xe/tests/xe_guc_id_mgr_test.c b/drivers/gpu/drm/xe/tests/xe_guc_id_mgr_test.c
> index f21d3341b5033..3e6d289f7d7a0 100644
> --- a/drivers/gpu/drm/xe/tests/xe_guc_id_mgr_test.c
> +++ b/drivers/gpu/drm/xe/tests/xe_guc_id_mgr_test.c
[ ... ]
> @@ -153,26 +160,31 @@ static void check_quota(struct kunit *test)
> {
> struct xe_guc_id_mgr *idm = test->priv;
> unsigned int n;
> + unsigned int max;
>
> - KUNIT_ASSERT_EQ(test, 0, idm_init(idm, 2, 0));
> + KUNIT_ASSERT_EQ(test, 0, idm_init(idm, 2, 2));
> + max = xe_guc_id_mgr_max_shareable(idm);
>
> mutex_lock(idm_mutex(idm));
>
> - for (n = 0; n < idm_total(idm) - 1; n++) {
> + for (n = 0; n < max - 1; n++) {
> kunit_info(test, "n=%u", n);
> - KUNIT_EXPECT_EQ(test, idm_reserve_chunk_locked(idm, 1, idm_total(idm)), -EDQUOT);
> + KUNIT_EXPECT_GE(test,
> + xe_guc_id_mgr_reserve_shareable_locked(idm, 1, max), 0);
[Severity: Medium]
Does changing the initialization to idm_init(idm, 2, 2) bypass the quota
enforcement logic this function is supposed to test?
Because usable (2) + shareable (2) is less than GUC_ID_MAX, these pools are
configured as non-overlapping. Non-overlapping pools intentionally bypass the
spare quota check.
With the test now receiving successful allocations instead of -EDQUOT, it
appears the assertions were inverted (expecting >= 0 instead of -EDQUOT),
which removes the test's coverage for the quota enforcement feature entirely.
> + KUNIT_EXPECT_GE(test,
> + xe_guc_id_mgr_reserve_shareable_locked(idm, 1, max - n), 0);
> KUNIT_EXPECT_EQ(test,
> - idm_reserve_chunk_locked(idm, 1, idm_total(idm) - n),
> - -EDQUOT);
> + xe_guc_id_mgr_reserve_shareable_locked(idm, max - n, 1),
> + -ENOSPC);
[ ... ]
> diff --git a/drivers/gpu/drm/xe/xe_gt_sriov_pf_config.c b/drivers/gpu/drm/xe/xe_gt_sriov_pf_config.c
> index b4f4a7aa21c78..79535f7478e96 100644
> --- a/drivers/gpu/drm/xe/xe_gt_sriov_pf_config.c
> +++ b/drivers/gpu/drm/xe/xe_gt_sriov_pf_config.c
[ ... ]
> @@ -889,7 +889,7 @@ static int pf_reserve_ctxs(struct xe_gt *gt, u32 num)
> struct xe_guc_id_mgr *idm = >->uc.guc.submission_state.idm;
> unsigned int spare = pf_get_spare_ctxs(gt);
>
> - return xe_guc_id_mgr_reserve(idm, num, spare);
> + return xe_guc_id_mgr_reserve_shareable(idm, num, spare);
[Severity: Medium]
Will this switch to xe_guc_id_mgr_reserve_shareable() expose a mathematical
error in the spare quota calculation?
Looking at idm_reserve_chunk_shareable_locked() in xe_guc_id_mgr.c:
if (spare) {
unsigned int used_overlap = bitmap_weight(idm->bitmap, idm->usable) -
bitmap_weight(idm->bitmap, shareable_start);
...
unsigned int need_overlap = count > free_tail ? count - free_tail : 0;
unsigned int overlap = idm->usable - shareable_start;
if (used_overlap + need_overlap + spare > overlap)
return -EDQUOT;
}
This logic calculates quota based entirely on the overlap region, effectively
ignoring free IDs in the PF-exclusive region.
While this may be masked in production because the PF currently initializes
the manager with full overlap (GUC_ID_MAX, GUC_ID_MAX), any partial overlap
configuration (e.g., usable = 65536, shareable = 2) will incorrectly fail
allocations with -EDQUOT whenever spare > overlap, regardless of the actual
number of free usable IDs available.
> }
>
> static void pf_release_ctxs(struct xe_gt *gt, u32 start, u32 num)
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260817091013.280173-1-piotr.piorkowski@intel.com?part=4
next prev parent reply other threads:[~2026-08-17 9:24 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-17 9:10 [PATCH v2 0/4] Split GuC ID space into usable and shareable pools Piórkowski, Piotr
2026-08-17 9:10 ` [PATCH v2 1/4] drm/xe/guc: Split GuC ID manager " Piórkowski, Piotr
2026-08-17 9:24 ` sashiko-bot
2026-08-17 9:10 ` [PATCH v2 2/4] drm/xe/kunit: Extend GuC ID manager split-pool coverage Piórkowski, Piotr
2026-08-17 9:23 ` sashiko-bot
2026-08-17 9:10 ` [PATCH v2 3/4] drm/xe/guc: Start use explicitly usable GuC IDs for for submission Piórkowski, Piotr
2026-08-17 9:10 ` [PATCH v2 4/4] drm/xe/pf: Explicitly use shareable GuC IDs for VFs provisioning Piórkowski, Piotr
2026-08-17 9:24 ` sashiko-bot [this message]
2026-08-17 13:01 ` ✗ CI.checkpatch: warning for Split GuC ID space into usable and shareable pools (rev2) Patchwork
2026-08-17 13:03 ` ✓ CI.KUnit: success " Patchwork
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=20260817092435.BF06D1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=piotr.piorkowski@intel.com \
--cc=sashiko-reviews@lists.linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.