"VIRTIO协议v1.1官方文档发布：半虚拟化设备接口规范更新"

需积分: 5 70 浏览量更新于2024-03-12 1 收藏 698KB PDF 举报

The Virtual I/O Device (VIRTIO) Version 1.1 is a specification that outlines the protocol for virtual devices in a virtualized environment. Published as the Committee Specification 0111 in April 2019, this document serves as the authoritative source for implementing VIRTIO devices in virtualized systems. The VIRTIO protocol enables efficient communication between virtual machines and their host system by defining a set of standard interfaces and data structures. By using VIRTIO devices, virtual machines can access storage, networking, and other peripherals with high performance and minimal overhead. The VIRTIO-V1.1.pdf document provides detailed information on how VIRTIO devices should be implemented, including specifications for device discovery, device configuration, and data transfer mechanisms. It also outlines requirements for drivers that support VIRTIO devices and guidelines for ensuring compatibility across different virtualization platforms. One of the key features of VIRTIO Version 1.1 is its support for para-virtualization, which allows virtual machines to communicate with the host system more efficiently by offloading certain tasks to the host. This approach reduces the overhead associated with virtualized I/O operations and improves overall system performance. The specification includes URIs for accessing the text, PDF, and HTML versions of the document, ensuring that developers and system administrators have easy access to the latest information on VIRTIO devices. The VIRTIO-V1.1.pdf document is updated periodically to address any new requirements or enhancements to the protocol. Overall, the VIRTIO Version 1.1 specification is essential for virtualization professionals looking to maximize the performance and efficiency of their virtualized environments. By following the guidelines outlined in this document, developers can ensure seamless integration of VIRTIO devices and achieve optimal performance in their virtualized systems.

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-cs01

11 April 2019

Page 16 of 166

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-cs01

11 April 2019

Page 17 of 166

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-cs01

11 April 2019

Page 18 of 166

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-cs01

11 April 2019

Page 19 of 166

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-cs01

11 April 2019

Page 20 of 166

剩余165页未读，继续阅读

田园诗人之园

粉丝: 5130
资源: 14

"VIRTIO协议v1.1官方文档发布：半虚拟化设备接口规范更新"

virtio-win-0.1.262.iso

Driver_VirtIO_win_x64.iso

virtio协议

virtio-v1.1-csprd01.pdf

virtio-v1.0-cs04.pdf

BF-2 Virtio-net_.docx

virtio-win-1.9.19-1.el8.noarch.rpm

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

virtio-win10 .iso下载

virtio-win-0.1.204.iso.zip

最新资源