summaryrefslogtreecommitdiff
path: root/content.tex
AgeCommit message (Collapse)Author
2018-06-07content: support SR-IOVHEADmasterTiwei Bie
Allocate a feature bit for virtio devices which support SR-IOV. Note: at proposer's request, driver requirements have been omitted - a reworked version is now being discussed. Suggested-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Tiwei Bie <tiwei.bie@intel.com> Fixes: https://github.com/oasis-tcs/virtio-spec/issues/11 Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Cornelia Huck <cohuck@redhat.com>
2018-05-23VIRTIO_F_IO_BARRIER: use I/O barriers in driverTiwei Bie
There will be hardware virtio devices in the future, which require drivers to use the barriers suitable for I/O devices, compared with software virtio devices which just require drivers to use the barriers suitable for CPU cores. To fix the ordering issue for hardware virtio devices, add a new feature: VIRTIO_F_IO_BARRIER. When negotiated, driver will use the barriers suitable for I/O devices. Fixes: https://github.com/oasis-tcs/virtio-spec/issues/10 Signed-off-by: Tiwei Bie <tiwei.bie@intel.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
2018-05-23content: document hugetlb page allocation countsJonathan Helman
The Linux kernel exports the number of successful and failed hugetlb page allocations via the virtio balloon driver. These two counts need to be documented in this specification. Fixes: https://github.com/oasis-tcs/virtio-spec/issues/8 Signed-off-by: Jonathan Helman <jonathan.helman@oracle.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2018-04-26Revert "VIRTIO_F_NOTIFICATION_DATA: extra data to devices"Michael S. Tsirkin
This reverts commit 396b1957817e0bd14697e28d9fe61bfc80f1350f. Was pushed by mistake. Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2018-03-27VIRTIO_F_NOTIFICATION_DATA: extra data to devicesMichael S. Tsirkin
Some devices benefit from ability to find out the number of available descriptors in the ring: for efficiency or as a debugging aid. To help with these optimizations, add a new feature: VIRTIO_F_NOTIFICATION_DATA. When negotiated, driver notifications to the device include this extra information. Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2018-03-20virtio-net: Add missing flag define to structsameehj
The flag VIRTIO_NET_HDR_F_DATA_VALID is aleady mentioned in the virtio-net spec however it is not defined in the struct. This flag is already defined and used in virtio-net device in Qemu as well as some of it's drivers. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Fixes: https://github.com/oasis-tcs/virtio-spec/issues/6 Approved-by: https://www.oasis-open.org/apps/org/workgroup/virtio/ballot.php?id=3182
2018-03-20content: document balloon memory statisticsTomáš Golembiovský
Linux kernel provides some balloon memory statistics that were not included in the specs. Include them to avoid any ID clashes in the future. Signed-off-by: Tomáš Golembiovský <tgolembi@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Fixes: https://github.com/oasis-tcs/virtio-spec/issues/4 Approved-by: https://www.oasis-open.org/apps/org/workgroup/virtio/ballot.php?id=3180
2018-03-20virtio-blk: add discard and write zeroes features to specificationChangpeng Liu
Existing virtio-blk protocol doesn't have DISCARD/WRITE ZEROES support, this will impact the performance when using SSD backend over file systems. Here is the proposal to extend existing virtio-blk protocol to support DISCARD/WRITE ZEROES commands. Basic idea here is using 16 Bytes payload to support 1 descriptor, users can put several segments together with 1 DISCARD/WRITE ZEROES command. struct virtio_blk_discard_write_zeroes { le64 sector; le32 num_sectors; struct { le32 unmap:1; le32 reserved:31; } flags; }; For the purpose to support such feature, we need to introduce 2 new feature flags: VIRTIO_BLK_F_DISCARD/VIRTIO_BLK_F_WRITE_ZEROES, and 2 new command types: VIRTIO_BLK_T_DISCARD/VIRTIO_BLK_T_WRITE_ZEROES. Also we introduce several new parameters in the configuration space of virtio-blk: max_discard_sectors/max_discard_seg/max_write_zeroes_sectors. These parameters will tell the OS what's the granularity when issuing such commands. If both DISCARD and WRITE ZEROES are supported, unmap flag bit maybe used for WRITE ZEROES command with DISCARD bit enabled. Signed-off-by: Changpeng Liu <changpeng.liu@intel.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Approved-by: https://www.oasis-open.org/apps/org/workgroup/virtio/ballot.php?id=3181 Fixes: https://github.com/oasis-tcs/virtio-spec/issues/5
2018-03-20content: in-order buffer useMichael S. Tsirkin
Using descriptors in-order is sometimes beneficial. Add an option for that - per-format detail allowing more optimizations will be added by follow-up patches. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Approved-by: https://www.oasis-open.org/apps/org/workgroup/virtio/ballot.php?id=3177 Fixes: https://github.com/oasis-tcs/virtio-spec/issues/3
2018-03-20packed virtqueues: more efficient virtqueue layoutMichael S. Tsirkin
Performance analysis of this is in my kvm forum 2016 presentation. The idea is to have a r/w descriptor in a ring structure, replacing the used and available ring, index and descriptor buffer. This is also easier for devices to implement than the 1.0 layout. Several more enhancements will be necessary to actually make this efficient for devices to use. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Cornelia Huck <cohuck@redhat.com> Approved-by: https://www.oasis-open.org/apps/org/workgroup/virtio/ballot.php?id=3177 Fixes: https://github.com/oasis-tcs/virtio-spec/issues/3
2018-03-20split-ring: generalize textMichael S. Tsirkin
Update generic text to talk about available/used buffers, not rings. Move some split-ring specific text to the correct section. Update conformance section with link to the new conformance clause. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Approved-by: https://www.oasis-open.org/apps/org/workgroup/virtio/ballot.php?id=3177 Fixes: https://github.com/oasis-tcs/virtio-spec/issues/3
2018-03-20content: generalize rest of textMichael S. Tsirkin
Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Approved-by: https://www.oasis-open.org/apps/org/workgroup/virtio/ballot.php?id=3177 Fixes: https://github.com/oasis-tcs/virtio-spec/issues/3
2018-03-20content: generalize transport ring part namingMichael S. Tsirkin
Replace descriptor table/available ring/used ring with descriptor area/driver area/device area in all transports. Document what's in which area. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Approved-by: https://www.oasis-open.org/apps/org/workgroup/virtio/ballot.php?id=3177 Fixes: https://github.com/oasis-tcs/virtio-spec/issues/3
2018-03-20content: len -> used length, used ring -> vqMichael S. Tsirkin
Document buffer used len and use that terminology everywhere in the generic section. Further, drop the 'used ring' terminology and just say virtqueue. Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Approved-by: https://www.oasis-open.org/apps/org/workgroup/virtio/ballot.php?id=3177 Fixes: https://github.com/oasis-tcs/virtio-spec/issues/3
2018-03-20content: move virtqueue operation descriptionMichael S. Tsirkin
virtqueue operation description is specific to the virtqueue format. Move it out to split-ring.tex and update all references. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Approved-by: https://www.oasis-open.org/apps/org/workgroup/virtio/ballot.php?id=3177 Fixes: https://github.com/oasis-tcs/virtio-spec/issues/3
2018-03-20content: move ring text out to a separate fileMichael S. Tsirkin
Will be easier to manage this way. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Approved-by: https://www.oasis-open.org/apps/org/workgroup/virtio/ballot.php?id=3177 Fixes: https://github.com/oasis-tcs/virtio-spec/issues/3
2018-03-20content: move 1.0 queue format out to a separate sectionMichael S. Tsirkin
Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Approved-by: https://www.oasis-open.org/apps/org/workgroup/virtio/ballot.php?id=3177 Fixes: https://github.com/oasis-tcs/virtio-spec/issues/3
2018-03-09virtio-scsi: fix typosPaolo Bonzini
Fixes: VIRTIO-155 Approved-by: https://www.oasis-open.org/apps/org/workgroup/virtio/ballot.php?id=3118 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-12-12content: reserve virtio device ID for IOMMUJean-Philippe Brucker
Reserve device ID 23 for virtio-iommu devices. Resolved VIRTIO-162 Approved https://www.oasis-open.org/apps/org/workgroup/virtio/ballot.php?id=3155 Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-09-11net: relax buf size requirements for mrg buffersMichael S. Tsirkin
VIRTIO-84 added a requirement that each buffer is > header size but there's no reason to require that for merge-able buffers since data can be placed in follow-up buffers. The current wording seems confusing enough that it seems likely no one relies on this. VIRTIO-159 Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <1490654778-11857-1-git-send-email-mst@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2017-09-11net: clarify device rules for mergeable buffersMichael S. Tsirkin
The idea behind mergeable buffers was to simply use them in a way similar to a chain of descriptors. Unfortunately the current text does not say so - apparently nothing says device can't spread a packet over as many buffers as it likes - but this didn't prevent drivers from relying on buffers being used as a chain of descriptors, completely - and blindly accessing it without checking the length at least for the packet header. Let's just make the spec match this reality - if devices ever want more flexibility, we can add a feature bit. Further, correct all misuses of a "descriptor" to "buffer" as that is the entity that is being merged. VIRTIO-160 Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <1490655576-12173-1-git-send-email-mst@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2017-09-08virtio-net: fix virtqueue numbering errorCornelia Huck
receiveq(n) is at position 2(n-1), not 2n. Same error for transmitq(n) and controlq. VIRTIO-161 Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Halil Pasic <pasic@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2017-01-10context: Document VIRTIO_F_IOMMU_PLATFORM reserved feature bit (33)mstsirkin
On most virtio systems, physical addresses are provided from the driver to the device and subsequently used to access memory directly. However, some systems feature an IOMMU that complicates things slightly: - The IOMMU might require configuration for DMA to work at all. Once configured, the driver must pass bus addresses to the device, which are then translated by the IOMMU into physical addresses in memory. - The IOMMU might be bypassed by virtio DMA. In this case, physical addresses must still be provided to the device by the driver, even though an IOMMU appears to be present. This has been solved by the addition of a new reserved feature bit, VIRTIO_F_IOMMU_PLATFORM, to describe the two cases above. Legacy systems will not negotiate the feature, and therefore continue to operate directly on physical addresses. VIRTIO-154 Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Will Deacon <will.deacon@arm.com> git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio/trunk@587 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
2016-10-11virtio-net: add Max MTU configuration fieldmstsirkin
It is helpful for a host to indicate it's MTU to be set on guest NICs other than the assumed 1500 byte value. This helps in situations where the host network is using Jumbo Frames, or aiding in PMTU discovery by configuring a homogenous network. It is also helpful for sizing receive buffers correctly. The change adds a new field to configuration area of network devices. It will be used to pass a maximum MTU from the device to the driver. This will be used by the driver as a maximum value for packet sizes during transmission, without segmentation offloading. In addition, in order to support backward and forward compatibility, we introduce a new feature bit called VIRTIO_NET_F_MTU. VIRTIO-152 Signed-off-by: Aaron Conole <aconole@redhat.com> Cc: Victor Kaplansky <victork@redhat.com> Reviewed-by: Hannes Reiencke <hare@suse.de> Acked-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Maxime Coquelin <maxime.coquelin@redhat.com> Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio/trunk@585 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
2016-10-10content: Reserve virtio device ID for pstoremstsirkin
This patch just reserve next available device ID for pstore device type. The device specification for pstore will come later. VIRTIO-150 Signed-off-by: Namhyung Kim <namhyung@kernel.org> Message-Id: <1468941217-12904-1-git-send-email-namhyung@gmail.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com> git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio/trunk@583 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
2016-10-10content: reserve virtio device ID for sdmmstsirkin
VIRTIO-149 Signed-off-by: Christian Pinto <c.pinto@virtualopensystems.com> Signed-off-by: Baptiste Reynal <b.reynal@virtualopensystems.com> Message-Id: <1467111824-11548-2-git-send-email-c.pinto@virtualopensystems.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com> git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio/trunk@582 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
2016-10-10virtio: reserve device id for virtio cryptomstsirkin
Reserve a device ID for virtio crypto device to avoid collisions with other new virtio devices. Because 19 had been reserved for virtio socket device, I'd like to reserve 20 for crypto device. VIRTIO-148 Suggested-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Gonglei <arei.gonglei@huawei.com> Message-Id: <1460685060-5904-1-git-send-email-arei.gonglei@huawei.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com> git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio/trunk@581 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
2016-10-10vsock: reserve device IDmstsirkin
Add a device ID for the Socket device. The draft specification is currently under review but it helps to reserve the ID to avoid collisions with other new virtio devices. VIRTIO-147 Suggested-by: Ian Campbell <ian.campbell@docker.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <1458729661-7514-1-git-send-email-stefanha@redhat.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com> git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio/trunk@580 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
2016-10-10ccw: add CCW_CMD_READ_STATUSmstsirkin
ccw currently allows the driver to update the status via the CCW_CMD_WRITE_STATUS command; however, it does not allow the driver to retrieve the current status at the device, which is needed to properly support DEVICE_NEEDS_RESET. Therefore, provide a new command CCW_CMD_READ_STATUS allowing the driver to retrieve the device status. Provide this command when revision 2 has been negotiated. VIRTIO-117 Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com> Message-Id: <1445243513-2263-2-git-send-email-cornelia.huck@de.ibm.com> git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio/trunk@579 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
2016-02-16init: sort status bitsmstsirkin
Status bit order is inconsistent: they are neither in increasing order nor in the order they are likely to be used. The second approach seems more useful since there aren't that many bits, so the numerical order does not help much. A typical order of use would be: ACKNOWLEDGE DRIVER then either FAILED or FEATURES_OK then either FAILED or DRIVER_OK then DEVICE_NEEDS_RESET (if device detects an error) Sort the bits accordingly. Reported-by: Kevin Lo <kevlo@kevlo.org> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio/branches/v1.0@559 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
2016-02-16virtio-ring.h -> virtio-queue.hmstsirkin
Since vring* and VRING* have been replaced with virtq* and VIRTQ* respectively, rename the header virtio_ring.h to virtio_queue.h. Suggested-by: Kevin Lo <kevlo@kevlo.org> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio/branches/v1.0@558 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
2016-02-16virtio header: tweak change motivationmstsirkin
The changes are not just to remove Linux assumptions, we have also renamed ring->queue. Tweak the header description accordingly. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio/branches/v1.0@555 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
2016-02-16virtio-net: fix inconsistent legacy header sizemstsirkin
Current text says: The legacy driver only presented num_buffers in the struct virtio_net_hdr when VIRTIO_NET_F_MRG_RXBUF was not negotiated; Should be: "... was negotiated ..." instead of "... was not negotiated ..." To be consistent with the following: without that feature the structure was 2 bytes shorter. Reported-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio/branches/v1.0@554 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
2015-10-21pci: clarify configuration access capability rulesmstsirkin
The point of the configuration access capability is to enable access to other capabilities. The intent never was to allow writes to a random place within device BARs. Limiting drivers simplifies devices - and devices can always add another capability if drivers ever want to access some other range. This resolves VIRTIO-145. Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Accepted by electronic ballot: https://www.oasis-open.org/apps/org/workgroup/virtio/ballot.php?id=2865 git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio/branches/v1.0@547 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
2015-10-21virtio-blk: restore VIRTIO_BLK_F_FLUSH and VIRTIO_BLK_F_CONFIG_WCEmstsirkin
VIRTIO_BLK_F_CONFIG_WCE is important in order to achieve good performance (up to 2x, though more realistically +30-40%) in latency-bound workloads. However, it was removed by mistake together with VIRTIO_BLK_F_FLUSH. In addition, even removing VIRTIO_BLK_F_FLUSH was probably not a great idea, because it simplifies simple drivers (e.g. firmware) that are okay with a writethrough cache but still need data to persist after power loss. What really should have been removed is just the possibility that devices not propose VIRTIO_BLK_F_FLUSH, but even that only deserves a "SHOULD" in the new world of conformance statements. Restore these, with the following changes: * clarify and use conformance statements in order to define writeback and writethrough caching according to what is commonly done by high-end storage. * clarify (with conformance statements) the influence of the VIRTIO_BLK_F_FLUSH feature on caching and how to proceed if only one of VIRTIO_BLK_F_FLUSH and VIRTIO_BLK_F_CONFIG_WCE is negotiated. * strengthen the requirement for persisting writes to MUST after a VIRTIO_BLK_T_FLUSH request (and in other cases too involving the new features). The suggested behavior upon feature negotiation is okay for the Linux implementation of virtio1, even after the implementation is modified to support the two new features. This fixes VIRTIO-144. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Accepted by electronic ballot: https://www.oasis-open.org/apps/org/workgroup/virtio/ballot.php?id=2864 Signed-off-by: Michael S. Tsirkin <mst@redhat.com> git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio/branches/v1.0@546 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
2015-10-11virtio-blk: flush: Fix driver vs. device typomstsirkin
This is a simple non-material change. Signed-off-by: Paolo Bonzini <pbonzini@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@542 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
2015-10-11virtio-blk: fix typo in legacy framing requirements sectionmstsirkin
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio/branches/v1.0@541 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
2015-10-11virtqueues: fix trivial typomstsirkin
Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.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@540 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
2015-05-21content: replace \\note with note environmentmstsirkin
\\note just before start of subsection seems to confuse latex, resulting in incorrect text alignment. Replace with \begin{note} \end{note}. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio/branches/v1.0@532 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
2015-05-18network device: document VIRTIO_NET_F_CTRL_RX_EXTRAmstsirkin
VIRTIO-124 Signed-off-by: Michael S. Tsirkin <mst@redhat.com> git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio/branches/v1.0@529 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
2015-05-18network device: xmit/receive cleanupmstsirkin
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
2015-05-18balloon: document deflate on oommstsirkin
Document the new option, and also clarify behaviour without it. In particular, I noticed that actual field is not the actual number of pages in the balloon as driver might do inflate followed by deflate. Also, device isn't always driven by interrupts, driver can inflate/deflate in response to e.g. memory compaction. VIRTIO-126 Signed-off-by: Michael S. Tsirkin <mst@redhat.com> git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio/branches/v1.0@527 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
2015-05-18balloon: transitional device supportmstsirkin
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
2015-04-29entropy device: typo fixmstsirkin
The driver MUST examine the length written by the driver makes no sense. length is written by the device. VIRTIO-142 Signed-off-by: Michael S. Tsirkin <mst@redhat.com> git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio/branches/v1.0@523 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
2015-04-29used ring: specify legacy behaviour for len fieldmstsirkin
many hypervisors implemented len field incorrectly. Document existing bugs in the legacy sections. VIRTIO-141 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Cc: Paolo Bonzini <pbonzini@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@522 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
2015-04-29VIRTIO-134: Spell out details of indirect elements in chainsmstsirkin
1) It's implied that a chain terminates with an indirect descriptor (since VIRTIO-15) but we didn't spell out that a device MUST NOT continue it. 2) We allow [direct]->[direct]->[indirect], and qemu and bhyve both accept it. Make it clear that this is valid, thus devices MUST handle it. 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@521 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
2015-04-22balloon: MUST -> has tomstsirkin
MUST shouldn't be used outside normative statements, that's confusing. Replace with "has to". Signed-off-by: Michael S. Tsirkin <mst@redhat.com> git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio/branches/v1.0@509 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
2015-04-22pci: missing documentation for dealing with 64 bit config fieldsmstsirkin
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
2015-04-22mark diff for non-transitional with legacymstsirkin
latexdiff doesn't handle changing labels well, causes latex unresolved reference errors. opencode and mark up diff manually. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio/branches/v1.0@507 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
2015-04-22multiple errors: Non-transitional With Legacymstsirkin
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. VIRTIO-138 Signed-off-by: Michael S. Tsirkin <mst@redhat.com> git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio/branches/v1.0@506 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-18 06:22:08 +0000