# Virtio MMIO v2 controlled transport contract (K1461–K1465) This contract covers one bounded modern Virtio MMIO bridge in an isolated development image. It does not change the existing legacy MMIO v1 production path. The transport rules follow [Virtual I/O Device (VIRTIO) Version 1.3, section 4.2](https://docs.oasis-open.org/virtio/virtio/v1.3/virtio-v1.3.html). ## Local model (K1461–K1464) - A DTB candidate is one 0x200-byte bridge at a 0x200-byte aligned physical address outside RAM. The caller must establish Device memory attributes before volatile register access. - A bridge is present only after reading MagicValue `0x74726976`, Version `2`, and a nonzero DeviceID. VendorID is retained for evidence but is not a device allowlist. - The registry owns a window with a generation number. Duplicate or overlapping claims fail without changing existing ownership. A released generation cannot operate on a later claim at the same address. - Feature negotiation accepts only bits offered by the device and requires `VIRTIO_F_VERSION_1` (high word bit 0). The guest may publish `FEATURES_OK` only after writing the accepted low and high feature words and observing the device retain the status bit. - Queue publication requires a nonzero power-of-two size within both the device maximum and this prototype's 1024-entry bound. Descriptor, available, and used addresses must be nonzero and satisfy their base alignments. The physical path must populate and order queue memory before writing QueueReady `1` and must observe the readback before DRIVER_OK. - The physical path writes DeviceStatus `0`, observes both DeviceStatus `0` and QueueReady `0`, and only then records reset. Releasing ownership while a queue is ready or DRIVER_OK is active fails. The local model does not itself perform MMIO writes or prove DMA lifetime. ## Guest acceptance (K1465) An isolated QEMU guest must discover a real v2 bridge from the DTB, validate its Device mapping, negotiate the required feature and status sequence, publish a disposable queue only after its memory is ready, and observe QueueReady and DRIVER_OK. It must reset the device, observe QueueReady and status return to zero, release queue memory and registry ownership, and return from the probe. Direct and UEFI profiles at 256, 512, and 1024 MiB must pass. Canonical product release acceptance is separate.