8/14/2019 The XenTMHypervisor

1/7

The Xen TM Hypervisor

Destin Smith-NorrisCOP 4610 - Computer Operating Systems

dsmithn@fau.edu

November 20, 2009

1

8/14/2019 The XenTMHypervisor

2/7

CONTENTS 2

Contents

1 Introduction 3

2 Architecture 3

3 Functions 4

4 Evaluation 5

8/14/2019 The XenTMHypervisor

3/7

1 INTRODUCTION 3

1 Introduction

I have chosen to research Xen for this project. It is not a full featured Operating System;however, it does feature many of the characteristics of one. Xen is a virtualizationenvironment that acts as a thin layer between the hardware and the Operating Systemof a computer. The makers of Xen designed it to be able to handle 100 simultaneousOperating System instances with minimal performance degradation[1].

The uses for such an environment are limitless. The main advantages to OS vir-tualization are security, hardware reduction, efciency, and application mobility [1].For instance, a single web server can host 20 different websites each running on theirown unique operating system. They can have all their own settings and be completelyindependent of each other. Another example is mobile platforms such as a cell phone.A Xen hypervisor running on top of an ARM based device allows the cell phone toapply high security and reliability to the low level applications required for the com-munications features of the cell phones, and also allow an independent OS for runninguser applications with less restrictions and priority.

Xen is an open source operating system originally developed as a research projectat the University of Cambridge in 2003. Since then, one of the original developers,Ian Pratt, has started up a commercial company to sell the product, XenSource, Inc.Xen has had a major impact on the Virtualization industry. It is included in manycommercial Linux distributions, as well as inuencing Microsofts Hyper-V[3] andCitrixs virtualization products. I will be discussing the original and still Open Sourceproduct as well as some of the changes which have occurred over the years.

2 Architecture

Figure 1: Xen Architecture Layout

The Xen architecture is built upon layered modules. The foundation of a Xen

8/14/2019 The XenTMHypervisor

4/7

3 FUNCTIONS 4

system is the Xen Hypervisor [4]. This is what sits directly on the hardware of a systembelow any other Operating Systems. It is responsible for CPU scheduling and memorymanagement for the various virtual machines running above it[4]. The Hypervisor hasno knowledge of networking, storage or any other standard I/O function found on thecomputer[4].

A modied Linux kernel runs directly above the Xen Hypervisor, called Domain0. This unique virtual machine is given access to the physical hardware resourcesavailable on the computer. Domain 0 includes drivers for networking and local disk management. All networking and storage requests from other operating systems arerequired to go through Domain 0 to be processed[4]. The Xen Domain Managementand Control run on Domain 0 and allow control of the other virtualized OperatingSystems.

Running parallel to Domain 0 are any numberof other modied Operating Systems.These are called Domain U (Dom U) PV guests[4]. These are paravirtualized virtualmachines running on top of the Xen hypervisor. The Dom U guests are modied toknow they are running in a virtualized environment, but are ran at almost no loss inperformance compared to a normal running system[1]. It is also possible to run fullyvirtualized machines as Domain U HVM guests. This means any operating systemsuch as Windows can run unmodied. Each HVM instance requires a daemon (Qemu-dm) to be running in the Domain 0 machine to support networking and disk accessrequests.

3 Functions

The goal of Xen is to paravirtualize the underlining hardware of a system so that amodied Operating System can be run on top of it with little performance impact andthe smallest possible modication to the OS code. The complexity of Xen is that itmust manage the different operating systems running simultaneously to ensure theyare independent from each other and can act as if they were running directly on thehardware.

The most complex issue is virtualizing the memory[1]. For example, because thepopular x86 does not have a software managed translation lookaside buffer (TLB), ad-dress space switches typically require a complete TLB ush. Because of this, Xenleaves guest OSes to be responsible for allocating and managing hardware page ta-bles, with minimal involvement from Xen; and Xen exists at the top of every ad-dress space preventing the need to perform a TLB ush when entering and leavingthe hypervisor[1]. Processes are given direct read and write access to the memory, andonly when they need to go outside of their allocated memory reservation is Xen calledto validate the request. Also, guests are instructed to minimize their memory footprints

