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
|
\chapter{Introduction}
\input{abstract.tex}
\begin{description}
\item[Straightforward:] Virtio devices use normal bus mechanisms of
interrupts and DMA which should be familiar to any device driver
author. There is no exotic page-flipping or COW mechanism: it's just
a normal device.\footnote{This lack of page-sharing implies that the implementation of the
device (e.g. the hypervisor or host) needs full access to the
guest memory. Communication with untrusted parties (i.e.
inter-guest communication) requires copying.
}
\item[Efficient:] Virtio devices consist of rings of descriptors
for both input and output, which are neatly laid out to avoid cache
effects from both driver and device writing to the same cache
lines.
\item[Standard:] Virtio makes no assumptions about the environment in which
it operates, beyond supporting the bus to which device is attached.
In this specification, virtio
devices are implemented over MMIO, Channel I/O and PCI bus transports
\footnote{The Linux implementation further separates the virtio
transport code from the specific virtio drivers: these drivers are shared
between different transports.
}, earlier drafts
have been implemented on other buses not included here.
\item[Extensible:] Virtio devices contain feature bits which are
acknowledged by the guest operating system during device setup.
This allows forwards and backwards compatibility: the device
offers all the features it knows about, and the driver
acknowledges those it understands and wishes to use.
\end{description}
\section{Terminology}\label{Terminology}
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in \hyperref[intro:rfc2119]{[RFC2119]}.
An older specification (see \hyperref[intro:Virtio PCI Draft]{[Virtio PCI Draft]}) defined a
similar, but different interface between the hypervisor and the guest.
To simplify transition and note differences, the following terms are used:
\begin{description}
\item[Legacy Interface]
An interface specified by \hyperref[intro:Virtio PCI Draft]{[Virtio PCI Draft]}.
\item[Legacy Device]
A device which implements \hyperref[intro:Virtio PCI Draft]{[Virtio PCI Draft]}, but not this specification.
\item[Legacy Driver]
A driver which implements \hyperref[intro:Virtio PCI Draft]{[Virtio PCI Draft]}, but not this specification.
\item[Transitional Device]
A device which implements both this specification and the older
\hyperref[intro:Virtio PCI Draft]{[Virtio PCI Draft]}
specification, thus allowing legacy drivers.
\item[Transitional Driver]
A driver which implements both this specification and the older
\hyperref[intro:Virtio PCI Draft]{[Virtio PCI Draft]}
specification, thus allowing legacy devices.
\item[Non-Transitional Device]
A device which does not implement the
\hyperref[intro:Virtio PCI Draft]{[Virtio PCI Draft]} specification.
\item[Non-Transitional Driver]
A driver which does not implement the
\hyperref[intro:Virtio PCI Draft]{[Virtio PCI Draft]} specification.
\end{description}
\section{Normative References}
\begin{longtable}{l p{5in}}
\phantomsection\label{intro:rfc2119}\textbf{[RFC2119]} & S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, \newline\url{http://www.ietf.org/rfc/rfc2119.txt}, March 1997\\
\phantomsection\label{intro:S390 PoP}\textbf{[S390 PoP]} & z/Architecture Principles of Operation, IBM Publication SA22-7832, \newline\url{http://publibfi.boulder.ibm.com/epubs/pdf/dz9zr009.pdf}, and any future revisions\\
\phantomsection\label{intro:S390 Common I/O}\textbf{[S390 Common I/O]} & ESA/390 Common I/O-Device and Self-Description, IBM Publication SA22-7204, \newline\url{http://publibfp.dhe.ibm.com/cgi-bin/bookmgr/BOOKS/dz9ar501/CCONTENTS}, and any future revisions\\
\phantomsection\label{intro:PCI}\textbf{[PCI]} &
Conventional PCI Specifications,
\newline\url{http://www.pcisig.com/specifications/conventional/},
PCI-SIG\\
\phantomsection\label{intro:PCIe}\textbf{[PCIe]} &
PCI Express Specifications
\newline\url{http://www.pcisig.com/specifications/pciexpress/},
PCI-SIG\\
\phantomsection\label{intro:Virtio PCI Draft}\textbf{[Virtio PCI Draft]} &
Virtio PCI Draft Specification
\newline\url{http://ozlabs.org/~rusty/virtio-spec/virtio-0.9.5.pdf}\\
\phantomsection\label{intro:IEEE 802}\textbf{[IEEE 802]} &
IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture,
\newline\url{http://standards.ieee.org/about/get/802/802.html},
IEEE\\
\phantomsection\label{intro:SAM}\textbf{[SAM]} &
SCSI Architectural Model,
\newline\url{http://www.t10.org/cgi-bin/ac.pl?t=f&f=sam4r05.pdf}\\
\phantomsection\label{intro:SCSI MMC}\textbf{[SCSI MMC]} &
SCSI Multimedia Commands,
\newline\url{http://www.t10.org/cgi-bin/ac.pl?t=f&f=mmc6r00.pdf}\\
\end{longtable}
\section{Structure Specifications}
Many device and driver in-memory structure layouts are documented using
the C struct syntax. All structures are assumed to be without additional
padding. To stress this, cases where common C compilers are known to insert
extra padding within structures are tagged using the GNU C
__attribute__((packed)) syntax.
For the integer data types used in the structure definitions, the following
conventions are used:
\begin{description}
\item[u8, u16, u32, u64] An unsigned integer of the specified length in bits.
\item[le16, le32, le64] An unsigned integer of the specified length in bits,
in little-endian byte order.
\item[be16, be32, be64] An unsigned integer of the specified length in bits,
in big-endian byte order.
\end{description}
\newpage
|
