Age | Commit message (Collapse) | Author |
|
Link new conformance statements added by commit
network device: document VIRTIO_NET_F_CTRL_RX_EXTRA
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio/branches/v1.0@530 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
|
|
Fix up multiple issues in xmit/receive sections:
- drop MAY/MUST/SHOULD outside normative statements
- spell out conformance requirements for both drivers and
devices, for xmit and receive paths
- document the missing VIRTIO_NET_HDR_F_DATA_VALID
- document handling of unrecognized flag bits so we can extend
flags in the future, similar to VIRTIO_NET_HDR_F_DATA_VALID
VIRTIO-123
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio/branches/v1.0@528 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
|
|
Virtio 1.0 cs02 doesn't include a modern balloon device. At some
point we'll likely define an incompatible interface with a
different ID and different semantics. But for now, it's not a
big effort to support a transitional balloon device: this has the
advantage of supporting existing drivers, transparently, as well
as transports that don't allow mixing virtio 0 and virtio 1
devices. And balloon is an easy device to test, so it's also
useful for people to test virtio core handling of transitional
devices.
Three issues with legacy hypervisors have been identified:
1. Actual value is actually used, and is necessary for management
to work. Luckily 4 byte config space writes are now atomic.
When using old guests, hypervisors can detect access to the last byte.
When using old hypervisors, drivers can use atomic 4-byte accesses.
2. Hypervisors actually didn't ignore the stats from the first
buffer supplied. This means the values there would be
incorrect until hypervisor resends the request.
Add a note suggesting hypervisors ignore the 1st buffer.
3. QEMU simply over-writes stats from each buffer it gets.
Thus if driver supplies a different subset of stats
on each request, stale values will be there.
Require drivers to supply the same subset on each
request. This also gives us a simple way to figure out
which stats are supported.
VIRTIO-143
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio/branches/v1.0@526 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
|
|
previous commit "used ring: specify legacy behaviour for len field"
to resolve VIRTIO-141 added new sections with normative
statements for legacy balloon and scsi devices. Link them from
the conformance section.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio/branches/v1.0@524 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
|
|
Add links to new conformance statements added to
resolve VIRTIO-137 (describing used ring entry len usage).
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio/branches/v1.0@510 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
|
|
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.
VIRTIO-139
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio/branches/v1.0@508 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
|
|
4.1.5.1.2.1 is incorrectly labelled as a driver requirement; it's
self-evidently referring to the device.
VIRTIO-133
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio/branches/v1.0@488 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
|
|
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.
VIRTIO-116
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Approved unanimously:
https://www.oasis-open.org/apps/org/workgroup/virtio/ballot.php?id=2762
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio/branches/v1.0@479 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
|
|
The specification for the configuration layout for block devices
should be its own subsection as for all other devices and not be
hidden beneath "Feature bits".
The normative sections for device operation should appear under
the device operation section.
VIRTIO-125
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio/branches/v1.0@449 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
|
|
As passed at meeting 2014-05-06:
https://lists.oasis-open.org/archives/virtio/201405/msg00016.html
Signed-off-by: Rusty Russell <rusty@au1.ibm.com>
git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio@368 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
|
|
For the network device, we had two device normative sections both called
"setting up receive buffers", neither of which was referenced in the
conformance section.
Let's rename the second one to "processing of packets" which seems to
better match the actual contents and reference both of them from the
conformance statement for network devices.
Resolves VIRTIO-97.
Agreed on the 2014/05/06 TC meeting.
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio@362 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
|
|
Both device and driver conformance referred to ccw twice; let's add the
correct mmio references.
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
(cherry picked from commit feeca2541850c2e1e03ed5ec3b98a5e75ccb4053)
git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio@361 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
|
|
This reverts commit feeca2541850c2e1e03ed5ec3b98a5e75ccb4053.
Revert temporarily so we are back to text matching WD02.
git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio@334 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
|
|
Both device and driver conformance referred to ccw twice; let's add the
correct mmio references.
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio@333 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
|
|
These are never introduced, so use simpler names: virtq* for structures
and VIRTIO_ for features.
I added two notes about the old names, for helping people coming from
the old spec.
Signed-off-by: Rusty Russell <rusty@au1.ibm.com>
git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio@327 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
|
|
Avoid these words where they are redundant. This also lead me to
notice that we were not consistent in the use of the term
"device-specific configuration" in the PCI section, so cleaned that up
too.
Signed-off-by: Rusty Russell <rusty@au1.ibm.com>
git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio@323 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
|
|
Signed-off-by: Rusty Russell <rusty@au1.ibm.com>
git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio@321 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
|
|
Clean up the remaining lowercase "musts". We actually introduce a
new normative section in the balloon; for the rest we clarify them
one way or another.
Signed-off-by: Rusty Russell <rusty@au1.ibm.com>
git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio@318 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
|
|
Change accepted on VIRTIO TC Meeting, 3 December 2013
VIRTIO-64
Cc: Patrick Durusau <patrick@durusau.net
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio@303 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
|
|
Change accepted on VIRTIO TC Meeting, 3 December 2013
document that there are two conformance levels
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio@300 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
|
|
Now we have grouped all the normative statements, the conformance
clauses for drivers and devices can simply reference them.
Signed-off-by: Rusty Russell <rusty@au1.ibm.com>
git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio@278 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
|
|
We should make it clearer later, for now this should
be enough for the CSD 1.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio@131 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
|
|
I imported latex templates from the CMIS specifications
and changed s/CMIS/VIRTIO/ everywhere.
The result is very close to one produced by exporting from the
ODF we were supplied, with the exception of the TOC formatting,
where section numbers are in blue instead of black, and major
sections don't have dots leading to page numbers.
I'm guessing this isn't very important, someone with more latex
knowledge can try to figure this out.
Generating html doesn't actually work for me.
It doesn't work for me for CMIS either, so
it's probably just an issue with my local latex setup.
I'm not sure we need html output at all.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio@103 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
|