A lightweight, predictable and dependable kernel for multicore processors
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
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
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.
- Supports Intel® 32-bit x86 architecture in protected mode
- Support for physical address extensions (PAE) to support
memory addressing above 4GB (32-bit)
- Software-based preemptive multi-tasking
- Virtual memory addressing
- Prioritized time-budgeted Virtual CPU (VCPU) scheduler for
integrated task and interrupt scheduling
- Real-time hardware performance monitoring
- Symmetric multi-processing, up to 8 logical CPUs (Currently being extended)
- 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
- New - Support for real-time
USB bus scheduler (USB 2.0 EHCI and USB 3.x xHCI)
- New - MATLAB/SIMULINK backend code generation for Quest
- New - tpipe API for
composable tuned pipes, enabling the construction of
real-time task pipelines with end-to-end throughput and
delay guarantees suitable for real-time I/O data processing
- The Quest RTOS works on PC-class platforms, as well as single-board computers (SBCs) such as the Intel Galileo, Edison, MinnowMax, Joule, Aero Compute Board, Up and Up Squared. Many SBCs have GPIO pin control
- Quest has been tested to work with GPIOs on the Galileo,
Edison and MinnowMax -- GPIO support on other platforms
should be straightforward, but has not been verified to be
- On platforms with appropriate hardware performance counter support, Quest features memory bus traffic monitoring, as part of the MARACAS (memory aware, real-time aware, cache aware scheduling) framework
- The Quest-V partitioning hypervisor has been tested on PC-class
platforms with legacy BIOS and EFI firmware, including the Skull
Canyon, and SBCs such as the Aero Compute Board, Joule,
and Up Squared
- New - Quest-V is currently being ported to the Cincoze DX-1100 industrial PC
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!