Philippe GERUM - SourceTrek

ELCEurope 2009  Grenoble

Introduction

   

The context

● Linux about to be natively real-time– PREEMPT_RT close to mainline

   

The context

● Linux about to be natively real-time– PREEMPT_RT close to mainline

● Legacy applications knocking on Linux's door– Traditional, embedded RTOS– Non-POSIX core API– Flat / physically addressed memory– Typically: VxWorks, pSOS, VRTX etc.

   

The issue

● Porting them to Linux currently means– Rebasing on Linux, changing design

or,– Keeping design, keeping proprietary RTOS

● How to go the Linux way?– Keeping design, using Linux technologies

   

Possible solution

● Combine existing Linux technologies– Native real-time support– Linux-native virtualization– RTOS emulation

   

Common porting strategies

● Port to dual kernel– Over POSIX API– Over API emulator– Over ad hoc API

Kernel space

User space

Real-time core

Application

APIs, emulators

Linuxsub-systems

RT driversRT drivers

Regulardrivers

Regulardrivers

RT libraries GNU libc

   

Common porting strategies

● Go Linux native– Over POSIX API– Over API emulator

Kernel space

User space

Application

Linuxsub-systems

RT driversRT drivers Regular

drivers

Regulardrivers

GNU libc

EmulatorsEmulators

   

Common porting strategies

● Introduce virtualization– Original RTOS guest– Vendor-specific

● Bare metal hypervisor– Leverage multi-core

Bare metal (RT) HypervisorBare metal (RT) Hypervisor

Linu

x

RTO

S

SBC

/ ha

rdw

are

Core Core

   

Approaches are challenging

● Dual kernel Linux architecture is complex

   

Approaches are challenging

● Dual kernel Linux architecture is complex

LibrariesLibraries

Rea

l-tim

e st

ack

Reg

ular

Lin

ux

Drivers

Core Core

Drivers

Libraries

Apps Apps

   

Approaches are challenging

● Dual kernel Linux architecture is complex– Pressure on application design

LibrariesLibraries

Rea

l-tim

e st

ack

Reg

ular

Lin

ux

Drivers

Core Core

Drivers

Libraries

Apps Apps

   

Approaches are challenging

● Native real-time Linux is complex

   

Approaches are challenging

● Native real-time Linux is complex

LibrariesLibraries

Drivers

Core

Apps

Global efficiency

General fairness

Bounded latency

Total unfairness

RegularReal-time

   

Approaches are challenging

● Native real-time Linux is complex– Pressure on system configuration

LibrariesLibraries

Drivers

Core

Apps

Global efficiency

General fairness

Bounded latency

Total unfairness

RegularReal-time

   

Approaches are challenging

● Proprietary virtualization systems?

   

Approaches are challenging

● Proprietary virtualization systems?– Introduce dependencies on vendor

● Hypervisor technology● Private (PV) Linux kernel● Original RTOS as guest

   

Approaches are challenging

● Proprietary virtualization systems?– Introduce dependencies on vendor

● Hypervisor technology● Private (PV) Linux kernel● Original RTOS as guest

– Enable Linux for proprietary RTOS

   

Approaches are challenging

● Proprietary virtualization systems?– Introduce dependencies on vendor

● Hypervisor technology● Private (PV) Linux kernel● Original RTOS as guest

– Enable Linux for proprietary RTOS

BUT,– Do not help the Linux real-time effort

   

Teams are challenged

● Inclination to seek 1:1 API mapping– Over-emulation of missing calls– Pitfalls in mapping common calls

   

Teams are challenged

● Inclination to seek 1:1 API mapping– Over-emulation of missing calls– Pitfalls in mapping common calls

● Driver model– Weak vs strong– Linux kernel API is more complex

   

Teams are challenged

● Inclination to seek 1:1 API mapping– Over-emulation of missing calls– Pitfalls in mapping common calls

● Driver model– Weak vs strong– Linux kernel API is more complex

● Protocol stacks– Keep “as is” or offload to Linux?

   

Legacy issues

● Software architecture– BSP code exposed– Application and driver code entangled– Non-public API sometimes used

   

Legacy issues

● Software architecture– BSP code exposed– Application and driver code entangled– Non-public API sometimes used

● Programming model– Flat / physically addressed memory assumed– Supervisor mode assumed– CPU architecture assumed

About RTOS emulators

   

RTOS API emulation?

● A way to mimic the RTOS interfaces– Evades the BSP issue– Source-level approach

● Has real-time requirements– Must run over a deterministic core– Must exhibit real-time properties itself

   

Myths and Reality

● Can (RTOS) API emulation be accurate?– Based on public, dependable interfaces– Relies on a documented feature set

   

Myths and Reality

● Can (RTOS) API emulation be accurate?– Based on public, dependable interfaces– Relies on a documented feature set

Do you trust your vendor documentation?

   

Myths and Reality

● Can (RTOS) API emulation be accurate?– Based on public, dependable interfaces– Relies on a documented feature set

Do you trust your vendor documentation? YES

Should your code rely on undocumented features?

   

Myths and Reality

● Can (RTOS) API emulation be accurate?– Based on public, dependable interfaces– Relies on a documented feature set

Do you trust your vendor documentation? YES

Should your code rely on undocumented features? NO

Should your code expect undocumented behavior?

   

Myths and Reality

● Can (RTOS) API emulation be accurate?– Based on public, dependable interfaces– Relies on a documented feature set

Do you trust your vendor documentation? YES

Should your code rely on undocumented features? NO

Should your code expect undocumented behavior? NO

Therefore, you don't need the original API implementation to emulate it properly.

   

Myths and Reality

● Isn't API emulation slower?

   

