[Pedro Henrique Penna (ppenna)]

Summary

Guest-initiated connected UDP to a host-loopback service timed out over IPv4 and IPv6 (#560). OpenVMM translated the guest's datagrams to the gateway onto host loopback, but answered them from the virtual addresses at which it presents other host peers, 10.0.0.254 and fd00::a00:ff for 10.0.0.2/24, instead of the gateway that the guest addressed, 10.0.0.1 and fd00::a00:1. Unconnected sockets accepted those replies; connected sockets drop datagrams from any other peer, so they timed out. The issue was reported on Windows/WHP, and it reproduces identically on Linux/KVM and Linux/MSHV.

• pin consomme: answer guest UDP to host loopback from the gateway nanvix/openvmm#137: replies on a guest UDP flow come from the address and port that the guest addressed, while host peers that the guest did not address, such as the host clients of published listeners, keep their virtual addresses; its second commit stops the VM's devices before OpenVMM tears down the partition and guest memory, which fixes the root cause of the intermittent ttrpc::test_ttrpc_interface abort on Linux/MSHV (OpenVMM: intermittent abort while stopping the VM in MSHV test_ttrpc_interface vmm-test #393) that failed this pull request's first CI run
• extend the host-loopback-policy microVM scenario with connected UDP exchanges through the gateway to host services on IPv4 and IPv6 loopback
• describe the source of these replies in doc/run.md and doc/design/3.5-network.md, and index the pin in the roadmap

Fixes #560. Part of #393.

OpenVMM dependency

• Source PR: consomme: answer guest UDP to host loopback from the gateway nanvix/openvmm#137 (draft), two SSH-signed commits directly on OpenVMM main at c6d97c529986c0b3b1bf1fd7f00406654cdeee67, the revision that dev pins: eae7da6f3 (consomme UDP replies) and 5ab8a8462 (device stop before VM teardown)
• Pinned revision: 5ab8a84621524f1777b2cb5e65a70dab42c8b453, the PR head. Merging the PR by fast-forwarding OpenVMM main, as consomme: present IPv6 host peers inside the static subnet nanvix/openvmm#135 was, keeps this pin on main
• Relationship: a new revision, not a replacement, so no tree or patch equivalence applies. The roadmap index records positions 319 and 320

Changes

• openvmm: c6d97c52 → 5ab8a846
• host-loopback-policy: the allow phase starts UDP echo services on host 127.0.0.1 and ::1, admits only the guest's datagrams to them with an IPv4 and an IPv6 egress rule under its egress default of deny, and requires the guest's nc -u, whose socket is connected, to receive each reply through the gateway (failure codes 84 and 85)
• scripts/test_microvm_tests.py: the allow script fails with 84 or 85 when either reply is missing, the echo service answers every request and rejects unexpected ones, and the rendered script leaves no placeholder
• documentation: doc/run.md, doc/design/3.5-network.md, and the roadmap index

The #393 abort in the first CI run

The first CI run on this pull request, 38945387812, failed only OpenVMM vmm-tests / Linux / MSHV: ttrpc::test_ttrpc_interface got channel closed from TeardownVm because OpenVMM aborted while it stopped the VM worker after a guest power-off, the signature of #393. The runner kept the core dump (SIGABRT). Symbolized against a build of the same source and toolchain, it shows a SIGSEGV on a netvsp queue thread in IncomingRing::verify_interrupts_unmasked, which read its vmbus ring's control page, through locked pages, from guest memory that teardown had already unmapped; trycopy's signal handler turned it into an abort without a message. LoadedVm::run tore down the partition and guest memory without stopping the device state units, and nanvix/openvmm#137's second commit stops them first, as the restart path already does.

On bare-metal Linux/MSHV, the abort did not reproduce in 200 runs without the fix, as #393 predicted, but a temporary delay on the netvsp queue thread at the point where the CI runner's thread stalled reproduces it, with the same faulting frame. With the fix, that reproduction passes 3/3, ttrpc::test_ttrpc_interface passes 200/200 in 8 concurrent loops, and 32/32 of the ttrpc, Linux direct-boot, and x86_64_exclusive VMM tests pass. The fix's OpenVMM gates are listed in nanvix/openvmm#137.

Validation

On bare-metal hosts, with an Alpine guest on 10.0.0.2/24 and --host-loopback allow, and NVX 36fc8aed with this change, before it moved onto the current dev, whose new commits change only CI kernel-cache keys, doc/usage.md, and performance baselines. Baseline: the released v0.1.0-dev.36fc8aedcb39 OpenVMM (c6d97c52). Fixed: OpenVMM built from nanvix/openvmm#137 before its test-only hop-limit refactor, so with the same production code.

Host	Backend	#560 probe, baseline → fixed	host-loopback-policy, baseline → fixed	Other network scenarios, fixed
prometheus32	Linux/KVM	2 replies from the wrong address and 2 timeouts → 4 replies from the gateway	fails (84) → passes	pass
prometheus30	Linux/MSHV	2 replies from the wrong address and 2 timeouts → 4 replies from the gateway	fails (84) → passes	pass
prometheus28	Windows/WHP	2 replies from the wrong address and 2 timeouts → 4 replies from the gateway	fails (84) → passes	pass

The probe mirrors the issue's: an unconnected and then a connected UDP socket per family. With the baseline, the unconnected replies came from 10.0.0.254 and fd00::a00:ff, and the connected sockets timed out. The other network scenarios are virtio-net, directional-network-policy, private-network-ingress, ipv6-egress-policy, l3-l4-egress-policy, l3-l4-egress-protocols, l3-l4-egress-port-ranges, network-snapshot, and endpoint-policy-snapshot.

On 6bb5fe23, rebased onto the current dev (11c7a0f4, whose new commits change guest-build cache inputs and performance baselines), on Windows:

• python scripts\nvx.py verify
• ruff check and ruff format --check for scripts and .github/specula; pyright for Linux and Windows: 0 errors
• the validate-nvx unit tests: 1181 tests OK (117 skipped on Windows)
• python scripts/check_markdown_links.py

The OpenVMM revision's own gates are listed in nanvix/openvmm#137.

Not run: the ACI Edge Sandboxes end-to-end suite, through whose library backend the issue was reported; this PR changes neither aci_edge_sandboxes nor nvx-rs.

Exact NVX head: 6bb5fe2362058fae38f6bb43d2d29733ad2cdc3a
Exact OpenVMM head: 5ab8a84621524f1777b2cb5e65a70dab42c8b453

[Copilot]

🔵 Needs a closer look

A publication-port collision remains unresolved, and exact-head validation of the networking dependency is not established.

1 open finding

• Reject echo ports overlapping selected publication ports · New

What changed in this PR

Updates the OpenVMM integration to preserve gateway source addresses for host-loopback UDP replies, addressing connected-socket timeouts in #560.

Changes:

• Pins the OpenVMM fix.
• Adds IPv4 and IPv6 connected-UDP regression coverage.
• Documents reply addressing and records the dependency revision.

File	Description
scripts/​test_microvm_tests.py	Tests echo services and missing-reply failures.
scripts/​nvx_tools/​microvm_tests.py	Adds host UDP echo services and egress rules.
scripts/​nvx_tools/​microvm_test_scripts/​host-loopback-policy.sh.in	Checks connected UDP replies through both gateways.
doc/​run.md	Explains gateway-sourced replies.
doc/​openvmm-upstream-roadmap.md	Records the updated OpenVMM revision.
doc/​design/​3.5-network.md	Clarifies reply and host-peer addressing.

🧠 Review effort: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

🔵 Needs a closer look

The draft networking dependency and missing integration CI validation warrant final human review.

0 open findings

1 resolved since last review

• Reject echo ports overlapping selected publication ports

🧠 Review effort: Balanced

[Copilot]

🔵 Needs a closer look

The additional VM-wide teardown change warrants human review, with exact-head cross-platform runtime validation still unverified.

0 open findings

🧠 Review effort: Balanced