Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Wajdeczko <michal.wajdeczko@intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: intel-xe@lists.freedesktop.org
Subject: Re: [PATCH] drm/xe/pf: Don't advertise support to enable VFs if not ready
Date: Tue, 14 May 2024 15:46:16 +0200	[thread overview]
Message-ID: <b49e6b94-ce29-43d8-af23-19366ba45578@intel.com> (raw)
In-Reply-To: <aqh6x2lwhruly3g4pxjiljnbodaxidb6np6tievlxk4ivq4nbt@b3z2lzsdectv>



On 14.05.2024 15:09, Lucas De Marchi wrote:
> On Tue, May 07, 2024 at 06:57:57PM GMT, Michal Wajdeczko wrote:
>> Even if we have not enabled SR-IOV support using the platform
>> specific has_sriov flag, the hardware may still report SR-IOV
>> capability and the PCI layer may wrongly advertise driver support
>> to enable VFs.  Explicitly reset the number of supported VFs to
>> zero to avoid confusion.
>>
>> Applications may read the /sys/bus/pci/devices/.../sriov_totalvfs
>> prior to enabling VFs using the sriov_numvfs to check if such an
>> operation is possible.
>>
>> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
>> ---
>> drivers/gpu/drm/xe/xe_sriov.c | 11 +++++++++++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/xe/xe_sriov.c
>> b/drivers/gpu/drm/xe/xe_sriov.c
>> index 1c3fa84b6adb..a274a5fb1401 100644
>> --- a/drivers/gpu/drm/xe/xe_sriov.c
>> +++ b/drivers/gpu/drm/xe/xe_sriov.c
>> @@ -53,6 +53,7 @@ static bool test_is_vf(struct xe_device *xe)
>>  */
>> void xe_sriov_probe_early(struct xe_device *xe)
>> {
>> +    struct pci_dev *pdev = to_pci_dev(xe->drm.dev);
>>     enum xe_sriov_mode mode = XE_SRIOV_MODE_NONE;
>>     bool has_sriov = xe->info.has_sriov;
>>
>> @@ -61,6 +62,16 @@ void xe_sriov_probe_early(struct xe_device *xe)
>>             mode = XE_SRIOV_MODE_VF;
>>         else if (xe_sriov_pf_readiness(xe))
>>             mode = XE_SRIOV_MODE_PF;
>> +    } else if (pci_sriov_get_totalvfs(pdev)) {
>> +        /*
>> +         * Even if we have not enabled SR-IOV support using the
>> +         * platform specific has_sriov flag, the hardware may still
>> +         * report SR-IOV capability and the PCI layer may wrongly
>> +         * advertise driver support to enable VFs. Explicitly reset
>> +         * the number of supported VFs to zero to avoid confusion.
> 
> Aren't these 2 different things? The PCI layer is reporting SR-IOV
> availability as reported by the HW, which doesn't mean the driver
> supports it.

Without support in our PF driver we can't support any VFs, even if HW is
reporting that it can. What we do here is aligned what the PCI layer is
expecting from the PF drivers if there is something to adjust - see [1]

/sys/bus/pci/devices/.../sriov_totalvfs

"This file appears when a physical PCIe device supports SR-IOV.
Userspace applications can read this file to determine the
maximum number of Virtual Functions (VFs) a PCIe physical
function (PF) can support. Typically, this is the value reported
in the PF's SR-IOV extended capability structure's TotalVFs
element.  Drivers have the ability at probe time to reduce the
value read from this file via the pci_sriov_set_totalvfs()
function"

[1]
https://elixir.bootlin.com/linux/latest/source/Documentation/ABI/testing/sysfs-bus-pci#L289


> 
> Lucas De Marchi
> 
>> +         */
>> +        drm_info(&xe->drm, "Support for SR-IOV is not available\n");
>> +        pci_sriov_set_totalvfs(pdev, 0);
>>     }
>>
>>     xe_assert(xe, !xe->sriov.__mode);
>> -- 
>> 2.43.0
>>

  reply	other threads:[~2024-05-14 13:46 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-07 16:57 [PATCH] drm/xe/pf: Don't advertise support to enable VFs if not ready Michal Wajdeczko
2024-05-07 19:39 ` ✓ CI.Patch_applied: success for " Patchwork
2024-05-07 19:39 ` ✓ CI.checkpatch: " Patchwork
2024-05-07 19:40 ` ✓ CI.KUnit: " Patchwork
2024-05-07 19:52 ` ✓ CI.Build: " Patchwork
2024-05-07 19:55 ` ✓ CI.Hooks: " Patchwork
2024-05-07 19:56 ` ✓ CI.checksparse: " Patchwork
2024-05-07 21:02 ` ✓ CI.BAT: " Patchwork
2024-05-08  6:21 ` ✗ CI.FULL: failure " Patchwork
2024-05-15 12:21   ` Michal Wajdeczko
2024-05-14 10:50 ` [PATCH] " Piotr Piórkowski
2024-05-14 13:09 ` Lucas De Marchi
2024-05-14 13:46   ` Michal Wajdeczko [this message]
2024-05-15 18:56     ` Lucas De Marchi
2024-05-14 17:00 ` ✓ CI.Patch_applied: success for drm/xe/pf: Don't advertise support to enable VFs if not ready (rev2) Patchwork
2024-05-14 17:00 ` ✓ CI.checkpatch: " Patchwork
2024-05-14 17:01 ` ✓ CI.KUnit: " Patchwork
2024-05-14 17:13 ` ✓ CI.Build: " Patchwork
2024-05-14 17:15 ` ✓ CI.Hooks: " Patchwork
2024-05-14 17:17 ` ✓ CI.checksparse: " Patchwork
2024-05-14 17:37 ` ✓ CI.BAT: " Patchwork
2024-05-14 20:12 ` ✗ CI.FULL: failure " Patchwork
2024-05-15 12:16   ` Michal Wajdeczko

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=b49e6b94-ce29-43d8-af23-19366ba45578@intel.com \
    --to=michal.wajdeczko@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=lucas.demarchi@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