@@ -10,7 +10,7 @@ platform uses.
 
 | Port | Function | Architectural purpose |
 | ---: | --- | --- |
-| `0xe9..0xeb` | Host/guest byte channel | Early console data, bounded host input, restore metadata, generation identity, and host time samples |
+| `0xe9..0xeb` | Host/guest byte channel | Early console data, restore metadata, generation identity, and host time samples |
 | `0x604` | Shutdown | Guest-requested process termination with a status byte |
 | `0x605` | Snapshot request | Guest-initiated capture and post-restore acknowledgement |
 
@@ -26,8 +26,10 @@ machine omits, and carries:
 
 - The guest's console. The kernel writes its boot messages to the channel
   from early in its initialization, before it probes any driver, and the
-  channel is also the kernel console, with host input, unless a
-  [boot console](3.3-consoles.md#331-boot-console) is configured.
+  channel is also the kernel console unless a
+  [boot console](3.3-consoles.md#331-boot-console) is configured. The channel
+  takes no host input, so host input reaches the guest only through its
+  [consoles](3.3-consoles.md).
 - Failure reports from the guest agents, including failures of the control
   console.
 - The one-time [restore packet](5.5-restore-protocol.md#555-restore-packet),
@@ -54,10 +56,10 @@ silently lost; see
 
 The channel's protocol is also minimal: it needs no feature negotiation,
 queues in guest memory, or interrupt line. Each output byte is one port write,
-and the guest polls a status port for input. Every access to the channel's
-ports is a synchronous exit that the VMM completes before the guest continues,
-so a host time that the VMM records during an access lies between two guest
-TSC reads taken around it. The guest checks each
+and the guest reads records and status with port reads. Every access to the
+channel's ports is a synchronous exit that the VMM completes before the guest
+continues, so a host time that the VMM records during an access lies between
+two guest TSC reads taken around it. The guest checks each
 [time sample](3.2-clock-and-time.md#329-time-samples)'s pairing of host UTC
 with its TSC against them.
 
@@ -68,7 +70,7 @@ port, a status and record-selector port, and a time-sample window.
 
 | Port | Access | Behavior |
 | ---: | --- | --- |
-| `0xe9` | Read and write | Raw byte input and output. A console read consumes one pending byte and zero-fills the rest of the access. With a record selected, a 1-, 2-, or 4-byte read returns that many bytes of the record, little-endian and zero-filled past its end. |
+| `0xe9` | Read and write | Raw byte output. Without a selected record, a read returns zeros. With a record selected, a 1-, 2-, or 4-byte read returns that many bytes of the record, little-endian and zero-filled past its end. |
 | `0xea` | Read | Status bits, listed in Table 3.3 |
 | `0xea` | Write | Record selector: `0xa5` selects the one-time [restore packet](5.5-restore-protocol.md#555-restore-packet), `0xa6` selects the 16-byte generation ID, and `0xa7` latches a fresh [time sample](3.2-clock-and-time.md#329-time-samples) without changing the `0xe9` selection |
 | `0xeb` | Read | The next bytes of the latched time sample, zero-filled past its end or when no sample is latched |
@@ -79,7 +81,7 @@ Table 3.3 lists the status bits.
 
 | Status bit | Meaning |
 | ---: | --- |
-| 0 | Host input is pending |
+| 0 | Zero: the channel takes no host input |
 | 1 | A fresh restore packet is available |
 | 2 | The restore carries a processor target |
 | 3 | The restore carries a memory target |
@@ -99,22 +101,22 @@ how a restored guest checks the ID, and
 [Entropy Refresh](5.5-restore-protocol.md#558-entropy-refresh) how it obtains
 fresh random numbers.
 
-The time-sample window is separate from the data port because the guest
-console driver polls status and reads data from a timer context, so a sample
-on the console stream could interleave with input bytes. Guest users of the
-selectors serialize their transactions. Every byte the guest reads is a port
-exit, so records are small and readable four bytes per exit.
-
-The receive and transmit buffers are each bounded at 1 MiB. Output overflow
-drops the newest bytes and emits a rate-limited warning; input applies
-backpressure by not reading the host endpoint while its buffer is full.
-Pending bytes are saved, so capture does not silently lose VMM-owned I/O. The
-time-sample window is not saved state.
-
-While host input is gated for a snapshot boundary or post-restore repair, the
-channel stops reading its host endpoint, returns zero for console reads, and
-clears the input-pending bit. Guest output, the generation ID, any restore
-packet, and the time-sample window remain available.
+The time-sample window is separate from the data port, so that the guest can
+latch and read a sample without changing the data port's record selection.
+Guest users of the selectors serialize their transactions. Every byte the
+guest reads is a port exit, so records are small and readable four bytes per
+exit.
+
+The transmit buffer is bounded at 1 MiB. Overflow drops the newest bytes and
+emits a rate-limited warning. Pending output is saved, so capture does not
+silently lose VMM-owned output, and a restore refuses saved state that holds
+host input, as a snapshot of an earlier VMM can. The time-sample window is not
+saved state.
+
+Since the channel takes no host input, gating host input for a snapshot
+boundary or post-restore repair leaves it unchanged: guest output, the
+generation ID, any restore packet, and the time-sample window remain
+available.
 
 ## 3.1.2 Shutdown
 
 
@@ -15,9 +15,11 @@ endpoints, saved state, and reconnect policies.
 ## 3.3.1 Boot Console
 
 The optional boot console carries boot messages and an ordinary byte stream.
-The kernel console uses it once its driver is ready, and the byte channel
-remains the early console. Host RX accepted by the device and partial guest TX
-progress are device-private saved state, so restore never replays a
+It is the only console for interactive host input, since the
+[byte channel](3.1-platform-control-device.md#311-hostguest-byte-channel)
+takes none. The kernel console uses it once its driver is ready, and the byte
+channel remains the early console. Host RX accepted by the device and partial
+guest TX progress are device-private saved state, so restore never replays a
 descriptor from byte zero or silently loses VMM-owned data.
 
 The host attachment is one of:
 
@@ -55,7 +55,8 @@ earlycon=xe9 console=hvc0 reboot=t panic=-1
 ```
 
 When the boot virtio-console is present, the kernel console becomes `hvc1`,
-and the byte channel remains the early console. User arguments follow the
+and the byte channel remains the early console. Without it, the kernel console
+stays on the byte channel, which takes no host input. User arguments follow the
 base tokens. A fresh boot then appends host-owned tokens in this order:
 
 1. `nr_cpus=<capacity>`, so Linux sizes its processor state to the validated
 
@@ -7,18 +7,20 @@
   `b2676222b383bf50c7022f6a5983920421469a47`; see [Upstream status](#upstream-status).
 - Mapped fork tip: `3cdf4fe3834cfb90b9ee685875493bc9bff1b7a4`, position 135. The graph, PR
   summary, and commit mapping below cover positions 001-135 and the PR20 fixup at position 152.
-- NVX's pinned OpenVMM revision: `5aa8b028503237757b95f5629ebdbb4d56a67d51`, position 211.
-  Position 211, which microsoft/openvmm#4894 proposes for `feature/microvm/dev`, is one commit on
-  position 210, `eda13d80a`, the head of the `feature/microvm/release/v4.0` branch of
-  microsoft/openvmm, to which `feature/microvm/dev` also points. The v4.0 reorganization moved the
-  205 commits of `feature/microvm/release/v3.0` and the NVX pin before it, `35e76265f`, onto
-  `c6d3da0ff`. It dropped the eight commits whose changes upstream had landed or superseded,
-  retired the fallible device start that microsoft/nvx#1232 replaces with awaited device
-  restoration, folded that restoration into the commits that it changes, and added 14 commits that
-  give each ABI that the chain introduces a single version; see
-  [The v4.0 reorganization](#the-v40-reorganization). The pin is 76 commits past the mapped tip on
-  the same first-parent chain. Positions 136-211, except the PR20 fixup at position 152, are not
-  yet assigned to PRs; see [Commits after the mapped tip](#commits-after-the-mapped-tip).
+- NVX's pinned OpenVMM revision: `4713c539ac989c5760415f8441bdb85ae9be3e82`, position 213.
+  Position 213, which microsoft/openvmm#4887 proposes for `feature/microvm/dev`, is one commit on
+  position 212, `de29849a4`, which microsoft/openvmm#4886 proposes as one commit on position 211,
+  `5aa8b0285`, which microsoft/openvmm#4894 proposes as one commit on position 210, `eda13d80a`,
+  the head of the `feature/microvm/release/v4.0` branch of microsoft/openvmm, to which
+  `feature/microvm/dev` also points. The v4.0 reorganization moved the 205 commits of
+  `feature/microvm/release/v3.0` and the NVX pin before it, `35e76265f`, onto `c6d3da0ff`. It
+  dropped the eight commits whose changes upstream had landed or superseded, retired the fallible
+  device start that microsoft/nvx#1232 replaces with awaited device restoration, folded that
+  restoration into the commits that it changes, and added 14 commits that give each ABI that the
+  chain introduces a single version; see [The v4.0 reorganization](#the-v40-reorganization). The
+  pin is 78 commits past the mapped tip on the same first-parent chain. Positions 136-213, except
+  the PR20 fixup at position 152, are not yet assigned to PRs; see
+  [Commits after the mapped tip](#commits-after-the-mapped-tip).
 - Upstream main: `ca6b2b177da5e33ae1bcac72986b31d6b039811c` (2026-11-02), one commit past the
   fork base; see [Upstream main past the fork base](#upstream-main-past-the-fork-base).
 
@@ -644,8 +646,8 @@ c6d3da0ff
   -> command lines [189] -> KVP test [190-191]
   -> sandbox block roles [192] -> virtio feature masks [193-194]
   -> IOAPIC interrupt lines [195-196] -> ABI restart [197-210]
-  -> boot console exit drain [211]
-  -> 5aa8b0285 (NVX pin)
+  -> boot console exit drain [211] -> portb without host input [212-213]
+  -> 4713c539a (NVX pin)
 ```
 
 For upstream review, PR01-PR07 and PR14 can be rebased independently onto current upstream main,
@@ -661,12 +663,12 @@ see [The v3.0 reorganization](#the-v30-reorganization).
 
 ## Commits after the mapped tip
 
-The NVX pin extends the chain past position 135 without merges. Of the 76 later commits, position
+The NVX pin extends the chain past position 135 without merges. Of the 78 later commits, position
 152 is a PR20 fixup, and the others are not yet classified or assigned to PRs. Each of positions
 136-191 combines the v2.4 commits that the table lists, as v3.0 positions 145-200 did, which
 developed one concept; "(part)" marks a v2.4 fixup that split across commits. Positions 192-196
 followed the v3.0 reorganization, positions 197-210 are the ABI restart of the v4.0
-reorganization, and position 211 followed it, so they combine none.
+reorganization, and positions 211-213 followed it, so they combine none.
 
 | Position | Commit | v3.0 position | v2.4 positions | Topic |
 | ---: | --- | ---: | --- | --- |
@@ -746,6 +748,8 @@ reorganization, and position 211 followed it, so they combine none.
 | 209 | `31d684ae0` | - | - | microVM: drop the history from the layout and snapshot helpers |
 | 210 | `eda13d80a` | - | - | openvmm_helpers: number the snapshot's fields without gaps |
 | 211 | `5aa8b0285` | - | - | microVM: drain the boot console's terminal output at guest exit (microsoft/openvmm#4894) |
+| 212 | `de29849a4` | - | - | vmm_tests: drive the microVM guests without portb input (microsoft/openvmm#4886) |
+| 213 | `4713c539a` | - | - | microVM: remove portb's host input (microsoft/openvmm#4887) |
 
 The remarks that say whether commits apply to upstream main record what the v3.0 reorganization
 found on its base, `b2676222b`, at the positions that the commits have now.
@@ -774,7 +778,15 @@ position 087 selects, to the IOAPIC input of its window, which changes the inter
 discovery tokens that PR17's position 078 records in the snapshot contract and that the slots of
 PR18, PR19, and PR23 use. Position 211 extends the portb exit drain of PR24's position 123 to the
 relay that copies the boot console of PR16's position 071 to the terminal, and gives the
-management RPC's drain of PR25's position 128 no such relay. Assigning the later
+management RPC's drain of PR25's position 128 no such relay. Position 212 makes the guests of the
+microVM cold-boot test and portb harness of PR15's position 069, of the check of PR17's position
+084 that an unconfigured snapshot request continues, and of the management RPC's microVM test of
+PR25's position 128 run without portb's host input, and removes the harness's input. Position 213
+then removes that input: the receive path of the portb console of PR15's position 064, which
+PR20's position 098 shares with the restore records and PR20's position 099 gates, and the
+console input that PR15's position 068 gives the device on the CLI. Since those reads also
+noticed a departed peer of a listening endpoint, position 213 has the device poll the backend for
+it instead. Assigning the later
 commits therefore means revisiting those PRs, not only appending new ones.
 
 Position 182, by contrast, changes only `disk_blob`, which upstream main and the fork base
@@ -819,6 +831,9 @@ introduce those ABIs upstream.
 Position 211 changes only the microVM CLI's output drain and host consoles, the anonymous serial
 pair that they use, and the CLI guide: replaying it on upstream main, `ca6b2b177`, conflicts in
 five of its seven files, four of which upstream main lacks, so it follows those PRs upstream.
+Positions 212 and 213 change only the microVM portb device, its CLI and test harness, the VMM tests
+of PR15, PR17, and PR25, and their Guide pages: replaying them on upstream main conflicts in all
+nine of their files, six of which upstream main lacks, so they follow those PRs upstream.
 
 ## PR summary
 
 
@@ -377,11 +377,12 @@ Most `nvx-rs run` options pass through unchanged: `--machine`, `--processors`,
 
 Always include `--single-process`. Include `--virtio-console console` to type
 into the guest's shell on a fresh boot: without a boot console, the guest's
-console is the byte channel, `hvc0`. A restore keeps the console of its
-snapshot. OpenVMM requires `--virtio-console console` again to restore a
-snapshot of a boot that passed it, and refuses `--virtio-console` for a
-snapshot without a boot console. `nvx-rs run` passes the option to a fresh boot
-only, so it cannot yet restore a snapshot of a boot with it
+console is the byte channel, `hvc0`, which takes no input, so OpenVMM discards
+the terminal's keystrokes, though Ctrl-Q still opens its REPL. A restore keeps
+the console of its snapshot. OpenVMM requires `--virtio-console console` again
+to restore a snapshot of a boot that passed it, and refuses `--virtio-console`
+for a snapshot without a boot console. `nvx-rs run` passes the option to a
+fresh boot only, so it cannot yet restore a snapshot of a boot with it
 ([#1254](https://github.com/microsoft/nvx/issues/1254)). When restoring, omit
 `--memory`, `--kernel`, `--initrd`, and `--net`, whose addresses the snapshot
 keeps; see [Networked snapshots](#networked-snapshots). Every restore gives the