Live migration of direct-access devices

Kadav, Asim; Swift, Michael M.

doi:10.1145/1618525.1618536

Cited by 45 publications

(22 citation statements)

References 7 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Device state checkpoints enable virtual-machine checkpoints to a pass-through device [25] and live migration, because the device state from the source can be extracted and restored on identical hardware at the destination. With virtual devices, the latency of live migration can be as low as 60ms [10], so a 2 second delay to initialize a passthrough device adds significant downtime [20]. Finally, device state checkpointing enables dynamic fault tolerance at fine granularity as demonstrated by FGFT.…”

Section: Discussionmentioning

confidence: 99%

Fine-grained fault tolerance using device checkpoints

2013

Self Cite

View full text Add to dashboard Cite

Recovering faults in drivers is difficult compared to other code because their state is spread across both memory and a device. Existing driver fault-tolerance mechanisms either restart the driver and discard its state, which can break applications, or require an extensive logging mechanism to replay requests and recreate driver state. Even logging may be insufficient, though, if the semantics of requests are ambiguous. In addition, these systems either require large subsystems that must be kept up-to-date as the kernel changes, or require substantial rewriting of drivers.We present a new driver fault-tolerance mechanism that provides fine-grained control over the code protected. Fine-Grained Fault Tolerance (FGFT) isolates driver code at the granularity of a single entry point. It executes driver code as a transaction, allowing roll back if the driver fails. We develop a novel checkpointing mechanism to save and restore device state using existing powermanagement code. Unlike past systems, FGFT can be incrementally deployed in a single driver without the need for a large kernel subsystem, but at the cost of small modifications to the driver.In the evaluation, we show that FGFT can have almost zero runtime cost in many cases, and that checkpoint-based recovery can reduce the duration of a failure by 79% compared to restarting the driver. Finally, we show that applying FGFT to a driver requires little effort, and the majority of drivers in common classes already contain the power-management code needed for checkpoint/restore.

show abstract

Section: Discussionmentioning

confidence: 99%

Fine-grained fault tolerance using device checkpoints

2013

Self Cite

View full text Add to dashboard Cite

show abstract

“…In these instances, the hypervisor is unable to capture and migrate the state of devices, and the in VM device driver is exposed to any mismatch between device models on the server and the desktop. Solutions have been proposed to support migration of passthrough devices [67,113], and some newer devices provide support for Single-Root I/O Virtualization and Sharing (SR-IOV) [64,50], which virtualizes the device itself, allowing context switching between VMs, and more importantly, the hypervisor to capture and restore device state.…”

Section: Considerations For Deployment Of Partial Vm Migrationmentioning

confidence: 99%

Energy-Oriented Partial Desktop Virtual Machine Migration

Bila

Wright

Lara

et al. 2015

ACM Trans. Comput. Syst.

View full text Add to dashboard Cite

Modern offices are crowded with personal computers. While studies have shown these to be idle most of the time, they remain powered, consuming up to 60% of their peak power. Hardware based solutions engendered by PC vendors (e.g., low power states, Wake-on-LAN) have proven unsuccessful because, in spite of user inactivity, these machines often need to remain network active in support of background applications that maintain network presence.Recent solutions have been proposed that perform consolidation of idle desktop virtual machines. However, desktop VMs are often large requiring gigabytes of memory.Consolidating such VMs, creates large network transfers lasting in the order of minutes, and utilizes server memory inefficiently. When multiple VMs migrate simultaneously, each VM's experienced migration latency grows, and this limits the use of VM consolidation to environments in which only a few daily migrations are expected per VM. This thesis introduces partial VM migration, an approach that transparently migrates only the working set of an idle VM, by migrating memory pages on-demand. It creates a partial replica of the desktop VM on the consolidation server by copying only VM metadata, and transferring pages to the server, as the VM accesses them. This approach places desktop PCs in low power state when inactive and resumes them to running state when pages are needed by the VM running on the consolidation server.Jettison, our software prototype of partial VM migration for off-the-shelf PCs, can ii deliver 78% to 91% energy savings during idle periods lasting more than an hour, while providing low migration latencies of about 4 seconds, and migrating minimal state that is under an order of magnitude of the VM's memory footprint. In shorter idle periods of up to thirty minutes, Jettison delivers savings of 7% to 31%.We present two approaches that increase energy savings attained with partial VM migration, especially in short idle periods. The first, Context-Aware Selective Resume, expedites PC resume and suspend cycle times by supplying a context identifier at desktop resume, and initializing only devices and code that are relevant to the context. CAESAR, the Context-Aware Selective Resume framework, enables applications to register context vectors that are invoked when the desktop is resumed with matching context. CAESAR increases energy savings in short periods of five minutes to an hour by up to 66%.The second approach, the low power page cache, embeds network accessible low power hardware in the PC, to enable serving of pages to the consolidation server, while the PC is in low power state. We show that Oasis, our prototype page cache, addresses the shortcomings of energy-oriented on-demand page migration by increasing energy savings, especially during short idle periods. In periods of up to an hour, Oasis increases savings by up to twenty times.iii DedicationIn memory of Jorge Francisco Bila.iv Acknowledgements I am indebted to many people for their contributions this work. First and foremost is Eyal de La...

show abstract

“…For example, as devices become increasingly virtualization aware, quick ways to initialize or reset are critical for important virtualization features such as re-assignment of devices and live migration [19]. Drivers contain significant configuration code (15%), specifically in network (31%) and video (27%) drivers.…”

Section: What Is the Function Breakdown Of Driver Code?mentioning

confidence: 99%

Understanding modern device drivers

Kadav

Swift

2012

SIGARCH Comput. Archit. News

Self Cite

View full text Add to dashboard Cite

Device drivers are the single largest contributor to operating-system kernel code with over 5 million lines of code in the Linux kernel, and cause significant complexity, bugs and development costs. Recent years have seen a flurry of research aimed at improving the reliability and simplifying the development of drivers. However, little is known about what constitutes this huge body of code beyond the small set of drivers used for research.In this paper, we study the source code of Linux drivers to understand what drivers actually do, how current research applies to them and what opportunities exist for future research. We determine whether assumptions made by driver research, such as that all drivers belong to a class, are indeed true. We also analyze driver code and abstractions to determine whether drivers can benefit from code re-organization or hardware trends. We develop a set of staticanalysis tools to analyze driver code across various axes. Broadly, our study looks at three aspects of driver code (i) what are the characteristics of driver code functionality and how applicable is driver research to all drivers, (ii) how do drivers interact with the kernel, devices, and buses, and (iii) are there similarities that can be abstracted into libraries to reduce driver size and complexity?We find that many assumptions made by driver research do not apply to all drivers. At least 44% of drivers have code that is not captured by a class definition, 28% of drivers support more than one device per driver, and 15% of drivers do significant computation over data. From the driver interactions study, we find that the USB bus offers an efficient bus interface with significant standardized code and coarse-grained access, ideal for executing drivers in isolation. We also find that drivers for different buses and classes have widely varying levels of device interaction, which indicates that the cost of isolation will vary by class. Finally, from our driver similarity study, we find 8% of all driver code is substantially similar to code elsewhere and may be removed with new abstractions or libraries.

show abstract

Live migration of direct-access devices

Cited by 45 publications

References 7 publications

Fine-grained fault tolerance using device checkpoints

Fine-grained fault tolerance using device checkpoints

Energy-Oriented Partial Desktop Virtual Machine Migration

Understanding modern device drivers

Contact Info

Product

Resources

About