
A lightweight, predictable and dependable kernel for multicore processors
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.
For more details, please see the Frequently Asked Questions.
Features
- Supports IntelĀ® 32-bit x86 architecture in protected mode
- Software-based preemptive multi-tasking
- Virtual memory addressing
- Prioritized real-time Virtual CPU scheduler
- Real-time hardware performance monitoring
- Symmetric multi-processing, up to 8 logical CPUs
- Boots from HD, CD-ROM, USB or Network (PXE)
- Simple ATA and ATAPI support with ext2, iso9660 and romfs filesystems
- USB 1.1/2.0 (UHCI/EHCI) support: mass storage, network, serial port, video camera
- PCI network cards: e1000, pcnet32, realtek 8169
- TCP/IP networking provided by lwIP
- Integration with ACPICA, a reference ACPI implementation
- Sound Blaster 16 driver using DMA
- IntelĀ® hardware virtualization (VMX/EPT) support
- Basic shell and 8042 keyboard driver
- Newlib API with UNIX-like fork/exec/exit process semantics
- Configurable online fault detection and recovery
- Configurable operating modes: SMP, multikernel, and
separation kernel mode with Linux front-end
- Quest works on PC-class platforms, as well as Intel Galileo, Edison and MinnowMax boards. The GPIO support is fully functional on Galileo, Edison and MinnowMax.
- New. Quest supports mixed-criticality scheduling modes, including novel handling of mixed-criticality I/O operations.
- New. On platforms with appropriate hardware performance counter support, Quest now features memory bus traffic monitoring, as part of the MARACAS (memory aware, real-time aware, cache aware scheduling) framework.
- 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.
Been there, done that, bought the t-shirt?
- 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!Department of Computer Science, Boston University
Page maintained by Rich West