From: sashiko-bot@kernel.org
To: "Nareshkumar Gollakoti" <naresh.kumar.g@intel.com>,
intel-xe@lists.freedesktop.org
Subject: Re: [PATCH 1/6] drm/xe/pci: log ATS/PASID enablement state at probe
Date: Wed, 21 Oct 2026 04:32:30 +0000 [thread overview]
Message-ID: <sashiko-outbox-179784@kernel.org> (raw)
In-Reply-To: <20261021041117.1774877-2-naresh.kumar.g@intel.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] drm/xe/pci: xe_pci_ats_pasid_enabled() always returns false on SR-IOV VFs
- [Low] drm/xe/pci: build failure in __xe_pci_probe() without CONFIG_PCI_ATS/PASID
--
commit 9613705bbc43ffcbfae8d92b0e6cff920caffa87
Author: Nareshkumar Gollakoti <naresh.kumar.g@intel.com>
drm/xe/pci: log ATS/PASID enablement state at probe
This commit logs ATS and PASID enablement states during __xe_pci_probe() when
their PCI capabilities are present, and introduces xe_pci_ats_pasid_enabled()
to check whether both features are enabled on a PCI device.
> diff --git a/drivers/gpu/drm/xe/xe_pci.c b/drivers/gpu/drm/xe/xe_pci.c
> index 44587b5f4df60..7c8a4286b657a 100644
> --- a/drivers/gpu/drm/xe/xe_pci.c
> +++ b/drivers/gpu/drm/xe/xe_pci.c
> @@ -1281,6 +1281,13 @@ static int __xe_pci_probe(struct pci_dev *pdev, const struct xe_device_desc *des
> xe_step_name(xe->info.step.media),
> xe_step_name(xe->info.step.basedie));
>
> + if (pdev->ats_cap)
> + drm_dbg(&xe->drm, "Arch ATS = %s",
> + str_enabled_disabled(pdev->ats_enabled));
> + if (pdev->pasid_cap)
> + drm_dbg(&xe->drm, "Arch PASID = %s",
> + str_enabled_disabled(pdev->pasid_enabled));
[Severity: Low]
Will __xe_pci_probe() in drivers/gpu/drm/xe/xe_pci.c fail to build when
CONFIG_PCI_ATS or CONFIG_PCI_PASID is disabled?
In include/linux/pci.h, struct pci_dev only defines ats_cap and pasid_cap
when their respective Kconfig options are enabled:
#ifdef CONFIG_PCI_ATS
...
u16 ats_cap; /* ATS Capability offset */
u8 ats_stu; /* ATS Smallest Translation Unit */
#endif
...
#ifdef CONFIG_PCI_PASID
u16 pasid_cap; /* PASID Capability offset */
u16 pasid_features;
#endif
Since CONFIG_DRM_XE in drivers/gpu/drm/xe/Kconfig only depends on DRM and
PCI without selecting or depending on PCI_ATS or PCI_PASID (for example, in
drivers/gpu/drm/xe/.kunitconfig), accessing pdev->ats_cap and pdev->pasid_cap
directly without IS_ENABLED() guards breaks the build when either option is
not set.
> +
> drm_dbg(&xe->drm, "SR-IOV support: %s (mode: %s)\n",
> str_yes_no(xe_device_has_sriov(xe)),
> xe_sriov_mode_to_string(xe_device_sriov_mode(xe)));
> diff --git a/drivers/gpu/drm/xe/xe_pci.h b/drivers/gpu/drm/xe/xe_pci.h
> index 11bcc5fe2c5b9..5f784229a5ecf 100644
> --- a/drivers/gpu/drm/xe/xe_pci.h
> +++ b/drivers/gpu/drm/xe/xe_pci.h
> @@ -5,6 +5,7 @@
>
> #ifndef _XE_PCI_H_
> #define _XE_PCI_H_
> +#include <linux/pci.h>
>
> struct pci_dev;
>
> @@ -12,4 +13,9 @@ int xe_register_pci_driver(void);
> void xe_unregister_pci_driver(void);
> struct xe_device *xe_pci_to_pf_device(struct pci_dev *pdev);
>
> +static inline bool xe_pci_ats_pasid_enabled(struct pci_dev *pdev)
> +{
> + return pdev->ats_enabled && pdev->pasid_enabled;
> +}
[Severity: Medium]
How does xe_pci_ats_pasid_enabled() in drivers/gpu/drm/xe/xe_pci.h (as well
as the PASID check in __xe_pci_probe()) behave on SR-IOV Virtual Functions?
In drivers/pci/ats.c, pci_enable_pasid() notes that VFs do not implement
their own PASID capability (so pdev->pasid_cap is 0) and instead share the
PF's PASID configuration:
if (pdev->is_virtfn) {
if (pci_physfn(pdev)->pasid_enabled)
return 0;
return -EINVAL;
}
When the IOMMU enables PASID on a VF via pci_enable_pasid(), it checks
pci_physfn(pdev)->pasid_enabled and returns 0 without setting
pdev->pasid_enabled on the VF's pci_dev (whereas pci_enable_ats() sets
pdev->ats_enabled on the VF).
Because xe_pci_ats_pasid_enabled() and __xe_pci_probe() inspect
pdev->pasid_enabled and pdev->pasid_cap directly instead of checking
pci_physfn(pdev) (or calling pci_pasid_status(pdev)), won't
xe_pci_ats_pasid_enabled() always return false on VFs and __xe_pci_probe()
always skip logging the PASID state on VFs?
> +
> #endif
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261021041117.1774877-1-naresh.kumar.g@intel.com?part=1
next prev parent reply other threads:[~2026-10-21 4:32 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-21 4:11 [PATCH 0/6] ATS/PASID SVA support and PRI-less fault servicing Nareshkumar Gollakoti
2026-10-21 4:11 ` [PATCH 1/6] drm/xe/pci: log ATS/PASID enablement state at probe Nareshkumar Gollakoti
2026-10-21 4:32 ` sashiko-bot [this message]
2026-10-21 4:11 ` [PATCH 2/6] drm/xe/vm: Setup SVA infrastructure for PASID support Nareshkumar Gollakoti
2026-10-21 4:30 ` sashiko-bot
2026-10-21 4:11 ` [PATCH 3/6] drm/xe/vm: add helper to retrieve VM SVA PASID Nareshkumar Gollakoti
2026-10-21 4:11 ` [PATCH 4/6] drm/xe/lrc: program CTX_SYS_PASID for ATS/PASID-enabled contexts Nareshkumar Gollakoti
2026-10-21 4:11 ` [PATCH 5/6] drm/xe/pci: add helper for ATS/PASID without PRI Nareshkumar Gollakoti
2026-10-21 4:11 ` [PATCH 6/6] drm/xe/pagefault: add CPU mirror VMA for SVA faults " Nareshkumar Gollakoti
2026-10-21 4:35 ` sashiko-bot
2026-10-21 4:21 ` ✗ CI.KUnit: failure for ATS/PASID SVA support and PRI-less fault servicing Patchwork
2026-10-21 15:25 ` [PATCH 0/6] " Thomas Hellström
2026-10-22 6:30 ` Kumar G, Naresh
2026-10-22 11:12 ` Thomas Hellström
2026-10-21 21:24 ` 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=sashiko-outbox-179784@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=naresh.kumar.g@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox