WSL2 on AMD: Connected UDP socket loopback delivery silently drops packets after initial transmission (kvm_amd vs kvm_intel)

[ZoeRen-pp]

Windows Version

10.0.26200.8246

WSL Version

2.7.1.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

6.6.114.1-1

Distro Version

Ubuntu 24.04.4 LTS

Other Software

QEMU 8.2.2 (Debian 1:8.2.2+ds-0ubuntu1.16)
GNS3 server 2.2.58.1
ubridge 0.9.19

Repro Steps

Hardware: AMD Ryzen CPU with Hyper-V nested virtualization enabled
(same configuration works good on Intel CPU)

1. Install GNS3 server in WSL2 Ubuntu 24.04
2. Create a topology with two QEMU VMs (e.g., Cisco IOSv and Huawei NE40E images)
3. Connect them via a virtual link (uses ubridge UDP tunnel internally)
4. Configure IP addresses on both ends of the link
5. Try ping between the two VMs

Internally, GNS3/QEMU uses:
qemu-system-x86_64 -enable-kvm
-netdev socket,id=net0,udp=127.0.0.1:20053,localaddr=127.0.0.1:20052
And ubridge creates a connected UDP socket on port 20053 to bridge frames.

Expected Behavior

Ping between the VMs should succeed (and does succeed on Intel CPU
machines with the same WSL kernel, QEMU, GNS3, and image versions).

Actual Behavior

Ping fails with 100% packet loss.

Diagnostic findings:

• strace shows QEMU calls sendto(fd, ..., 127.0.0.1:20053) and the
  kernel returns success (= packet length, e.g. 60).
• However, the receiving connected UDP socket on port 20053 (held by
  ubridge) only receives the initial ~10 packets sent during VM boot.
• After that, sendto() continues to return success but no packets reach
  the receiver. /proc/net/snmp shows OutDatagrams increasing but
  InDatagrams unchanged — packets are silently dropped on loopback.
• The guest OS believes packets are sent (interface tx counter increases).

Workaround: Replacing -netdev socket with -netdev tap + Linux bridge
makes networking work. This proves the issue is specifically with
connected UDP socket loopback delivery in this environment.

Reproduction tests already done that did NOT fix the issue:

• QEMU 6.2 vs 8.2.2: same behavior
• KVM enabled vs accel=tcg: same behavior
• -netdev socket vs -netdev dgram: same behavior
• e1000 vs i82559er NIC: same behavior
• kvm_amd npt=0: same behavior
• Upgrading WSL kernel from 6.6.87.2 to 6.6.114.1: same behavior
• Disabling bridge-nf-call-iptables: irrelevant
• Standard Python connected UDP socket loopback test: WORKS fine,
  so issue only manifests with QEMU's high-rate sendto pattern.

Same exact software stack on Intel CPU works perfectly. Only difference
between machines: kvm_intel vs kvm_amd module.

wsl_kvm_amd_repro.sh

Diagnostic Logs

dmesg | grep kvm output:
[ 2.733852] kvm_amd: TSC scaling supported
[ 2.733858] kvm_amd: Nested Virtualization enabled
[ 2.733859] kvm_amd: Nested Paging enabled
[ 2.733861] kvm_amd: kvm_amd: Hyper-V enlightened NPT TLB flush enabled
[ 2.733862] kvm_amd: kvm_amd: Hyper-V Direct TLB Flush enabled
[ 2.733872] kvm_amd: Virtual VMLOAD VMSAVE supported

Intel machine (working) shows instead:
kvm_intel: Using Hyper-V Enlightened VMCS

[github-actions]

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise, please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How to collect WSL logs

Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The script will output the path of the log file once done.

If this is a networking issue, please use .\collect-wsl-logs.ps1 -LogProfile networking instead, following the instructions in Collect WSL logs for networking issues

Once completed please upload the output files to this GitHub issue.

See Collect WSL logs (recommended method).

If you choose to email these logs instead of attaching them to the bug, please send them to wsl-gh-logs@microsoft.com with the GitHub issue number in the subject, and include a link to your GitHub issue comment in the message body, and reply with '/emailed-logs'.

[chemwolf6922]

Hi @ZoeRen-pp , could you please help confirm when doing the accel=tcg test. Is the kvm_amd module still loaded? This will help identify if the problem is introduced by that module. Thanks.

[ZoeRen-pp]

Confirmed - I unloaded both kvm_amd and kvm modules entirely
(verified /dev/kvm is absent and lsmod | grep kvm returns nothing)
and re-ran the reproduction with QEMU in pure TCG mode (no -enable-kvm,
no -accel kvm).

The bug still reproduces identically: only 9 packets received in 90 seconds.

System Information (TCG mode test, kvm_amd unloaded)
====================================================
Kernel:    6.6.114.1-microsoft-standard-WSL2
CPU:       AMD Ryzen 7 7840HS w/ Radeon 780M Graphics
QEMU:      QEMU emulator version 8.2.2
kvm_amd:   0 module(s) loaded
kvm:       0 module(s) loaded
/dev/kvm:  absent

Listener output:
[listener] t=  5s: 4 packets (639 bytes)
[listener] t= 10s: 8 packets (1637 bytes)
[listener] t= 15s: 9 packets (2066 bytes)
[listener] t= 20s: 9 packets (2066 bytes)
... (no further packets through t=90s) ...
[listener] FINAL: 9 packets, 2066 bytes in 90s

So the bug is NOT introduced by the kvm_amd module. It must be in the
WSL2 kernel itself, with the trigger somehow being CPU-architecture dependent
(since the same WSL2 kernel + same QEMU version works fine on Intel CPUs).

Possible avenues to investigate:

• AMD-specific code paths in the WSL2 kernel networking stack
• Differences in how Hyper-V exposes the host CPU to the WSL2 VM
• AMD-specific timer or scheduler behavior affecting socket buffer drain timing