Goal

• Avoid excessive VLAN configuration in default driver setup to reduce CPU overhead and prevent fallback to inefficient RX modes on the device.

Current State

• When the driver negotiates the VLAN feature and the user does not explicitly configure it ("Priority and VLAN tagging" = All by default), the Windows NetKVM driver sends 4095 VLAN ADD requests during initialization.

This leads to two spec-described issues:

“…it can use a hash filter or silently switch to allmulti or promiscuous mode if it is given too many addresses.”
— Virtio Spec v1.2-cs01, Section 5.1.3.2

"Similar to the MAC address based filtering, the VLAN filtering is also best-effort: unwanted packets could still arrive.”
— Virtio Spec v1.2-cs01, Section 5.1.3.3

Refer: https://docs.oasis-open.org/virtio/virtio/v1.3/csd01/virtio-v1.3-csd01.html#fn12x5-bk

As a result, the device may stop filtering properly, and the OS ends up handling unwanted packets, increasing CPU load. 

This behavior is functionally equivalent to not negotiating the VLAN feature at all, and differs from the Linux driver, which only configures VLANs when explicitly requested.

Recommendation

• Do not send VLAN ADD requests unless the user explicitly configures VLANs.
• Align behavior with Linux driver.
• Reconfirm MS certification requirements, but avoid inefficient default behavior.

Refer: https://github.com/virtio-win/kvm-guest-drivers-windows/issues/1392