virtio-v1.1技术规范草案：OASIS VIRTIO TC发布

virtio

需积分: 5 57 浏览量更新于2024-06-30 收藏 679KB PDF 举报

身份认证购VIP最低享 7 折!

30元优惠券

Virtio (Virtual I/O Device) 是一种轻量级、高效和标准的设备模型，用于虚拟化环境中的设备通信。版本1.1是该技术的一个重要里程碑，标志着OASIS Virtual I/O Device (VIRTIO) TC（标准化组织）对此进行了公共审查草案01（CSRPD01）的更新。这份规范于2018年12月20日发布，其目的是提供一个简洁、可移植且低开销的I/O解决方案，特别适合云计算和嵌入式系统。 Virtio 1.1的修订稿包含了对原有1.0版本的改进和扩展，旨在提升性能和兼容性。它定义了通用的I/O请求接口，使得虚拟机可以直接与硬件进行通信，减少了虚拟机到宿主机之间的I/O瓶颈。该规范的作者是Michael Tsirkin和Cornelia Huck，来自Red Hat，他们是技术委员会的主要贡献者和编辑。在Virtio 1.1的文档中，包括了一份详细的司机列表，这些列表展示了如何实现和使用Virtio驱动程序，这对于开发人员理解和实现Virtio驱动至关重要。此外，该规范还指出了与之前版本的差异以及可能的替代或超集关系，即Virtio 1.1旨在取代或超越1.0版本。作为一项开放标准，Virtio 1.1允许不同的硬件厂商和操作系统开发商遵循统一的规范，从而促进硬件和软件之间的互操作性。它适用于多种应用场景，如KVM（Kernel-based Virtual Machine）这样的虚拟化平台，以及嵌入式设备和物联网(IoT)设备，其中对资源效率和性能有高要求。为了获取最新和权威的Virtio规范，用户应参考https://docs.oasis-open.org/virtio/virtio/v1.1/virtio-v1.1.pdf 和 https://docs.oasis-open.org/virtio/virtio/v1.1/virtio-v1.1.html。这个版本相较于早期草案提供了更为完善的文档和实施指南，确保了虚拟化环境中设备通信的最佳实践。 Virtio 1.1不仅是虚拟化技术的重要升级，也是推动现代计算架构中硬件抽象和性能优化的关键要素。对于任何从事虚拟化、云计算或者系统设计的工程师来说，理解并熟悉Virtio规范都是不可或缺的。

资源详情

资源推荐

2.1.2 Device Requirements: Device Status Field

The device MUST initialize device status to 0 upon reset.

The device MUST NOT consume buffers or send any used buffer notifications to the driver before DRIVER_-

OK.

The device SHOULD set DEVICE_NEEDS_RESET when it enters an error state that a reset is needed. If

DRIVER_OK is set, after it sets DEVICE_NEEDS_RESET, the device MUST send a device configuration

change notification to the driver.

2.2 Feature Bits

Each virtio device offers all the features it understands. During device initialization, the driver reads this and

tells the device the subset that it accepts. The only way to renegotiate is to reset the device.

This allows for forwards and backwards compatibility: if the device is enhanced with a new feature bit, older

drivers will not write that feature bit back to the device. Similarly, if a driver is enhanced with a feature that

the device doesn’t support, it see the new feature is not offered.

Feature bits are allocated as follows:

0 to 23 Feature bits for the specific device type

24 to 37 Feature bits reserved for extensions to the queue and feature negotiation mechanisms

38 and above Feature bits reserved for future extensions.

Note: For example, feature bit 0 for a network device (i.e. Device ID 1) indicates that the device supports

checksumming of packets.

In particular, new fields in the device configuration space are indicated by offering a new feature bit.

2.2.1 Driver Requirements: Feature Bits

The driver MUST NOT accept a feature which the device did not offer, and MUST NOT accept a feature

which requires another feature which was not accepted.

The driver SHOULD go into backwards compatibility mode if the device does not offer a feature it under-

stands, otherwise MUST set the FAILED device status bit and cease initialization.

