Download Design and Implementation of Safety Critical Real

Design and Implementation of Safety
Critical Real-Time OS.
M. Tech Project Second Stage Report
Submitted in partial fulfillment of the requirements
for the degree of
Master of Technology
by
Momin Matin Nabilal
Roll No. : 06305011
under the guidance of
Dr. Krithi Ramamritham
Department of Computer Science and Engineering
Indian Institute of Technology Bombay
Mumbai
1
Acknowledgments
I am thankful to Dr. Krithi Ramamritham for providing me direction and insight through
numerous discussions. I am also thankful to Mr G. Karmakar, Ms. Vibhooti Verma, Mr
Manish Aggarwal and Mr. Anupam Chomal for their constant help and support. Let me
take this opportunity to thank the open source community to make well implemented and
well documented real-time kernels available. Study of these implementations helped us a
lot in getting started with our project and made our work much simpler than it would
have otherwise been.
2
Abstract
Integrated Real-Time Systems are systems in which applications with different levels of
criticality coexist. The challenges in designing such a system are to achieve strong temporal partitioning and spatial partitioning for ensuring timeliness and isolation respectively.
Design of such an integrated real-time system, named Strongly Partitioned real-time Kernel(SParK), has been proposed by Vibhooti Verma in her MTech project work [Ver06].
Our work aims at the low level design and implementation of SParK. SParK is based on
concepts of Virtual Machine Monitor. The SParK is designed to provide a strongly partitioned operating environment to the partitions that can accommodate individual RTOS
having its own scheduling policy, memory management policy, interrupt handling policy
and inter-task communication etc. SParK has responsibility of scheduling all the partitions in a way that all real-time requirements of all the tasks are guaranteed. Applications
are hosted on different operating system to achieve spatial and temporal partitioning. The
report gives the requirements, motivations, challenges in implementing SParK and also
gives the to-date implementation status of the same. It also covers a detailed study of the
mechanisms employed to ensure temporal partitioning in the system. A detailed explanation of the design and development of a typical individual RTOS, namely Safety Critical
Operating System (SCOS) has also been made. Conclusion and future work follow to end
the report.
Contents
1 Introduction
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5 Requirements Specification . . . . . . . . . . . . . . . . . .
1.5.1 Hardware Initialization . . . . . . . . . . . . . . . .
1.5.2 Partitioning and Partition Management . . . . . . .
1.5.3 Memory Management to ensure Spatial Partitioning
1.5.4 Temporal Partitioning / Partition Scheduling . . .
1.5.5 Timer and Time Management . . . . . . . . . . . .
1.5.6 Interrupt Handling . . . . . . . . . . . . . . . . . .
1.5.7 Device Driver Support . . . . . . . . . . . . . . . .
1.5.8 Hardware Interface . . . . . . . . . . . . . . . . . .
1.5.9 Software Interface . . . . . . . . . . . . . . . . . . .
1.5.10 Communication Interface . . . . . . . . . . . . . . .
1.5.11 Hardware Limitations . . . . . . . . . . . . . . . .
1.6 SParK and Virtualisation . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
3
4
4
5
6
6
6
6
7
7
7
7
7
8
8
8
8
2 Overview of SParK
10
2.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Guiding Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3 Temporal Partitioning
3.1 Two-level Hierarchical Scheduling . . .
3.2 Timer Virtualization . . . . . . . . . .
3.2.1 Hardware Timer Configuration
3.2.2 Virtual Timer Interrupts . . . .
3.3 Fault Containment . . . . . . . . . . .
4 Guest RTOS (SCOS)
4.1 Introduction . . . . . .
4.2 Paravirtualization . . .
4.3 Hypercalls . . . . . . .
4.3.1 Implementation
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
12
12
13
13
14
19
.
.
.
.
20
20
21
21
22
4.4 Design and Implementation .
4.4.1 Processes . . . . . . .
4.4.2 Memory Management .
4.4.3 Scheduler . . . . . . .
4.5 List of Hypercalls . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
23
23
23
24
25
5 Conclusion and Future Work
27
5.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2
Chapter 1
Introduction
1.1
Overview
Integrated Real-Time Systems consist of various real-time applications which ensure safe
running of the systems. A modern Integrated Real-Time System, such as factory automation or a modern vehicle with many features of automation, consists of many applications
running at different criticality levels. To achieve reliability, re-usability, and cost reduction, a significant trend in building large complex real-time systems is to integrate separate
application modules of different criticality on a common hardware platform. Thus different applications hosted on differnet RTOSs will be executed on the same hardware. An
essential requirement of integrated real-time systems is to guarantee spatial and temporal
partitioning among applications in order to ensure an exclusive access of physical and
temporal resources to the applications while sharing computing resources. Partition is
nothing but an entity which gets a share of system resources like memory, CPU time,
device access etc and is capable of hosting a RTOS with to its own scheduling algorithm.
Temporal partitioning ensures that execution time reserved to a partition, would not be
changed either by overrun or by hazardous events of other application. Spatial partitioning guarantees that physical resources, such as memory and I/O space of an application,
are protected from illegal accesses attempted by other partition. Strong Partitioning conceptually means that the boundaries among applications are well defined and protected
so that the operation of an application module in one partition will not be disrupted nor
corrupted by the erroneous behavior of another module in another partition .
Such a Strongly Partitioned real-time Kernel (SParK) has been proposed and designed
by Vibhooti Verma in her Mtech Project [Ver06]. We propose to implement this proposed
SParK design and develop a new safety critical RTOS which would be capable of hosting
different integrated real-time systems. We also intend to design and develop a new RTOS,
namely Safety Critical Operating System (SCOS), which will be capable of running in
an individual partition on top of SParK. This report highlights the salient features and
requirements of SParK and gives an account of the to date implementation status of the
same.
3
1.2
Outline
The report is outlined as follows. In this chapter motivation and challenges involved
in design and implementation of SParK are covered. Also the system description and
requirement specifications for SParK are described. This chapter also describes how
virtual machine techniques are useful in implementing the SParK. Chapter 2 gives an
architectural overview of SParK, our design and implementation guiding principles and
system assumptions. In chapter 3, we describe the mechanisms that have been employed
to achieve temporal partitioning in the system. Chapter 4 gives the requirements, design
and to date development of the Safety Critical Operating System (SCOS). This is followed
by Conclusions and Future work.
1.3
Motivation
Following are the motivations behind building SParK as identified in [Ver06]:
Fault Containment : Since the system under consideration consists of applications with
different criticality, misbehavior of any application and in particular a non-critical
application might affect other applications that are safety critical. The two hazards
that are common to such a system are: (i) a fault in one application might corrupt
other applications code, data and control signals and (ii) a faulty application might
affect the ability of other applications to access a shared resource such as processor or
an I/O device. SParK ensures fault containment by encapsulating the applications
depending on their criticality in various partitions which are spatially as well as
temporally isolated.
Modular Verification and Validation (V&V) of Applications : As applications are
hosted on different partitions, different levels of V&V process can be used depending
on the criticality of the partition. Rigorous V&V of the whole system in a traditional design by considering all applications at a time requires a lot of effort. Any
compromise in this effort might lead to a weak and unsafe system. With SParK
architecture, each partition can be verified and validated independently (except
partitions requiring inter-partition communication) thereby reducing the overhead.
The critical partitions can be subjected to rigorous V&V whereas non-critical partitions can have nominal V&V. If a new partition with new application is added to
the system, it can be verified and validated independent of other partitions.
Efficient Utilization of resources : The common practice in design and implementation of integrated real-time system is that, applications with different criticality
are hosted on different machines. This approach requires more hardware resources
(I/O devices, processor, memory, etc.) and hence leads to (i) under utilization of
resources (ii) more effort to manage the system (iii) increase in the development cost
of such a system. SParK efficiently utilizes the resources by sharing them among
partitions and hence reduces the overall cost of the system.
Application Specific Operating System : Certain applications developed on a specific operating system perform better when they are hosted on the same operating
4
system. Hence, when different partitions are hosted on the same machine, better
performance can be extracted from them if they are allowed to run on the operating
system of their choice (i.e., for which they were developed). Also, the application
does not need any modifications to run on this new platform.
Schedulability Analysis : Global schedulability analysis considering timing attributes
of all the tasks of all the applications in the system leads to large scheduling overhead. Also, addition of a new task in any application requires schedulability analysis
of the whole system. SParK carries out local schedulability analysis for tasks of each
partition, independent of other partitions. Its global proportional sharing policy ensures that this localized analysis is sufficient.
1.4
Challenges
Listed below are the challenges in implementing SParK as identified in [Ver06].
• Running multiple operating system concurrently on common hardware requires complex resource management techniques.
• Placing an application on separate physical machine allows it to have exclusive
access to the systems resources, and thus have better performance than if it had to
share that system with other applications. Maintaining the same performance while
sharing resources among partitions is a big challenge.
• Since complete temporal isolation has to be ensured, two level hierarchical scheduling algorithm has to be used which results in performance bottleneck due to partition
switch overhead. Scheduling partitions with minimum number of partition switches
is a challenging issue.
• As SParK is a resource manager of the entire system, it runs in privileged mode
whereas other operating system run in user mode. Guest RTOS running in user
mode, trap SParK while trying to execute privileged instruction. SParK emulates
privileged institutions for guest RTOS. Emulation of instructions leads to context
switch overhead and performance degradation. Minimizing emulation overhead
by replacing privileged instructions to equivalent unprivileged instruction in guest
RTOS, along with maintaining integrity of entire system is challenging.
• Some processor architectures do not support complete virtualization of their instruction set. To make them virtualizable either OS has to be modified or on fly binary
translation mechanism has to be used. Both techniques require lot of efforts.
• Interrupt delivery to deactivated partitions meeting all timeliness requirement without performance degradation is very difficult to implement. Partitions are in deactivated state when they are not running on real-processor
• The guest RTOSs hosted by partitions require different timer resolutions, share
same hardware timer device. The challenge in SParK is to generate and deliver
virtual timer interrupt in such a way that apparent time in guest RTOSs never lags
real-time beyond some tolerance range.
5
1.5
Requirements Specification
The aim of this project is to develop a Strongly Partitioned Kernel (SParK) for Integrated
Real-Time Systems that will support multiple RTOSs along with their applications of different criticality running on the same processor. A System architecture for integrated
real-time system should provide a strongly partitioned operating environment to the partitions so as to accommodate multiple RTOSs, each having its own scheduling, memory
management, interrupt handling policies and inter-task communication facilities, etc. The
Strongly partitioned Kernel should remain at the lower level (than the application OSs)
and should provide only minimal necessary functions, such as partition management and
scheduling, memory management and protection for partitions, interrupt handling, timer
services, safe inter-partition communication and device driver support. Thus, SParK will
be responsible for managing system resources and maintaining integrity of the the entire
system.
Mentioned below is a formal requirements specification for SParK.
1.5.1
Hardware Initialization
The SParK kernel needs to initialize the following hardware:
• Programmable Interrupt Controller
• Programmable Timer/Counter
• RS-232 serial port
• Ethernet port
• Display Terminal (CRT) port
• Printer
1.5.2
Partitioning and Partition Management
The prime requirement of SParK is fault containment within partitions. It means that
the partitioned system will provide fault containment equivalent to an ideal system in
which each partition gets the feeling of being allocated separate processor and peripherals
and that inter-partition communications being carried on dedicated channels.
1.5.3
Memory Management to ensure Spatial Partitioning
SParK needs to provide facility to create partitions in such a way that memory allocated
to one partition will be protected from any unauthorised ‘write’ attempt by software
running in other partitions. To ensure Spacial Partitioning hardware mediation provided
by Memory Management Unit(MMU) on the processor may be used. Further, facility for
memory protection of individual tasks running on one partition(Guest RTOS) needs to
be provided.
6
1.5.4
Temporal Partitioning / Partition Scheduling
Temporal partitioning ensures that execution time reserved to a partition, would not be
changed either by overrun or by hazardous events of other application(partition). SParK
should ensure that no software in any partition should be able to monopolize the CPU
usage or be able to crash the CPU. Thus, each partition should get a feeling of running
over a separate processor at a slower speed than the actual processor(virtualised CPU).
1.5.5
Timer and Time Management
SParK and partition’s local RTOS will be synchronised to and scheduled based on the
timer tick generated by SParK using the underlying hardware timer. In other words, each
partition will maintain a local time tick that is synchronised to the global reference clock,
the SParK generated tick. Therefore, the local time tick interval of a partition will always
be a multiple of SParK tick interval.
1.5.6
Interrupt Handling
There are two aspects of interrupt handling
• There can be an interrupt to be handled by a particular partition whose timing is
out of phase with the real time when the partition gets its CPU share.
• Third party RTOS may use interrupt-enable and interupt-disable command to guard
critical sections in implementing system calls, which can affect the partition schedulability.
In SParK environment, suitable mechanism needs to be used to handle the above interrupt
handling issues to guarantee a bounded response to interrupts.
1.5.7
Device Driver Support
The SParK kernel needs to provide fault tolerent drivers for the following devices
• RS-232 serial communication
• Ethernet
• Terminal
• Printer
1.5.8
Hardware Interface
The SParK system should be ported on the following architectures
• Intel x86 architecture
• PowerPC based in-house board
7
1.5.9
Software Interface
Third-party RTOSs need to be ported to SParK. The necessary changes to support paravirtualization approach need to be identified and implemented. Currently recognised
candidate RTOSs are
• Stand Alone RTLinux (SARTL)
• µCOS-II
1.5.10
Communication Interface
Following communication interfaces for communication with the outside world need to be
provided
• RS-232 serial communication
• Ethernet
1.5.11
Hardware Limitations
The PowerPC 7447A CPU provides with only 2 execution privilege levels. Present virtual
systems exploit 3 execution privilege levels. SParK needs to adapt to this limitation.
1.6
SParK and Virtualisation
The concept of running more than one RTOS on a common hardware is very similar to
that of virtual machine environment where various operating systems run on top of Virtual
Machine Monitor(VMM). Virtualization provides an illusion to all the guest OS that they
are having exclusive access of all the resources, which is a requirement in SParK too. In
our Integrated Real-Time System, SParK will be responsible for providing virtualization
of all the resources like CPU, memory, i/o devices, timers and interrupts. The basic
difference between Virtual machine architecture and SParK is that SParK has to ensure
real-time guarantees. Ensuring real-time guarantees requires predictability in primitive
operations of operating systems. SParK needs to have temporal and spatial partitioning
at its core design. Although there is significant similarity between both systems, strict
timeliness requirements by SParK makes it more complicated. Real-Time task’s timing
constraints necessitate basic OS primitive to be predictable.
Existing virtualization techniques provide the basic framework to achieve SParK. Virtualization of system resources can be achieved in two ways.
Full system virtualization : It provides a virtual replica of the system’s hardware so
that guest OSs and software may run on the virtual hardware exactly as they would
run on the original hardware. This allows any guest OS to run on top of VMM.
Paravirtualization : It is a virtualization technique that presents a software interface to
virtual machines that is similar but not identical to that of the underlying hardware.
This requires an OS to be explicitly ported to run as a guest OS on top of the virtual
machine monitor.
8
Virtualization provides all guest RTOSs illusion of accessing all the resources exclusively. In our Integrated Real-Time Systems, SParK will be responsible for providing
virtualization of all resources like CPU, memory, timers and interrupts etc. Since applications running on different partitions can request services from each other, SParK
should provide safe inter-partition communication mechanism which satisfies real-time
timing constraints. Various existing approaches for virtualization of system resources
and our approach to do the same have been described in detail in [Ver06]. Overall, the
Paravirtualization method of resource sharing shall be employed.
9
Chapter 2
Overview of SParK
SParK (Safety Partitioned Kernel) is a thin microkernel that runs directly above the
machine hardware. It runs in the highest privilege level and has complete control over
the hardware. Many Guest RTOS with their own set of tasks can run over the SParK in
different partitions and communicate among themselves to achieve a common goal.
2.1
Architecture
Figure 2.1: Architecture of SParK
The above figure shows the architecture of SParK. Bottom most layer is the hardware
layer over which SParK run at the highest privilege level ‘ring 0’. Over SParK, there
can be one or more number of Guest RTOS running. These guest RTOS can be full
fledged real-time operating system that can have their own scheduling algorithm, memory
management and inter task communication etc. The tasks in a partition run at the lowest
privilege level ‘ring 3’, also known as user level.
10
2.2
Guiding Principles
There are times when there can be more than one approach available to implement a
certain functionality. To decision of the eventually chosen approach largely depends on
the requirement of the project and also the guiding principles. For our project too, we
define certain guiding principles which helps us to choose one approach amongst many, if
available. These principles are :
• SParK layer should be as thin as possible. This principle states that, SParK layer
should do only the minimal tasks that are required. Rest all should be taken care
by the Guest OS. This is similar to approach used in developing microkernels. This
helps to implement a clean and almost bug free code. The aim is to build such
a system that can be as close as possible to be verifiable although this is not the
requirement.
• Code should be as simple as possible and easily understandable. To achieve this goal,
it is acceptable to sacrifice the efficiency of the system rather than implementing a
complex system which is difficult to understand. In other words we can compromise
on efficiency rather than complexity.
2.3
Assumptions
Designing of any new system is based on some assumptions. The various assumptions for
the SParK system are as follows:
• All the tasks are periodic in nature and do not terminate ever.
• The worst case execution time and periodicity of each task will be known a priori.
• The number of tasks in any application is fixed, i.e. no dynamic task would be
created or destroyed during the runtime.
• SParK is the diskless system, which means that the whole system along with the
guest RTOSs fits in the physical memory.
• No dynamic memory allocation and no Demand Paging is required once the system
starts executing after system initialization.
The rest of the report discusses further details of the SParK system. Namely temporal
partitioning and design and development of SCOS have been covered in this report. To
study spatial partitioning please refer to report presented by Manish Aggarwal [Agg08].
The system scheduler deployed in SParK has been explained in detail by Anupan Chaumal
in his report [Cha08].
11
Chapter 3
Temporal Partitioning
One of the most fundamental differences between SParK and a generic Virtual Machine
Monitor (VMM) is that of ensuring temporal partitioning. Unlike a generic VMM, SParK
hosts real-time RTOSs running time critical applications. Thus, it is extremely important
to ensure that execution time reserved to a partition, would not be changed either by
overrun or by hazardous events of other applications.
Temporal partitioning has been ensured under SParK through the following mechanisms
• Two-level Hierarchical Scheduling
• Timer Virtualization
• Fault Containment
3.1
Two-level Hierarchical Scheduling
Two-level hierarchical scheduling is used to achieve temporal partitioning in SParK. Lower
level scheduler is responsible for scheduling partitions in such a way that all real-time
tasks running in guest RTOSs hosted on partitions meet their deadlines whereas upper
level schedulers (scheduler in respective guest RTOSs) are responsible for scheduling tasks
within that particular partition. The two-level hierarchical scheduler achieves temporal
partitioning by allocating fixed fractions of time to partitions.
Vibhooti had compared two two-level hierarchical schedulers in her thesis [Ver06], viz.
Static Cycle Driven Scheduling [Kim01] and Dynamic-Priority-Driven Open Environment
Scheduling. It was observed that SParK system requirements are fulfilled using both
the schedulers, but the Static Cycle Driven Scheduling was much more simpler and less
complicated than the Dynamic-Priority-Driven Open Environment Scheduling. Since our
implementation principles are simple design and ease of implementation, we shall be using
Static Cycle Driven Scheduling as the two-level scheduler.
The two-level scheduler requires the inter-arrival period and worst-case execution time
of all the applications of all the partitions. Assume that partition Pk has n applications
A1 , A2 ...An with inter-arrival period T1 , T2 ...Tn and worst case execution time C1 , C2 ...Cn
respectively. This two-level scheduler will come up with an offline RMA (Rate Monotonic
12
Analysis) based analysis to come up with a pair (αk , ηk ) for partition Pk . The pair signifies
that tasks under partition Pk are schedulable if Pk is given αk ∗ ηk of CPU time every
ηk units of time. Using these (αk , ηk ) pairs, the two-level scheduler comes up with a
constant cyclic schedule with a fixed cycle period η and partition shares α1 , α2 ...αn . This
offline analysis forms the lower level static cyclic scheduler run by SParK. The upper level
scheduler is implemented individually by the guest RTOSs running on separate partitions.
This scheduler needs to be a fixed-priority preemptive scheduler.
The low-level cyclic scheduler has been implemented by SParK by collecting the ηk
and the α1 , α2 ...αn values for the n partitions from a predefined position in the memory,
which is embedded in the SParK executable binary at compile time. The scheduler is
executed at fixed intervals of time on every hardware-timer interrupt as the Interrupt
Service Routine (ISR). Similarly, the upper level scheduler is executed periodically by
every guest RTOS running in each individual partition in its own ISR. Since the system
has only one hardware timer interrupt which is owned by SParK, it is the responsibility of
SParK to make the guest RTOSs available with Virtual Timer Interrupts (VTI) at fixed
and predictable intervals of time in a reliable manner. This process of timer interrupt
sharing amongst the guest RTOSs is the process of Timer Virtualization which we shall
discuss next.
3.2
Timer Virtualization
Virtualizing timers accurately is crucial, since exact timing behavior are very important
in time critical real-time systems. It is essential to keep track of the passage of time
in both, the SParK(VMM) as well as the guest RTOSs running in the partitions. On
physical machines, a general purpose OS has a timer device which keeps interrupting on
fixed intervals according to timer resolution set in the device. Virtual machines in which
a RTOSs run, cannot exactly duplicate the timing behavior of a physical machine as they
are not running all the time and they share the same timer device. Thus, it is very crucial
that the timer device is reliably and efficiently shared amongst the guest RTOSs. Before
discussing the issues and mechanisms available for timer virtualization, we shall discuss
briefly about the hardware timer configuration in the next section.
3.2.1
Hardware Timer Configuration
Computer machines contain several different devices that can be used to keep track of
time. Different operating systems make different choices about which of these devices
to use and how to use them. Using several of the devices in combination is important
in many operating systems. Sometimes, one device that runs at a known speed is used
to measure the speed of another device; sometimes a fine-grained timing device is used
to add additional precision to the time read from a more coarse-grained timing device.
Thus, it is necessary to support all these devices in a virtual machine like SParK. In
short, SParK needs to provide a virtual interface to the guest RTOS which gives it a
functionality similar to the that provided by the physical timer hardware.
Historically, a number of devices have been available like PIT (Programmable Interval
Timer), CMOS RTC (Real Time Clock), Local APIC (Advanced Programmable Inter13
rupt Controller) Timers, ACPI (Advanced Configuration and Power Interface) or Chipset
Timer and TSC (Time Stamp Counter). No matter what be the underlying physical
timer device, the guest RTOS requires periodic interrupts at pre-defined regular intervals
in order to maintain the system time.
Currently, in our system implementation, we have programmed and configured the
most common and widely used of these timer devices, viz PIT (Programmable Interval
Timer).
Programmable Interval Timer
The Programmable Interval Timer (PIT 8254), also called the System Clock, is a very
useful chip for accurately generating interrupts at regular time intervals. The chip has 3
channels of which Channel 0 is tied to IRQ0, to interrupt the CPU at regular times and
Channel 2 is connected to the system speaker.
In a RTOS, almost all applications are periodic in nature and critically dependent on
the time to know when they should invoke, execute or suspend. The only way to keep
track of time in a RTOS is to maintain a timer that would interrupt the CPU after specified time. Timer interrupt is the basic interrupt in any OS to account for the passage of
time precisely. The PIT provides two modes of timer configuration: Oneshot and Periodic
mode.
• Oneshot mode:- In oneshot mode, timer is programmed to generate a single interrupt event after a predefined interval of time. The time interval is defined by
the value of the count programmed in the PIT. Oneshot mode may be used to
programme the timer to interrupt for next event that could preempt the current
running process or some predefined specific time (5ms in our case), which ever is
earlier. This mode gives us finer granularity in defining inter-interrupt interval and
helps the RTOS in providing good response time. But this mode has a time overhead
involved in programming the PIT after every timer interrupt delivery.
• Periodic:- In periodic mode, the timer is programmed to interrupt CPU after every
specified interval of time. In this mode, timer is programmed only once so, there is
no overhead of programming the timer again and again. But with this method we
loose the discretion provided by oneshot timer of programming every intertick time.
SParK system will host guest RTOSs with a well defined inter-interrupt time period
requirement. Thus, the fine granularity advantage present in one-shot mode is not of an
advantage in SParK. The periodic timer mode blends perfectly with SParK requirement,
removing the overhead of reconfiguring the timer after every interrupt. Currently we are
using the periodic mode timer with timer tick interval of 5ms.
3.2.2
Virtual Timer Interrupts
As discussed earlier, the guest RTOSs require reliable timer interrupts at predefined intervals in order to accurately maintain system time, which would be use to make scheduling
14
decisions. This section discusses the issues involved and the possible mechanisms in providing these interrupts to the guest RTOSs. Since these are not actual hardware timer
interrupts, they have been termed as Virtual Timer Interrupts.
Issues
Issues in timer virtualization are as follows:
• Since only one virtual machine is active at any instance, timer interrupts can not
be handled immediately by deactivated virtual machines. Keeping track of time in
deactivated partitions is a big challenge.
• In Integrated Real-Time System, many guest real-time operating systems demanding different timer resolution, are sharing the same timer device. Typically an operating system has its own dedicated timer device and thus it sets its timer frequency
according to required resolution. Since the timer is being shared, its frequency can
not be set for a particular frequency required by some operating system. SParK
needs to generate timer ticks for all guest RTOSs according to their required timer
resolution.
The second issue has been handled by enforcing the guest RTOSs to configure timer with
a period that is an exact multiple of the period of the hardware timer interrupt configured
by SParK. In order to overcome the first issue the following solutions are possible:
• Virtual interrupts can be delivered to every guest RTOS which has a timer interrupt
due, irrespective of the fact whether its partition is currently active (i.e., scheduled
by SParK’s lower level scheduler) or not. Thus, every guest RTOS gets an opportunity to keep its system time up to the mark, as it receives all of its timer interrupts
at regular intervals of time. This scheme has a very serious disadvantage though.
An idle virtual machine still has to process hundreds of interrupts per second. Even
when a virtual machine is otherwise completely idle, it must run briefly each time
it receives a timer interrupt. If a virtual machine is requesting 100 interrupts per
second, it thus becomes ready to run at least 100 times per second, at evenly spaced
intervals. If N virtual machines are running, processing the interrupts imposes a
background load of 100*N context switches per second (even if all the virtual machines are idle). This also requires SParK to keep track of due timer interrupts for
all of its guest RTOSs, making the SParK layer more complex, which is against our
system design and implementation policy.
• Another method could collect the timer interrupts due for a particular guest RTOS
while it was inactive and deliver it to the guest RTOS only when it is active. Since
the guest RTOS has pending timer interrupts, the time maintained by guest RTOS
(guest time) gets behind the real time elapsed. For the guest time to be able to catch
the real time, the SParK will deliver timer interrupts to the guest RTOS at a faster
rate. For example, if a guest RTOS requests for timer interrupts every 10 msec, it
could be provided with pending interrupts every 2 msec. This would increase the
guest time with a speed up of 5 (10msec/5msec). Once the guest time equals the
real time interrupts can be delivered at normal intervals to the guest RTOS. This
15
scheme is very usefull in systems that need to provide full virtualization [VMw05].
But this scheme has a very serious drawback for time-critical real-time applications.
The guest RTOS has inaccurate real time when the catching up period (by delivering
interrupts at a faster rate) is going on. All scheduling decisions taken during this
time cannot be guaranteed to be correct. Hence, this method gets completely ruled
out for real-time applications.
• One may deviate from the previous solution by delivering timer interrupts only to
the active partition, but not pursue the catch up business. Thus, every active partion
will receive interrupts only at normal intervals of time. But this would lead to guest
time lagging behind the real time. In order to overcome this shortcoming, the guest
RTOS can update its guest time to real time on its every fresh invocation/scheduling
by SParK. The time updation can be done through a hypercall 4.3. This approach
can be very effectively used by systems providing paravirtualization solutions.
Our system is a simpler system as we do not need plethora of timer devices but it
is made difficult by the fact that we can not give up while catching up. Our tasks have
nothing to do with the absolute time and sudden increase in time are fine if all the tasks
are schedulable. Every virtual machine (partition) gets enough cpu time so that all its
tasks are schedulable is ensured by the scheduling algorithms. We need to have the real
time information to know when a task’s resume time becomes greater than the current
real time and hence the task needs to be invoked.
With these requirements in mind, the last solution fits best for our system. The
solution avoids the complexity involved with catch up interrupts of the second solution,
and also the extremely large frequent context switches of the first solution. We suggest a
minor change in the scheme to improve efficiency. Instead of using hypercalls to update
the real time, the guest RTOS may register a predefined memory location with SParK
to update the real time. Thus, on every partition switch, SParK will update the newly
scheduled partitions registered memory with the real time. The guest RTOS can read the
real time from this location. A better optimization can be made by the guest RTOS by
registering its own guest time maintaining memory location with SParK. This will relieve
the guest RTOS from the task of copying the real time from some other location to the
guest time maintaining memory location.
This approach will work perfectly fine with any fixed priority driven preemptive
scheduling algorithm at the guest RTOS (higher) level. But it may not work if partition uses static table driven algorithm for scheduling. Partition will have to know which
slots it gets from lower layer partition scheduler in SParK and accordingly schedule its
tasks only in the slots allocated to it. This is not very generalized and hence we may
need to go for adding constraints to lower level scheduling. While deciding the partition
cycle for the partition, slot size of the partition applying static scheduling for tasks within
it should be taken into account. One unit time of partition having capacity c, will be
equivalent to 1c unit time in SParK (where c < 1, unit time of partition has to be multiple of unit time of SParK). The SParK will have to deliver a tick to a partition having
partition
static scheduling every 1c ∗ timerresolutionof
time unit. This may lead to many context
timerresolutionof SP arK
switches at the lower level SParK cyclic scheduler. Hence, we restrict the guest RTOSs to
implement only fixed priority preemptive schedulers, and dissuade them from using static
table driven scheduling.
16
Implementation
Timer interrupt is a very frequent event during the system execution. Hence it is very
important that the mechanism of delivering virtual interrupts to the guest RTOSs is
time efficient. This section discusses the possible interrupt delivery mechanisms, selected
approach and implementation details of the selected approach. Following discussion is
with reference to the x86 processor [Int04] only, which is the current platform on which
the system is being deployed.
Whenever a guest RTOS wants virtual timer interrupts facility from SParK, it has to
register itself with SParK through a hypercall (explained in section 4.3) named
spark RegisterTimer(long lPeriod, long lHandler, long ptrRealTime)
where,
• lPeriod: is the time resolution in nanoseconds. This value needs to be an exact
multiple of SParK’s hardware timer resolution
• lHandler: is the address of the guest RTOS timer ISR handler
• ptrRealTime: is the memory location which needs to be updated by SParK by real
time after every fresh invocation/scheduling of the guest RTOS
While a particular guest RTOS is active (scheduled by SParK), whenever a hardware
timer interrupt occurs, the current control of execution can be either at
• ‘ring 2’ in a guest RTOS kernel area executing a system call for the user tasks
• ‘ring 3’ in the user area, running a user task
Thus, whenever SParK is required to deliver virtual timer interrupt to the guest RTOS the
control of execution needs to go from the SParK hardware timer ISR to the virtual timer
ISR of the guest RTOS (lHandler) and from there to the code that was being executed
before the hardware timer interrupt occurred. This code could be either at ‘ring 2’ or
‘ring 3’. Here we have two possible ways of transfer of control,viz:
• transfer of control from the interrupted code to the SParK ISR, from SParK ISR
to guest RTOS ISR, from guest RTOS ISR back to SParK ISR, and from SparK
ISR back to interrupted code. This is similar to the way signals are implemented
in Linux OS [BC03]. In Linux, once a user level signal handler is executed, it is
forced to execute a software interrupt to give the control back to the kernel. This is
done to enable delivery of all the pending signal handlers for a particular process.
This method has the drawback of time inefficiency due to the software interrupt
required to pass control back to the kernel. Also, SParK does not require back the
control after guest RTOS ISR execution for any further decision making. Thus the
advantage of this method does not apply to our requirement.
• transfer of control from the interrupted code to the SParK ISR, from SParK ISR
to guest RTOS ISR, from guest RTOS ISR directly back to interrupted code. This
method saves the time spent due to the forced software interrupt in the previous
17
method. Also, since control goes directly to interrupted code, time spent in the
indirection caused by transferring control back to SParK is also saved. This method
is more complex to implement compared to the previous method, but the time
efficiency advantage outweighs this disadvantage.
Due to its obvious advantages, the later of the two mechanisms has been deployed to
implement virtual timer interrupts. But, as mentioned earlier, it has a complex implementation, which we shall discuss below.
Whenever a hardware timer interrupt occurs, the kernel stack of the ‘ring 0’ ISR
handler present in SParK will contain the stack segment (SS), top of stack (ESP), processor special flags (EFLAGS), code segment (CS) and interrupted code’s program counter
(EIP) present from bottom towards the top. These values can either be of ‘ring 2’ or
‘ring 3’, depending whether a system call was interrupted or a user code execution was
interrupted. The guest RTOS ISR handler (lHandler), where we intend to transfer the
control at the end of ‘ring 0’ SParK ISR, is in the guest RTOS at ‘ring 2’.
If the interrupted code is at ‘ring 2’, we have to transfer control from ‘ring 0’ (SParK
ISR) to ‘ring 2’ (guest RTOS ISR), and then from ‘ring 2’ (guest RTOS ISR) to ‘ring 2’
(interrupted code in guest RTOS). The transfer from SParK ISR to guest ISR is easily
achieved by changing the EIP value on the SParK ISR stack by lHandler, the address of
guest ISR. The iret instruction at the end of SParK ISR will transfer control to the guest
ISR. But, in order that the guest ISR returns control properly to the interrupted code, it
is necessary that the guest ISR stack is decorated in such a way that the iret instruction
at the end of the guest ISR gives the desired result. This needs to be done in the SParK
ISR alone, since SParK ISR has the interrupted code’s program counter (EIP) and code
segment on its ‘ring 0’ stack. The SParK ISR puts these two values (CS and EIP) on
the interrupted program’s stack. The top of stack (ESP) needed for this purpose is also
present on SParK ISR’s ‘ring 0’ stack. Thus, proper transfer of control is ensured.
Now, if the interrupted code is at ‘ring 3’, we need to transfer control from ‘ring 0’
(SParK ISR) to ‘ring 2’ (guest RTOS ISR), and then from ‘ring 2’ (guest RTOS ISR) to
‘ring 3’ (interrupted user code). The transfer from SParK ISR to guest ISR is similar to
the previous case, that is changing the EIP value on the SParK ISR stack by lHandler, the
address of guest ISR. But along with this some more changes are required. First of all the
SS and CS values on the ‘ring 0’ SParK ISR stack are not of ‘ring 2’, but instead of ‘ring
3’. These need to be changed to ‘ring 2’ values. Since SParK has access to the Global
Descriptor Table (GDT), it can easily retrieve these values and write them at appropriate
locations on its own stack. Now the iret instruction at the end of SParK ISR will do the
needful. But transfer of control from guest ISR (at ‘ring 2’) to interrupted user code (at
‘ring 3’) needs more to be done than the previous case. SParK has no knowledge of guest
RTOS’s ‘ring 2’ top of stack (ESP). There is no way it can be made available to SParK
unless the guest RTOS itself does it. The best time for the guest RTOS to do this is at
the time of switching to a new user task in its scheduler. This is because OSs usually
maintain a separate kernel stack for every user application. This value needs to be stored
by SParK and used in this special case. Once the top of the guest RTOS ‘ring 2’ stack
is known, it can be appropriately decorated to ensure that iret at the end of guest ISR
transfers control to the interrupted code in user area.
18
3.3
Fault Containment
Other than the mechanisms discussed till now, an important feature to ensure temporal
partitioning is fault containment. It may so happen that a corrupt guest RTOS (either on
purpose or due to buggy implementation) could get the whole system down. If the guest
RTOS executes an instruction like hlt which halts the whole system, then this could lead
to complete breach of temporal partitioning. We have taken care of such situations by
not giving the guest RTOS privileges to execute such privileged instructions. Privileged
instructions can be executed only by code running at ‘ring 0’. In our system, only SParK
microkernel runs at ‘ring 0’. Guest RTOS kernels run at ‘ring 2’. Hence all privileges
instructions and program executions that lead to system crash are caught by SParK as
exceptions. These exceptions could be page faults (which are not normally possible in
our system which is completely in-memory), general protection errors (due to execution
of privileged instructions), stack segment errors (due to illegal stack manipulations) etc.
The guest RTOS responsible for the exception is identified by SParK and is made inactive
completely. The concerned guest RTOS is never scheduled again. Since we have a static
cycle driven scheduler at the SParK level, we end up with spare time slots due to the
shutdown of this corrupt partition. This extra time may then be lent to an idle partition
in the system which may be used to handle soft aperiodic tasks. Or else, it could be lent
to the Virtual Interrupt Partition [Ver06] to increase its interrupt serving capacity.
19
Chapter 4
Guest RTOS (SCOS)
4.1
Introduction
Along with development of the SParK microkernel, our work also aims at the developing a
typical full fledged guest RTOS, named Safety Critical Operating System (SCOS), capable
of running in a virtual machine partition. The aim of Safety Critical Operating System
(SCOS) is to develop a stand-alone RTOS for safety critical system that will implement
memory protection between all processes at run time. The SCOS shall provide priority
based preemptive scheduling while round robbin scheduling for tasks having same priority
and all the tasks shall be managed in strict and deterministic time frame. The SCOS needs
to perform following jobs:
• Manage the interface to the underlying computer hardware.
• Task Management
• Interrupt Management
• Memory management with protection
• Timer Services
• Inter-task communication
• Provide common services including I/O to standard devices such as CRT displays,
printer etc. including RS-232 communication and TCP/IP on Ethernet.
The SCOS design and implementation also needs to be:
• Scalable
• Portable
20
4.2
Paravirtualization
As mentioned in the section on SparK and Virtualization 1.6 earlier, the SCOS will be
running as a guest RTOS in a virtual machine (VM) partition on top of the SParK VMM.
Thus, the SCOS can be developed following the principles of either full virtualization or
paravirtualization. The major difference between full virtualization and paravirtualization
is that a paravirtualized OS is aware that it is running on top of a VMM, whereas a fully
virtualized OS gets a feeling of running directly on top of the physical machine. Full virtualization has the obvious advantage that off the shelf RTOSs can be directly deployed
on SParK. Paravirtualization on the other hand requires changes in the guest RTOSs
source code before deploying it on a particular VMM. This also renders the guest RTOS
implementation non-portable to other VMMs (in general). But, in the case of time critical
real-time systems (as is our case), full virtualization has some serious disadvantages compared to paravirtualization. Virtualization techniques deployed in full virtualization are
overall not as efficient as in paravirtualization.For example, on the fly binary translation
in full virtualization requires code characterization and look-up, which is time consuming
with unpredictable execution timing requirements, which is very undesirable for real-time
systems. This lack of time efficiency is the cost that needs to be paid for deploying unmodified OSs. Also, as explained in section of Virtual Timer Interrupts 3.2.2, the full
virtualization technique of deploying virtual timer interrupts to the guest RTOSs is completely ruled out for time critical real-time OSs. Paravirtualized OSs on the other hand,
are much more efficient and deterministic in terms of execution time. Also, virtualization
techniques used under paravirtualization suit very well for real-time systems. Hence, we
develop our SCOS under the techniques of paravirtualization. The concept of hypercalls
is very important in paravirtualization which will be discussed next.
4.3
Hypercalls
Hypercalls under SParK are analogous to system calls under a normal operating system
like unix. They provide an interface to the guest RTOSs to receive services like hardware
resource access, common resource sharing etc. from SParK. Hypercalls assist fulfill the
following requirements:
1. To provide an interface for the guest RTOSs to access the hardware resources
2. To enable mitigation of SParK during hardware resource access by guest RTOSs
3. To monitor and authenticate critical/shared resource accesses by guest RTOSs
4. To enable resource sharing (eg terminal) amongst the guest RTOSs
As enumerated in the requirements, hypercalls act as a very convenient mechanism to
monitor the activities of guest RTOSs. All critical resource accesses/sharing by guest
RTOSs can be monitored by SParK using hypercalls. Also, hypercalls enable shared
resource (like terminal) sharing amongst the guest RTOSs.
21
4.3.1
Implementation
Hypercalls are very similar to functions calls that a process can make to a usefull function
library. But two major differences between hypercalls and a normal function call are that:
• Hypercalls are made between executions running at two different execution levels (
between guest RTOS at ‘ring 2’ and SParK at ‘ring 0’). Whereas, function calls are
made at the same execution level.
• Function calls are made to procedures/functions present in the same binary of execution. Thus, at compile time, the linker does the necessary symbol resolutions
to direct the function calls to their definitions. Hypercalls, on the other hand, are
made between two different binaries (the guest RTOS binary and the SParK kernel).
Thus compile time symbol resolution is not possible.
These problems are similar to those that are faced by system calls between a user level
task and the OS kernel under normal OSs like unix. Hence the solution too is similar
to that employed in system calls. The solution is split into two parts, with part of the
activities needed to be done by the guest RTOS and the remaining part by SParK.
In Guest RTOS
Hypercalls have been implemented in the guest RTOSs using the software interrupt 0x82.
(for its configuration details see the implementation details in SParK below). Software
interrupts are traps which provide a very convenient mechanism to switch between execution privilege levels during far (system) calls. Every hypercall is assigned a unique
number which is registered between the guest RTOS and SParK at compile time itself.
Hypercalls with at most 6 function parameters can be implemented. The parameters need
to be put into register ebx, ecx, edx, esi, edi, ebp for parameter 1, 2, 3, 4, 5, 6 respectively.
Convenient macros have been defined for the same.
The steps involved at Guest RTOS side in calling a hypercall are as follows:
1. Select the hypercall; this is done by loading register eax with the relevant hypercall
number
2. Load the actual parameters related to the hypercall in the relevant registers as
mentioned above
3. Call software interrupt 0x82 (control goes to SParK after this step)
4. Get the return value of the executed hypercall in the register eax
In SParK
SparK needs to configure the Interrupt Descriptor Table (IDT) for enabling software
interrupt 0x82 from programmes running at ‘ring 2’ (guest RTOSs). It does so by making
relevant entries in row 0x82 of the IDT.
The steps involved at SparK side on receiving a hypercall (software interrupt 0x82) are
as follows:
1. Save the hardware context of the caller (guest RTOS in this case)
22
2. Check register eax and look-up the hypercall request made by the guest OS
3. Execute the hypercall
4. Store the result of execution (success/error code) in the register eax
5. Restore the hardware context of the caller (guest RTOS in this case)
The end of the chapter contains a list of all the hypercalls identified and implemented to
date. The remainder of the chapter explains the SCOS system design and implementation.
4.4
4.4.1
Design and Implementation
Processes
In the SCOS User processes/tasks are compiled along with the SCOS kernel. This is
usually the case with RTOSs which have well defined tasks known before deployment.
No interface has been created for on-the-fly dynamic loading of tasks. Once the SCOS
kernel is up with all the necessary initializations, it creates all the pre-compiled tasks
and initializes the task control blocks (TCB) for each task. The TCB contains all the
information required for scheduling and maintaining the tasks. The tasks are created
through a standard POSIX interface pthread create. The SCOS runs these user tasks
at ‘ring 3’, the lowest privilege level. System calls have been implemented for tasks to
receive services like setting task periodicity, assigning task priority, using system terminal
etc. SCOS has implemented inter-task memory protection and protection of SCOS kernel
from the user tasks, which has been discussed in the section of memory management 4.4.2
below.
4.4.2
Memory Management
The memory layout of the SCOS is shown in figure 4.4.2. SParK reserves a predefined
chunk of continuous physical memory for very guest RTOS. The guest RTOS, though, is
not aware of the actual physical address assigned for its residence. It generates all of its
addresses offset from logical address zero. SParK uses segmentation feature of the x86
Memory Management Unit (MMU) to convert these logical addresses into appropriate
physical addresses. Thus, the guest RTOS can develop its own memory management
scheme without caring about which part of the physical memory is assigned to it.
Inter-task Memory Protection
SParK gives the guest RTOS the option of using paging for memory management. SCOS
uses this feature to attain inter-task isolation (memory protection). Paging is also used
to protect the SCOS kernel from corrupt/misbehaving tasks. SParK provides the guest
RTOSs with the spark RegisterPages hypercall. This hypercall can be used to register
multiple page tables with SParK, with a unique identification number for each registration.
SCOS uses this hypercall to register separate page tables for each of its user tasks. Every
page table has the task memory area and the SCOS kernel mapped into it. SParK verifies
23
Guest RTOS n
Heap Area
Task n
Guest RTOS 1
Task 1
SParK
Guest RTOS kernel
Physical Memory
Memory Allocated to Guest RTOS 1
Figure 4.1: Memory Layout of the SCOS guest RTOS
these page tables for valid entries and registers them with itself. Now whenever the
SCOS wants to schedule a new task it uses the spark LoadPDE hypercall to load the
appropriate page table in the processor MMU. This mechanism helps provide SCOS the
inter-task protection feature. In order to protect the SCOS kernel from its user task, it
maps all of its kernel pages as superusers and its task pages as users. This facility of
differentiating between users and superusers has been provided by x86 MMU paging unit
itself. Thus, whenever a user task tries to access superuser SCOS pages, it will raise an
exception. In this manner, protection to the SCOS kernel is provided.
4.4.3
Scheduler
As constrained by the two-level static scheduler (see section 3.1), SCOS has a generic fixed
priority preemptive scheduler to schedule its individual tasks. All tasks are assigned lowest
priority at the time of task creation. A particular tasks priority can then be changed (to
a higher value) by SCOS kernel itself or by a user task through the pthread setpriority
system call. Thus, this generic scheduler can be used to generate a RM (Rate monotonic)
scheduler or any fixed priority scheduler according to the user requirement. If there is a
tie between two tasks of equal priority, opportunity would be given to the task that was
created later in the at the time of task initialization. This knowledge needs to be used
by system designer at SCOS compile time to ensure proper working of tasks with same
priority. It may be used to generate a round-robin schedule between equal priority tasks.
SCOS invokes its scheduler at every virtual timer interrupt. Whenever there is the
need to switch to a new task, the scheduler loads a new page table corresponding to the
newly schedulable task and registers the top of stack (ESP) of the new tasks kernel stack
using appropriate hypercalls provided by SParK. These are necessary to provide inter-task
protection and ensure proper functioning of virtual timer interrupts as explained earlier.
24
4.5
List of Hypercalls
Listed below are the hypercalls identified and implemented to date:
• long spark print(char *ptrStr)
where,
– ptrStr: is the pointer to the null terminated string that the guest RTOS wishes
to print on the terminal
Used to print on the standard system terminal
• long spark RegisterTimer(long lPeriod, long lHandler, long ptrRealTime)
where,
– lPeriod: is the time resolution in nanoseconds. This value needs to be an exact
multiple of SParK’s hardware timer resolution
– lHandler: is the address of the guest RTOS timer ISR handler
– ptrRealTime: is the memory location which needs to be updated by SParK by
real time after every fresh invocation/scheduling of the guest RTOS
Used to register for the timer interrupt facility with SParK.
• long spark registerPages(int iId, unsigned long uPageTable )
where,
– iId: is the unique identification number to identify the registered page table
– uPageTable: address of the memory location where the page table is stored
Used to validate and register page tables from guest RTOS at per task level granularity. The guest RTOS can use only those page tables that it has registered through
this hypercall.
• long long spark loadPDE(int iId)
where,
– iId: is the identification number of a previously registered page table
Used to load a particular (valid) page table on behalf of the guest RTOS.
• long spark serial out(char *ptrStr)
where,
– ptrStr: is the pointer to the null terminated string that the guest RTOS wishes
to send on the serial communication port
Used to send a character string data on the serial port
• long spark parallel out(unsigned char bData)
where,
25
– bData: is a single byte data that the guest RTOS wants to send on the parallel
communication port
Used to send a single byte of data on the parallel port
26
Chapter 5
Conclusion and Future Work
5.1
Conclusion
Thus, by the end of the second stage of our MTech project, we have designed and developed
a running prototype of an Integrated Real-Time System, namely SParK. We have found
and realised solutions for some major problems and challenges that we had identified
at the end of first stage. A sound memory management scheme [Agg08] has ensured
spatial partitioning in the system. Also, a simple and effective two-level hierarchical
scheduling policy [Cha08] along with a novel timer virtualization mechanism have made
realising temporal partitioning possible. A full fledged guest RTOS, namely SCOS, has
been deployed on top of the SParK microkernel. A dummy integrated-systems prototype,
with three guest RTOSs running on top of SParK, has also been demoed. But there are
still further goals that we need to achieve, which have been discussed in the next section
of future work.
5.2
Future Work
There are still many features that are needed to be implemented in the SParK system.
We need to implement the Virtual Interrupt Server proposed in [Ver06]. Also, device
virtualization needs to be provided through Virtual Device Partitions proposed in [Ver06].
Support for varying ranges of i/o devices (like network i/o device) need to be realised. A
mechanism for inter-partition communication needs to be implemented. The system needs
to be thouroughly tested with various real world real-time integrated-systems prototypes.
Also, it needs to be noted that SParK needs to be ported on the PowerPC architecture
too. Hence, similar solutions for the PowerPC architecture are needed to be designed and
realised.
27
Bibliography
[Agg08]
Manish Aggarwal. Design and implementation of safety critical and real-time
os, stage 2. Master’s thesis, Indian Institute of Technology, Bombay, 2008.
[BC03]
D. Bovet and M. Cesati. Understanding the Linux Kernel. O’ Reilly, 2003.
[Cha08]
Anupam Chaumal. Design and implementation of safety critical and real-time
os, stage 2. Master’s thesis, Indian Institute of Technology, Bombay, 2008.
[Int04]
Intel. Intel Systems Programming Guide, Volume 1,2 and 3. Intel, Intel Corporation, Denver, 2004.
[Kim01] Daeyoung Kim. Strongly partitioned system architecture for integration of realtime applications. Technical report, University of Florida, 2001.
[Ver06]
Vibhooti Verma. Integrated real time systems, stage 3. Master’s thesis, Indian
Institute of Technology, Bombay, 2006.
[VMw05] VMware. Timekeeping in vmware virtual machines. white paper, 2005.
28