...
In the unaccelerated 2D mode there is no support for DMA transfers from resources, just to them. Resources are initially simple 2D resources, consisting of a width, height and format along with an identifier. The guest must then attach backing store to the resources in order for DMA transfers to work.
Device ID.
REQ-1: The device ID MUST be set according to the requirement in chapter 5.7.1 in [VIRTIO-GPU].
Virtqueues.
REQ-2: The virtqueues MUST be set up according to the requirement in chapter 5.7.2 in [VIRTIO-GPU].
Feature bits.
REQ-3: The VIRTIO_GPU_F_VIRGL flag, described in chapter 5.7.3 in [VIRTIO-GPU], SHALL NOT be set.
Device configuration layout.
REQ-4: The implementation MUST use the device configuration layout according to chapter 5.7.4 in [VIRTIO-GPU].
REQ-4.1: The implementation SHALL NOT touch the reserved structure field as it is used for the 3D mode.
Device Operation.
REQ-5: The implementation MUST suport the device operation conceprt (the command set and the operation flow) according to chapter 5.7.6 in [VIRTIO-GPU].
...
REQ-5.2: The implementation MUST be capable to perform DMA operations to client's attached resources to fulfil the requirement in chapter 5.7.6.1 in [VIRTIO-GPU].
VGA Compatibility.
REQ-6: VGA compatibility, as described in chapter 5.7.7 in [VIRTIO-GPU], is optional.
...
3D mode will offload rendering operations to the host gpu and therefore requires a gpu with 3D support on the host machine. The guest side requires additional software in order to convert OpenGL commands to the raw graphics stack state (Gallium state) and channel them through virtio-gpu to the host. Currently the 'mesa' library is used for this purpose. The backend then receives the raw graphics stack state and interprets it using the virglrenderer library from the raw state into an OpenGL form, which can be executed as entirely normal OpenGL on the host machine. The host also translates shaders from the TGSI format used by Gallium into the GLSL format used by OpenGL.
Device ID.
REQ-1: The device ID MUST be set according to the requirement in chapter 5.7.1 in [VIRTIO-GPU].
Virtqueues.
REQ-2: The virtqueues MUST be set up according to the requirement in chapter 5.7.2 in [VIRTIO-GPU].
Feature bits.
REQ-3: The implementation MUST set the VIRTIO_GPU_F_VIRGL flag, described in chapter 5.7.3 in [VIRTIO-GPU].
Device configuration layout.
REQ-4: The implementation MUST use the device configuration layout according to chapter 5.7.4 in [VIRTIO-GPU].
...
REQ-4.1.1: The implementation SHALL NOT report the value of '0' as it is treated as absence of 3D support.
Device Operation.
REQ-5: The implementation MUST suport the device operation conceprt concept (the command set and the operation flow) according to chapter 5.7.6 in [VIRTIO-GPU].
...
REQ-5.6: The implementation MUST be capable to perform DMA operations to and from client's attached resources to fulfil the requirement in chapter 5.7.6.1 in [VIRTIO-GPU] and in 'Virtio-GPU | Virgl3D commands' in [VIRTIO-VIRGL].
VGA Compatibility.
REQ-6: VGA compatibility, as described in chapter 5.7.7 in [VIRTIO-GPU], is optional.
Additional features.
REQ-7: In addition to the command set and features, defined in [VIRTIO-GPU] and [VIRTIO-VIRGL], the implementation MAY provide:
...
NOTE: The current specification draft looks quite neat except the fact that it marks many requirements as SHOULD or MAY and leaves it for an implementation. Here I try to provide more strict rules when it is applicable.
An IOMMU provides virtual address spaces to other devices. Traditionally devices able to do Direct Memory Access (DMA masters) would use bus addresses, allowing them to access most of the system memory. An IOMMU limits their scope, enforcing address ranges and permissions of DMA transactions. The virtio-iommu device manages Direct Memory Access (DMA) from one or more physical or virtual devices assigned to a guest.
Device ID.
REQ-1: Requirement according to chapter The device ID MUST be set according to the requirement in chapter 2.1 in [VIRTIO-IOMMU].
Virtqueues.
REQ-2: Requirement according to chapter 2 The virtqueues MUST be set up according to the requirement in 2.2 in [VIRTIO-IOMMU].
Feature bits.
REQ-3: Requirement according to chapter The valid feature bits set is described in chapter 2.3 in [VIRTIO-IOMMU] and is dependant on the particular implementation.
Device configuration layout.
REQ-4: Requirement according to chapter The implementation MUST use the device configuration layout according to chapter 2.4 in [VIRTIO-IOMMU].
Device initialization.
REQ-5: Requirement The implementation MUST follow the initialisation guideline according to chapter 2.5 in [VIRTIO-IOMMU].
REQ-5.1: As for chapter 2.5.2, the requirement regarding the non accepted VIRTIO_IOMMU_F_BYPASS feature is to be read as SHALL NOT.
Device Operation.
REQ-6: Requirement according to chapter The implementation MUST suport the device operation concept (the command set and the operation flow) according to chapter 2.6 in [VIRTIO-IOMMU].
REQ-6.1: As for chapter 2.6.2, MAY and SHOULD are to be read as MUST, SHOULD NOT is to be read as SHALL NOT.
REQ-6.2: As for chapter 2.6.3.2, when implementing a handler for the ATTACH request, SHOULD is to be read as MUST, SHOULD NOT is to be read as SHALL NOT.
REQ-6.3: As for chapter 2.6.4.2, when implementing a handler for the DETACH request, SHOULD is to be read as MUST, SHOULD NOT is to be read as SHALL NOT.
REQ-6.4: As for chapter 2.6.5.2 2, when implementing a handler for the MAP request, SHOULD is to be read as MUST, SHOULD NOT is to be read as SHALL NOT.
REQ-6.5: As for chapter 2.6.6.2 2, when implementing a handler for the UNMAP request, SHOULD is to be read as MUST, SHOULD NOT is to be read as SHALL NOT.
REQ-6.6: As for chapter 2.6.7.2, when implementing a handler for the PROBE request, MAY and SHOULD are to be read as MUST, SHOULD NOT is to be read as SHALL NOT.
REQ-6.7: As for chapter 2.6.8.2.2 SHOULD 2, when implementing support for the RESV_MEM property, SHOULD is to be read as MUST, SHOULD NOT is to be read as SHALL NOT.
REQ-6.8: As for chapter 2.6.9.2, when implementing support for fault reporting, SHOULD is to be read as MUST, SHOULD NOT is to be read as SHALL NOT.
4. Supplemental Virtual Device categories
...
[VIRTIO-IOMMU] VIRTIO-IOMMU DRAFT 0.8
RESV_MEM