[windows/whpx] published ports stall while guest waits for TSI_LISTEN

[ZhiXiao-Lin]

Environment

• Host: Windows 11 Pro, build 26200, x86_64
• Hypervisor: WHPX
• Guest image: Alpine 3.20
• Network mode: default TSI
• A3S Box source: v3.0.5 baseline plus the Windows/WHPX enablement work

Reproduction

a3s-box run -d --name whpx-port-repro -p 58363:8080 alpine:3.20 -- sh -c "while true; do printf 'HTTP/1.1 200 OK\r\nContent-Length: 8\r\nConnection: close\r\n\r\nPORT_OK\n' | nc -l -p 8080; done"
a3s-box port whpx-port-repro

The host-side forwarding worker listens on 0.0.0.0:58363, but a TCP request to that port times out.

Narrowing

A libkrun Windows vsock control trace shows:

1. guest-init connects to the host control endpoint on vsock port 4093;
2. the host forwarding worker sends FRAME_OPEN;
3. the guest consumes the frame (its credit count advances);
4. no FRAME_OPEN_ACK returns.

The guest kernel's TSI socket hijack sends TSI_PROXY_CREATE followed by a TSI_LISTEN datagram (destination port 1029) before it calls the native guest socket's listen(). The active Windows backend in vsock_windows.rs ignores the TSI flags and treats that datagram as ordinary UDP. Because no tsi_listen_rsp arrives, the guest blocks indefinitely in listen() and the port bridge's loopback connect cannot finish.

Expected behavior

Published TCP ports should reach a guest service under WHPX. If the Windows backend does not provide a host-side TSI listener, it must explicitly reject TSI_LISTEN with one of the Linux errors that trigger guest-kernel fallback (for example -EPERM), allowing the already bound native guest socket to listen for the named-pipe bridge.

Regression coverage

• Verify the exact DGRAM response header and Linux errno for TSI_LISTEN.
• Run the real ignored published-port HTTP smoke test under WHPX.
• Make at least two sequential requests to exercise connection cleanup and reuse.

This is distinct from #23, which was a macOS post-handshake data-forwarding failure.

[ZhiXiao-Lin]

Fix and validation are pushed:

• libkrun: 9d82ae5eefcc2a51a780f9ece3103ce7fefda171 on fix/windows-whpx-runtime-20260720
• Box/guest bridge: 22947a1e13d36a8d2e71ea816a77026de65af23e on fix/windows-whpx-validation-20260720

The Windows vsock backend now returns Linux -EPERM for unsupported TSI_LISTEN, allowing the guest kernel to use the native listener consumed by the named-pipe bridge. Guest-init also drains coalesced control frames instead of leaving a second open request buffered.

Validation:

• new exact-header/errno libkrun unit tests passed
• libkrun devices: 67/67 tests passed
• libkrun VMM: 45 passed / 11 ignored; 9 runnable ignored WHPX tests passed
• real WHPX published-port smoke passed with two sequential HTTP connections to the same mapping
• repeated back-to-back published-port runs also passed

Keeping this issue open until the branches are merged.

[ZhiXiao-Lin]

Current main-targeting integration is PR #134, now at a6ed30886eb6ae8d2050a3ea0c20f548d40f9b27, including the currently pinned libkrun fix.

I reran the issue's BusyBox nc -l -p 8080 reproduction on the current full WHPX stack. Two independent box runs each served two sequential HTTP requests through the same published-port mapping, with PORT_OK returned on every request. This covers listener fallback plus connection cleanup/reuse.

Keeping this issue open until #134 is merged.