1. Philippe GERUM - SourceTrek ELC-Europe 2009 - Grenoble

2. Introduction

3. The context ● Linux about to be natively real-time – PREEMPT_RT close to mainline

4. 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.

5. 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

6. Possible solution ● Combine existing Linux technologies – Native real-time support – Linux-native virtualization – RTOS emulation

7. Common porting strategies ● Port to dual kernel – Over POSIX API – Over API emulator – Over ad hoc API Kernel space User space Real-time core Applicatio n APIs, emulators Linux sub-systems RT driver s Regula r drivers Regula r drivers RT librariesGNU libc

8. Common porting strategies ● Go Linux native – Over POSIX API – Over API emulator Kernel space User space Application Linux sub-systems RT drivers Regular drivers Regular drivers GNU libc Emulators

9. Common porting strategies ● Introduce virtualization – Original RTOS guest – Vendor-specific ● Bare metal hypervisor – Leverage multi-core Bare metal (RT) Hypervisor Linux RTOS SBC / hardware Core

10. Approaches are challenging ● Dual kernel Linux architecture is complex

11. Approaches are challenging ● Dual kernel Linux architecture is complex Libraries Real-time stack Regular Linux Drivers Core Drivers Libraries Apps

12. Approaches are challenging ● Dual kernel Linux architecture is complex – Pressure on application design Libraries Real-time stack Regular Linux Drivers Core Drivers Libraries Apps

13. Approaches are challenging ● Native real-time Linux is complex

14. Approaches are challenging ● Native real-time Linux is complex Libraries Drivers Core Apps Global efficiency General fairness Bounded latency Total unfairness RegularReal-time

15. Approaches are challenging ● Native real-time Linux is complex – Pressure on system configuration Libraries Drivers Core Apps Global efficiency General fairness Bounded latency Total unfairness RegularReal-time

16. Approaches are challenging ● Proprietary virtualization systems?

17. Approaches are challenging ● Proprietary virtualization systems? – Introduce dependencies on vendor ● Hypervisor technology ● Private (PV) Linux kernel ● Original RTOS as guest

18. 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

19. 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

20. Teams are challenged ● Inclination to seek 1:1 API mapping – Over-emulation of missing calls – Pitfalls in mapping common calls

21. 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

22. 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?

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

24. 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

25. About RTOS emulators

26. 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

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

28. 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?

29. 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?

30. 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?

31. 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.

32. Myths and Reality ● Isn't API emulation slower?

33. 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

34. 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

35. RTOS emulators shortcomings ● Limited emulation coverage – noarch/generic core services

36. 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

37. 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

38. Our assets

39. PREEMPT-RT ● Fully native real-time support – Enables real-time virtualization ● Promise of embedded multi-core scalability – Sophisticated locking model – Sophisticated scheduling

40. KVM ● Complete sandboxing ● Compatible memory spaces ● Device virtualization through host – virtio ● Device emulation through VM – Qemu-based modelling

41. Introducing Xenomai ● Generic RTOS core ● Host abstraction – Dual kernel – Simulator – (Single image *) Generic RTOS SAL Host system (Linux, Simulator) (*) Xenomai/SOLO

42. Introducing Xenomai ● Generic RTOS core ● Host abstraction – Dual kernel – Simulator – (Single image *) ● RTOS personalities VxWorkspSOSVRTX... Generic RTOS SAL Host system (Linux, Simulator) (*) Xenomai/SOLO

43. Introducing Xenomai ● RTOS building blocks – Thread scheduling – Synchronization – Interrupt handling – Memory allocation – Timing services Building blocks Sched Synch IRQ Memory Timing

44. Introducing Xenomai ● RTOS building blocks – Thread scheduling – Synchronization – Interrupt handling – Memory allocation – Timing services Building blocks e.g. VxWorks taskLib semLib msgQLib wdLib tickLi b sysLib Sched Synch IRQ Memory Timing

45. What about combining? ● Real-time host kernel – PREEMPT-RT Real-time kernel sub-systems Real-time Application

46. What about combining? ● Real-time host kernel – PREEMPT-RT ● Virtualization core – KVM – QEMU KV M Guest QEMU

47. What about combining? ● Real-time host kernel – PREEMPT-RT ● Virtualization core – KVM – QEMU ● RTOS emulation – Xenomai KV M Xenomai emulator QEMU

48. Virtualization + RTOS emulation Improvements ● Native real-time ● Original programming model ● Better emulation coverage ● Sandboxing ● Legacy device emulation

49. Virtualization + RTOS emulation Restrictions ● No ABI compatibility ● Still not 100% source compatible ● Reworking the device driver layer still required

50. Virtualize & Emulate

51. Improved emulation engine Emulation core ● Xenomai guest – Freestanding mode – RTOS personality ● QEMU – Virtual machine Emulator Xenomai QEMU Application

52. Improved emulation engine Handling I/O ● Paravirtualized – Common hw – High bandwidth ● Emulated – Precise emulation – Low bandwidth Emulator Xenomai QEMU PV Drivers EMU virti o Application

53. Improved emulation engine Native real-time VMM ● PREEMPT-RT host – KVM-enabled Linux -rt Emulator Xenomai QEMU PV KVM Drivers EMU virti o Application

54. TODO list ● Real-time aware KVM – Guest scheduling ● Real-time aware QEMU – I/O emulation ● Guest mode Xenomai core ● Extended emulation coverage

55. More applications

56. Could also be used for... ● Application-specific virtual RTOS – Virtual RT appliance (sort of)

57. Could also be used for... ● Application-specific virtual RTOS – Virtual RT appliance (sort of) ● Transition path for in-house RTOS – Consolidate & extend via virtualization

58. 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

59. Conclusion

60. Legacy RT application to Linux Today ● Rebase on Linux, change design ● Keep design, keep proprietary RTOS

61. ● 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

62. ● The End Thank you for attending