Page History

Kai

Access to (shared) physical ethernet

and guest-to-guest communication

Done initial browsing of the specification. Opinions still pending.

Use-cases: ?

Completeness: Protocol: , VIRTIO spec: (see comment)

Need in Embedded/Automotive: None? Can we find a use-case?

Applicability: For what it does, seems ok. But might not be really needed and therefore "not applicable". Is there something else/more needed?

WIP

Essentially used for "shared folder" capability between host & guest, as in desktop (or maybe some server) usage. Its applicability to embedded hypervisor usage, in which the "host" is not really being used by itself) seems questionable. What's the use-case?

In VIRTIO spec: A PCI type device can indicate that it is going to use the 9P protocol. The specification also has 9P as a specific separate device type. Other than that, I found no further description of such a device type. The protocol is specified elsewhere and complemented by scattered information regarding the specific implementations (Xen, KVM, QEMU, ...)

The protocol seems proven and supposedly OK for what it does. Possibly more security features needed, depending on use-case. VIRTIO however seems to defer the definition completely to "somewhere else"? At least a reference to a canonical specification would seem appropriate.

It is a minimalistic network file-system protocol. It seems apt for the task. Other network protocols like NFS, SMB/SAMBA etc. would be too heavy. It feels a bit esoteric, and while "reinventing" is bad, in this simple case would not be the worst ever, if VIRTIO had defined something else. Flexibility and security features seem somewhat glossed over. There's basically only "fixed user" or "pass-through" for mapping ownership on files in guest/host.

Links: Virtio 1.0 spec : {PCI-9P, 9P device type}.
Kernel support: Xen/Linux 4.12+ FE driver
Xen implementation details

A note on its documentation/definition not being very precise

A set of man pages seemingly defining P9? intro, others

QEMU instruction how to set up a VirtFS (P9).
Example/info how to natively mount a 9P network filesystem,
Source code for 9pfs FUSE driver

Example how to set up in Linux system

IOMMU coordinates of DMA devices'
connection to memory.

Some info on Linux/Xen code here:

HVWS: Xen input and experience on Audio, Display, Input and TEE

Automotive sensors:

Automotive sensors? Radar/LiDAR/? (or are they separate ECUs?)

Standard embedded sensor (ambient light...)

Some OS have requirements - eg. Android requires orientation sensor.

CPUs/SoCs have "internal" sensors too. Relating to temperature and power mgmt. Some internal control tweaks for power management (core frequency / voltage) are like tiny internal actuators. Virtual access to those? Same or different APIs?

Artem proposed that Systems Control Management Interface (SCMI) protocol is flexible and an appropriate abstraction for sensors. It is also appropriate for controlling power-management and related things. The 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. EPAM/Xen tried out putting code in ARM-TF, to act as this SCP.

SCMI destined (?) to become a ARM-wide standard in a currently fragmented reality.

Presentation Link TBD

Upper protocol defined, but could imagine different lower transport. One mailbox-style transport is kind-of defined by ARM spec? Discussion if VIRTIO transport would be appropriate. A "SCMI device" type added to VIRTIO?

Challenges:

• Current situation in ARM is fragmented with many overlapping unique APIs across chip vendors.
• Is this doable also on x86, and is it likely to be adopted?
• Discuss applicability beyond "sensors" and where boundaries are drawn.

Reference:

• Related: ARM SCMI "Platform Design document"

What about PINCTRL, and handling the many multiplexed pins in a modern SoC. Any remaining need for lower-level protocols for accessing/virtualizing hardware?

Example Assigning Host USB device to a Guest VM in KVM, here:

https://www.linux-kvm.org/page/USB_Host_Device_Assigned_to_Guest

Which use cases do we want to address?

•USB 2.0 (EHCI controller)
•USB 3.0 (xHCI controllers will replace ECHI)
•USB C
•Host only
•Device Classes:

• Mass storage. Enable use of USB device with volume provider
• Communications (e.g. serial, Ethernet)
• Human interface (e.g. keyboard, mouse)

•On-The-Go (system can function as both USB host and USB device)
•Hot-plug (partial support):

• Static configuration of device “tree”. A device can be plugged into a port. Dynamically detect device type.
• Device tree cannot grow dynamically, i.e. cannot plug in a hub

Other Serial devices?

(Where does LIN, etc. fit in?)

LIN-bus:

• Source code for linux-lin driver (for Linux, not necessarily virtual environment):
• Paper by Czech Technical University & Volkswagen Group Research:
  LIN based on SocketCAN → 1. OSADL article, 2. paper (PDF).
  • The paper concludes that LIN data frames are similar enough to CAN frames that it can reuse CAN software infrastructure (such as the SocketCAN standard). LIN is a serial bus, implemented with a UARTs, and therefore standard UART device drivers would be used. For virtual environments, we can rely on the same conclusions, and therefore refer to the answer given for CAN.
  • On the other hand, LIN is most popular for its simplicity / low cost (even lower than CAN) and used in very simple ECUs or to/from input devices like switches, knobs and buttons. On the larger CPU it is likely to be run by a separate dedicated microcontroller, or at least small on-chip CPU core. Therefore it can often be considered out-of-scope for the CPU that implements virtualization.

virtio-can: VIRTIO-based CAN driver

Must have requirements:

• IEEE 802.1AS compatible egress and ingress timestamps on ethernet frames available in the virtio consumer OS

Good to have:

• IEEE 802.1Q-2011 queue enhancement mechanisms available in the virtio consumer OS
  • Interesting read about KVM: https://www.linux-kvm.org/page/Multiqueue

General architectural considerations:

• What if there is more than one consumer of the IEEE 802.1AS defined network timebase on the same system?

Sang-bum

+OpenSynergy with BT experience