Research-Stack/6-Documentation/docs/specs/virtio_net_compute_fabric_spec.md

Specification: Virtio-Net DMA Compute Fabric & Packet-as-Computation (PIST)

This document specifies the architecture, data structures, and mathematical mapping for treating virtualized Ethernet networking hardware as a high-throughput, zero-copy, packetized DMA computation backplane.

---

1. Core Paradigm Shift

Traditional systems treat networking as a transmission layer for serialized compute payloads (e.g. JSON over TCP sockets):

\text{Memory} \xrightarrow{\text{Serialize}} \text{Payload} \xrightarrow{\text{OSI Stack}} \text{Network} \xrightarrow{\text{OSI Reassembly}} \text{Deserialize} \xrightarrow{\text{CPU Compute}}

This specification defines a dataflow model where:

1. Ethernet is Math: Packet headers, segmentation flags, and hardware queue indexes are structural dimensions of a computational state vector (\Gamma).
2. Computation is Trajectory: A program execution is represented as the trajectory of structured packet witnesses traversing a sequence of admissible transition operators (T_i) mapped directly to ring descriptors:

\Gamma_{k+1} = T_i(\Gamma_k)

3. Offloads are Algebra: Hardwired NIC/switch ASICs (CRC32, Toeplitz hashing, TCP Segmentation) are exploited as hardware-accelerated linear algebraic operators.

       GUEST MEMORY                       RING TRANSPORT                    TRANSFORM ENGINE
  ┌──────────────────────┐           ┌───────────────────────┐          ┌───────────────────────┐
  │ [PistPacket Header]  │           │   virtio-net TX Ring  │          │   Host QEMU/vhost     │
  │   - computation_id   │ ────────▶ │  (lock-free producer) │ ───────▶ │   (Matrix Transform)  │
  │   - coordinate_path  │           └───────────────────────┘          └───────────┬───────────┘
  │   - payload (Matrix) │                                                          │
  └──────────────────────┘                                                          ▼
  ┌──────────────────────┐           ┌───────────────────────┐          ┌───────────────────────┐
  │  Verified Result     │ ◀──────── │   virtio-net RX Ring  │ ◀────────│  NIC Offload Engines  │
  │  (CRC Witness Valid) │           │  (lock-free consumer) │          │  (Toeplitz RSS / CRC) │
  └──────────────────────┘           └───────────────────────┘          └───────────────────────┘

---

2. Packet Structure (PistPacket)

Compute frames traverse the ring buffer using standard Ethernet packaging to maintain driver compatibility, but their payload is structured as an immutable computation state capsule:

struct __attribute__((packed)) pist_packet {
    /* 14-byte standard Ethernet Frame Header */
    uint8_t  dest_mac[6];       /* Target transform operator ID (T_i) */
    uint8_t  src_mac[6];        /* Provenance chain head / origin ID */
    uint16_t ethertype;         /* PIST-over-Ethernet identifier (0x88B5 or custom) */

    /* PIST Computation Header */
    uint64_t computation_id;    /* Unique ID of the dataflow graph instance */
    uint64_t step_index;        /* Sequential transition step count */
    uint32_t coordinate_path;   /* QuadTree/coordinate addressing path for spatial layout */
    uint32_t witness_hash;      /* Galois Field (CRC32) witness signature */
    uint32_t payload_len;       /* Length of active fixed-point matrix payload */

    /* Data Payload */
    uint8_t  payload[];         /* Saturating Q16_16 fixed-point data vector */
};

Header Semantics:

• dest_mac: Used by switch ASICs to route the packet to the appropriate hardware accelerator (GPU, FPGA, or SmartNIC queue) executing T_i.
• coordinate_path: Encodes tree coordinates (e.g. 00 for A_{11}, 01 for A_{12}) enabling structured spatial partitioning.
• witness_hash: Pre-calculated transition polynomial signature. An operator only executes if the incoming hash matches the mathematical precondition for that step.

---

3. Exploit Mapping: Network ASIC to Linear Algebra

This design maps linear algebra workloads onto standard hardware-assisted network offloads:

