...
3. Common Virtual Device categories
3.1 Storage (Block Device)
When using hypervisor technology data on storage devices needs to adhere to high-level security and safety requirements such as isolation and access restrictions. Virtio and its layer for block devices provides the infrastructure for sharing block devices and establish isolation of storage spaces. This is because, actual device access can be controlled by the hypervisor. However, Virtio favors generality over using hardware-specific features. This is problematic in case of specific requirements w.r.t. robustness and endurance measures often associated with the use of persistent data storage such as flash devices. In this context one can spot three relevant scenarios:
...
Comments on the above, according to previous discussions
3.2 Network Device
...
3.3 GPU Device
The virtio-gpu is a virtio based graphics adapter. It can operate in 2D mode and in 3D (virgl) mode. The device architecture is based around the concept of resources private to the host, the guest must DMA transfer into these resources. This is a design requirement in order to interface with 3D rendering.
3.3.1 GPU Device in 2D Mode
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.1: The implementation MUST support scatter-gather operations to fulfil the requirement in chapter 5.7.6.1 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.
3.3.2 GPU Device in 3D Mode
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.
Standard networks
Standard networks means those that are overwhelmingly standard in the computing world. In other words, any IP based network, typically with TCP (UDP for certain cases) as transport. While it's not really necessary to put limits on that, the physical layer is normally some variation of the Ethernet standard(s) or WiFi, or other transport that transparently exposes a TCP/IP network interface.
PLACEHOLDER: It is assumed that [VIRTIO] specification is an adequate definition of how to describe virtual platform interface and that operating systems can easily expose physical, virtual and inter-vm networks as network interfaces, i.e. what in Linux might be listed for a physical interface with a name like "eth0".
- Virtual and hardware (pass-through) interfaces shall be exposed as the operating system's standard network interface concept.
- The hypervisor/equivalent shall provide the ability to dedicate and expose any hardware network interface to one virtual machine.
- The hypervisor/equivalent shall(?) be able to configure virtual inter-vm networking interfaces.
Communication between VM and hypervisor. This is described as vsock in the VIRTIO specification. Is there a use case for this?
Automotive networks
All traditional in-car networks and buses, such as CAN, FlexRay, LIN, etc., which are not Ethernet TCP/IP style networks, are treated in the chapter TBD.
Time-sensitive Networking standards
Placeholder. How do those requirements affect, and how is the real-time demands implemented in practice in a virtual environment?
3.3 GPU Device
The virtio-gpu is a virtio based graphics adapter. It can operate in 2D mode and in 3D (virgl) mode. The device architecture is based around the concept of resources private to the host, the guest must DMA transfer into these resources. This is a design requirement in order to interface with 3D rendering.
3.3.1 GPU Device in 2D Mode
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.1: The implementation MUST support scatter-gather operations to fulfil the requirement in chapter 5.7.6.1 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 REQ-3: The implementation MUST set the VIRTIO_GPU_F_VIRGL flag, described in chapter 5.7.3 in [VIRTIO-GPU].
Device configuration layoutVGA Compatibility.
REQ-4: The implementation MUST use the device configuration layout according to chapter 6: VGA compatibility, as described in chapter 5.7.4 7 in [VIRTIO-GPU], is optional.
REQ-4.1: The implementation MUST use the previously reserved config structure field to report the number of capsets supported by the virglrenderer library.
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 concept (the command set and the operation flow) according to chapter 5.7.6 in [VIRTIO-GPU].
REQ-5.1: The implementation MUST support scatter-gather operations to fulfil the requirement in chapter 5.7.6.1 in [VIRTIO-GPU].
REQ-5.2: The implementation MUST support the extended command set as described in chapter 'Virtio-GPU | Virgl3D commands' in [VIRTIO-VIRGL].
REQ-5.3: The implementation MUST support the 3D command set as described in chapter 'VIRTIO_GPU_CMD_SUBMIT_3D' in [VIRTIO-VIRGL].
3.3.2 GPU Device in 3D Mode
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-5.4: The implementation MUST support the VIRTIO_GPU_CMD_GET_CAPSET_INFO command set as described in [??? only kernel sources as a reference so far].
REQ-54.51: The implementation MUST support the VIRTIO_GPU_CMD_GET_CAPSET command set as described in [??? only kernel sources as a reference so far]use the previously reserved config structure field to report the number of capsets supported by the virglrenderer library.
REQ-5.6: The implementation MUST be capable to perform DMA operations to and from 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 concept (the command set and the operation flow) according to chapter client's attached resources to fulfil the requirement in chapter 5.7.6 .1 in in [VIRTIO-GPU] and in 'Virtio-GPU | Virgl3D commands' in [VIRTIO-VIRGL].
...
REQ-6: VGA compatibility, as described REQ-5.1: The implementation MUST support scatter-gather operations to fulfil the requirement in chapter 5.7.7 6.1 in [VIRTIO-GPU], is optional.
Additional features.
REQ-5.2: The implementation MUST support the extended command set as described in chapter 'Virtio-GPU | Virgl3D commands' in [VIRTIO-VIRGL].
REQ-5.3: The implementation MUST support the 3D command set as described in chapter 'VIRTIO_GPU_CMD_SUBMIT_3D' in REQ-7: In addition to the command set and features, defined in [VIRTIO-GPU] and [VIRTIO-VIRGL], the implementation MAY provide:
- an additional flag to request more detailded GL error reporting to the client
3.4 IOMMU Device
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: The device ID MUST be set according to the requirement in chapter 2.1 in [VIRTIO-IOMMU].
Virtqueues.
REQ-2: The virtqueues MUST be set up according to the requirement in 2.2 in [VIRTIO-IOMMU].
Feature bits.
REQ-3: 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: The implementation MUST use the device configuration layout according to chapter 2.4 in [VIRTIO-IOMMU].
Device initialization.
REQ-5: The implementation MUST follow the initialisation guideline according to chapter 2.5 in [VIRTIO-IOMMU].
REQ-5.1: When implementing device initialization requirements from chapter 2.5.2, a stricter requirement takes place:
a. If the driver does not accept the VIRTIO_IOMMU_F_BYPASS feature, the device SHALL NOT let endpoints access the guest-physical address space.
Device Operation.
.
REQ-5.4: The implementation MUST support the VIRTIO_GPU_CMD_GET_CAPSET_INFO command set as described in [??? only kernel sources as a reference so far].
REQ-5.5: The implementation MUST support the VIRTIO_GPU_CMD_GET_CAPSET command set as described in [??? only kernel sources as a reference so far].
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:
- an additional flag to request more detailded GL error reporting to the client
3.4 IOMMU Device
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: The device ID MUST be set according to the requirement in chapter 2.1 REQ-6: The implementation MUST suport the device operation concept (the command set and the operation flow) according to chapter 2.6 in [VIRTIO-IOMMU].
Virtqueues.
REQ-6.1: When implementing support for device operation requirements from chapter 2.6.2, stricter requirements take place: a. The device SHALL NOT set status to VIRTIO_IOMMU_S_OK if a request didn’t succeed.
b. If a request type is not recognized, the device MUST return the buffers on the used ring and set the len field of the used element to zero.
c. If the VIRTIO_IOMMU_F_INPUT_RANGE feature is offered and the range described by fields virt_start and virt_end doesn’t fit in the range described by input_range, the device MUST set status to VIRTIO_IOMMU_S_RANGE and ignore the request.
d. If the VIRTIO_IOMMU_F_DOMAIN_BITS is offered and bits above domain_bits are set in field domain, the device MUST set status to VIRTIO_IOMMU_S_RANGE and ignore the request.
...
The virtqueues MUST be set up according to the requirement in 2.2 in [VIRTIO-IOMMU].
Feature bits.
REQ-3: 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: The implementation MUST use the device configuration layout according to chapter 2.4 in [VIRTIO-IOMMU].
Device initialization.
REQ-5: The implementation MUST follow the initialisation guideline according to chapter 2.5 in [VIRTIO-IOMMU].
REQ-5.1: When implementing device initialization requirements from chapter 2.5.2, a stricter requirement takes place:
a. If the driver does not accept the VIRTIO_IOMMU_F_BYPASS feature, the device SHALL NOT let endpoints access the guest-physical address space.
Device Operation.
REQ-6: 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: When implementing support for device operation requirements from chapter 2.6
...
.2, stricter requirements take place:
...
a.
...
The device SHALL NOT set status to VIRTIO_IOMMU_S_
...
OK if a request didn’t succeed.
...
...
b.
...
If a request type is not recognized, the device MUST
...
return the buffers on the used ring and set the len field of the used element to zero.
...
c.
...
If the VIRTIO_IOMMU_F_INPUT_RANGE feature is offered and the range described by fields virt_start and virt_end doesn’t fit in the range described by input_range, the device MUST set
...
status to VIRTIO_IOMMU_S_
...
RANGE and ignore the request.
...
d. If the VIRTIO_IOMMU_F_DOMAIN_BITS is offered and bits above domain_bits are set in field domain, the device MUST set status to VIRTIO_IOMMU_S_RANGE and ignore the request.
REQ-6.2: When implementing a handler for the ATTACH request as described in chapter 2.6.3.2, stricter requirements take place: endpoint identified by endpoint is already attached to another domain, then the device MUST first detach it from that domain and attach it to the one identified by domain. In that case the device behaves as if the driver issued a DETACH request with this endpoint, followed by the ATTACH request. If the device cannot do so, it MUST set the request status to VIRTIO_IOMMU_S_UNSUPP.
e a. If properties of the endpoint (obtained with a PROBE request) are incompatible with properties of other endpoints already attached to the requested domain, the device SHALL NOT attach the endpoint and MUSTthe reserved field of an ATTACH request is not zero, the device MUST set the request status to VIRTIO_IOMMU_S_INVAL and SHALL NOT attach the endpoint to the domain.
b. If the endpoint identified by endpoint doesn’t exist, then the device MUST set the request status to set the request status to VIRTIO_IOMMU_S_UNSUPPNOENT.
REQ-6.3: When implementing a handler for the DETACH request as described in chapter 2.6.4.2, stricter requirements take place: a c. If the reserved field of a DETACH request is not zero, the device MUST set the request status to VIRTIO_IOMMU_S_INVAL, in which case the device SHALL NOT perform the DETACH operation.
b. If the endpoint identified by endpoint doesn’t exist, then another endpoint is already attached to the domain identified by domain, then the device MUST attempt to attach the endpoint identified by endpoint to the domain. If it cannot do so, the device MUST set the request status to VIRTIOstatus to VIRTIO_IOMMU_S_NOENTUNSUPP.
c d. If the domain identified by domain doesn’t exist, or if the endpoint identified by endpoint isn’t is already attached to this to another domain, then the device MUST set the request first detach it from that domain and attach it to the one identified by domain. In that case the device behaves as if the driver issued a DETACH request with this endpoint, followed by the ATTACH request. If the device cannot do so, it MUST set the request status to VIRTIO_IOMMU_S_INVALUNSUPP.
REQ-6.4: When implementing a handler for the MAP request as described in chapter 2.6.5.2, stricter requirements take place: a. If virt_start, phys_start or (virt_end + 1) is not aligned on the page granularity, the device MUST set the e. If properties of the endpoint (obtained with a PROBE request) are incompatible with properties of other endpoints already attached to the requested domain, the device SHALL NOT attach the endpoint and MUST set the request status to VIRTIO_IOMMU_S_RANGE and SHALL NOT create the mappingUNSUPP.
REQ-6.3: When implementing a handler for the DETACH request as described in chapter 2.6.4.2, stricter requirements take place:
b a. If the device doesn’t recognize a flags bit, it reserved field of a DETACH request is not zero, the device MUST set the request status to VIRTIO_IOMMU_S_INVAL. In this , in which case the device SHALL NOT create perform the mappingDETACH operation.
c b. If a flag or combination of flag isn’t supported, the device the endpoint identified by endpoint doesn’t exist, then the device MUST set the request status to VIRTIOto VIRTIO_IOMMU_S_UNSUPPNOENT.
d. The device SHALL NOT allow writes to a range mapped without the c. If the domain identified by domain doesn’t exist, or if the endpoint identified by endpoint isn’t attached to this domain, then the device MUST set the request status to VIRTIO_IOMMU_MAP_F_WRITE flag. However, if the underlying architecture does not support write-only mappings, the device MAY allow reads to a range mapped with VIRTIO_IOMMU_MAP_F_WRITE but not VIRTIO_IOMMU_MAP_F_READ.S_INVAL.
REQ-6.4: When implementing a handler for the MAP request as described in chapter 2.6.5.2, stricter requirements take place:
e. If domain does not exist a. If virt_start, phys_start or (virt_end + 1) is not aligned on the page granularity, the device MUST set the set the request status to VIRTIO_IOMMU_S_NOENTRANGE and SHALL NOT create the mapping.
REQ-6.5: When implementing a handler for the UNMAP request as described in chapter 2.6.6.2, stricter requirements take place: a b. If the reserved field of an UNMAP request is not zero, the device device doesn’t recognize a flags bit, it MUST set the request status to VIRTIO_IOMMU_S_INVAL, in which . In this case the device SHALL NOT perform create the UNMAP operationmapping.
b c. If domain does not exista flag or combination of flag isn’t supported, the device MUST set the request status to VIRTIO_IOMMU_S_NOENTUNSUPP.
c. If a mapping affected by the range is not covered in its entirety by the range (the UNMAP request would split the mapping), then the device MUST set the request status to VIRTIO_IOMMU_S_RANGE, and SHALL NOT remove any mapping d. The device SHALL NOT allow writes to a range mapped without the VIRTIO_IOMMU_MAP_F_WRITE flag. However, if the underlying architecture does not support write-only mappings, the device MAY allow reads to a range mapped with VIRTIO_IOMMU_MAP_F_WRITE but not VIRTIO_IOMMU_MAP_F_READ.
d e. If part of the range or the full range is not covered by an existing mapping, then the device MUST remove all mappings affected by the range and set the domain does not exist, the device MUST set the request status to VIRTIO_IOMMU_S_OKNOENT.
REQ-6.65: When implementing a handler for the PROBE UNMAP request as described in chapter 2.6.76.2, stricter requirements take place:
a. If the reserved field of a PROBE an UNMAP request is not zero, the device MUST set the request status to VIRTIO_IOMMU_S_INVAL, in which case the device SHALL NOT perform the UNMAP operation.
b. If the endpoint identified by endpoint doesn’t domain does not exist, then the device SHOULD MUST set the request status to to VIRTIO_IOMMU_S_NOENT.
c. If the device does not offer the VIRTIO_IOMMU_F_PROBE feature, and if the driver sends a VIRTIO_IOMMU_T_PROBE requesta mapping affected by the range is not covered in its entirety by the range (the UNMAP request would split the mapping), then the device MUST return the buffers on the used ring and set the len field of the used element to zerorequest status to VIRTIO_IOMMU_S_RANGE, and SHALL NOT remove any mapping.
d. The device MUST set bits [15:12] of property type to zero.
e. If the properties list is smaller than probe_size, then the device SHALL NOT write any property and MUST If part of the range or the full range is not covered by an existing mapping, then the device MUST remove all mappings affected by the range and set the request status to VIRTIO_IOMMU_S_INVALOK.
f. If the device doesn’t fill all probe_size bytes with properties, it MUST terminate the list with a property of type NONE and size 0. The device MAY fill the remaining bytes of properties, if any, with zeroes. If there isn’t enough space remaining in properties to terminate the list with a complete NONE property (4 bytes), then the device MUST fill the remaining bytes with zeroes.
REQ-6.7: When implementing support for RESV_MEM property as described in chapter 2.6.8.2.2, stricter requirements take place:
REQ-6.6: When implementing a handler for the PROBE request as described in chapter 2.6.7.2, stricter requirements take place:
a. If the reserved field of a PROBE request is not zero, the device MUST set the request status to VIRTIO_IOMMU_S_INVAL.
b. If the endpoint identified by endpoint doesn’t exist, then the device SHOULD set the request status to VIRTIO_IOMMU_S_NOENT.
c. If the device does not offer the VIRTIO_IOMMU_F_PROBE feature, and if the driver sends a VIRTIO_IOMMU_T_PROBE request, then the device MUST return the buffers on the used ring and set the len field of the used element to zero a. The device MUST set reserved to zero.
b. The device SHALL NOT present more than one VIRTIO_IOMMU_RESV_MEM_T_MSI property per endpoint.
c d. The device SHALL NOT present RESV_MEM properties that overlap each others for the same endpoint.
REQ-6.8: When implementing support for fault reporting as described in chapter 2.6.9.2, stricter requirements take place:
MUST set bits [15:12] of property type to zero.
e. If the properties list is smaller than probe_size, then the device SHALL NOT write any property and MUST set the request status to VIRTIO_IOMMU_S_INVAL.
a. The device MUST set reserved and reserved1 to zero.
b. The device MUST set undefined flags to zero.
c. The device MUST write a valid endpoint ID in endpoint.
d. If a buffer is too small to contain the fault report (this would happen for example if the device implements a more recent version of this specification than the driver, whose fault report contains additional fields) , the device SHALL NOT use multiple buffers to describe it. The device MUST fall back to using an older fault report format that fits in the buffer.
4. Supplemental Virtual Device categories
f. If the device doesn’t fill all probe_size bytes with properties, it MUST terminate the list with a property of type NONE and size 0. The device MAY fill the remaining bytes of properties, if any, with zeroes. If there isn’t enough space remaining in properties to terminate the list with a complete NONE property (4 bytes), then the device MUST fill the remaining bytes with zeroes.
REQ-6.7: When implementing support for RESV_MEM property as described in chapter 2.6.8.2.2, stricter requirements take place:
a. The device MUST set reserved to zero.
b. The device SHALL NOT present more than one VIRTIO_IOMMU_RESV_MEM_T_MSI property per endpoint.
c. The device SHALL NOT present RESV_MEM properties that overlap each others for the same endpoint.
REQ-6.8: When implementing support for fault reporting as described in chapter 2.6.9.2, stricter requirements take place:
a. The device MUST set reserved and reserved1 to zero.
b. The device MUST set undefined flags to zero.
c. The device MUST write a valid endpoint ID in endpoint.
d. If a buffer is too small to contain the fault report (this would happen for example if the device implements a more recent version of this specification than the driver, whose fault report contains additional fields) , the device SHALL NOT use multiple buffers to describe it. The device MUST fall back to using an older fault report format that fits in the buffer.
4. Special Virtual Device categories
4.x Automotive Sensors
Protocol access
Sensors can be handled by a dedicated co-processor or the hypervisor implementation and provide the sensor data through a communication protocol. This essentially offloads the burden of defining a "virtual hardware access" from the VM to the measuring hardware.
Systems Control Management Interface (SCMI) protocol was not originally defined for the virtual-sensor purpose itself, but describes a flexible and an appropriate abstraction for sensors. It is also appropriate for controlling power-management and related things. The actual hardware access implementation is according to ARM offloaded to a "Systems Control Processor" but this is a virtual concept. It could be a dedicated core in some cases, perhaps in others not.
- The hypervisor/equivalent shall use SCMI protocol to expose sensor data from a dedicated sensor subsystem to the virtual machines.
Direct Hardware access
For sensor hardware that shall be processed directly by the operating system it may be necessary to provide physical or virtual hardware access
- The hypervisor/equivalent shall provide configurable pass-through access to a VM for sensor hardware (which category of hardware?)
- The hypervisor/equivalent shall be
For digital I/O pins, refer to standard pinmux specification ( need clarification)
4.x Audio
4.x Media codec
TODO Hardware-assisted codecs
4.x Cryptography
TBC No particular info in VIRTIO on this?
4.x.x Random Number Generation
Random number generation is typically created by a combination of a true-random and pseudo-random implementations. A pseudo-random generation algorithm is implemented in software. "True" random values may be acquired by a hardware-assisted device, or a hardware (noise) device may be used to acquire a random seed which is then further used by a pseudo-random algorithm.
- The virtual platform SHALL provide VMs with access to a hardware-assisted high quality random number generator through the operating system's preferred interface.
(/dev/random device on Linux) - TODO, improve this:
The virtual platform should describe a security analysis of how to avoid any type of side-band analysis of the random number generation.
5. Supplemental Virtual Device categories
5.x Text Console
While they may be rarely an appropriate interface for the normal operation of the automotive system, text consoles are expected to be present for development purposes.
TBC. It is expected that the virtual interface of the console is adequately defined by [VIRTIO].
- To not impede efficient development, text consoles shall be according to the operating systems' normal standards so that they can be connected to any normal development flow.
- Text consoles are often connected to a shell capable of running commmands. For security reasons, text consoles shall be possible to shut off entirely in the configuration of a production system. This configuration must furthermore not be modifiable from any guest operating system.
54.1 9pfs and host-to-vm filesystem sharing
...