Page History

...

• Implement virtual block device according to chapters 5.2 in [VIRTIO].
• The system must implement support for the VIRTIO_BLK_F_FLUSH feature flag.
• The system must implement support for the VIRTIO_BLK_F_CONFIG_WCE feature flag.
• The system must implement support for the VIRTIO_BLK_F_DISCARD feature flag.
• The system must implement support for the VIRTIO_BLK_F_WRITE_ZEROS feature flag.

3.2 Network Device

Standard networks

Standard networks means include those that are overwhelmingly standard not automotive specific, but instead frequently used in the computing world.  In other words , any these are typically IP based network, typically with TCP (UDP for certain cases) as transport.  While it's not really necessary to put limits on that, the networks, but some of them simulate this level through other means (e.g. vsock which does not use IP addressing).  The physical layer is normally some variation of the Ethernet/WiFi standard(s) or WiFi, ) (according to standards 802.*) 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?

similar network socket interface 

virtio-net  = Layer 2  (Ethernet / MAC addresses)
virtio-vsock = Layer 4.  Has its own socket type.  Optimized by stripping away the IP stack.  Possibility to address VMs without using IP addresses. Primary function is Host (HV) to VM communication.

Discussion:
Vsock: Each VM has logical ID but the VM normally does not know about it.  Example usage: Running a particular agent in the VM that does something on behalf of the HV.  There is also the possibility to use this for VM-to-VM communication, but since this is a special socket type it would involve writing code that is custom for the virtualization case, as opposed to native.

vsock is the application API.   Multiple different named transport variations exist in different hypervisors which means the driver implementation differs depending on chosen hypervisor.  Virtio-vsock however locks this down to one chosen method.

Requirements:

• If the platform implements virtual networking, it shall also use the virtio-net required interface between drivers and Hypervisor.

• If the platform implements vsock, it shall also use the virtio-vsock required API between drivers and Hypervisor.

• Virtual network interfaces shall be exposed as the operating system's standard network interface concept, i.e. they should show up as a normal network device.

• 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.

• Implementations of virtio-net shall support the  VIRTIO_NET_F_MTU  feature flag

• Implementations of virtio-net shall support the  VIRTIO_NET_F_MAC  feature flag

• Implementations of virtio-net shall support the  VIRTIO_NET_F_CTRL_MAC_ADDR  feature flag

Discussion:
    Virtual network interfaces ought to be exposed to user space code in the guest OS as standard network interfaces.   This minimizes custom code appearing because of the usage of virtualization is minimized.  

MTU may differ on the actual network being used.   There is a feature flag that a network device can state its maximum (advised) MTU and the guest application code might make use of this to avoid segmented messages.

The guest may require a custom MAC address on a network interface.  This is important for example when setting up bridge devices which expose the guest's MAC address to the outside network.  To avoid clashes the host must be able to set an explicit (possibly also stable across reboots) MAC address in each VM (at a later time, after bootup).

In addition, the guest shall be able to set its own MAC address.  (Adam: The HV can deny the request ...?) 

Offloading and other features are considered optimizations and therefore not set as absolutely required.

... discussion on MAC address change request from a guest VM --> who if anyone should force other VMs to update (clear ARP caches)?
Some features exist but they seem to be primarily for live migration.  For the moment this is not required.

Wireless Stuff

Wifi adds some additional characteristics not used in wired networks : SSID, passwords/authentication, signal strength, preferred frequency...
What are the typical designs for this?  Expose WiFi to only one VM and let it act as gateway/router for the others.  Or should the WiFi interface be truly sharable  (e.g. Ethernet level bridges created in HV so that each VM has its own network device and they all connect to the WiFi connection)?

---> MORE WORK NEEDED!

Automotive networks

All traditional in-car networks and buses, such as CAN, FlexRay, LIN, MOST, etc., which are not Ethernet TCP/IP style networks, are treated in the chapter TBD.

...

 REQ-1:   The device ID MUST be set according to the requirement in chapter 5.7.1 in [VIRTIO-GPU].in chapter 5.7.1 in [VIRTIO-GPU].

 ---------- >   CHECK IF CHAPTER NUMBERS ARE VALID FOR VIRTIO 1.1

Virtqueues.

 REQ-2:   The virtqueues MUST be set up according to the requirement in chapter 5.7.2 in [VIRTIO-GPU].

...

        VGA Compatibility.

 REQ-6:   VGA compatibility, as described in chapter 5.7.7 in [VIRTIO-GPU], is optionalcompatibility, as described in chapter 5.7.7 in [VIRTIO-GPU], is optional.

   
REQ-TBD: * The implementation shall support feature flag VIRTIO_GPU_F_EDID as described in [VIRTIO]

REQ-TBD: * The device must implement support for the VIRTIO_GPU_CMD_RESOURCE_CREATE_V2 as described in [VIRTIO-FUTURE]

Discussion:

Newer versions of VIRTIO include features like EDID support. A primary use is the DPI value of a virtual display, which is otherwise unknown,
and this would means things like font sizes get messed up. 

When attaching buffers use pixel format, size, and other metadata for registering the stride.  With uncommon screen resolutions, this might be unaligned and some custom strides might be needed to match.

3.3.2 GPU Device in 3D Mode

...