2.2.2 Device Requirements: Feature Bits

The device MUST NOT offer a feature which requires another feature which was not offered. The device

SHOULD accept any valid subset of features the driver accepts, otherwise it MUST fail to set the FEA-

TURES_OK device status bit when the driver writes it.

If a device has successfully negotiated a set of features at least once (by accepting the FEATURES_OK

device status bit during device initialization), then it SHOULD NOT fail re-negotiation of the same set of

features after a device or system reset. Failure to do so would interfere with resuming from suspend and

error recovery.

2.2.3 Legacy Interface: A Note on Feature Bits

Transitional Drivers MUST detect Legacy Devices by detecting that the feature bit VIRTIO_F_VERSION_1

is not offered. Transitional devices MUST detect Legacy drivers by detecting that VIRTIO_F_VERSION_1

has not been acknowledged by the driver.

In this case device is used through the legacy interface.

virtio-v1.1-csprd01

20 December 2018

Page 16 of 158

Legacy interface support is OPTIONAL. Thus, both transitional and non-transitional devices and drivers are

compliant with this specification.

Requirements pertaining to transitional devices and drivers is contained in sections named ’Legacy Interface’

like this one.

When device is used through the legacy interface, transitional devices and transitional drivers MUST operate

according to the requirements documented within these legacy interface sections. Specification text within

these sections generally does not apply to non-transitional devices.

2.3 Notifications

The notion of sending a notification (driver to device or device to driver) plays an important role in this

specification. The modus operandi of the notifications is transport specific.

There are three types of notifications:

• configuration change notification

• available buffer notification

• used buffer notification.

Configuration change notifications and used buffer notifications are sent by the device, the recipient is the

driver. A configuration change notification indicates that the device configuration space has changed; a

used buffer notification indicates that a buffer may have been made used on the virtqueue designated by

the notification.

Available buffer notifications are sent by the driver, the recipient is the device. This type of notification

indicates that a buffer may have been made available on the virtqueue designated by the notification.

The semantics, the transport-specific implementations, and other important aspects of the different notifica-

tions are specified in detail in the following chapters.

Most transports implement notifications sent by the device to the driver using interrupts. Therefore, in pre-

vious versions of this specification, these notifications were often called interrupts. Some names defined

in this specification still retain this interrupt terminology. Occasionally, the term event is used to refer to a

notification or a receipt of a notification.

2.4 Device Configuration Space

Device configuration space is generally used for rarely-changing or initialization-time parameters. Where

configuration fields are optional, their existence is indicated by feature bits: Future versions of this specifi-

cation will likely extend the device configuration space by adding extra fields at the tail.

Note: The device configuration space uses the little-endian format for multi-byte fields.

Each transport also provides a generation count for the device configuration space, which will change when-

ever there is a possibility that two accesses to the device configuration space can see different versions of

that space.

2.4.1 Driver Requirements: Device Configuration Space

Drivers MUST NOT assume reads from fields greater than 32 bits wide are atomic, nor are reads from

multiple fields: drivers SHOULD read device configuration space fields like so:

u32 before, after;

do {

before = get_config_generation(device);

// read config entry/entries.

virtio-v1.1-csprd01

20 December 2018

Page 17 of 158

after = get_config_generation(device);

} while (after != before);

For optional configuration space fields, the driver MUST check that the corresponding feature is offered

before accessing that part of the configuration space.

Note: See section 3.1 for details on feature negotiation.

Drivers MUST NOT limit structure size and device configuration space size. Instead, drivers SHOULD only

check that device configuration space is large enough to contain the fields necessary for device operation.

Note: For example, if the specification states that device configuration space ’includes a single 8-bit field’

drivers should understand this to mean that the device configuration space might also include an

arbitrary amount of tail padding, and accept any device configuration space size equal to or greater

than the specified 8-bit size.

2.4.2 Device Requirements: Device Configuration Space

The device MUST allow reading of any device-specific configuration field before FEATURES_OK is set by

the driver. This includes fields which are conditional on feature bits, as long as those feature bits are offered

by the device.

