Quest
    A lightweight, predictable and dependable kernel for multicore processors


Overview

Quest is a relatively small real-time operating system (RTOS). It works on both uni- and multicore processors, and supports various operating modes depending on the underlying hardware features. It can be configured as either a lightweight SMP system (having a single memory image running on multiple cores), a scalable multikernel (running multiple instances of the OS on separate cores, thereby reducing cross-core contention), or as a secure separation kernel (a.k.a. partitioning hypervisor, called Quest-V, operating as a distributed system on a chip). In the latter case, hardware virtualization is used to "sandbox", or isolate subsets of hardware resources (i.e., memory regions, CPU cores, and I/O devices) amongst different software components. In this way, the system can be made more secure and robust, in the presence of faults from both errant or malicious code. 

The system features a novel real-time scheduling framework, where all control flows (including those triggered by interrupts) are associated with threads mapped to priority-aware and resource accountable virtual CPUs (VCPUs). This enables Quest to support both spatial and temporal partitioning of resources.

When operating as a distributed system on a chip, in multi-/separation kernel mode, online fault detection and recovery mechanisms can be employed to maintain system availability.

Quest is open source software available under the terms of the GNU General Public License v3.

For more details, please see the Frequently Asked Questions.

Features

Why a New OS?

Given the current state-of-the-art in OS development, and the numerous systems already available, this is a natural question to ask. In particular, writing a new OS is time-consuming, and technically difficult. It is unlikely that without many man-years of development a new OS will ever have the maturity to support commercial-grade applications, partly due to the lack of driver support and rich APIs/libraries on which such applications depend. However, from our experience the code complexity of existing modern systems often becomes a hindrance when developing new policies and mechanisms. Similarly, many pre-existing systems have evolved from designs that are fundamentally based on principles from several decades ago, yet in that time there have been significant hardware changes. We now have multicore processors with hardware virtualization support, simultaneous multi-threading (SMT), shared on-chip caches, NUMA topologies with on-chip integrated memory controllers and interconnection networks, and power management features. It is true that many modern OSes have evolved to support these new hardware features but there is evidence to suggest a new approach is worthwhile considering e.g., due to scalability concerns associated with the management of many on-chip cores, or due to micro-architectural resource contention involving shared caches, bus interconnects and memory.

Food for thought: Linux has arguably had more impact on computing research than almost any other open source software artefact. When it came into being, it was itself based on an old idea: UNIX. The brilliance of Linux is perhaps less in its design (although maybe that's testament to the good design of UNIX) but more in the value of it being open source. The goal of Quest is to now take that one step further by looking at a new open source system design that is not tied to the constraints of traditional systems.

Time as a first-class resource. Quest aims to support "time as a first-class resource". From the ground up, Quest manages all resources via time-budgeted and temporally-isolated virtual CPUs (VCPUs). The system features a hierarchical scheduling infrastructure, with both main and IO VCPUs to handle the execution of conventional tasks and system events associated with interrupts.  This means that real-time and non-real-time tasks can co-exist without interference, at least in terms of the resource time budgets they are guaranteed. This does not, however, guarantee the amount of progress a task makes in real-time, because micro-architectural resource contention is still possible. For example, one task may evict another's memory contents from a shared on-chip cache, or may compete for memory bus bandwidth. These factors all affect the execution time of tasks.

To ensure efficient progress is made by all tasks, and to try to bound the amount of interference between tasks caused by micro-architectural resource contention, Quest incorporates a real-time performance monitoring sub-system that uses hardware performance counters to track micro-architectural resource usage. From this, we are able to construct performance curves and various resource usage models, including predictions of cache occupancy and the effect this will have on task execution.

Aside from predictability and efficiency objectives, Quest also aims to ensure its integrity is not compromised by ill-written or malicious third party software. This aspect of safety is to prevent system failure when any sub-component behaves erroneously. In this regard, Quest utilizes various hardware and software features (including hardware virtualization) to isolate system components, so that if one component fails the system can recover.

Been there, done that, bought the t-shirt?

Acknowledgement

This work is funded in part by various grants, including: NSF #0615153, #1117025, and #1527050, and gifts from Intel and Drako Motors. Thank you!

Quest, still searching...

Department of Computer Science, Boston University

Page maintained by Rich West