Network ASIC Feature	Network Purpose	Algebraic Representation	Computational Exploit
RSS (Receive Side Scaling)	CPU Queue Load Balancing	Toeplitz Matrix Multiplication: R = T \cdot V \pmod 2	Parallel 1D Convolutions, linear feedback transforms, and hardware-level task routing.
TSO (TCP Segmentation)	Packet Fragmentation	Tensor Slicing: M_{large} \to \bigcup_{j} m_{j}	Automatic recursive tiling of large matrices into QuadTree quadrant blocks.
LRO/MRG_RXBUF (Receive Coalescing)	Buffer Aggregation	Block Aggregation (Matrix Sum/Concat)	Tiled matrix block consolidation and queue synchronization.
FCS (Frame Check Sequence)	Frame Bit Error Detection	Galois Field Polynomial division over GF(2)[x]	Instantaneous graph connection validation and mathematical transition proofs.

Mathematical Target: The Toeplitz Transform (RSS)

The Toeplitz engine on the NIC multiplies the header vector V by a Toeplitz matrix T (defined by the RSS key K programmed into the card) over GF(2):

R_i = \sum_{j} T_{i-j} \cdot V_j \pmod 2

This operation executes at full line rate (100 Gbps+) on commodity switches, effectively yielding billions of binary matrix-vector convolutions per second without CPU overhead.

---

4. Formal Grounding: Lean Tree Solvers

Computational routing and spatial tiling correctness are verified using the formal tree representations in TreeDIATKruskal.lean.

A block-matrix multiplication:

\begin{pmatrix} A_{11} & A_{12} \\ A_{21} & A_{22} \end{pmatrix} \cdot \begin{pmatrix} B_{11} & B_{12} \\ B_{21} & B_{22} \end{pmatrix}

is formalized as a recursive traversal of a TreeNode QuadTree.

-- From Semantics/Semantics/TreeDIATKruskal.lean
inductive TreeEmbeds : TreeNode → TreeNode → Prop
  | refl (t : TreeNode) : TreeEmbeds t t
  | intoLeft {s : TreeNode} {label : Nat} {l r : TreeNode} (h : TreeEmbeds s l) : TreeEmbeds s (.node label l r)
  | intoRight {s : TreeNode} {label : Nat} {l r : TreeNode} (h : TreeEmbeds s r) : TreeEmbeds s (.node label l r)
  | node {label : Nat} {l₁ r₁ l₂ r₂ : TreeNode} (hL : TreeEmbeds l₁ l₂) (hR : TreeEmbeds r₁ r₂) : TreeEmbeds (.node label l₁ r₁) (.node label l₂ r₂)

Verification Contracts:

1. Structural Admissibility: The TreeEmbeds earlier later relation proves that the sub-matrix workload earlier is homeomorphically compatible with the allocated physical cluster topology later.
2. Termination Guarantee: treeEmbeds_nodeCount_le proves that sub-tasks strictly decrease in node size as computational flow descends the tree, guaranteeing routing termination.
3. Round-Free Denominator Scheduling: Scheduling density priority is sorted via scoreLENat cross-multiplication, avoiding rounding drift in fixed-point registers:

   leaf_A \cdot (depth_B \cdot labels_B + 1) \le leaf_B \cdot (depth_A \cdot labels_A + 1)

---

5. Execution Pipeline (Zero-Copy Lifecycle)

[Guest App] Program descriptors in guest memory.
    │
    ▼
[Virtio TX Ring] Kick virtqueue; raw descriptors enqueued. (Zero-copy)
    │
    ▼
[QEMU Backend] Pop descriptor; detect PIST EtherType.
    │
    ├─► Match 'coordinate_path' to QuadTree structure.
    ├─► Apply matrix quadrant transform T_i.
    ▼
[NIC Offload Block] (Optional routing through hardware switch)
    ├─► TSO segments large payload matrices into sub-blocks.
    ├─► RSS Toeplitz hashes coordinates to assign target queues.
    ├─► CRC32 calculates Galois Field witness signature.
    ▼
