Code Monkey home page Code Monkey logo

virtio-spec's Introduction

README

Members of the OASIS Virtual I/O Device (VIRTIO) TC create and manage technical content in this TC GitHub repository ( https://github.com/oasis-tcs/virtio-spec ) as part of the TC's chartered work (i.e., the program of work and deliverables described in its charter).

OASIS TC GitHub repositories, as described in GitHub Repositories for OASIS TC Members' Chartered Work, are governed by the OASIS TC Process, IPR Policy, and other policies, similar to TC Wikis, TC JIRA issues tracking instances, TC SVN/Subversion repositories, etc. While they make use of public GitHub repositories, these TC GitHub repositories are distinct from OASIS Open Repositories, which are used for development of open source licensed content.

Description

This repository includes the authoritative source of the VIRTIO (Virtual I/O) Specification document. VIRTIO document describes the specifications of the "virtio" family of devices. These devices are found in virtual environments, yet by design they look like physical devices to the guest within the virtual machine โ€” and this document treats them as such. This similarity allows the guest to use standard drivers and discovery mechanisms.

The purpose of virtio and this specification is that virtual environments and guests should have a straightforward, efficient, standard and extensible mechanism for virtual devices, rather than boutique per-environment or per-OS mechanisms.

Contributions

As stated in this repository's CONTRIBUTING file, contributors to this repository are expected to be Members of the OASIS virtio TC, for any substantive change requests. Anyone wishing to contribute to this GitHub project and participate in the TC's technical activity is invited to join as an OASIS TC Member. Public feedback is also accepted, subject to the terms of the OASIS Feedback License.

Licensing

Please see the LICENSE file for description of the license terms and OASIS policies applicable to the TC's work in this GitHub project. Content in this repository is intended to be part of the virtio TC's permanent record of activity, visible and freely available for all to use, subject to applicable OASIS policies, as presented in the repository LICENSE file.

Further Description of this Repository

Building Instructions

Authoritative version of the specification is maintained in the TeX document format. PDF and HTML versions are made available for ease of use and review. In order to build the HTML and PDF versions of the spec you will need the TeX document production system. The easiest way to get it up and running is probably by installing Tex-Live.
Installation cheat sheet:
Fedora:
sudo dnf install texlive-scheme-full
Ubuntu and other Debian derivatives:
sudo apt-get install texlive-full
OSX:
OSX users don't need to install Tex-Live because they already have MacTeX installed.
The build process generates a ZIP package file including the original TeX sources, as well as HTML and PDF formatted versions of the specification.
To generate the ZIP package, run:
./makeall.sh
Troubleshooting notes:
PDFs of the specification can be generated with either MicroSoft's Core fonts for the Web: Arial and Courier New, or Liberation fonts: Liberation Sans and Liberation Mono. Most systems come with one of these two variants included: should you get an error message about missing fonts, you will need to downloads and install one of the above font packages.

Providing Feedback

Informal feedback is accepted through the virtio-comment mailing list, and is archived in the mailing list archives. To provide feedback, subscribe by sending mail to [email protected], then after confirming you agree to the IPR sending your feedback to [email protected].

Note that only plain text part of the message is archived, and all attachments are stripped. Accordingly, messages sent to the mailing list should use text/plain encoding and not have any attachments.

The preferred form of providing feedback is in form of a patch. A patch can be generated and sent by cloning the spec repository, creating a commit, formatting it as a patch and then sending it. For example:

git clone https://github.com/oasis-tcs/virtio-spec.git
... edit spec text, and save ...

git commit -a
... describe the proposed change, in the following format:
single line summary

detailed description, including motivation for the change

Signed-off-by: Name <email>
... then save and close the editor ...

git format-patch -o proposal1/ HEAD~1..
... generates a new directory proposal1/ and a file starting with 0001- ...

git send-email [email protected] proposal1/0001-*

When to use the virtio-comment mailing list:
questions and change proposals for the Virtio specification, including the specification of basic functionality, transports and devices.
When not to use the virtio-comment mailing list:
questions and change proposals for Virtio drivers and devices implementing the specification. (please use the virtio-dev mailing list for this).
To do:
send email preferably in text format (best for archiving).
Not to do:
  • copy both virtio-dev and virtio-comment mailing lists (instead, pick one);
  • send full copies of the virtio spec (in any format).

Note for TC Members

TC Members should review TC specific process rules under "Further Description of this Repository" in https://github.com/oasis-tcs/virtio-admin.

Implementation discussion

Implementation discussion takes place on the virtio-dev mailing list, and is archived in the mailing list archives. To participate in the discussion, subscribe by sending mail to [email protected]. After agreeing to the IPR, to participate in the discussion, send mail to [email protected].

This is the correct list to copy on Linux virtio UAPI change proposals.

Note that only the plain text part of the message is archived, and all attachments are stripped. Accordingly, messages sent to the mailing list should use text/plain encoding and not have any attachments.

When to use the virtio-dev mailing list:
questions and change proposals for Virtio drivers and devices implementing the specification.
When not to use the virtio-dev mailing list:
questions and change proposals for the Virtio specification, including the specification of basic functionality, transports and devices (please use the virtio-comment mailing list for this).
To do:
send email preferably in text format (best for archiving).
Not to do:
copy both virtio-dev and virtio-comment mailing lists (instead, pick one).

Use of github issues

Note: according to the virtio TC rules, all official TC communication is taking place on one of the TC mailing lists. In particular, all comments must be provided on one of the TC mailing lists. Accordingly, the TC will not respond to comments provided in github issues: github issues are used solely to track integration of comments into the specification.

To request a TC vote on resolving a specific comment:

  1. Create a github issue, or edit an existing issue, with a short summary of the comment. The issue MUST specify the link to the latest proposal in the TC mailing list archives. Note: the link MUST be in the issue description itself - not in the comments.
  2. Reply by email to the comment email, requesting that the TC vote on resolving the issue. The mail requesting the vote should include the following, on a line by itself:
    Fixes: https://github.com/oasis-tcs/virtio-spec/issues/NNN (NNN is the issue number)
  3. Please make sure to allow time for review between posting a comment and asking for a vote.

TC standing rules

The TC adopted the following standing rule:

Minor cleanups, including editorial formatting changes, spelling and typo fixes can be committed directly into git for approval as part of the next specification approval ballot.

  1. To request such a commit, reply by email to the comment email, requesting that the issue is resolved under the minor cleanups standing rule.
  2. Please make sure to allow time for review between posting a comment and asking for a commit.

Contact

Please send questions or comments about OASIS TC GitHub repositories to Robin Cover and Chet Ensign. For questions about content in this repository, please contact the TC Chair or Co-Chairs as listed on the the virtio TC's home page.

virtio-spec's People

Contributors

alvaro-karsz avatar bonzini avatar chenhao94 avatar cohuck avatar dagrh avatar davidhildenbrand avatar egranata avatar eugpermar avatar fengidri avatar gurchetansingh avatar halil-pasic avatar heneko-de avatar jan-kiszka avatar jpbrucker avatar kraxel avatar mgurtovoy avatar mstsirkin avatar nimisolo avatar paravmellanox avatar peter-hilber-at-opensynergy-dot-com avatar robincover avatar ssqre avatar stefanharh avatar stefano-garzarella avatar stsquad avatar vireshk avatar vmireyno-mvl avatar yang8621 avatar ybendito avatar ybettan avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

virtio-spec's Issues

vsock: add vsock device

The virtio vsock device is a zero-configuration socket communications
device. It is designed as a guest<->host management channel suitable
for communicating with guest agents.

vsock is designed with the sockets API in mind and the driver is
typically implemented as an address family (at the same level as
AF_INET). Applications written for the sockets API can be ported with
minimal changes (similar amount of effort as adding IPv6 support to an
IPv4 application).

Unlike the existing console device, which is also used for guest<->host
communication, multiple clients can connect to a server at the same time
over vsock. This limitation requires console-based users to arbitrate
access through a single client. In vsock they can connect directly and
do not have to synchronize with each other.

Unlike network devices, no configuration is necessary because the device
comes with its address in the configuration space.

The vsock device was prototyped by Gerd Hoffmann and Asias He. I picked
the code and design up from them.

https://lists.oasis-open.org/archives/virtio-dev/201811/msg00145.html

virtio network device: reserve feature bits used by production Windows driver

During previous activity of Windows virtio network adapter driver's certification the pilot implementation of Windows style RSC in device and driver is using feature bits 41 and 42 to activate RSC support.
Existing widely used production drivers check these bits and expect to receive packets with different size of the header if this feature is used.
In case one of these feature bits will be used by virtio network device for any purpose the driver will not function with such device.
The suggestion is to reserve these feature bits until updated driver with better, forward-compatible implementation of RSC support will replace the previous ones.

http://lists.oasis-open.org/archives/virtio-comment/201810/msg00010.html

Enhance device requirements for feature bits

Some guests might not resume properly from suspend a feature changes under their feet.
This applies to Linux guests and the SRIOV feature, offloads for the networking
device and highly likely to more devices and features.

Forbid devices from changing features even across a reset but keep
the door open for white-listing specific feature bits where we will know
what we are doing (e.g. the specific feature bit is re-sampled each time,
failure to resume is the intended behaviour etc).

https://lists.oasis-open.org/archives/virtio-dev/201806/msg00098.html

Various typos, grammar and cosmetic fixes

(1) Under: 2.6.12 Supplying Buffers to The Device
text: The driver performs suitable a memory barrier
fix: The driver performs a suitable memory barrier

(2) Under: 2.6.5.2 Driver Requirements: The Virtqueue Descriptor Table
text: Drivers MUST NOT add a descriptor chain over than 2^32 bytes long in total
fix : Drivers MUST NOT add a descriptor chain longer than 2^32 bytes in total

(3) under 2.7.5 Scatter-Gather Support
text: mixing direct and direct descriptors in a ring is valid,
fix: mixing indirect and non-indirect descriptors in a ring is valid

(4) under: 3.1.1 Driver Requirements: Device Initialization
text: Set the ACKNOWLEDGE status bit: the guest OS has notice the device
fix: Set the ACKNOWLEDGE status bit: the guest OS has noticed the device

(5) under 4.1.4.3 Common configuration structure layout
text: On reset, specifies the maximum queue size supported by the hypervisor. This
can be modified by driver to reduce memory requirements.
fix: On reset, specifies the maximum queue size supported by the device. This
can be modified by the driver to reduce memory requirements.

Fix proposed in patchset:
https://www.mail-archive.com/[email protected]/msg04008.html
the above is the cover note - patches themselves under:
https://www.mail-archive.com/[email protected]/msg04006.html
https://www.mail-archive.com/[email protected]/msg04007.html

virtio network device: define interface for steering control / RSS

In case of multiple queue pairs the spec currently defines only automatic/uncontrolled steering capability. In order to support RSS (receive side scaling) feature on VM and especially to let bare metal virtio device to use simpler steering mechanism, respective interface must be defined in the spec

Latest patch
https://lists.oasis-open.org/archives/virtio-comment/201911/msg00014.html
https://lists.oasis-open.org/archives/virtio-comment/201910/msg00039.html
https://lists.oasis-open.org/archives/virtio-comment/201910/msg00020.html
https://lists.oasis-open.org/archives/virtio-comment/201910/msg00001.html

Block Device: duplicated text in Legacy Interface: Framing Requirements

Reported-by: "Savir, Gil" [email protected]

In version 1.1 draft 01 - Section 5.2.6.4 - second bullet:

Duplicated text "errors, data_len, sense_len and residual MUST reside in a single, separate device-writable descriptor" appears
+both in the beginning and at the end of the 2nd sentence.

The original text:

  • For SCSI commands there are additional constraints. errors, data_len, sense_len and residual MUST reside in a single, separate
    +device-writable descriptor, sense MUST reside in a single separate devicewritable descriptor of size 96 bytes, and errors,
    +data_len, sense_len and residual MUST reside a single separate device-writable descriptor.

I suggest to delete the 1st one, so in the end result, fields are described in same order as appear in struct virtio_scsi_pc_req.

https://lists.oasis-open.org/archives/virtio/201903/msg00071.html

virtio: generalize io_barrier/platform_iommu

it isn't always clear to everyone when should device set
platform_iommu and when io_barrier.
for example, some platforms need tricks like flushing cache
and this is in practice already covered by platform_iommu.
Let's rename platform_iommu to access_platform
and make it clear that with this flag which memory
can be accessed and at what address is platform specific,
without this flag device acts same as CPU.

On the other hand, io_barriers is a confusing name as it is not clear
which operations are meant by an barrier - it is not
really the io that is ordered. Rename it to order_platform.
barriers is just one possible implementation of a driver
used to order accesses.

https://lists.oasis-open.org/archives/virtio/201811/msg00013.html

virtio ring features: inconsistent naming

Reported-by: Don Wallwork [email protected]

features like VIRTIO_F_EVENT_IDX and
VIRTIO_F_INDIRECT_DESC do not
appear in Linux kernel or QEMU code; VIRTIO_RING_F_EVENT_IDX and
VIRTIO_RING_F_INDIRECT_DESC
are used instead.

Also noticed that there seems to be an inconsistency in the spec in that
VIRTIO_F_EVENT_IDX is
used in some places and VIRTIO_F_RING_EVENT_IDX is used in others

https://lists.oasis-open.org/archives/virtio-comment/201902/msg00032.html

Proposed patch: https://lists.oasis-open.org/archives/virtio-comment/202105/msg00003.html

Clarifying section "2.6.12 virtqueue Operation" in virtio-v1.1

We'd like to propose clarifying the usage of packets and buffers in section "2.6.12 virtqueue operation" in the note part.

This is the current writing:

"Note: As an example, the simplest virtio network device has two virtqueues: the transmit virtqueue and the receive virtqueue. The driver adds outgoing (device-readable) packets to the transmit virtqueue, and then frees them after they are used. Similarly, incoming (device-writable) buffers are added to the receive virtqueue, and processed after they are used."

And this is the proposed writing:

"Note: As an example, the simplest virtio network device has two virtqueues: the transmit virtqueue and the receive virtqueue. The driver adds outgoing packets as device-readable buffers to the transmit virtqueue, and then frees them after they are used. Similarly, device-writable buffers for incoming packets are added to the receive virtqueue, and processed after they are used."

Add virtio IOMMU device specification

add packed ring layout support

This is a proposal to implement an alternative ring layout.
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 more efficient and easier for devices to implement than the 1.0 layout.

Additionally, a new feature flag is proposed that makes devices promise to process descriptors
in-order. With this feature drivers can also be made simpler and more efficient.

Discussion and performance analysis of this is in Michael Tsirkin's kvm forum 2016 and 2017 presentations.

Proposal: https://lists.oasis-open.org/archives/virtio/201803/msg00041.html

Note: should this proposal be accepted and approved, one or more
claims disclosed to the TC admin and listed on the Virtio TC
IPR page https://github.com/oasis-tcs/virtio-admin/blob/master/IPR.md
might become Essential Claims.

Typo in Virtqueue Used Ring description

In the Section titled "Virtqueue Used Ring" (currently 2.5.8), the text says:

idx field indicates where the driver would put the next descriptor entry in the ring...

Since this is the used ring, and is only supposed to be written by the device, the text should say

...where the device would put...

instead.

virtio network device: support for RSC compatibility with WHCK requirements

Currently virtio network device supports reassembly of received TCP segments, controlled by feature bits VIRTIO_NET_F_GUEST_TSO4 and VIRTIO_NET_F_GUEST_TSO6. This feature has a gap with Windows hardware compatibility requirements. In addition to packet reassembly it is required to coalesce duplicate ack packets and report number of coalesced segments and number of duplicate acks in the metadata of reported packet.
Suggested extension of network device specification includes additional feature bit (extended RSC support) and additional flag bit in virtio network packet header (extended RSC info) which allows to deliver required information in existing header's fields 'csum_start' and 'csum_offset'

http://lists.oasis-open.org/archives/virtio-comment/201810/msg00009.html

suggestion: split host and guest event index feature bits

Reported-by: "Savir, Gil" [email protected]

If VIRTIO_F_EVENT_IDX feature bit is negotiated, then Available Buffer
Notification Suppression mechanism used is avail event (not flags).

The spec (both v1.0 / v1.1-draft) states that the device MAY use this mechanism
(Paragraph 2.4.9.2 / 2.6.10.2 respectively).

However, if split ring is in use, and if VIRTIO_F_EVENT_IDX has been negotiated,
then the device that never updates the index value in the available event suppression
structure would never get notifications until index wraps around.

Proposal is to split VIRTIO_F_EVENT_IDX into (say) VIRTIO_F_GUEST_EVENT_IDX and VIRTIO_F_HOST_EVENT_IDX, such that used_event and avail_event usage will be independent.

https://lists.oasis-open.org/archives/virtio-comment/201901/msg00021.html

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.