没有合适的资源?快使用搜索试试~ 我知道了~
资源推荐
资源详情
资源评论
Virtio PCI Card Specication
v0.9.5 DRAFT
-
Rusty Russell <rusty@rustcorp.com.au> IBM Corporation (Editor)
2012 May 7.
Chapter 1
Purpose and Description
This document describes the specications of the virtio family of
PCI
de-
vices. These are devices are found in
virtual environments
, yet by design they
are not all that dierent from physical PCI devices, and this document treats
them as such. This allows the guest to use standard PCI drivers and discovery
mechanisms.
The purpose of virtio and this specication is that virtual environments and
guests should have a straightforward, ecient, standard and extensible mecha-
nism for virtual devices, rather than boutique per-environment or per-OS mech-
anisms.
Straightforward:
Virtio PCI devices use normal PCI mechanisms of inter-
rupts and DMA which should be familiar to any device driver author.
There is no exotic page-ipping or COW mechanism: it's just a PCI de-
vice.
1
Ecient:
Virtio PCI devices consist of rings of descriptors for input and out-
put, which are neatly separated to avoid cache eects from both guest and
device writing to the same cache lines.
Standard:
Virtio PCI makes no assumptions about the environment in which
it operates, beyond supporting PCI. In fact the virtio devices specied in
the appendices do not require PCI at all: they have been implemented on
non-PCI buses.
2
1
This lack of page-sharing implies that the implementation of the device (e.g. the hyper-
visor or host) needs full access to the guest memory. Communication with untrusted parties
(i.e. inter-guest communication) requires copying.
2
The Linux implementation further separates the PCI virtio code from the specic virtio
drivers: these drivers are shared with the non-PCI implementations (currently lguest and
S/390).
1
Extensible:
Virtio PCI devices contain feature bits which are acknowledged
by the guest operating system during device setup. This allows forwards
and backwards compatibility: the device oers all the features it knows
about, and the driver acknowledges those it understands and wishes to
use.
1.1 Virtqueues
The mechanism for bulk data transport on virtio PCI devices is pretentiously
called a virtqueue. Each device can have zero or more virtqueues: for example,
the network device has one for transmit and one for receive.
Each virtqueue occupies two or more physically-contiguous pages (dened, for
the purposes of this specication, as 4096 bytes), and consists of three parts:
Descriptor Table Available Ring
(padding)
Used Ring
When the driver wants to send a buer to the device, it lls in a slot in the
descriptor table (or chains several together), and writes the descriptor index
into the available ring. It then noties the device. When the device has nished
a buer, it writes the descriptor into the used ring, and sends an interrupt.
2
Chapter 2
Specication
2.1 PCI Discovery
Any PCI device with Vendor ID 0x1AF4, and Device ID 0x1000 through 0x103F
inclusive is a virtio device
1
. The device must also have a Revision ID of 0 to
match this specication.
The Subsystem Device ID indicates which virtio device is supported by the
device. The Subsystem Vendor ID should reect the PCI Vendor ID of the
environment (it's currently only used for informational purposes by the guest).
Subsystem Device ID Virtio Device Specication
1 network card Appendix C
2 block device Appendix D
3 console Appendix E
4 entropy source Appendix F
5 memory ballooning Appendix G
6 ioMemory -
7 rpmsg Appendix H
8 SCSI host Appendix I
9 9P transport -
10 mac80211 wlan -
2.2 Device Conguration
To congure the device, we use the rst I/O region of the PCI device. This
contains a
virtio header
followed by a
device-specic region.
1
The actual value within this range is ignored
3
There may be dierent widths of accesses to the I/O region; the natural access
method for each eld in the virtio header must be used (i.e. 32-bit accesses for
32-bit elds, etc), but the device-specic region can be accessed using any width
accesses, and should obtain the same results.
Note that this is possible because while the virtio header is PCI (i.e. little)
endian, the device-specic region is encoded in the native endian of the guest
(where such distinction is applicable).
2.2.1 Device Initialization Sequence
We start with an overview of device initialization, then expand on the details
of the device and how each step is preformed.
1. Reset the device. This is not required on initial start up.
2. The ACKNOWLEDGE status bit is set: we have noticed the device.
3. The DRIVER status bit is set: we know how to drive the device.
4. Device-specic setup, including reading the Device Feature Bits, discov-
ery of virtqueues for the device, optional MSI-X setup, and reading and
possibly writing the virtio conguration space.
5. The subset of Device Feature Bits understood by the driver is written to
the device.
6. The DRIVER_OK status bit is set.
7. The device can now be used (ie. buers added to the virtqueues)
2
If any of these steps go irrecoverably wrong, the guest should set the FAILED
status bit to indicate that it has given up on the device (it can reset the device
later to restart if desired).
We now cover the elds required for general setup in detail.
2.2.2 Virtio Header
The virtio header looks as follows:
Bits 32 32 32 16 16 16 8 8
Read/Write R R+W R+W R R+W R+W R+W R
Purpose
Device Guest Queue Queue Queue Queue Device ISR
Features bits 0:31 Features bits 0:31 Address Size Select Notify Status Status
2
Historically, drivers have used the device before steps 5 and 6. This is only allowed if the
driver does not use any features which would alter this early use of the device.
4
剩余61页未读,继续阅读
资源评论
commonyun163
- 粉丝: 0
- 资源: 1
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功