Re: [PATCH v2 0/3] PCI/IOV: Restore initial VF BAR sizing after VF ReBAR

["Bernatowicz, Marcin" <marcin.bernatowicz@linux.intel.com>]

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