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
