1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
|
478 & 15 Mar 2015 & Cornelia Huck & {VIRTIO-129: legacy:
clean up virtqueue layout definitions
Generalize "Legacy Interfaces: A Note on Virtqueue Layout" to allow
for different alignment requirements. Have pci and ccw refer to that
section for legacy devices. Remove the double definition of virtqueue
alignment (which referred to legacy, but was not tagged as such) from
the ccw section.
See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues /
Legacy Interfaces: A Note on Virtqueue Layout}, \ref{sec:Virtio
Transport Options / Virtio Over PCI Bus / PCI-specific
Initialization And Device Operation / Device Initialization /
Virtqueue Configuration / Legacy Interface: A Note on Virtqueue
Configuration} and \ref{sec:Virtio Transport Options / Virtio
over channel I/O / Device Initialization / Configuring a
Virtqueue / Legacy Interface: A Note on Configuring a Virtqueue}.
} \\
\hline
479 & 15 Mar 2015 & Cornelia Huck & {VIRTIO-118:
ccw: clarify basic channel commands
"Basic channel commands" seems to be not as clear as it
could, so let's spell out which channel commands we refer to.
See \ref{sec:Virtio Transport Options / Virtio over channel I/O /
Basic Concepts}.
} \\
\hline
479 & 15 Mar 2015 & Cornelia Huck & {VIRTIO-116:
ccw: allow WRITE_STATUS to fail
We want to be able to fail setting a status on the device
(e.g. FEATURES_OK if the device can't work with the features
negotiated).
The easiest way to do that is to allow the device to fail the
WRITE_STATUS command by posting a command reject.
See \ref{sec:Virtio Transport Options / Virtio over channel I/O /
Device Initialization / Communicating Status Information}.
} \\
\hline
485 & 15 Mar 2015 & Jason Wang & {VIRTIO-135:
virtio-ring: comment fixup
virtio_ring.h included with spec has this text:
/* Support for avail_idx and used_idx fields */
it should really refer to avail_event and used_event.
See Appendix \ref{sec:virtio-ring.h}.
} \\
\hline
486 & 15 Mar 2015 & Jason Wang & {VIRTIO-136:
document idx field in virtqueue used ring
Section \ref{sec:Basic Facilities of a Virtio Device / Virtqueues
/ The Virtqueue Used Ring} The Virtqueue Used Ring
listed the idx field, but never documented it.
See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues /
The Virtqueue Used Ring}.
} \\
\hline
487 & 15 Mar 2015 & Rusty Russell & {VIRTIO-130:
ISR status: Fix incorrect diagram
ISR status capability diagram has the "Device Configuration
Interrupt " as bit 0, and the "Queue Interrupt" as bit 1. This is
the wrong way around: it disagrees with the legacy
implementations, as well as the spec elsewhere.
All current guests correctly follow the text, fix
up the diagram to match.
See \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI
Device Layout / ISR status capability}.
} \\
\hline
488 & 15 Mar 2015 & Rusty Russell & {VIRTIO-133:
Change 4.1.5.1.2.1 to device requirement
4.1.5.1.2.1 is incorrectly labelled as a driver requirement; it's
self-evidently referring to the device.
See \ref{sec:Conformance / Driver Conformance / PCI Driver
Conformance}, \ref{sec:Conformance / Device Conformance / PCI
Device Conformance} and \ref{devicenormative:Virtio
Transport Options / Virtio Over PCI Bus / PCI-specific
Initialization And Device Operation / Device Initialization /
Non-transitional Device With Legacy Driver}.
} \\
\hline
504 & 22 Apr 2015 & Rusty Russell & {VIRTIO-137:
define the meaning and requirements of the len field.
We said what it was for, and noted why. We didn't place any
requirements on it, nor clearly spell out the implications of its use.
This clarification comes particularly from noticing that QEMU
didn't set len correctly, and philosophising over the correct value
when an error has occurred.
See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues /
The Virtqueue Used Ring}, \ref{devicenormative:Basic Facilities
of a Virtio Device / Virtqueues / The Virtqueue Used Ring} and
\ref{sec:Basic Facilities of a Virtio Device / Virtqueues / The
Virtqueue Used Ring}.
} \\
\hline
506 & 22 Apr 2015 & Michael S. Tsirkin & {VIRTIO-138:
multiple errors: Non-transitional With Legacy
virtio 1.0 has two sections titled "Non-transitional Device With
Legacy Driver" the first says devices SHOULD fail, the second
says devices MUST fail. Clearly a mistake.
Other issues: devices don't really fail - they cause drivers to
fail. second section seems to be in the wrong place, and also
have a section followed by subsection with no explanatory text in
between, which is ugly.
Finally, this text was originally ritten to handle buggy windows
drivers gracefully, but later we changed device IDs so it's not
really required there. Might be handy for some other buggy legacy
drivers, though no such drivers are known.
To fix, drop the duplicate section variant, add some explanatory
text, clarify what does "same ID" mean here, and clarify
that the work-around is only needed if a buggy driver
is known to bind to a transitional device.
See \ref{sec:Virtio Transport Options / Virtio
Over PCI Bus / PCI Device Layout / Non-transitional Device With
Legacy Driver: A Note on PCI Device Layout},
\ref{devicenormative:Virtio Transport Options / Virtio Over PCI
Bus / PCI-specific Initialization And Device Operation / Device
Initialization / Non-transitional Device With Legacy Driver} and
\ref{sec:Virtio Transport Options / Virtio Over PCI Bus /
PCI-specific Initialization And Device Operation / Device
Initialization}.
} \\
\hline
508 & 22 Apr 2015 & Michael S. Tsirkin & {VIRTIO-139:
pci: missing documentation for dealing with 64 bit config fields
pci spec says what width access to use for 32, 16 and 8
bit fields, but does not explicitly say what to do for
32 bit fields. As we have text that says driver must
treat 64 bit accesses as non-atomic, this seems
to imply driver should always do two 32 bit wide accesses.
Let's make this an explicit requirement, and require
devices to support this.
See \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI
Device Layout}, \ref{drivernormative:Virtio Transport Options /
Virtio Over PCI Bus / PCI Device Layout},
\ref{devicenormative:Virtio Transport Options / Virtio Over PCI
Bus / PCI Device Layout} and \ref{sec:Conformance / Driver
Conformance / PCI Driver Conformance}.
} \\
\hline
509 & 22 Apr 2015 & Michael S. Tsirkin & {balloon:
MUST -> has to
MUST shouldn't be used outside normative statements,
that's confusing. Replace with "has to".
See \ref{sec:Device Types / Memory Balloon Device / Feature
bits}.
} \\
\hline
510 & 22 Apr 2015 & Michael S. Tsirkin & {conformance:
add VIRTIO-137 statement links
Add links to new conformance statements added to
resolve VIRTIO-137 (describing used ring entry len usage).
See \ref{sec:Conformance / Device Conformance}
and \ref{sec:Conformance / Driver Conformance}.
} \\
\hline
517 & 22 Apr 2015 & Michael S. Tsirkin & {acknowledgements:
contributors+minor fixup
acknowledge feedback by Jason Wang, add Richard Sohn who
joined the TC, sort acknowledged reviewers alphabetically.
See \ref{chap:Acknowledgements}.
} \\
\hline
|