2.4.3 Legacy Interface: A Note on Device Configuration Space endian-ness

Note that for legacy interfaces, device configuration space is generally the guest’s native endian, rather than

PCI’s little-endian. The correct endian-ness is documented for each device.

2.4.4 Legacy Interface: Device Configuration Space

Legacy devices did not have a configuration generation field, thus are susceptible to race conditions if

configuration is updated. This affects the block capacity (see 5.2.4) and network mac (see 5.1.4) fields;

when using the legacy interface, drivers SHOULD read these fields multiple times until two reads generate

a consistent result.

2.5 Virtqueues

The mechanism for bulk data transport on virtio devices is pretentiously called a virtqueue. Each device can

have zero or more virtqueues

Driver makes requests available to device by adding an available buffer to the queue - i.e. adding a buffer

describing the request to a virtqueue, and optionally triggering a driver event - i.e. sending an available

buffer notification to the device.

Device executes the requests and - when complete - adds a used buffer to the queue - i.e. lets the driver

know by marking the buffer as used. Device can then trigger a device event - i.e. send a used buffer

notification to the driver.

Device reports the number of bytes it has written to memory for each buffer it uses. This is referred to as

“used length”.

Device is not generally required to use buffers in the same order in which they have been made available

by the driver.

For example, the simplest network device has one virtqueue for transmit and one for receive.

virtio-v1.1-csprd01

20 December 2018

Page 18 of 158

Some devices always use descriptors in the same order in which they have been made available. These

devices can offer the VIRTIO_F_IN_ORDER feature. If negotiated, this knowledge might allow optimizations

or simplify driver and/or device code.

Each virtqueue can consist of up to 3 parts:

• Descriptor Area - used for describing buffers

• Driver Area - extra data supplied by driver to the device

• Device Area - extra data supplied by device to driver

Note: Note that previous versions of this spec used different names for these parts (following 2.6):

• Descriptor Table - for the Descriptor Area

• Available Ring - for the Driver Area

• Used Ring - for the Device Area

Two formats are supported: Split Virtqueues (see 2.6 Split Virtqueues) and Packed Virtqueues (see 2.7 Packed

Virtqueues).

Every driver and device supports either the Packed or the Split Virtqueue format, or both.

2.6 Split Virtqueues

The split virtqueue format was the only format supported by the version 1.0 (and earlier) of this standard.

The split virtqueue format separates the virtqueue into several parts, where each part is write-able by either

the driver or the device, but not both. Multiple parts and/or locations within a part need to be updated when

making a buffer available and when marking it as used.

Each queue has a 16-bit queue size parameter, which sets the number of entries and implies the total size

of the queue.

Each virtqueue consists of three parts:

• Descriptor Table - occupies the Descriptor Area

• Available Ring - occupies the Driver Area

• Used Ring - occupies the Device Area

where each part is physically-contiguous in guest memory, and has different alignment requirements.

The memory alignment and size requirements, in bytes, of each part of the virtqueue are summarized in the

following table:

Virtqueue Part Alignment Size

Descriptor Table 16 16∗(Queue Size)

Available Ring 2 6 + 2∗(Queue Size)

Used Ring 4 6 + 8∗(Queue Size)

The Alignment column gives the minimum alignment for each part of the virtqueue.

The Size column gives the total number of bytes for each part of the virtqueue.

Queue Size corresponds to the maximum number of buffers in the virtqueue

. Queue Size value is always

a power of 2. The maximum Queue Size value is 32768. This value is specified in a bus-specific way.

When the driver wants to send a buffer to the device, it fills in a slot in the descriptor table (or chains several

together), and writes the descriptor index into the available ring. It then notifies the device. When the device

has finished a buffer, it writes the descriptor index into the used ring, and sends a used buffer notification.

For example, if Queue Size is 4 then at most 4 buffers can be queued at any given time.

virtio-v1.1-csprd01

20 December 2018

Page 19 of 158

2.6.1 Driver Requirements: Virtqueues

The driver MUST ensure that the physical address of the first byte of each virtqueue part is a multiple of the

specified alignment value in the above table.

