Re: [PULL 12/14] virtio-net: Advertise UDP tunnel GSO support by default

["Michael S. Tsirkin" <mst@redhat.com>]

On Fri, Jun 05, 2026 at 04:02:39PM +0200, Fiona Ebner wrote:
> Dear maintainers,
> 
> Am 09.11.25 um 4:10 PM schrieb Michael S. Tsirkin:
> > diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> > index 17ed0ef919..3b85560f6f 100644
> > --- a/hw/net/virtio-net.c
> > +++ b/hw/net/virtio-net.c
> > @@ -4299,19 +4299,19 @@ static const Property virtio_net_properties[] = {
> >      VIRTIO_DEFINE_PROP_FEATURE("host_tunnel", VirtIONet,
> >                                 host_features_ex,
> >                                 VIRTIO_NET_F_HOST_UDP_TUNNEL_GSO,
> > -                               false),
> > +                               true),
> it seems that the host_tunnel setting can cause issues when VXLAN
> traffic originating in a guest goes over a physical NIC which does not
> support the feature. We received several reports about the issue
> [0][1][2][3] and were able to reproduce it. Turning off the
> 'host_tunnel' property in the commandline for the VirtIO net device
> makes TCP traffic work. The network configuration from our reproducer
> setup is as follows:
> 
>       guest A (iperf3 -c)                   guest B (iperf3 -s)
>   vxlan using vNIC as underlay         vxlan using vNIC as underlay
> virtualized NIC exposed to guest     virtualized NIC exposed to guest
>     ---guest boundary---                  ---guest boundary---
>  tap device connected to bridge       tap device connected to bridge
> bridge with physical NIC as port     bridge with physical NIC as port
>         physical NIC   <---host boundary--->   physical NIC
> 
> Bridge configuration:
> iface vmbr0 inet static
> 	address 10.48.0.109/20
> 	gateway 10.48.0.1
> 	bridge-ports nic3
> 	bridge-stp off
> 	bridge-fd 0
> 	bridge-vlan-aware yes
> 	bridge-vids 2-4094
> 
> VXLAN created with:
> ip link add vxlan0 type vxlan id 100 remote X dstport 4789 dev eth1
> where eth1 is the virtualized NIC exposed to the guest
> 
> The physical NIC does not have the feature:
> Ethernet controller [0200]: Broadcom Inc. and subsidiaries NetXtreme
> BCM5719 Gigabit Ethernet PCIe [14e4:1657] (rev 01)
> tx-udp_tnl-segmentation: off [fixed]
> tx-udp_tnl-csum-segmentation: off [fixed]
> 
> Using a physical NIC which does have the feature works:
> Ethernet controller [0200]: Broadcom Inc. and subsidiaries BCM57504
> NetXtreme-E 10Gb/25Gb/40Gb/50Gb/100Gb Ethernet [14e4:1751] (rev 11)
> tx-udp_tnl-segmentation: on
> tx-udp_tnl-csum-segmentation: on
> 
> Host kernel:
> Proxmox VE with 7.0.2-6-pve
> 
> Guest kernel:
> Apline with 6.18.34-0-lts
> 
> QEMU commandline for the vNIC:
> > -netdev 'type=tap,id=net2,ifname=tap103i2,script=/usr/libexec/qemu-server/pve-bridge,downscript=/usr/libexec/qemu-server/pve-bridgedown,vhost=on' \
> > -device 'virtio-net-pci,mac=BC:24:11:78:C3:3B,netdev=net2,bus=pci.0,addr=0x14,id=net2,rx_queue_size=1024,tx_queue_size=256,host_mtu=1500' \
> 
> We can see that QEMU sets the features for the tap interface via ioctl()
> and the host kernel allows it:
> tx-udp_tnl-segmentation: on
> tx-udp_tnl-csum-segmentation: on
> 
> As far as we understand, in the problematic scenario, nothing is ever
> filling in the checksums for the inner TCP packets, meaning the outer
> UDP checksum ends up being wrong on the target side. Is the host kernel
> responsible for doing that before passing the packet to the physical NIC
> (without the feature)? Or who would be?
> 
> Turning off host_tunnel_csum without turning off host_tunnel does not help.
> 
> Interestingly, turning off the features for the working physical NIC
> does not make it break:
> tx-udp_tnl-segmentation: off
> tx-udp_tnl-csum-segmentation: off
> Could it be that the NIC just always fills in the inner TCP checksums
> regardless of that setting?
> 
> On the other hand, running
> localhost:~# ethtool -K eth2 tx-checksum-ip-generic off
> Actual changes:
> tx-checksum-ip-generic: off
> tx-tcp-segmentation: off [not requested]
> tx-tcp-ecn-segmentation: off [not requested]
> tx-tcp6-segmentation: off [not requested]
> tx-udp-segmentation: off [not requested]
> inside the guests makes it work for the physical NIC without the
> tx-udp_tnl* features.
> 
> I wanted to ask if this configuration is expected to be unsupported and
> if the management is expected to turn off the feature on the commandline
> if the traffic might go over a physical NIC without the feature. Or if
> this could be a kernel or NIC bug that should be investigated further?
> In the former case, should the option really be turned on by default
> with new machine versions?
> 
> I'll be happy to test and capture/provide additional information. Let me
> know what would be interesting.
> 
> Thanks to Stefan and Gabriel for looking into the issue with me!
> 
> Best Regards,
> Fiona
> 
> [0]: https://bugzilla.proxmox.com/show_bug.cgi?id=7627
> [1]: https://forum.proxmox.com/threads/183494/post-855144
> [2]: https://forum.proxmox.com/threads/182328/post-854627
> [3]: https://forum.proxmox.com/threads/183963/post-855737


looks like a kernel or nic bug to me.


-- 
MST