PF drivers can resize a VF BAR using VF Resizable BAR (ReBAR) support via
pci_iov_vf_bar_set_size(). The new size persists in the SR-IOV capability
config space. A later reprobe / unplug-rescan / next pci_enable_sriov()
then sees the inflated VF BAR registers, and the PCI core reserves MMIO
based on that size multiplied by TotalVFs.

On platforms with tight apertures, this can make subsequent SR-IOV enable
fail due to lack of address space.

This series records the initial per-VF BAR sizes during SR-IOV init and
restores those sizes when SR-IOV is disabled, when SR-IOV enable fails,
or when the PF driver is detached.

Note on user-visible behavior: drivers that rely on a resized VF BAR
persisting across an enable/disable cycle must now call
pci_iov_vf_bar_set_size() again before each pci_enable_sriov().

v1 -> v2:
  - Addressed sashiko-bot feedback.
  - Restore VF BAR sizes on early sriov_enable() validation failures too.
  - Move the detach-time restore from sriov_release() to pci_iov_remove().

Marcin Bernatowicz (3):
  PCI/IOV: Remember initial VF BAR sizes
  PCI/IOV: Restore initial VF ReBAR sizes on SR-IOV disable/failure
  PCI/IOV: Restore initial VF ReBAR sizes on PF driver remove

 drivers/pci/iov.c | 86 ++++++++++++++++++++++++++++++++++++++++-------
 drivers/pci/pci.h |  3 +-
 2 files changed, 76 insertions(+), 13 deletions(-)

-- 
2.43.0

Hi,

On 8/3/26 7:30 PM, Marcin Bernatowicz wrote:
> PF drivers can resize a VF BAR using VF Resizable BAR (ReBAR) support via
> pci_iov_vf_bar_set_size(). The new size persists in the SR-IOV capability
> config space. A later reprobe / unplug-rescan / next pci_enable_sriov()
> then sees the inflated VF BAR registers, and the PCI core reserves MMIO
> based on that size multiplied by TotalVFs.

Would it make sense for pci_enable_sriov() to check for a ReBAR 
capability in the VF and set it to the smallest possible setting, so we 
get the same behaviour regardless of whether this was cleaned up correctly?

Also, should it be "previous" or "smallest" size (in order to not make a 
missed cleanup permanent)?

I'm a bit worried about POWER, while we do have lots of MMIO space, we 
also use kexec() quite a lot because on several machines, the bootloader 
is some ancient minimal Linux system.

    Simon

On 8/3/2026 1:17 PM, Simon Richter wrote:
> Hi,
>
> On 8/3/26 7:30 PM, Marcin Bernatowicz wrote:
>> PF drivers can resize a VF BAR using VF Resizable BAR (ReBAR) support 
>> via
>> pci_iov_vf_bar_set_size(). The new size persists in the SR-IOV 
>> capability
>> config space. A later reprobe / unplug-rescan / next pci_enable_sriov()
>> then sees the inflated VF BAR registers, and the PCI core reserves MMIO
>> based on that size multiplied by TotalVFs.
>
> Would it make sense for pci_enable_sriov() to check for a ReBAR 
> capability in the VF and set it to the smallest possible setting, so 
> we get the same behaviour regardless of whether this was cleaned up 
> correctly?
>
> Also, should it be "previous" or "smallest" size (in order to not make 
> a missed cleanup permanent)?
>
> I'm a bit worried about POWER, while we do have lots of MMIO space, we 
> also use kexec() quite a lot because on several machines, the 
> bootloader is some ancient minimal Linux system.
>
>    Simon

Hi Simon,

Thanks for the point.

I think an unconditional reset in pci_enable_sriov() would conflict with 
PF drivers
that intentionally set VF ReBAR before enable (Xe does this in its 
sriov_configure flow).
A core reset-to-smallest would override that policy.

For this reason, this series restores the initial-at-probe size in 
SR-IOV lifecycle cleanup paths
(disable, enable failure, PF remove), which fixes persistence from this 
kernel without forcing a global sizing policy.

You are right that kexec can inherit an already mutated value from an 
older kernel;
that limitation exists, but this series prevents further drift once 
running on a patched kernel.

Thanks,
Marcin