summaryrefslogtreecommitdiff
path: root/introduction.tex
diff options
context:
space:
mode:
Diffstat (limited to 'introduction.tex')
-rw-r--r--introduction.tex161
1 files changed, 161 insertions, 0 deletions
diff --git a/introduction.tex b/introduction.tex
new file mode 100644
index 0000000..979881e
--- /dev/null
+++ b/introduction.tex
@@ -0,0 +1,161 @@
+\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{Normative References}
+
+\begin{longtable}{l p{5in}}
+ \phantomsection\label{intro:rfc2119}\textbf{[RFC2119]} &
+Bradner S., ``Key words for use in RFCs to Indicate Requirement
+Levels'', BCP 14, RFC 2119, March 1997. \newline\url{http://www.ietf.org/rfc/rfc2119.txt}\\
+ \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: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{Non-Normative References}
+
+\begin{longtable}{l p{5in}}
+ \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}\\
+\end{longtable}
+
+\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]}.
+
+\subsection{Legacy Interface: Terminology}\label{intro:Legacy
+Interface: Terminology}
+
+Earlier drafts of this specification (i.e. revisions before 1.0,
+see e.g. \hyperref[intro:Virtio PCI Draft]{[Virtio PCI Draft]})
+defined a similar, but different
+interface between the driver and the device.
+Since these are widely deployed, this specification
+accommodates OPTIONAL features to simplify transition
+from these earlier draft interfaces.
+
+Specifically devices and drivers MAY support:
+\begin{description}
+\item[Legacy Interface]
+ is an interface specified by an earlier draft of this specification
+ (before 1.0)
+\item[Legacy Device]
+ is a device implemented before this specification was released,
+ and implementing a legacy interface on the host side
+\item[Legacy Driver]
+ is a driver implemented before this specification was released,
+ and implementing a legacy interface on the guest side
+\end{description}
+
+Legacy devices and legacy drivers are not compliant with this
+specification.
+
+To simplify transition from these earlier draft interfaces,
+a device MAY implement:
+
+\begin{description}
+\item[Transitional Device]
+ a device supporting both drivers conforming to this
+ specification, and allowing legacy drivers.
+\end{description}
+
+Similarly, a driver MAY implement:
+\begin{description}
+\item[Transitional Driver]
+ a driver supporting both devices conforming to this
+ specification, and legacy devices.
+\end{description}
+
+\begin{note}
+ Legacy interfaces are not required; ie. don't implement them unless you
+ have a need for backwards compatibility!
+\end{note}
+
+Devices or drivers with no legacy compatibility are referred to as
+non-transitional devices and drivers, respectively.
+
+\subsection{Transition from earlier specification drafts}\label{sec:Transition from earlier specification drafts}
+
+For devices and drivers already implementing the legacy
+interface, some changes will have to be made to support this
+specification.
+
+In this case, it might be beneficial for the reader to focus on
+sections tagged "Legacy Interface" in the section title.
+These highlight the changes made since the earlier drafts.
+
+\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
+