by returning all unused pages back to Xen[1].The CPU must also be virtualized. The term we have been using for Xen, hyper-visor, implies that it must run at a higher level than the operating system, which isknown as the super user. In system architectures with only two privilege levels, theOS and the applications must run on the same level and extra security features mustbe present to protect the system. X86, however, provides four privilege levels, also

8/14/2019 The XenTMHypervisor

5/7

4 EVALUATION 5

known as rings. The most privileged ring 0 is used for Xen and the operating system ismodied to run in the unused ring 1, while the applications continue to run in ring 3 asnormal. Privileged instructions are interpreted by Xen and executed by the hypervisortransparently[1].

One unique aspect of Xen is its take on CPU scheduling. It gives the user theability to select from three algorithms to choose one that best performs for a usersneeds[2]. The algorithms to choose from are Borrowed Virtual Time (BVT), SimpleEarliest Deadline First (SEDF), and Credit scheduler. This added complexity must betaken into account when setting up a production environment because selecting andconguring the CPU Scheduling algorithms is vital to getting the optimal performanceout of the servers. Also, it must be remembered that these algorithms are for schedulingOperating System instances , or VMs, not actual userland processes.

Exceptions, including system calls and page faults, must be handled by Xen. Theyare virtualized very straightforwardly and Xen attempts to minimize the overhead re-quired. System calls and interrupts can be registered with software even handlers andrequire no special interaction with Xen. Page faults, however, must always go throughXen because they execute in ring 0. Xen monitors for so called double faults wherethe OS can not handle the exception then Xen terminates the offending guest[1].

As opposed to full virtualization, Xen does not try to emulate existing hardware. In-stead, Xen exposes a set of clean and simple device abstractions[1]. Data is exchangedto and from domains through Xen itself, using shared-memory and asynchronous bufferdescriptor rings. This provides a high-performance communication mechanism whileallowing Xen to validate the data[1]. This ensures protection of this system from in-valid memory calls and other security issues with minimal overhead.

4 Evaluation

Xen is a perfect example of a case where less is more. In less than 150,000 lines of code Xen can save companies thousands of dollars in hardware and power reductions.With near-native performance and simple operation Xen can provide a server or even ahand held device with multiple highly specialized operating system instances to t anyrequirements.

Xen is used in production environments around the world to provide cost effec-tive server consolidation. For instance, a single server can host many virtual privateservers, and sell access to them as if they were a dedicated server. The users areisolated from each other and performance is nearly as good as if they were paying tohave an entire server. The endless possibilities of The Cloud would not be possiblewithout operating system virtualization.

The security of Xen is one of its strongest points. Virtual machines are completely

isolated from each other in terms of memory access, CPU time, and hardware re-sources. However, there are always security issues with any technology. Vulnerabilitieshave been found which, for example, give a user in a guest domain access to the Dom 0instance. This is important to consider, because on top of the regular operating systemheadaches administrators face running one operating system, now they must managenumerous OS instances as well as Xen itself.

8/14/2019 The XenTMHypervisor

6/7

8/14/2019 The XenTMHypervisor

7/7

REFERENCES 7

References

[1] PaulBarham, Boris Dragovic, Keir Fraser, Steven Hand, TimHarris, Alex Ho, Rolf Neugebauer, Ian Pratt, and Andrew Wareld. Xen and the art of virtualization. InSOSP 03: Proceedings of the nineteenth ACM symposium on Operating systems principles , pages 164177, New York, NY, USA, 2003. ACM.

[2] L. Cherkasova, D. Gupta, and A. Vahdat. Comparison of the three CPU schedulersin Xen. PERFORMANCE EVALUATION REVIEW , 35(2):42, 2007.

[3] Mary Jo Foley. Review: Microsofts hyper-v puts vmware and linux on notice.http://blogs.zdnet.com/microsoft/?p=1182 .

[4] Xen c . Xen Architecture Overview , 2008.