Overview

Quest is a relatively small operating system, designed to be
dependable and predictable. 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 (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.

New.
Quest now runs on the Intel Joule, with Quest-V support under
development.

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.

If you're interested in joining the Quest group, we're
always keen to work with driver writers, library and
application developers, and anyone with knowledge of
computer architecture and operating systems. Consider being
a developer and buy the t-shirt! Join our Quest for
knowledge!

Acknowledgement

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