Based among other things on the idea presented at GENIVI AMM in Munich regarding VIRTIO use both with and without hypervisor, to communicate between multiple OSes, the need has been identified to describe the complexity of system design on modern heterogeneous multi-core SoCs, running several different Operating System kernel instances.
Outline/Brainstorm
Intro. Why ? Motivation
-- consolidation of systems, "mixed criticality" requirements, e.g. security, safety, real-timedness.
This background is well know... Previous AGL white paper intro should cover this quite well, for example.
Generally try reuse, don't redo, and complement with what is missing.
Overall scope: Multi-OS System design on heterogeneous multi-cores ?
With and without hypervisor. Dedicated cores. Isolation possibilities for memory, peripherals, etc. Light-weight solutions.
Dedicated cores or Linux Containers.
Understanding what is what... must be done right. search and reuse LXC description.
Include MCU-style hypervisors.
When hardware has support for isolation. TrustZone, but also other.
ARM input on this? Lots of ARM updates in the pipe... timing (can become obsolete quickly)
Describe at least High-level understanding.
System-level quality of service. Future architectures can guarantee QoS on internal interconnects and caches, etc. (what else?) controlled by VM configuration
– ref armv8 manual. MPEM Memory system resource performance....
Inter-partition protocols for example leveraging VIRTIO. (Partitions = VMs, to/from HV, but also between OSes running bare metal on dedicated core)
Hardware Device sharing - main purpose of Hypervisors. However device sharing can be set up with other means?
– Review "Adam's wish list" for silicon vendors... might be included in white paper as a result.
→ Risk of being outdated quickly since hardware is changing quickly
- Mostly HW features but also may include firmware requirements.
System design is unique – Not 100$ common hardware feature across all of them. But a small core of features are common.
Other hardware features can be mapped to functions of the system. E.g. if you need function X, then require hardware feature Y. Include optional and mandatory requirements.
The wishlist is likely to be more of principles than hard detailed requirements. In some areas analyze the more detailed requirements e.g. "X number of DMA channels"
Experiences that lead to requirements → 64 bit support on all I/O masters...
.... Is this risking scope creep for the white paper?
Wish list might be better as independent.
Key topics: Partitioning and Spatial/Timing isolation of parts.
Goals
- Establishing common language/terms/understanding
- Design guidance
Focus on using established and traditional terms (some were defined in 1970s...)
Target audience
- System Architects - system design guidance
- Guiding purchasing of ECU systems... requirements on the hardware and software stacks
- HW / SoC designers (for the needed HW features)
- IP-vendors (ARM)