2.6.2 Legacy Interfaces: A Note on Virtqueue Layout

For Legacy Interfaces, several additional restrictions are placed on the virtqueue layout:

Each virtqueue occupies two or more physically-contiguous pages (usually defined as 4096 bytes, but de-

pending on the transport; henceforth referred to as Queue Align) and consists of three parts:

Descriptor Table Available Ring (. ..padding. . .) Used Ring

The bus-specific Queue Size field controls the total number of bytes for the virtqueue. When using the legacy

interface, the transitional driver MUST retrieve the Queue Size field from the device and MUST allocate the

total number of bytes for the virtqueue according to the following formula (Queue Align given in qalign and

Queue Size given in qsz):

#define ALIGN(x) (((x) + qalign) & ~qalign)

static inline unsigned virtq_size(unsigned int qsz)

{

return ALIGN(sizeof(struct virtq_desc)*qsz + sizeof(u16)*(3 + qsz))

+ ALIGN(sizeof(u16)*3 + sizeof(struct virtq_used_elem)*qsz);

}

This wastes some space with padding. When using the legacy interface, both transitional devices and

drivers MUST use the following virtqueue layout structure to locate elements of the virtqueue:

struct virtq {

// The actual descriptors (16 bytes each)

struct virtq_desc desc[ Queue Size ];

// A ring of available descriptor heads with free-running index.

struct virtq_avail avail;

// Padding to the next Queue Align boundary.

u8 pad[ Padding ];

// A ring of used descriptor heads with free-running index.

struct virtq_used used;

};

2.6.3 Legacy Interfaces: A Note on Virtqueue Endianness

Note that when using the legacy interface, transitional devices and drivers MUST use the native endian of

the guest as the endian of fields and in the virtqueue. This is opposed to little-endian for non-legacy interface

as specified by this standard. It is assumed that the host is already aware of the guest endian.

2.6.4 Message Framing

The framing of messages with descriptors is independent of the contents of the buffers. For example, a

network transmit buffer consists of a 12 byte header followed by the network packet. This could be most

simply placed in the descriptor table as a 12 byte output descriptor followed by a 1514 byte output descriptor,

but it could also consist of a single 1526 byte output descriptor in the case where the header and packet are

adjacent, or even three or more descriptors (possibly with loss of efficiency in that case).

Note that, some device implementations have large-but-reasonable restrictions on total descriptor size (such

as based on IOV_MAX in the host OS). This has not been a problem in practice: little sympathy will be given

to drivers which create unreasonably-sized descriptors such as by dividing a network packet into 1500 single-

byte descriptors!

virtio-v1.1-csprd01

20 December 2018

Page 20 of 158

剩余157页未读，继续阅读

田园诗人之园

粉丝: 4360
资源: 14

virtio-v1.1技术规范草案：OASIS VIRTIO TC发布

virtio-v1.1.pdf

virtio-v1.0-cs04.pdf

virtio-win-0.1.173.iso

virtio-win-0.1.164.iso

virtio-win-0.1.208.iso

在 OpenStack 平台上修改相关配置文件，启用-device virtio-net-pci in kvm。在自行搭建的 OpenStack 私有云平台或赛项提供的 all-in-one 平台上，修改相关配置文件，启用-device virtio-net-pci in kvm

怎么将密码卡与guest里的virtio-crypto设备联系起来

virtio-win10 .iso下载

virtio-win的使用教程

virtio-win.iso

virtio-crypto技术

windows virtio-win驱动包含哪些

vdev-virtio-input

virtio-blk

KVM添加virtio-pci虚拟网卡

列举virtio规范(v1.1)中所有virtio net feature bit及其含义

qemu和virtinst，如何安装Windows Server 2022 Datacenter Desktop，网络模式为桥接模式，网卡、硬盘、显示驱动均为virtio，安装网卡、硬盘、显示驱动并加入到Windows AD中。

kvm windows

windows 安装qemu cotex-a7 openwrt

在ubuntu22.04系统下，使用qemu命令配置一台Rocky9.1服务器

最新资源