docs(rng-buf): Clarify spec diff and add impl plan

- Reference the "Difference from virtio spec" section from summary
- Rename section to "Difference from virtio spec"
- Reflow packed ring explanation for readability
- Add an implementation plan and future work outline

Signed-off-by: Tomasz Andrzejak <andreiltd@gmail.com>

Author: andreiltd

proposals/0001-rng-buf/README.md

@@ -26,7 +26,7 @@
 - [Implementation History](#implementation-history)
 - [Drawbacks](#drawbacks)
 - [Alternatives](#alternatives)
-  <!-- /toc -->
+    <!-- /toc -->
 
 ## Summary
 
@@ -38,7 +38,8 @@ as streams, RPC, and other I/O patterns in both single-threaded and multi-thread
 
 The design leverages virtio's well-defined publishing/consumption semantics and memory safety
 guarantees while adapting them to Hyperlight's specific needs. Since we control both ends of the
-queue, we can deviate from strict virtio compliance where it makes sense.
+queue, we can deviate from strict virtio compliance where it makes sense (see
+[Difference from virtio spec](#difference-from-virtio-spec) section).
 
 ## Motivation
 
@@ -206,10 +207,10 @@ with atomic publishing of flags ensure that the other side will never observe a
 - Driver: Write descriptor fields ? memory barrier ? atomic Release-store flags
 - Device: Atomic Acquire-load flags ? memory barrier ? read descriptor fields
 
-Because the packed ring reuses the same descriptor slot for both `available` and `used` states and both
-sides only poll a single next slot, each side needs to differentiate between "this change belongs to
-the current lap in the ring" and "this is an old value from the previous lap." This is done using
-"wrap" counters:
+Because the packed ring reuses the same descriptor slot for both `available` and `used` states and
+both sides only poll a single next slot, each side needs to differentiate between "this change
+belongs to the current lap in the ring" and "this is an old value from the previous lap." This is
+done using "wrap" counters:
 
 - Each side keeps a boolean "wrap" flag that toggles when it passes the last descriptor in the ring,
 - When the driver publishes an available descriptor, it sets `AVAIL` to its wrap bit and `USED` to
@@ -355,7 +356,7 @@ descriptor layer or in the flatbuffer schema:
 Snapshotting requires that the descriptor table has no in-flight guest-to-host requests and any
 attempt to snapshot a sandbox with such pending requests will result in a snapshot failure.
 
-### Difference from spec
+### Difference from virtio spec
 
 - Do not support indirect descriptor table (can be deferred to future work if needed),
 - Do not support feature negotiation, set of features is fixed for driver and device,
@@ -721,6 +722,23 @@ impl RingReceiver
 - Performance benchmarks vs. current VM exit approach
 - Stress testing under high load
 
+### Implementation Plan
+
+As proposed, the queue will eventually replace the current stack‑based mechanism for function calls.
+The initial implementation will be gated behind a feature flag. The work can be roughly broken down
+into:
+
+- Introduce a low‑level queue implementation that operates on shared memory.
+- Introduce a serialization trait for data that can be safely sent through the queue.
+- Introduce a high‑level API over the queue.
+- Integrate the queue infrastructure with the existing memory model and function‑call API.
+
+Future work includes:
+
+- Adding `Future` and `Stream` as function argument and return types.
+- Supporting host and guest running on separate threads.
+- Providing an asynchronous API for function calls, streams, and related workflows.
+
 ## Implementation History
 
 - **2025-11-12**: HIP proposed