[RFC PATCH 00/14] driver core: defer per-VF sysfs creation for fast SR-IOV bring-up

[David Matlack]

On Thu, Jul 2, 2026 at 10:40 AM Pavol Sakac <sakacpav at amazon.de> wrote:
>
> Virtualization hardware keeps increasing in CPU-core and VF density.
> Kernel is trending towards preserving VFs using LUO across a kexec
> which will put SR-IOV in live-update hotpath. VFs must be re-added to
> the sysfs tree, along with its supporting devices (e.g. vfio,
> iommu_groups). On production hardware a single VF can consume ~80 kernfs
> nodes. With thousands of VFs on modern hardware, hundreds of thousands
> of kernfs nodes need to be created, which can add 100ms+ to the boot
> time and to guest downtime.
>
> Proposed here is a PoC of deferred materialization of sysfs files until
> first access to avoid cost of kernfs node creation in hot path. In the
> reproducer below using a synthetic VF to isolate the sysfs overhead,
> the per-device sysfs-creation time is reduced by ~74%. It exploits the
> expected access pattern of hypervisors, where only a subset of device
> files need to be accessed to attach a VF to a VM on the hot path.

> Feedback appreciated for:
> - table-driven attribute refactor targeting common device add path /
>   suggestions for more efficient/less invasive approach
> - mechanism of interception in kernfs, materialization, locking scheme
> - fit into context of LUO - complementary or is there some other
>   mechanism already considered to mitigate the sysfs impact

Preserving VFs is still on the roadmap [1], but I think this would fit
in nicely.

My plan is to have the kernel keep SR-IOV enabled on the PF throughout
the Live Update and remember which VFs were preserved. The next kernel
would still need to create all the pci_dev structs for the VFs, sysfs
files associated with them, etc.. So speeding up the creation of sysfs
files for those VFs would be benificial to reducing the Live Update
blackout.

I have some questions similar to Greg's, but I will follow up on the
thread he started to discuss.

[1] https://lore.kernel.org/linux-pci/20260710212616.1351130-1-dmatlack@google.com/