From: "Bernatowicz, Marcin" <marcin.bernatowicz@linux.intel.com>
To: Michal Wajdeczko <michal.wajdeczko@intel.com>,
intel-xe@lists.freedesktop.org
Cc: "Michał Winiarski" <michal.winiarski@intel.com>
Subject: Re: [PATCH] drm/xe/pf: Keep VF LMEM BAR size low if no VFs enabled
Date: Fri, 19 Sep 2025 18:22:59 +0200 [thread overview]
Message-ID: <3455f6e5-89a6-4eb2-8b56-9b792d0b42b9@linux.intel.com> (raw)
In-Reply-To: <4c0f7b32-db6f-4758-89f9-22f6848d99a5@intel.com>
On 9/18/2025 8:24 PM, Michal Wajdeczko wrote:
>
>
> On 9/18/2025 6:43 PM, Marcin Bernatowicz wrote:
>> When VFs are enabled on dGFX the driver resizes the PF VF_LMEM_BAR to
>> fit the requested layout. After VFs are disabled the PF VF BAR
>> size is left as-is. On platforms with tight MMIO apertures a
>> subsequent unplug/rescan followed by another enable may fail with:
>>
>> "VF BAR …: can't assign; no space"
>>
>> because the PCI core reserves address space based on the (now large) VF
>> template, often multiplied by totalvfs.
>>
>> v2: Use pci.total_vfs in helper (Michał Wajdeczko)
>
> internal reviews don't count
Ack. I’ll drop the v2 note tied to internal review.
>
>>
>> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/5937
>> Fixes: 94eae6ee4c2d ("drm/xe/pf: Set VF LMEM BAR size")
>> Signed-off-by: Marcin Bernatowicz <marcin.bernatowicz@linux.intel.com>
>> Cc: Michał Wajdeczko <michal.wajdeczko@intel.com>
>> Cc: Michał Winiarski <michal.winiarski@intel.com>
>> ---
>> drivers/gpu/drm/xe/xe_pci_sriov.c | 22 ++++++++++++++++++++++
>> 1 file changed, 22 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/xe/xe_pci_sriov.c b/drivers/gpu/drm/xe/xe_pci_sriov.c
>> index af05db07162e..ff003a650f79 100644
>> --- a/drivers/gpu/drm/xe/xe_pci_sriov.c
>> +++ b/drivers/gpu/drm/xe/xe_pci_sriov.c
>> @@ -144,11 +144,26 @@ static int resize_vf_vram_bar(struct xe_device *xe, int num_vfs)
>> return pci_iov_vf_bar_set_size(pdev, VF_LMEM_BAR, __fls(sizes));
>> }
>>
>> +static void reduce_vf_vram_bar_size(struct xe_device *xe)
>
> is it "reduce" or "restore" ?
Agree — “restore” is clearer. We’re resetting the VF LMEM BAR template
to the order that fits total_vfs, not just shrinking it. I’ll rename to
restore_vf_vram_bar_size()
>
>> +{
>> + struct pci_dev *pdev = to_pci_dev(xe->drm.dev);
>> + int err;
>> +
>> + if (!IS_DGFX(xe))
>> + return;
>> +
>> + err = resize_vf_vram_bar(xe, pci_sriov_get_totalvfs(pdev));
>
> pci_sriov_get_totalvfs() might also return tweaked value based on xe.max_vfs modparam
>
> https://elixir.bootlin.com/linux/v6.17-rc6/source/drivers/pci/iov.c#L1276
>
Good catch. I’ll use the driver’s cached device total VFs:
xe->sriov.pf.device_total_vfs
>> + if (err)
>> + xe_sriov_info(xe, "Failed to reduce VF LMEM BAR size: %d\n",
>> + err);
>
> we try to show nice error codes using (%pe)
Ack
>
>> +}
>> +
>> static int pf_enable_vfs(struct xe_device *xe, int num_vfs)
>> {
>> struct pci_dev *pdev = to_pci_dev(xe->drm.dev);
>> int total_vfs = xe_sriov_pf_get_totalvfs(xe);
>> int err;
>> + bool vf_vram_bar_resized = false;
>
> please try to keep vars in reverse-xmas-tree order
Ack>
>>
>> xe_assert(xe, IS_SRIOV_PF(xe));
>> xe_assert(xe, num_vfs > 0);
>> @@ -178,6 +193,8 @@ static int pf_enable_vfs(struct xe_device *xe, int num_vfs)
>> err = resize_vf_vram_bar(xe, num_vfs);
>> if (err)
>> xe_sriov_info(xe, "Failed to set VF LMEM BAR size: %d\n", err);
>> + else
>> + vf_vram_bar_resized = true;
>> }
>>
>> err = pci_enable_sriov(pdev, num_vfs);
>> @@ -194,6 +211,9 @@ static int pf_enable_vfs(struct xe_device *xe, int num_vfs)
>> return num_vfs;
>>
>> failed:
>> + if (vf_vram_bar_resized)
>> + reduce_vf_vram_bar_size(xe);
>
> in pf_disable_vfs() below it's called unconditionally
> why can't we do the same here? or it's broken there?
>
Makes sense, I do not see a reason to not call it unconditionally here
and drop vf_vram_bar_resized
>> +
>> pf_unprovision_vfs(xe, num_vfs);
>> xe_pm_runtime_put(xe);
>> out:
>> @@ -218,6 +238,8 @@ static int pf_disable_vfs(struct xe_device *xe)
>>
>> pci_disable_sriov(pdev);
>>
>> + reduce_vf_vram_bar_size(xe);
>> +
>> pf_reset_vfs(xe, num_vfs);
>>
>> pf_unprovision_vfs(xe, num_vfs);
>
next prev parent reply other threads:[~2025-09-19 16:23 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-18 16:43 [PATCH] drm/xe/pf: Keep VF LMEM BAR size low if no VFs enabled Marcin Bernatowicz
2025-09-18 16:51 ` ✓ CI.KUnit: success for " Patchwork
2025-09-18 17:34 ` ✓ Xe.CI.BAT: " Patchwork
2025-09-18 18:24 ` [PATCH] " Michal Wajdeczko
2025-09-19 16:22 ` Bernatowicz, Marcin [this message]
2025-09-19 2:50 ` ✗ Xe.CI.Full: failure for " Patchwork
-- strict thread matches above, loose matches on Subject: below --
2025-09-22 8:57 [PATCH] " Marcin Bernatowicz
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=3455f6e5-89a6-4eb2-8b56-9b792d0b42b9@linux.intel.com \
--to=marcin.bernatowicz@linux.intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=michal.wajdeczko@intel.com \
--cc=michal.winiarski@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