From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: <intel-xe@lists.freedesktop.org>,
Lucas De Marchi <lucas.demarchi@intel.com>
Subject: Re: [PATCH v5 11/11] drm/xe/configfs: Allow adding configurations for future VFs
Date: Tue, 29 Jul 2025 17:50:47 -0400 [thread overview]
Message-ID: <aIlCN6BVU4RgS1Up@intel.com> (raw)
In-Reply-To: <20250729114215.177586-12-michal.wajdeczko@intel.com>
On Tue, Jul 29, 2025 at 01:42:15PM +0200, Michal Wajdeczko wrote:
> Since we are expecting that all configuration directory names
> will match some of the existing devices, we can't provide any
> configuration for the VFs until they are actually enabled.
>
> But we can relax that restriction by just checking if there
> is a PF device that could create given VF. This is easy since
> all our PF devices are always present at function 0 and we can
> query PF device for number of VFs it could support.
>
> Then for some system with PF device at 0000:00:02.0 we can add
> configs for all VFs:
>
> /sys/kernel/config/xe/
> ├── 0000:00:02.0
> │ └── ...
> ├── 0000:00:02.1
> │ └── ...
> ├── 0000:00:02.2
> │ └── ...
> :
> └── 0000:00:02.7
> └── ...
>
> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
> Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> ---
> v2: rebase and improve checks, fix include order
> v3: put correct device (Lucas)
> ---
> drivers/gpu/drm/xe/xe_configfs.c | 24 ++++++++++++++++++++++--
> 1 file changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/xe/xe_configfs.c b/drivers/gpu/drm/xe/xe_configfs.c
> index 766775772eef..da9a8e64621f 100644
> --- a/drivers/gpu/drm/xe/xe_configfs.c
> +++ b/drivers/gpu/drm/xe/xe_configfs.c
> @@ -12,9 +12,9 @@
> #include <linux/string.h>
>
> #include "xe_configfs.h"
> -#include "xe_module.h"
> -
> #include "xe_hw_engine_types.h"
> +#include "xe_module.h"
> +#include "xe_pci_types.h"
>
> /**
> * DOC: Xe Configfs
> @@ -285,6 +285,15 @@ static const struct xe_device_desc *xe_match_desc(struct pci_dev *pdev)
> return found ? (const void *)found->driver_data : NULL;
> }
>
> +static struct pci_dev *get_physfn_instead(struct pci_dev *virtfn)
> +{
> + struct pci_dev *physfn = pci_physfn(virtfn);
> +
> + pci_dev_get(physfn);
> + pci_dev_put(virtfn);
> + return physfn;
> +}
> +
> static struct config_group *xe_config_make_device_group(struct config_group *group,
> const char *name)
> {
> @@ -306,11 +315,22 @@ static struct config_group *xe_config_make_device_group(struct config_group *gro
> return ERR_PTR(-EINVAL);
>
> pdev = pci_get_domain_bus_and_slot(domain, bus, PCI_DEVFN(slot, function));
> + if (!pdev && function)
> + pdev = pci_get_domain_bus_and_slot(domain, bus, PCI_DEVFN(slot, 0));
> + if (!pdev && slot)
> + pdev = pci_get_domain_bus_and_slot(domain, bus, PCI_DEVFN(0, 0));
I confess I got a bit lost here... specially this last case with 00.00.0, why's this
needed?
Perhaps it would be good to add some comments here explaining a bit of the
flow and thought... from the commit message I understand the PCI_DEVFN(slot, 0)....
Oh wait... okay the discrete has another level 03.00.0 hence you check this
case here as well...
Perhaps a comment to explain the different cases here would be really helpful
for the future... but the code is right:
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> if (!pdev)
> return ERR_PTR(-ENODEV);
> + pdev = get_physfn_instead(pdev);
>
> match = xe_match_desc(pdev);
> + if (match) {
> + int vfnumber = PCI_DEVFN(slot, function) - pdev->devfn;
>
> + if (vfnumber && (!dev_is_pf(&pdev->dev) || !match->has_sriov ||
> + vfnumber > pci_sriov_get_totalvfs(pdev)))
> + match = NULL;
> + }
> pci_dev_put(pdev);
>
> if (!match)
> --
> 2.47.1
>
next prev parent reply other threads:[~2025-07-29 21:50 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-29 11:42 [PATCH v5 00/11] Updates for drm/xe/configfs Michal Wajdeczko
2025-07-29 11:42 ` [PATCH v5 01/11] drm/xe: Simplify module initialization code Michal Wajdeczko
2025-07-29 11:42 ` [PATCH v5 02/11] drm/xe: Print module init abort code Michal Wajdeczko
2025-07-29 11:42 ` [PATCH v5 03/11] drm/xe/configfs: Destroy xe_configfs.su_mutex on exit/error Michal Wajdeczko
2025-07-29 21:31 ` Rodrigo Vivi
2025-08-05 12:49 ` Lucas De Marchi
2025-07-29 11:42 ` [PATCH v5 04/11] drm/xe/configfs: Drop redundant init() error message Michal Wajdeczko
2025-07-29 17:58 ` John Harrison
2025-08-05 12:55 ` Lucas De Marchi
2025-07-29 11:42 ` [PATCH v5 05/11] drm/xe/configfs: Rename struct xe_config_device Michal Wajdeczko
2025-07-29 11:42 ` [PATCH v5 06/11] drm/xe/configfs: Rename configfs_find_group() helper Michal Wajdeczko
2025-07-29 11:42 ` [PATCH v5 07/11] drm/xe/configfs: Reintroduce struct xe_config_device Michal Wajdeczko
2025-07-29 11:42 ` [PATCH v5 08/11] drm/xe/configfs: Keep default device config settings together Michal Wajdeczko
2025-07-29 11:42 ` [PATCH v5 09/11] drm/xe/configfs: Check if device was preconfigured Michal Wajdeczko
2025-07-29 11:42 ` [PATCH v5 10/11] drm/xe/configfs: Only allow configurations for supported devices Michal Wajdeczko
2025-07-29 21:40 ` Rodrigo Vivi
2025-07-29 22:20 ` John Harrison
2025-07-30 8:23 ` Michal Wajdeczko
2025-07-30 16:30 ` Rodrigo Vivi
2025-07-30 17:12 ` John Harrison
2025-07-30 18:28 ` Rodrigo Vivi
2025-07-30 19:57 ` Michal Wajdeczko
2025-07-30 20:08 ` Rodrigo Vivi
2025-07-30 20:10 ` John Harrison
2025-07-29 11:42 ` [PATCH v5 11/11] drm/xe/configfs: Allow adding configurations for future VFs Michal Wajdeczko
2025-07-29 21:50 ` Rodrigo Vivi [this message]
2025-07-29 12:03 ` ✓ CI.KUnit: success for Updates for drm/xe/configfs (rev6) Patchwork
2025-07-29 13:16 ` ✓ Xe.CI.BAT: " Patchwork
2025-07-29 18:55 ` ✗ Xe.CI.Full: failure " 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=aIlCN6BVU4RgS1Up@intel.com \
--to=rodrigo.vivi@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=lucas.demarchi@intel.com \
--cc=michal.wajdeczko@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