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>
---
Changes from v1:
drop an unrelated chunk erroneously inserted here
virtio-v1.0-wd01-part1-specification.txt | 74 +++++++++++++++++++-------------
1 file changed, 44 insertions(+), 30 deletions(-)
diff --git a/virtio-v1.0-wd01-part1-specification.txt b/virtio-v1.0-wd01-part1-specification.txt
index a96b2e3..62e84f8 100644
--- a/virtio-v1.0-wd01-part1-specification.txt
+++ b/virtio-v1.0-wd01-part1-specification.txt
@@ -1251,7 +1251,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 +1462,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 |
+| 0x1, 0x101 | network card |
+------------+--------------------+
+| 0x2, 0x102 | block device |
+------------+--------------------+
-| 0 | reserved (invalid) |
+| 0x3, 0x103 | console |
+------------+--------------------+
-| 1 | network card |
+| 0x4, 0x104 | entropy source |
+------------+--------------------+
-| 2 | block device |
+| 0x5, 0x105 | memory ballooning |
+------------+--------------------+
-| 3 | console |
+| 0x6, 0x106 | ioMemory |
+------------+--------------------+
-| 4 | entropy source |
+| 0x7, 0x107 | rpmsg |
+------------+--------------------+
-| 5 | memory ballooning |
+| 0x8, 0x108 | SCSI host |
+------------+--------------------+
-| 6 | ioMemory |
+| 0x9, 0x109 | 9P transport |
+------------+--------------------+
-| 7 | rpmsg |
+| 0xA, 0x10A | mac80211 wlan |
+------------+--------------------+
-| 8 | SCSI host |
+| 0xB, 0x10B | rproc serial |
+------------+--------------------+
-| 9 | 9P transport |
-+------------+--------------------+
-| 10 | mac80211 wlan |
-+------------+--------------------+
-| 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 +1519,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 +1924,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 +2106,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 +2217,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 +2256,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 +2419,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