Describe the bug
When using iGPU SR-IOV on Proxmox VE, a Virtual Function Function Level Reset (VF FLR) triggers a disruption in the host's networking. Specifically, when a VM attached to a VF starts or stops, the VF FLR causes the host's virtual network bridges (e.g., vmbr0) and associated tap interfaces to unexpectedly enter a blocking and disabled state. This results in temporary but highly disruptive network disconnections for the PVE host and the entire LAN (if the host acts as a gateway).
To Reproduce
Steps to reproduce the behavior:
Configure iGPU SR-IOV (i915-sriov) on a Proxmox VE host.
Assign an iGPU Virtual Function (VF) to a guest VM via PCIe passthrough.
Start, shutdown, or reboot the guest VM to trigger the VF2 FLR event.
Ping the PVE host or monitor the network; observe the connection drop simultaneously with the reset.
Expected behavior
A VF reset on the iGPU should be isolated and must not trigger STP blocking, MAC address drifting, or PCIe bus resets that affect the host's physical NICs and virtual bridges.
Logs
dmesg output showing the exact moment the FLR triggers the network bridge to block:
Plaintext
[Tue Mar 31 23:35:10 2026] vfio-pci 0000:00:02.2: resetting
[Tue Mar 31 23:35:10 2026] i915 0000:00:02.0: VF2 FLR
[Tue Mar 31 23:35:10 2026] vfio-pci 0000:00:02.2: reset done
[Tue Mar 31 23:35:11 2026] tap103i0: entered promiscuous mode
[Tue Mar 31 23:35:11 2026] vmbr0: port 4(tap103i0) entered blocking state
[Tue Mar 31 23:35:11 2026] vmbr0: port 4(tap103i0) entered disabled state
[Tue Mar 31 23:35:11 2026] tap103i0: entered allmulticast mode
[Tue Mar 31 23:35:11 2026] vmbr0: port 4(tap103i0) entered blocking state
[Tue Mar 31 23:35:11 2026] vmbr0: port 4(tap103i0) entered forwarding state
Environment
OS: Debian GNU/Linux 13 (trixie) / Proxmox VE (Latest version)
Kernel: Latest available kernel for PVE
Hardware: Intel N100 platform
Driver: i915-sriov-dkms (version 20260305)
NIC: Intel i226 series
Current Workaround
Currently mitigating the issue by explicitly disabling Spanning Tree Protocol (STP), reducing forwarding delay to 0, and hardcoding the physical NIC MAC addresses to the virtual bridges in /etc/network/interfaces:
Plaintext
auto vmbr0
iface vmbr0 inet static
bridge-ports enp4s0
hwaddress 60:be:b4:14:f2:cf
bridge-stp off
bridge-fd 0
Note: Additional isolation via GRUB parameters (pcie_port_pm=off pcie_aspm=off pcie_acs_override=downstream,multifunction) is also being tested to prevent power state changes on the PCIe root complex from affecting the NICs.
飞牛正常解码安装的20250722，win10使用gpu就会不定时断网，硬解或者uu远程调用了gpu，有时重启大多数是断网
Describe the bug
When using iGPU SR-IOV on Proxmox VE, a Virtual Function Function Level Reset (VF FLR) triggers a disruption in the host's networking. Specifically, when a VM attached to a VF starts or stops, the VF FLR causes the host's virtual network bridges (e.g., vmbr0) and associated tap interfaces to unexpectedly enter a blocking and disabled state. This results in temporary but highly disruptive network disconnections for the PVE host and the entire LAN (if the host acts as a gateway).
To Reproduce
Steps to reproduce the behavior:
Configure iGPU SR-IOV (i915-sriov) on a Proxmox VE host.
Assign an iGPU Virtual Function (VF) to a guest VM via PCIe passthrough.
Start, shutdown, or reboot the guest VM to trigger the VF2 FLR event.
Ping the PVE host or monitor the network; observe the connection drop simultaneously with the reset.
Expected behavior
A VF reset on the iGPU should be isolated and must not trigger STP blocking, MAC address drifting, or PCIe bus resets that affect the host's physical NICs and virtual bridges.
Logs
dmesg output showing the exact moment the FLR triggers the network bridge to block:
Plaintext
[Tue Mar 31 23:35:10 2026] vfio-pci 0000:00:02.2: resetting
[Tue Mar 31 23:35:10 2026] i915 0000:00:02.0: VF2 FLR
[Tue Mar 31 23:35:10 2026] vfio-pci 0000:00:02.2: reset done
[Tue Mar 31 23:35:11 2026] tap103i0: entered promiscuous mode
[Tue Mar 31 23:35:11 2026] vmbr0: port 4(tap103i0) entered blocking state
[Tue Mar 31 23:35:11 2026] vmbr0: port 4(tap103i0) entered disabled state
[Tue Mar 31 23:35:11 2026] tap103i0: entered allmulticast mode
[Tue Mar 31 23:35:11 2026] vmbr0: port 4(tap103i0) entered blocking state
[Tue Mar 31 23:35:11 2026] vmbr0: port 4(tap103i0) entered forwarding state
Environment
OS: Debian GNU/Linux 13 (trixie) / Proxmox VE (Latest version)
Kernel: Latest available kernel for PVE
Hardware: Intel N100 platform
Driver: i915-sriov-dkms (version 20260305)
NIC: Intel i226 series
Current Workaround
Currently mitigating the issue by explicitly disabling Spanning Tree Protocol (STP), reducing forwarding delay to 0, and hardcoding the physical NIC MAC addresses to the virtual bridges in /etc/network/interfaces:
Plaintext
auto vmbr0
iface vmbr0 inet static
bridge-ports enp4s0
hwaddress 60:be:b4:14:f2:cf
bridge-stp off
bridge-fd 0
Note: Additional isolation via GRUB parameters (pcie_port_pm=off pcie_aspm=off pcie_acs_override=downstream,multifunction) is also being tested to prevent power state changes on the PCIe root complex from affecting the NICs.
飞牛正常解码安装的20250722，win10使用gpu就会不定时断网，硬解或者uu远程调用了gpu，有时重启大多数是断网