> Subject: [EXTERNAL] Re: [RFC] net/vdev_netvsc: check for NetVSC device before > auto-probe > > On Sun, 22 Feb 2026 12:48:13 -0800 > Stephen Hemminger <[email protected]> wrote: > > > The custom scan callback unconditionally injects net_vdev_netvsc into > > the devargs list on any Hyper-V system without checking whether NetVSC > > interfaces actually exist. This causes the eal_flags_vdev_opt_autotest > > to fail on GitHub Actions runners (which are Azure/Hyper-V VMs) > > because the vdev bus probes both the test's intended vdev and the > > injected net_vdev_netvsc, which fails to initialize on systems without > > NetVSC interfaces. > > > > Check whether at least one NetVSC interface exists (via the sysfs > > class_id check the driver already uses) before adding devargs in the > > scan callback. > > > > Fixes: 56252de779a6 ("net/vdev_netvsc: add automatic probing") > > Cc: [email protected] > > > > Signed-off-by: Stephen Hemminger <[email protected]> > > --- > > This is not sufficient to fix the github problem. > The container still has an interface, and cloud-init has given it an address. > But it > has no route to outside (in container). > > It looks like the whole automagic vdev_netvsc model is so brittle it should be > removed.
Can we set up a default config of not auto probing net_vdev_netvsc? Or some kind of flags that says a driver should not be auto loaded. Most customers are running "vdev" arguments to load them in their DPDK application.