[Virtio RX Ring] Push transformed results back into guest memory.
    │
    ▼
[Guest App / NAPI Hook] Intercept return frame; verify CRC witness; update state.

This pipeline allows matrix multiplication, grid subdivision, and node reduction to execute directly on the network plane, bypassing standard socket reassembly, OS scheduler bottlenecks, and user-space serialization layers.

---

6. Unified Transport Envelope & Multi-Hop Re-Encapsulation

For multi-transport and heterogeneous physical layouts, compute payloads are wrapped in a unified transmission envelope directly mirroring the formal specifications in MeshRouting.lean.

6.1 Wire Frame Layout

A serialized PIST packet is structured as a contiguous byte sequence containing:

1. Transport Selector Tag (1 byte):

   • 0x00: USB DMA
   • 0x01: WiFi
   • 0x02: Bluetooth
   • 0x03: Serial (UART)

2. Transport-Specific Header (Variable, H_{transport}):

   • USB DMA (H_{transport} = 4 bytes): session ID.
   • WiFi (H_{transport} = 4 bytes): source port + destination port.
   • Bluetooth (H_{transport} = 2 bytes): channel ID (cid).
   • Serial (H_{transport} = 1 byte): transmission mode.

3. RDMA Net Header (41 bytes): A packed representation of memory addresses and keys:

   struct __attribute__((packed)) rdma_net_header {
       uint8_t  version;       /* Protocol version (always 1) */
       uint8_t  transport;     /* Transport enum: 0=USB, 1=WiFi, 2=BT, 3=Serial */
       uint8_t  wr_type;       /* Work Request type: 0=SEND, 1=WRITE, 2=READ */
       uint32_t qpn;           /* Queue Pair Number */
       uint32_t lkey;          /* Local Memory Key */
       uint32_t rkey;          /* Remote Memory Key */
       uint64_t local_addr;    /* Local source memory address pointer */
       uint64_t remote_addr;   /* Remote target memory address pointer */
       uint32_t length;        /* Total payload byte length */
       uint32_t seq;           /* Sequence number for verification */
       uint16_t flags;         /* Operational flags */
   };
   

4. Fragment Header (4 bytes, Optional): Appended if the payload size exceeds the transport's MTU:

   • fragSeq (2 bytes, little-endian): Sequence index of the current fragment.
   • totalFrags (1 byte): Total fragment count in the payload block.
   • flags (1 byte): State bits (bit 0 = START, bit 1 = END, bit 2 = RETRANS).

5. Compute Payload: Raw Q_{16.16} fixed-point data stream.

6.2 Fragmentation Bounds

MTU constraints require fragmenting the payload when total envelope size exceeds the physical layer's threshold:

\text{Max Payload Size} = \text{MTU} - (1 + H_{transport} + 41 + 4)

MTUs are defined statically per physical substrate:

• USB DMA: 65,536 bytes
• WiFi: 1,472 bytes
• Bluetooth: 251 bytes
• Serial: 8 bytes

6.3 Multi-Hop Re-Encapsulation Flow

At intermediate gateway nodes, the packet undergoes reEncapForNextHop to cross physical boundaries:

1. The incoming driver strips the 1-byte transport tag and H_{transport} bytes.
2. The core router reads the rdma_net_header (41 bytes) to extract routing contexts, addresses, and sequence numbers.
3. The outbound driver assigns the new 1-byte transport tag corresponding to the target path.
4. The router prefixes a zeroed transport-specific header of size H_{transport} for the target physical layer.
5. The packet is dispatched over the target interface, maintaining zero-copy data boundaries for the underlying payload.

---

7. 16D Goxel-to-Frame Compression Projection (VCN Substrate)

Large multi-dimensional systems, such as 16-dimensional shape potential fields, utilize physical video encoding hardware (AMD VCN) as high-throughput image compressors.

7.1 Coordinate Projection Hierarchy

A 16-dimensional shape potential state vector (Goxel16D) is projected down to 3D voxels (Voxel3D), which are then mapped to 2D coordinates (u, v) for video frame processing.

