Intel i226-V 2.5GbE PCIe passthrough causes host PCIe AER errors and link flap on VM boot (PVE 8.2)

[Ali-dev]

Hi all,
Working on a small personal homelab project where I'm setting up a dedicated gateway/firewall VM on a mini PC node (running Proxmox VE 8.2 with kernel 6.8.4-3-pve).
I have two onboard Intel i226-V 2.5GbE interfaces. One is used for vmbr0 (management), and I'm passing the second one directly via PCIe passthrough (vfio-pci) to a Debian-based gateway VM.
IOMMU is enabled and the NIC is in its own isolated IOMMU group:
IOMMU Group 14: 03:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller I226-V [8086:125c] (rev 04)
In /etc/default/grub:
GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt pcie_aspm=off"
The issue:
Whenever the VM boots or reboots, the link drops on both ports for about 3-5 seconds, and dmesg on the PVE host gets flooded with PCIe AER (Advanced Error Reporting) corrected errors:
pcieport 0000:00:1c.4: AER: Corrected error received: 0000:03:00.0
igc 0000:03:00.0: PCIe link lost, resetting device...
Once the VM is fully booted, traffic flows fine and speeds reach ~2.35 Gbps over iperf3, but the momentary link flap drops my host management connection for a few seconds every time.
Has anyone dealt with this specific i226 PCIe reset issue during VFIO handover? Should I try pci=noaer or is there a specific kernel module parameter for igc or ASPM in bios that I should tweak?
Any pointers appreciated!

 

[steve999]

Hi Ali-dev,

That corrected-error burst plus a 3-5 second link flap on both ports is a very recognizable i226-V behaviour on consumer mini PC boards. A few things worth trying, in order:

1. Don't jump to pci=noaer yet. Corrected AER errors are informational, and hiding them takes away your only diagnostic signal. Keep them visible until you have a stable setup.

2. Check whether both NICs share the same root port. You said the management connection also drops, which suggests the reset is felt higher up the PCIe hierarchy - your AER line points at 0000:00:1c.4, the root port itself, not just the NIC. Run lspci -t and see if 03:00.0 and your second i226-V sit under the same root port. If they do, a link reset during VFIO handover can briefly take the whole downstream bus with it.

3. BIOS-level ASPM: you already have pcie_aspm=off on the kernel command line, but many mini PC firmwares enable ASPM at the firmware level before the kernel sees the device. Disable PCIe ASPM L1 in the BIOS too if the option exists.

4. Check the mini PC vendor for a BIOS update. The i225-V / i226-V line has a documented history of NVM/firmware issues that vendors fixed in later BIOS releases, and flap-on-reset is one of the reported symptoms.

5. If the goal is just a gateway VM, consider skipping passthrough entirely. A dedicated bridge on the second NIC with a virtio NIC for the VM avoids the VFIO reset completely, and on 2.5GbE a virtio bridge with multiqueue enabled usually gets close to line rate. You lose raw packet access, which matters for some firewall setups, but for plain routing and NAT it is the calmer option.

For what it is worth, I have been benchmarking a dual-i226-V mini PC and published the raw measurement data on GitHub (CC BY, iperf3 runs and WOL tests): https://github.com/sohasteve-pixel/eqi12-measurement-data - the close-to-line-rate figure above is from that: 890.75 / 902.57 Mbps bidirectional over 4 GiB runs on the bridged port.

If you keep passthrough, post what lspci -t shows - the shared root port question is the one I would bet on.