Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Proposing a document outline

...

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.

...

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.

...

  • 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, Synopsys, Imagination Technologies, Cadence)


...


Title candidates:

Next Generation Multi-OS System Design

Multi-OS System Design on Multicore SoCs


...

Outline:

1. Introduction

Intro: Need for multi-OS design.  Possibilities given by modern hardware, hypervisors and other techniques

Define Target audience

2. Isolation and Partitioning

Intro.  Talk about Partitioning and Spatial/Timing isolation of parts.

Partitioning Technologies

  1. Full-scale Hypervisors
  2. MCU Hypervisors
  3. Dedicated Core partitioning
  4. Operating System process partitioning / containers

3. Inter-core communication

  • VIRTIO between cores / OS partitions
  • What other standards

4. Functional Safety features

Describe specific features (hardware and software) supporting Functional Safety Goals

5. Cyber-security features

Describe specific features (hardware and software) supporting Functional Safety Goals

TrustZone but also others

6. Hardware sharing

Hardware Device sharing - is the main purpose of Hypervisors.  
However device sharing can be set up with other means?

Yes, examples:

  • h/w display layers
  • GPU virtualisaton with OS ID support

Specific Hardware Support

  • GPU virtualization features
  • GPU OS isolation
    • Separate input ports
    • GPU scheduler ensuring pipeline for each OS is serviced
    • Memory separation
    • Drawing isolation
      • Dedicated functional safety drawing paths, e.g. separate 2D rendering path for cluster telltales
  • Other HW features
    • Bus Master / IP / Memory access isolation
      • Independent security and safety groups control access of IP on bus and memory protection
    • Multi-level security isolation outside of common IP such as TrustZone
      • e.g. Implementation in real time R7 CPU
    • Lifecycle Management
      • e.g. control of security at different stages of its life (blue star) ← which chapter does this fit in?
  • --> Some architectures can guarantee QoS on internal interconnects and caches, etc.  (what else?) controlled by VM configuration or h/w controls.


7. Selecting a Design

  • Describe typical constraints and input that drives design decisions.
  • Walk through the main characteristics of each method, and any other consequences of choosing one method or other.
  • Guide the reader through the selection process, (comparing constraints to consequences of each choic)
    (Look at the "How to choose graphics sharing technology" presentation for inspiration)


8. Future outlook (?)

--> build something out of the "wish list"?


To be sorted

System-level quality of service.  What is this and where to fit in?