Add passt networking backend as alternative to minislirp

[jserv]

Problem

The current minislirp implementation adds substantial copy and context-switch
overhead on every packet. passt (the VM-facing counterpart of pasta, from the
passt project) achieves significantly better TCP throughput in upstream
benchmarks by using a more efficient data path.

Note: pasta connects a host network to a network namespace and is designed
for containers. Since kbox uses LKL (VM-like architecture), the correct tool
is passt, which speaks the qemu UNIX socket protocol suitable for VM
backends.

Proposed Changes

Add a --net=passt backend:

1. Write an LKL netdev backend that speaks the qemu UNIX socket protocol
   passt expects. This requires adapting the network initialization in
   net-slirp.c or creating a new net-passt.c backend module.
2. Spawn passt as an external process, connecting to LKL via the socket
   backend.
3. Preserve minislirp as the zero-dependency fallback when passt is not
   available.

Considerations

• Runtime detection of passt binary and version requirements.
• Behavioral differences vs minislirp: port forwarding model, UDP/DNS
  handling, IPv6 support, inbound connectivity semantics.
• Process lifecycle: supervision, cleanup, signal propagation, failure
  fallback to minislirp.
• Security and isolation tradeoffs vs minislirp should be documented.
• Namespace assumptions: kbox does not create a network namespace today;
  verify whether passt requires one or can operate without it.
• Relationship to bypass4netns-style socket switching: passt improves the
  stack-mediated path, while socket switching bypasses the stack entirely
  for eligible connections. These are complementary approaches.

[marceline127]

NEW: kbox/src/net-passt.c

UNIX Domain Socket Listener: Implement a listener using socket(AF_UNIX, SOCK_STREAM, 0) to establish the communication channel with passt.

QEMU Socket Protocol: Develop the LKL netdev backend to handle the binary frame format used by passt.

Frame Boundary Handling : Parse Ethernet frames with length prefixes from the stream-oriented UNIX socket.

MODIFY: kbox/src/net.h

Define enum kbox_net_backend { NET_SLIRP, NET_PASST } and extend initialization APIs to support backend selection (via --net=passt in main.c).

MODIFY: kbox/src/main.c

Passt initialization : call kbox_passt_init() before kbox_run_supervisor() so passt is ready before the guest starts, passing --publish flags as -t/-u arguments to passt at spawn time. On failure, fall back to minislirp.

Call kbox_passt_cleanup() after kbox_run_supervisor() returns.

Auto Fallback: If kbox_passt_init() returns failure (binary not found or connection timeout), log a warning and fall back to the minislirp backend without affecting the rest of the startup flow.

Cleanup: After kbox_run_supervisor() returns, call kbox_passt_cleanup() to send SIGTERM to the passt process, wait up to 1 second for graceful exit, then SIGKILL if necessary, and remove the socket file.

MODIFY: kbox/src/net-passt.c

Zero-Copy Research: Explore MSG_ZEROCOPY on the socket send path to reduce copy overhead between the LKL virtio-net driver and the passt socket.

Verification Plan:

Throughput Benchmarking: Use iperf3 to compare TCP/UDP performance between minislirp and passt.

CPU Utilization Analysis: Use top or perf to monitor the CPU usage of the kbox and passt processes during high-load bulk transfers.

Lifecycle Validation: Confirm that passt terminates correctly when the guest process exits or when kbox is interrupted (SIGINT/SIGTERM).

Fallback Test: Simulate a missing passt binary to ensure kbox successfully falls back to minislirp without interrupting the startup flow.

Socket Path Reliability: Ensure the unlink() logic correctly handles repeated startups without "Address already in use" errors.

[jserv]

Verification Plan:
Throughput Benchmarking: Use iperf3 to compare TCP/UDP performance between minislirp and passt.
[...]

Before proceeding, you need to analyze the baseline by benchmarking to understand the networking behavior. This baseline will serve as the reference for further improvements. Include the relevant performance metrics here.

[marceline127]

Verification Plan:

Baseline Performance Analysis (minislirp):

Network Throughput & Quality (via iperf3)

• TCP Throughput
• UDP Bandwidth & Packet Loss
• Jitter (Network Quality)

Network Performance (via netperf):

• Response Time (Latency)
• Network Utilization (CPU Efficiency) during bulk transfers.
• Transaction Rate

CPU Utilization (via top or perf):

• CPU cycles per MB transferred.

Verification Mechanism

Throughput Benchmarking: Use iperf3 to compare TCP/UDP performance between minislirp and passt.

CPU Utilization Analysis: Use top or perf to monitor the CPU usage of the kbox and passt processes during high-load bulk transfers.

Lifecycle Validation: Confirm that passt terminates correctly when the guest process exits or when kbox is interrupted (SIGINT/SIGTERM).

Fallback Test: Simulate a missing passt binary to ensure kbox successfully falls back to minislirp without interrupting the startup flow.

Socket Path Reliability: Ensure the unlink() logic correctly handles repeated startups without "Address already in use" errors.

[jserv]

Verification Plan:
Baseline Performance Analysis (minislirp):
Network Throughput & Quality (via iperf3)

You must provide the measured baseline for comparison and address the expected speedup or improvements.