Module vm_proto 

Host-side vsock client for communicating with the in-VM guest agent.

Reaching the guest

Every protocol function here dials the guest through the driver port’s Vsock capability: [connect_to_port] asks it for a connection to a guest port and retries — only — while the guest has no listener there yet, then turns the VsockConn it hands back into the tokio stream the frame codec speaks over. Where that connection comes from is the driver’s business.

The capability comes off the running VM’s handle (HandleVsock keeps that handle alive for the callers that hold the vsock across awaits). In the other direction — the guest agent’s readiness dial-out — the boot pre-listens through the driver’s VsockListen capability and [wait_ready] takes the one connection.

Frame format

The opcodes, payload layouts, and the JSON DTOs (StartCommand, WaitPortReq) are the exec-channel vocabulary in arcbox_vm_proto::exec, re-exported here. This module holds the connection and framing layer; the protocols each have a file of their own — exec (run, exec), clock (sync_clock), net (reconfigure_network), wait_port (wait_for_port), files — and client is what maps them onto the GuestAgent port. The vocabulary they speak belongs to the port, not here.

Structs

StartCommand

Parameters forwarded to the guest agent as the session-start frame.

VmProtoAgent

The guest agent of one running VM, reached over its vsock device.

VmProtoAgentFactory

Builds VmProtoAgents, and knows how their guests announce readiness.

WaitPortReq

MSG_WAIT_PORT payload.

Constants

AGENT_PORT

Guest-side vsock port the agent listens on (exec channel).

MSG_WAIT_PORT

Wait until the guest’s TCP listen table has a listener on a port. Payload: JSON WaitPortReq; answered with MSG_EXIT carrying 0 (listening) or 1 (deadline elapsed).

READY_PORT

Host-side port the guest agent dials once it is fully serving.