Page History

Kai

Included also automotive persistence requirements.

Access to (shared) physical ethernet

and guest-to-guest communication

Think about writing info how to share a physical network in practice

(Create bridge between virtual device and physical)

vsock should be moved to separate section?  Agreed.

WiFi seems to be not well covered.  Shall we wait on including it?

Now includes:

• RNG - OK. just clean up discussion text.
  TEE
  RPMB - open question, leave it as WIP in draft.
  Crypto acceleration new text is OK for draft.

ready for review

Discussion part needs cleanup

See GPU Summary Graphics Virtualization, VIRTIO GPU Operation Highlights pages

Draft spec – requirements written

Uncertainty (and lots of ongoing development) around 3D APIs - Vulkan progress, etc.

See GPU SummaryGraphics Virtualization page

and requirements in spec draft

Still a moving target (3D).  This is reflected in specification

Now part of VIRTIO 1.1

Mouse/touch events may need to remap coordinates in combined virtual systems but interface may still not be affected by this.

ready for review

Filesystem

9pfs and other

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?

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

ready for review

(cut down chapter, should be OK)

OK to have such a verbose chapter?  Maybe some more work...

IOMMU coordinates of DMA devices'
connection to memory.

See IOMMU Summary page

Applicability:

 Limit guest devices' scope to access system memory during DMA

 Enable scatter-gather accesses due to remapping (DMA buffers do not need to be physically-contiguous)

Nested virtualization. Any use-cases for automotive?
Group conclusion: Not needed nested virtualization - however there are still two levels because applications in guest are used to set up IOMMU (protection between applications) and then the VMs themselves are another level.   These levels drive the need for a virtualized IOMMU layer (and/or hardware support for the same)

ARM is actively working on the specification, more features are coming.

Nested virtualization? The use of Linux Containers inside a VM was mentioned. That in itself is not really nested virtualization. Namespace-based containers, is just a kernel feature providing separation independent of a hypervisor. However, Kata Containers is an approach to tie Linux containers into a hypervisor layer, making them "fully" virtualized. A theoretical situation arises that involves the use of Kata Containers on a Linux system that itself already runs in a VM. That might constitute an example of nested virtualization, but it was decided that this is not a mainstream idea, possibly not supported or feasible, and in each case likely more trouble than it is worth. "Flattening" the virtualization approach so that all units still run on one hypervisor is a likely outcome. Further research into partitioning methods is likely but for now this falls outside of a mainstream automotive virtual platform definition. We highlighted that Linux containers in their normal namespace based implementation are already a very useful system partition tool and it can be trivially applied also if the Linux kernel runs in a VM.

  Chapter has been written.

Xen working on more secure implementation (memory visibility problem, security of VIRTIO approach) - want to keep this open requirement wise to have flexibility.

Latest proposal to VIRTIO was close to go in but withdrawn to address final comments.

But:

Need a group review of text (verbose) and consider the comments here on the left. 

And also  VIRTIO parts have not been merged to official spec version.

   VIRTIO proposal is being discussed - still pending 2019-09-25

Requirement set is NOT ready (merged).

Leave comment and/or discussion and future outlook but not requirement.

Automotive sensors:

  Not covered by VIRTIO specifically.
Considering SCMI over VIRTIO as a future standard.

Artem proposed that Systems Control Management Interface (SCMI) protocol as a 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 attached (PDF)

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?

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?

Some OS have requirements that must be met by "platform" - eg. Android requires orientation sensor.

Good work done. 

Split out GPIO to separate chapter. 

Placeholder also for describing HW passthrough (in general)

All 3 need another review and cleanup to be complete.

Consider platform requirement for sensors that must exist (for Android etc.)

Artem

→ Dmitry

  Proposal to VIRTIO might come (OpenSynergy)

VPU = "AI" CPU optimized for visual recognition

coprocessors and other
dedicated hardware features

Matti: virtualize functions, not devices.

Gunnar: Analysis might extract some functions out of these...

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

Needs update – see minutes.

Other Serial devices?

... and LIN bus

VIRTIO applicability needs analysis

Spec chapter needs to be written.

TODO

LIN should not be mentioned in spec.
Comment on implementation later after analysis.

Fold discussion into console chapter.

Uncertain what parts are specified and implemented (in VIRTIO and Linux)

Cover this in console chapter

emergency-write / early debugging could be left out if we are not done with it.

Nikola (TSN)

Need new volunteer to complete it, perhaps from GHS?

The required features are not present in the network virtio devices as of virtio 1.0.

Is this → applicable enough to move into specification as requirements? --> 

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?

Comment on the possibility of implementing TSN is not prevented, (even without a virtual interface standard)

Need some more confirmation

OpenSynergy with BT experience ?

Not in VIRTIO scope

Virtualization of BT hardware might not be required.  However, commenting on various system designs seems appropriate.

Example: There exists an interface for virtualized audio device (virtio-sound), but Bluetooth is also an audio device (among other things...)  What does this mean for how to build an architecture that (for example) uses both virtualization for audio, and bluetooth technologies.

Write at least a Discussions chapter.
It is an important topic, common topic.

The HCI interface is the likely level of passthrough or virtualization.  The VM should have access to HCI since it can then implement standard Bluetooth stacks on top of it.

Not ready in time for first draft.

Must be mentioned, at least a comment and future plan.

May be partly applicable - I could write something here to get us started. - Gunnar

RAM device is being discussed as a better solution later on.
Proprietary protocols.

Random Number Generator

Very important for embedded systems... Let's see what is there and what we need to do.

SBSA has a generic interface, it should be the closest one.

Aim for simple interface.

Avoid VIRTIO/virt-queue type solution...

http://infocenter.arm.com/help/topic/com.arm.doc.den0029c/Server_Base_System_Architecture_v6_0_ARM_DEN_0029C_SBSA_6_0.pdf

  Write chapter.
Adam Lackorzynski

Want to include

TODO