Researcher profile

Eric Missimer

Eric Missimer contributes to research discovery and scholarly infrastructure.

ResearcherAffiliation not importedOpen to collaborate

Trust snapshot

Quick read

Trust 17 - UnverifiedVerification L1Unclaimed author
4works
0followers
1topics
3close collaborators

Actions

Decide how to stay connected

Follow researcher0

Identity and collaboration

How to connect with this researcher

Claiming links this public author record to a researcher profile and unlocks direct collaboration workflows.

Log in to claim

Direct collaboration

Open a focused conversation when the fit is right

Claim this author entity first to unlock direct invitations.

Research graph

See the researcher in context

Open full explorer

Inspect adjacent work, topics, institutions and collaborators without jumping out to a separate graph page.

Building this graph slice

BZPEER is loading the nearby papers, people, topics and institutions for this page.

Published work

4 published item(s)

preprint2016arXiv

Mixed-Criticality Scheduling with I/O

This paper addresses the problem of scheduling tasks with different criticality levels in the presence of I/O requests. In mixed-criticality scheduling, higher criticality tasks are given precedence over those of lower criticality when it is impossible to guarantee the schedulability of all tasks. While mixed-criticality scheduling has gained attention in recent years, most approaches typically assume a periodic task model. This assumption does not always hold in practice, especially for real-time and embedded systems that perform I/O. For example, many tasks block on I/O requests until devices signal their completion via interrupts; both the arrival of interrupts and the waking of blocked tasks can be aperiodic. In our prior work, we developed a scheduling technique in the Quest real-time operating system, which integrates the time-budgeted management of I/O operations with Sporadic Server scheduling of tasks. This paper extends our previous scheduling approach with support for mixed-criticality tasks and I/O requests on the same processing core. Results show the effective schedulability of different task sets in the presence of I/O requests is superior in our approach compared to traditional methods that manage I/O using techniques such as Sporadic Servers.

preprint2013arXiv

Predictable Migration and Communication in the Quest-V Multikernel

Quest-V is a system we have been developing from the ground up, with objectives focusing on safety, predictability and efficiency. It is designed to work on emerging multicore processors with hardware virtualization support. Quest-V is implemented as a "distributed system on a chip" and comprises multiple sandbox kernels. Sandbox kernels are isolated from one another in separate regions of physical memory, having access to a subset of processing cores and I/O devices. This partitioning prevents system failures in one sandbox affecting the operation of other sandboxes. Shared memory channels managed by system monitors enable inter-sandbox communication. The distributed nature of Quest-V means each sandbox has a separate physical clock, with all event timings being managed by per-core local timers. Each sandbox is responsible for its own scheduling and I/O management, without requiring intervention of a hypervisor. In this paper, we formulate bounds on inter-sandbox communication in the absence of a global scheduler or global system clock. We also describe how address space migration between sandboxes can be guaranteed without violating service constraints. Experimental results on a working system show the conditions under which Quest-V performs real-time communication and migration.

preprint2013arXiv

Quest-V: A Virtualized Multikernel for Safety-Critical Real-Time Systems

Modern processors are increasingly featuring multiple cores, as well as support for hardware virtualization. While these processors are common in desktop and server-class computing, they are less prevalent in embedded and real-time systems. However, smartphones and tablet PCs are starting to feature multicore processors with hardware virtualization. If the trend continues, it is possible that future real-time systems will feature more sophisticated processor architectures. Future automotive or avionics systems, for example, could replace complex networks of uniprocessors with consolidated services on a smaller number of multicore processors. Likewise, virtualization could be used to isolate services and increase the availability of a system even when failures occur. This paper investigates whether advances in modern processor technologies offer new opportunities to rethink the design of real-time operating systems. We describe some of the design principles behind Quest-V, which is being used as an exploratory vehicle for real-time system design on multicore processors with hardware virtualization capabilities. While not all embedded systems should assume such features, a case can be made that more robust, safety-critical systems can be built to use hardware virtualization without incurring significant overheads.

preprint2013arXiv

The Quest-V Separation Kernel for Mixed Criticality Systems

Multi- and many-core processors are becoming increasingly popular in embedded systems. Many of these processors now feature hardware virtualization capabilities, such as the ARM Cortex A15, and x86 processors with Intel VT-x or AMD-V support. Hardware virtualization offers opportunities to partition physical resources, including processor cores, memory and I/O devices amongst guest virtual machines. Mixed criticality systems and services can then co-exist on the same platform in separate virtual machines. However, traditional virtual machine systems are too expensive because of the costs of trapping into hypervisors to multiplex and manage machine physical resources on behalf of separate guests. For example, hypervisors are needed to schedule separate VMs on physical processor cores. In this paper, we discuss the design of the Quest-V separation kernel, that partitions services of different criticalities in separate virtual machines, or sandboxes. Each sandbox encapsulates a subset of machine physical resources that it manages without requiring intervention of a hypervisor. Moreover, a hypervisor is not needed for normal operation, except to bootstrap the system and establish communication channels between sandboxes.