Myths and Reality

● Isn't API emulation slower?– Traditional RTOS share basic semantics

● Optimized building blocks can be made● Efficient “window-dressing” follows● Leveraging single address space helps

   

Myths and Reality

● Isn't API emulation slower?– Traditional RTOS share basic semantics

● Optimized building blocks can be made● Efficient “window-dressing” follows● Leveraging single address space helps

– Naive emulation over POSIX not enough● POSIX semantics do not map 1:1● POSIX-based building blocks may work better

   

RTOS emulators shortcomings

● Limited emulation coverage– noarch/generic core services

   

RTOS emulators shortcomings

● Limited emulation coverage– noarch/generic core services

● Require Application / Driver split– BSP code not accessible from user-space– I/O resources live in kernel space

   

RTOS emulators shortcomings

● Limited emulation coverage– noarch/generic core services

● Require Application / Driver split– BSP code not accessible from user-space– I/O resources live in kernel space

● Restricted by Linux protections– No supervisor actions from user-space

Our assets

   

PREEMPT-RT

● Fully native real-time support– Enables real-time virtualization

● Promise of embedded multi-core scalability– Sophisticated locking model– Sophisticated scheduling

   

KVM

● Complete sandboxing● Compatible memory spaces● Device virtualization through host

– virtio● Device emulation through VM

– Qemu-based modelling

   

Introducing Xenomai

● Generic RTOS core● Host abstraction

– Dual kernel– Simulator– (Single image *)

Generic RTOS

SAL

Host system (Linux, Simulator)

(*) Xenomai/SOLO

   

Introducing Xenomai

● Generic RTOS core● Host abstraction

– Dual kernel– Simulator– (Single image *)

● RTOS personalities

VxWorks pSOS VRTX ...

Generic RTOS

SAL

Host system (Linux, Simulator)

(*) Xenomai/SOLO

   

Introducing Xenomai

● RTOS building blocks– Thread scheduling– Synchronization– Interrupt handling– Memory allocation– Timing services Bu

ildin

g bl

ocks

Sched

Synch

IRQ

Memory

Timing

   

Introducing Xenomai

● RTOS building blocks– Thread scheduling– Synchronization– Interrupt handling– Memory allocation– Timing services Bu

ildin

g bl

ocks

e.g.

VxW

orks

taskLib

semLib

msgQLib

wdLib

tickLib

sysLib

Sched

Synch

IRQ

Memory

Timing

   

What about combining?

● Real-time host kernel– PREEMPT-RT

Real-time kernel sub-systems

Real-timeApplication

   

What about combining?

● Real-time host kernel– PREEMPT-RT

● Virtualization core– KVM– QEMU

KVM

Guest

QEMU

   

What about combining?

● Real-time host kernel– PREEMPT-RT

● Virtualization core– KVM– QEMU

● RTOS emulation– Xenomai

KVM

Xenomaiemulator

QEMU

   

Virtualization + RTOS emulation

Improvements● Native real-time● Original programming model● Better emulation coverage● Sandboxing● Legacy device emulation

   

Virtualization + RTOS emulation

Restrictions● No ABI compatibility● Still not 100% source compatible● Reworking the device driver layer still required

Virtualize & Emulate

   

Improved emulation engine

Emulation core● Xenomai guest

– Freestanding mode– RTOS personality

● QEMU– Virtual machine

Emulator

Xenomai

QEMU

Application

   

Improved emulation engine

Handling I/O● Paravirtualized

– Common hw– High bandwidth

● Emulated– Precise emulation– Low bandwidth

Emulator

Xenomai

QEMU

PV

Drivers

EMU

virt

io

Application

   

Improved emulation engine

Native real-time VMM● PREEMPT-RT host

– KVM-enabled

Linux -rt

Emulator

Xenomai

QEMU

PV

KVM

Drivers

EMU

virt

io

Application

   

TODO list

● Real-time aware KVM– Guest scheduling

● Real-time aware QEMU– I/O emulation

● Guest mode Xenomai core● Extended emulation coverage

More applications

   

Could also be used for...

● Application-specific virtual RTOS– Virtual RT appliance (sort of)

   

Could also be used for...

● Application-specific virtual RTOS– Virtual RT appliance (sort of)

● Transition path for in-house RTOS– Consolidate & extend via virtualization

   

Could also be used for...

● Application-specific virtual RTOS– Virtual RT appliance (sort of)

● Transition path for in-house RTOS– Consolidate & extend via virtualization

● Simulation of complex architectures– e.g. modeling Arinc653 systems

Conclusion

   

Legacy RT application to Linux

Today● Rebase on Linux, change design● Keep design, keep proprietary RTOS

   

●Legacy RT application to Linux

Today● Rebase on Linux, change design● Keep design, keep proprietary RTOS

Tomorrow● Combine existing technologies

– Rely on real-time capable virtualization– Couple with accurate RTOS emulation

   

●The End

Thank you for attending

Slide 1Slide 2Slide 3Slide 4Slide 5Slide 6Slide 7Slide 8Slide 9Slide 10Slide 11Slide 12Slide 13Slide 14Slide 15Slide 16Slide 17Slide 18Slide 19Slide 20Slide 21Slide 22Slide 23Slide 24Slide 25Slide 26Slide 27Slide 28Slide 29Slide 30Slide 31Slide 32Slide 33Slide 34Slide 35Slide 36Slide 37Slide 38Slide 39Slide 40Slide 41Slide 42Slide 43Slide 44Slide 45Slide 46Slide 47Slide 48Slide 49Slide 50Slide 51Slide 52Slide 53Slide 54Slide 55Slide 56Slide 57Slide 58Slide 59Slide 60Slide 61Slide 62