Step 1: 16D Goxel to 3D Voxel

Given a 16-dimensional coordinate vector (d_0, \dots, d_{15}) in Q_{16.16} space, the spatial position (x, y, z) and attributes (intensity, torsion, coherence) are derived via:

x = \min\left(1023, \left\lfloor\frac{d_0.val}{64}\right\rfloor\right) - 512

y = \min\left(1023, \left\lfloor\frac{d_1.val}{64}\right\rfloor\right) - 512

z = \min\left(1023, \left\lfloor\frac{d_2.val}{64}\right\rfloor\right) - 512

\text{intensity} = d_3 + d_4 + d_5

\text{torsion} = d_6 + d_7

\text{coherence} = d_8 + d_9

Step 2: 3D Voxel to 2D Video Frame

The orthographic projection projects the voxel (x, y, z) onto the 2D pixel coordinates (u, v) in the frame:

u = \min(\text{width} - 1, \max(0, x + 512))

v = \min(\text{height} - 1, \max(0, y + 512))

\text{depth} = \text{intensity}

7.2 VCN Acceleration & Frame Formats

The 2D projection data is serialized into video frames for hardware-accelerated processing:

• YUV420 Frame Format: The depth/intensity values are written to the luminance channel (Y). Chroma subsampling (U and V) is used to optimize memory, yielding a frame size of:

  \text{Size}_{YUV420} = \text{width} \times \text{height} \times \frac{3}{2} \text{ bytes}

• RGB24 Frame Format: Each pixel maps to three identical R, G, B bytes representing greyscale depth:

  \text{Size}_{RGB24} = \text{width} \times \text{height} \times 3 \text{ bytes}

Standard computation frame resolutions range dynamically from 240p (320 \times 240) up to 16K (15,360 \times 8,640) at frame rates up to 240\text{ fps}.

Hardware encoding parameters use H.264 or HEVC codecs with high-compression quantization parameters (qpMin = 2, qpMax = 4) and transformSkip = true to prevent compression artifacts on numerical data grids.

7.3 Formal Soundness Theorems

The mathematical properties of the VCN compression pipeline are formally verified:

1. Energy Conservation (goxelFieldEnergyConservation): Let E_{field} be the field energy and C_{ratio} be the compression ratio. Saturated subtraction in Q_{16.16} guarantees:

   (E_{field} - C_{ratio}).val \le 32768 \quad (\text{representing } 0.5 \text{ in } Q_{16.16})

   provided that E_{field}.val \ge C_{ratio}.val and the energy difference is bounded within 0.5 units.
2. Topology Preservation (goxelTopologyPreserved): The mapping preserves neighborhood adjacency relations on the grid, subject to the capacity condition:

   \text{Field size } |Goxels| \le \text{width} \times \text{height}

7.4 Lossless Density Optimization Vectors

To maximize the raw throughput of the VCN compression pipeline under mathematical losslessness (qp = 0 / transquant_bypass = 1), the mapping layer implements four density optimization vectors:

7.4.1 Full-Range Pixel Mapping (Clamping Loss Elimination)

Standard YUV profiles restrict values to limited ranges (16 \le Y \le 235, 16 \le U, V \le 240) to prevent out-of-bounds analog video signals. Under a pure computation backplane, this limited range clamps and corrupts binary/fixed-point values.

