non-transitional devices should have been able to simply update revision ID to make sure legacy drivers are not loaded. Unfortunately, mistakes were made: - we didn't stress that drivers must check revision ID, and of course there's no easy way for drivers to test this failure path, so older versions of Windows drivers ignored revision (latest vision matches revision correctly) - CCW lacks revision ID field Both facts mean a non-transitional device would need a separate mechanism to prevent legacy drivers from loading. We aren't running out of device IDs yet, so let's use up some to resolve this. I incremented all IDs by 0x100 intentionally - for the PCI bindings, this should help remind people they can't just stick the Subsystem ID into the low byte of the Device ID. Signed-off-by: Michael S. Tsirkin <
mst@redhat.com> --- virtio-v1.0-wd01-part1-specification.txt 77 +++++++++++++++++++------------- 1 file changed, 47 insertions(+), 30 deletions(-) diff --git a/virtio-v1.0-wd01-part1-specification.txt b/virtio-v1.0-wd01-part1-specification.txt index a96b2e3..68cc6d4 100644 --- a/virtio-v1.0-wd01-part1-specification.txt +++ b/virtio-v1.0-wd01-part1-specification.txt @@ -728,6 +728,9 @@ Any PCI device with Vendor ID 0x1AF4, and Device ID 0x1000 through 0x103F inclusive is a virtio device[3]. The device must also have a Revision ID of 0 to match this specification. +NB: Drivers must not match, or attempt to use devices where Revision +ID does not match 0. + The Subsystem Device ID indicates which virtio device is supported by the device. The Subsystem Vendor ID should reflect the PCI Vendor ID of the environment (it's currently only used @@ -1251,7 +1254,7 @@ configuration space. The following list presents their layout: Device version number. Currently must be 1. • 0x008 R DeviceID - Virtio Subsystem Device ID (ie. 1 for network card). + Virtio Subsystem Device ID (ie. 0x1 for network card). • 0x00c R VendorID Virtio Subsystem Vendor ID. @@ -1462,37 +1465,51 @@ defined in this standard. Discovering what devices are available and their type is bus-dependent. ++-------------+--------------------+ + Device IDs Virtio Device ++-------------+--------------------+ ++-------------+--------------------+ + 0x0 reserved (invalid) +------------+--------------------+ - Device ID Virtio Device -+------------+--------------------+ -+------------+--------------------+ - 0 reserved (invalid) + 0x1, 0x101 network card +------------+--------------------+ - 1 network card + 0x2, 0x102 block device +------------+--------------------+ - 2 block device + 0x3, 0x103 console +------------+--------------------+ - 3 console + 0x4, 0x104 entropy source +------------+--------------------+ - 4 entropy source + 0x5, 0x105 memory ballooning +------------+--------------------+ - 5 memory ballooning + 0x6, 0x106 ioMemory +------------+--------------------+ - 6 ioMemory + 0x7, 0x107 rpmsg +------------+--------------------+ - 7 rpmsg + 0x8, 0x108 SCSI host +------------+--------------------+ - 8 SCSI host + 0x9, 0x109 9P transport +------------+--------------------+ - 9 9P transport + 0xA, 0x10A mac80211 wlan +------------+--------------------+ - 10 mac80211 wlan + 0xB, 0x10B rproc serial +------------+--------------------+ - 11 rproc serial -+------------+--------------------+ - 12 virtio CAIF + 0xC, 0x10C virtio CAIF +------------+--------------------+ +2.4.0 Legacy Interface: A Note on Device IDs +-------------------------------------- +Where two distinct IDs can identify a single virtio device, the +following rules should be obeyed: + +Transitional devices must use the smaller of the IDs. +For example use Device ID=0x1 for a network card. + +Non-transitional devices must use the larger of the IDs. +For example use Device ID=0x101 for a network card. + +Both transitional and non-transitional drivers must match all +IDs for a given device type. + 2.4.1. Network Device ==================== @@ -1505,10 +1522,10 @@ packets are enqueued into another for transmission in that order. A third command queue is used to control advanced filtering features. -2.4.1.1. Device ID +2.4.1.1. Device IDs ----------------- - 1 + 0x1, 0x101 2.4.1.2. Virtqueues ------------------ @@ -1910,9 +1927,9 @@ disk). Read and write requests (and other exotic requests) are placed in the queue, and serviced (probably out of order) by the device except where noted. -2.4.2.1. Device ID +2.4.2.1. Device IDs ----------------- - 2 + 0x2, 0x102 2.4.2.2. Virtqueues ------------------ @@ -2092,10 +2109,10 @@ successfully added, port open/close, etc.. For data IO, one or more empty buffers are placed in the receive queue for incoming data and outgoing characters are placed in the transmit queue. -2.4.3.1. Device ID +2.4.3.1. Device IDs ----------------- - 3 + 0x3, 0x103 2.4.3.2. Virtqueues ------------------ @@ -2203,9 +2220,9 @@ data and outgoing characters are placed in the transmit queue. The virtio entropy device supplies high-quality randomness for guest use. -2.4.4.1. Device ID +2.4.4.1. Device IDs ----------------- - 4 + 0x4, 0x104 2.4.4.2. Virtqueues ------------------ @@ -2242,9 +2259,9 @@ changes in allowance of underlying physical memory. If the feature is negotiated, the device can also be used to communicate guest memory statistics to the host. -2.4.5.1. Device ID +2.4.5.1. Device IDs ----------------- - 5 + 0x5, 0x105 2.4.5.2. Virtqueues ------------------ @@ -2405,9 +2422,9 @@ medium. In the transport protocol, the virtio driver acts as the initiator, while the virtio SCSI host provides one or more targets that receive and process the requests. -2.4.6.1. Device ID +2.4.6.1. Device IDs ----------------- - 8 + 0x8, 0x108 2.4.6.2. Virtqueues ------------------ -- MST