Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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