• Protocol Requirement: The transport and encoder must enforce Full-Range YUV (JPEG range, e.g., yuvj420p, yuvj444p or via FFmpeg's -color_range pc option). This enables using the full [0, 255] range for every byte, guaranteeing that all bit patterns are preserved without numerical clipping.

7.4.2 Independent Y-Plane Packing (YUV420)

In standard YUV420, a 2 \times 2 pixel macroblock utilizes 6 bytes of video frame storage (4\text{Y} + 1\text{U} + 1\text{V}). Traditional implementations duplicate the luminance byte across all four pixels (Y_0 = Y_1 = Y_2 = Y_3) to preserve spatial low-frequency bounds.

• Lossless Packing: Under a lossless configuration, spatial frequency boundaries are not quantized. The mapping engine packs six independent data bytes directly into the macroblock:

  \text{Macroblock} = \begin{pmatrix} Y_0 & Y_1 \\ Y_2 & Y_3 \end{pmatrix} \cup \{U_0, V_0\}

• Density Gain: Increases the macroblock capacity from 4 bytes of payload to 6 bytes, yielding a 50\% density increase within YUV420.

7.4.3 Subsampling Elimination via YUV444p / RGB24

When the hardware VCN block supports YUV444p or RGB24 profiles:

• Lossless Packing: The mapping layer disables chroma subsampling completely. Every pixel coordinate (u, v) stores three independent bytes (one in Y/Red, one in U/Green, one in V/Blue).
• Density Gain: A 1920 \times 1080 frame is packed to its maximum hardware boundary of 1920 \times 1080 \times 3 \text{ bytes} = 6.22 \text{ MB}, yielding a 3\times density increase over YUV420.

7.4.4 10-Bit and 12-Bit Hardware Channel Packing

Modern AMD VCN blocks support 10-bit HEVC (Main 10) and 12-bit AV1 hardware profiles.

• Lossless Packing: By increasing the bit depth, each color channel sample represents 10 or 12 bits of numerical precision. Two pixels in a 10-bit YUV444 frame can store five $12$-bit coefficients or three $20$-bit variables, mapping more cleanly to Q_{16.16} boundaries without bit-splitting overhead.
• Density Gain: Yields a 25\% to 50\% density increase per channel.

---

8. Multi-Transmit Striping & Fallback Routing

To maximize throughput across concurrent physical interfaces (e.g. WiFi, USB DMA, Serial) and handle failures gracefully, PIST implements a cost-aware striping and fallback routing protocol.

8.1 Transport Cost Optimization

Outbound paths are prioritized based on a dynamic cost metric computed over integer space:

\text{Cost}(t, L) = \text{latency}(t) \times 1000 + \frac{100000}{\text{bandwidth}(t)} \times 100 + \text{frags}(t, L) \times 10

Where transport parameters are defined as:

• USB DMA: bandwidth = 3,840 MB/s, latency = 1.0 ms (0x00010000 in Q_{16.16})
• WiFi: bandwidth = 150 MB/s, latency = 10.0 ms (0x000A0000 in Q_{16.16})
• Bluetooth: bandwidth = 3 MB/s, latency = 30.0 ms (0x001E0000 in Q_{16.16})
• Serial: bandwidth = 1 MB/s, latency = 5.0 ms (0x00050000 in Q_{16.16})

8.2 Parallel Stripe Planes

To transmit a large compute buffer concurrently, the workload is divided into N parallel stripe planes:

\text{Stripe Size} = \left\lfloor \frac{\text{Payload Length} + N - 1}{N} \right\rfloor

Each plane is dispatched over one of the N active transport layers, balancing the bandwidth capabilities.

8.3 Fallback State Machine

When a transmission failure is detected, the protocol dynamically falls back to the next best link:

1. Fallback Chain Sorting: The system sorts all available physical interfaces by ascending cost.
2. Link Promotion: Upon failure of the primary transport, the state machine triggers fallbackAdvance:
   • The failed link is removed from active candidates.
   • The next link in the sorted chain is promoted to currentTransport.
   • The retry counter is reset to maxRetries (default = 3).
3. Execution Recovery: The current stripe plane is re-fragmented according to the new link's MTU and retransmitted.

---

9. Appendix A: Naming Conventions & Standard Mappings

This section documents non-standard or domain-specific terminology used in this specification and aligns it with standard mathematical and industry networking conventions.

Project Term	Description / Custom Semantics	Standard Equivalent / Industry Specification	Standard Reference Link
PIST	Packet-as-Computation / Packet-in-State-Transfer. Treats Ethernet frames as dynamic algebraic state capsules.	Active Networking / In-Network Computing (INC) / Data Plane Programming (P4)	Active Networking (Wikipedia)
Goxel	16-dimensional shape potential state element representing a volumetric node in high-dimensional space.	Voxel (Volumetric Pixel) / Signed Distance Field (SDF) Volume Element	Voxel (Wikipedia)
Hoxel	A hyper-dimensional voxel (specifically 4D or higher) representing a hyper-volume element.	Hyper-Voxel / Hyper-volume Element	Hypervoxel Concept
Sidon Label	Unique address allocation key where pairwise sums of addresses are unique, preventing hash collisions.	Sidon Set / B_2 Set	Sidon Set (Wikipedia)
BraidStorm	8-strand braid topology modeling topological crossing nodes and crossing group iterations.	Braid Group (B_n) / Braid Topology	Braid Group (Wikipedia)
Eigensolid	Stationary state converged via braid crossings where consecutive operations act as identity.	Stationary State / Fixed Point of a Dynamic Map / Eigenstate	Fixed Point (Wikipedia)
Scar	Record logging FAMM capability memory failures, coarsening agents, and repair pressures.	Memory Fault Log / Exception Register / Error Status Record	Page Fault (Wikipedia)
VCN	Video Core Next. Dedicated AMD hardware block used for video stream encoding and decoding.	AMD VCN Hardware Accelerator	Video Core Next (Wikipedia)
RSS Toeplitz	Receive Side Scaling. Hashing mechanism that maps TCP/UDP headers using a Toeplitz matrix.	Microsoft RSS Specification / Toeplitz Hashing	Toeplitz Matrix (Wikipedia)
Yang-Baxter	Braid crossing relations modeling braid-order invariance.	Yang-Baxter Equation	Yang-Baxter (Wikipedia)
enwik9	Canonical 1GB Wikipedia XML dataset used as the end-to-end compression test benchmark.	Hutter Prize Large Text Compression Corpus	enwik9 Reference
MORE FAMM	Memory-Optimized Recursive Entropy Fractal Aggregate Memory Model.	Capability-Based Memory Segmentation / Segmented Paging	Capability-Based Security (Wikipedia)

10. Design Constraints & Boundary Safeguards

This section outlines the operational constraints, hardware limits, and security boundaries that must be maintained when executing PIST compute operations over virtualized Ethernet rings.

10.1 Numerical & Arithmetic Constraints

1. Fixed-Point Uniformity: All numerical data vectors residing in the packet payload must use Q_{16.16} fixed-point representation. Floating-point computations (Float) are strictly prohibited in the computational path.
2. GF(2) Offload Limits: The Toeplitz hashing engine (RSS) performs modulo-2 matrix-vector multiplication (GF(2) arithmetic). It cannot perform general arithmetic over Q_{16.16}. Standard additions and multiplications must be handled by the transform engines on the host or external accelerator nodes, using the RSS engine solely for hashing-based task distribution and spatial routing.
3. Non-overflow Saturation: Fixed-point arithmetic operations on the host or within shims must use saturating arithmetic. Underflows and overflows must saturate to the minimum/maximum representable values:
   • Max Value: +32767.99998 (0x7FFFFFFF raw)
   • Min Value: -32768.00000 (0x80000000 raw)

10.2 Queue & Ring Buffer Constraints

1. Descriptor Ring Capacity: The virtio-net descriptor table size (N) must be a power of 2 (128 \le N \le 1024).
2. In-Flight Flow Control: To prevent packet loss, the guest driver must implement strict flow control. The maximum number of concurrently dispatched (in-flight) descriptors must satisfy:

   \text{InFlight} \le N - 2

   If the available descriptor count falls below 2, the guest queue must block until the host returns a used buffer.
3. Alignment Boundaries: All descriptors referencing the packet payload must be aligned to 64-byte cache line boundaries to prevent split-cache access penalties and ensure optimal DMA transfer rates.

10.3 MTU & Packet Size Boundaries

1. MTU Mapping: Compute packets must not exceed the physical link or virtual device MTU unless TSO (TCP Segmentation Offload) is explicitly enabled.
2. Maximum Payload Bounds: For a standard virtual network interface with an MTU of 1500 bytes, the maximum payload size (L_{payload}) in a single unfragmented frame is:

   L_{payload} = 1500 - (14 + 41 + H_{transport}) \text{ bytes}

   Where 14 is the Ethernet header, 41 is the RDMANetHeader, and H_{transport} is the transport-specific overhead.
3. TSO Tiling Segments: When TSO is used for matrix slicing, the segment size (gso_size) must be a multiple of the matrix row size (e.g. multiples of 32 or 64 bytes) to ensure that split packets do not bisect individual fixed-point numeric fields.

10.4 Hypervisor Isolation & Security Safeguards

1. Address Space Isolation: Memory addresses passed in RDMANetHeader (local_addr, remote_addr) represent Guest Physical Addresses (GPA). The host vhost-user backend must translate GPAs using its memory map (VHOST_USER_SET_MEM_TABLE) and validate that all accessed regions lie strictly within the guest's allocated memory space. Directly dereferencing unvalidated addresses is forbidden.
2. Interface Scoping: PIST Ethernet frames must be tagged with a dedicated EtherType (e.g., 0x88B5 or local custom tags) and bound to link-local interfaces or internal virtual bridges (virbr0, xenbr0). The host network filter must drop any PIST-ethertype packets originating from external interfaces to prevent spoofing or injection of rogue state capsules.
3. State Verification: Gateway nodes and transform engines must only execute transition steps if the incoming witness_hash matches the pre-calculated Galois Field polynomial of the target state, preventing the execution of out-of-order or corrupt state transitions.

11. QEMU Graphics Framebuffer Backplane

As a parallel transport channel to virtualized network interfaces, the virtual VGA or GPU graphics framebuffer (/dev/fb0 on guest) can be exploited as a zero-copy DMA computation backplane.

This mechanism allows high-bandwidth VM-to-Host communication in locked-down microVMs where custom PCIe devices are blocked, but virtual graphics outputs (required for VM console access) remain enabled.

11.1 Pixel-to-Scalar Mapping Models

Data payloads are packed directly into the graphics framebuffer using format-specific pixel layouts:

1. ARGB8888 Mode (100% Density)

Each pixel is represented as a 32-bit (4-byte) word. One Q_{16.16} fixed-point scalar is mapped directly to one pixel.

• Byte Mapping:
  • Byte 0 (Blue Channel): Lowest 8 bits of Q_{16.16} scalar.
  • Byte 1 (Green Channel): Bits 8-15 of Q_{16.16} scalar.
  • Byte 2 (Red Channel): Bits 16-23 of Q_{16.16} scalar.
  • Byte 3 (Alpha Channel): Highest 8 bits of Q_{16.16} scalar.
• Capacity: A standard 1920 \times 1080 display framebuffer holds exactly:

  1920 \times 1080 \times 4 \text{ bytes} \approx 8.29 \text{ MB of raw numerical data}

2. RGB24 Mode (3-Byte Raw Packing)

Each pixel is represented as a 24-bit (3-byte) word. The red, green, and blue color channels hold three independent raw data bytes.

• Capacity: A 1920 \times 1080 display framebuffer holds:

  1920 \times 1080 \times 3 \text{ bytes} \approx 6.22 \text{ MB of raw data}

11.2 Memory-Mapped I/O Lifecycle

1. Guest Allocation: The guest application opens /dev/fb0 and maps the screen memory range into its user space using zero-copy memory mapping (mmap).
2. Envelope Injection: The guest prefixes the standard 24-byte signature header (RDMAVCN\0) at the start of the frame (top-left screen pixels) to denote sequence number, length, and pixel format tag.
3. DMA Transfer: The guest writes the packed matrix block into the mapped framebuffer. The write is instantly copied via guest physical memory to the virtual graphics card's PCI BAR.
4. Host Transformation: QEMU’s UI thread or VNC/SPICE server detects dirty display scanlines. The host-side transformation engine parses the signature header, extracts the raw pixel data, applies the linear algebra transform, and writes the output back to the display buffer.
5. Guest Readback: The guest application reads the updated frame buffer from /dev/fb0 to retrieve the computed state.