Paper Discussion - Fall 2008 - CS 736

Xen, in my opinion, is a great idea: the authors take a good idea with some caveats (virtualization) and trade perfection for performance by saying, "It's not against the rules to modify the guest." In doing so, they are able to reduce the overhead of full system virtualization to the point where it operates within a few percentage points of full speed.

What's valuable about Xen as systems design paper is that it draws a new line, identifying those specific components of an operating system that are the right point to virtualize. The success of their selections, according to results, means that they've selected these components well. In the sample guest they finished paravirtualizing (Linux), the modifications were also not very extensive, making this a viable option for real systems. Even in the systems they did not finish (Windows, particularly), they were able to make it work for some applications with some additional effort (not, in my opinion, an exorbitant amount). This demonstrates further that the technique is viable across multiple OS implementations, furthering the impact of their work.

The authors did identify a problem with the paravirtualization approach, however. Windows demonstrates that there exist systems that make paravirtualization hard(er). Windows may have been a worst-case scenario for this: at the time, there was not an isolated kernel layer available, so relevant components may well have been spread within its formidable code base. Nevertheless, this serves to underline the fact that paravirtualization comes only at some cost, and affords developers several chances to do it wrong.

Since Windows XP, the MinWin project has emerged within Microsoft, being the same NT kernel without the circular dependencies into library code. A good experiment with Xen that I'd like to see is the paravirtualization of this less-bad example of the same non-Linux system. How much easier does it become, I wonder? Also, I wonder whether the paravirtualization of software-isolated systems (such as Singularity) has any of the same benefits (or if pure hardware virtualization is just as good). In general, the question remains, when is the right time to paravirtualize, and is it really, "every time?"

Barham, et al. describe a virtual machine monitor that supports a variety of “paravirtualized” mainstream “guest” operating systems in Xen and the Art of Visualization. This technique requires changes to the code for the guest operating systems in an effort to significantly improve performance of applications running under them.

The authors contrast Xen with VMWare ESX Server, a system that fully virtualizes the platform under it at the cost of speed. They also mention the Denali VMM architecture, which runs applications linked against a library operating systems. Xen lies between the two philosophies: applications don't have to meet up against a new ABI, but their respective operating systems may require some work.

One of the big challenges to the Xen developers is both virtualizing and sharing memory between each guest OS: this is especially tricky if the guest OS leverages features built into hardware, such as a x86 TLB. Another challenge is handling what were once privileged instruction calls made by a guest OS as well as exceptions generated by the real machine (but potentially caused by the guest OS). Also, Xen has to isolate the real I/O hardware from each guest OS.

Xen's greatest weakness is the challenge of porting existing operating systems to run within its VMM. This is especially difficult with proprietary operating systems. Furthermore, many of the operations the Xen team show are slow in a fully virtualized environment can be improved by better hardware support for virtualization. Hardware vendors realize virtualization is going to become more and more important in the next decade, particularly in data-centers, which could be their undoing.

Summary
The paper describes the design of the Xen virtual machine monitor that allows upto 100 operating systems to co-exist simultaneously in a resource managed fashion. The main theme of the paper is the concept of para virtualization which enables Xen to achieve this task efficiently without huge performance overheads.

Problem attempted
The paper attempts to build a virtual machine monitor for x86 systems that supports efficient and concurrent execution of multiple operating systems. The ultimate target of he Xen VMM hosts upto 100 OS instances.

Contribution

1. The authors point out the inadequacy of performance isolation that is provided by traditional OS techniques. Scheduling, memory demand and network traffic of one process adversely affects the performance of another process, which is undesirable for a multi-programming system. They propose OS level multiplexing instead of process level multiplexing as the solution to this problem.

2. The paper introduces the notion of partial virtualization (paravirtualization) where the virtual machine abstraction is similar but not identical to the underlying hardware. This helps avoiding the costly performance penalties, such as efficiently virtualizing the x86 MMU, that arise from providing full virtualization to the x86 architecture. Besides, this has the added benefit of providing the operating system with real as well as virtual resources.

3. Like the exokernel, the paper stresses on the separation between mechanism from policy. The Xen provides only basic control operations and does not provide policy decisions such as packet filtering just as the exokernel avoids these policy decisions.

4. The Xen provides the hypercall mechanism for synchronous calls from a domain to Xen, while notifications made from Xen to a domain have been light-weight through asynchronous event mechanism instead of the usual delivery mechanisms for device interrupts. This asynchronous mechanism minimizes the work required to demultiplex data to a specific domain when an interrupt is received from a device.

5. In order to minimize the effect of virtualization on OS sub-systems, Xen uses Borrowed Virtual Time Scheduling Algorithm that has a special mechanism for waking up a domain when it receives an event.

Flaws

1. Though the appplication binaries need not be modified, the Xen architecture requires modifications to the guest operating system which may not often be possible in proprietary systems.

2. The system provides device I/O through device abstractions. But device abstractions often do not expose all the features of a device.

What it makes easier

1. Virtual address translation has been made much simpler compared to other contemporary virtualization systems. Providing full virtualization would require any VMM to provide each guest with a virtual page table and the hypervisor is responsible for trapping accesses to virtual page tables, validating updates and propagating changes to the MMU visible page table. In contrast, the Xen system is involved only in page table updates, whose overhead too can be minimized by the OS by batching update requests.

2. The authors claim that the performance isolation provided is working as expected which implies a system that is very robust to malicious applications.

What it makes harder

1. The requirement of every privileged instruction being validated by Xen is a lot of performance overhead on the guest OS.

In this paper, XEN an x86 virtual machine monitor is presented. XEN allows multiple operating systems to share hardware in a safe way, without sacrificing performance. This is achieved by providing a virtual machine abstraction to which operating systems can be ported. The authors present the basic features of the system and then perform various experiments to evaluate it.

According to the authors, the existing techniques of virtualization have certain drawbacks. Some require specialized hardware or cannot support commodity operating systems. Others sacrifice security, performance or functionality in order to achieve higher speed or total binary compatibility. The main goal of XEN is to allow common operating systems to be hosted simultaneously without affecting performance.

XEN runs on top of the machine hardware (ring 0). On top of it (ring 1) the OS system runs. The OS should be modified in order to be executed in this ring. Finally the ring 3 is used for application code. XEN offers execution domains where guests OS can run. OS can’t directly access hardware. Their requests are forwarded to XEN. In all the domains the top of the memory space is reserved for XEN. As far as it concerns I/O, XEN exposes a set of simple device abstractions, instead of emulating existing hardware devices.

One contribution of the system is that it avoids the drawbacks of full virtualization by using paravirtualization. More specifically, it uses a virtual machine abstraction that is similar but not identical to the underline hardware. In this way the performance is improved. Moreover, the paper proposes an efficient way to virtualize the x86 MMU. By using rings 0,1,3 , it prevents the guest OS from directly executing privileged instructions, yet it remains safely isolated from the applications which run in ring 3. Moreover memory management is done efficiently. The hosted OSes contact XEN for segmentation or paging and not the hardware itself. Finally, another contribution of the paper is the two mechanisms for control interaction between XEN and an overlying domain: hypercalls and asynchronous event mechanisms.

I believe that the main flaw of XEN is that guested OSes should be modified first in order to be executed. Although, the authors claim that minimal effort is needed in order to achieve that, I think that it may not be so easy.

Xen and the Art of Virtualization

Summary
The Paper dicusses the virtualization approaches, design, implementation and performance evaluation of Xen hypervisor which adopts the paravirtualization technique and focuses on providing virtual machine isolation, support for various guest OSes and low performance overhead due to virtualization for achieving widespread adoption.

Description of the problem being solved
The authors are trying to build a high performance para-virtualized VMM that provides for most of the essential feature not available in the existing VMMs like performance isolation & fair allocation of resources, support for multiple operating systems and minimal/no change in existing Application binary interfaces.

Contributions of the paper

1. Choice of the right set of design choices to create a performing VMM that can also support multiple OSes ( with acceptable porting effort, considering the performance gained thereby) and provide a safe, controlled,fair virtualization. For example, Xen picked para-virtualization from Denali , but chose no change in ABI for running application binaries without any change.

2. There are number of small innovations in implementing such a high performing VMM. For example,

a) the I/O rings for data transfer that allows moving data vertically through the system.
b) choice to allow the OSes directly allocate and manage hardware page tables with miminal validating role by Xen

3. Another contribution is that they demonstrated practically a VMM that has many desirable features like: resource allocation with fairness across guest OSes with minimum performance overhead by the VMM itself, secure isolation between guest OSes, easy management and control through DomainO. In retrospect such competitive offering is the key for their success and adoptation. For example, Amazon offers a commercial offering called Elastic Compute Cloud which uses Xen for the virtual machines that it provides to public users and thereby allows many people share the computing resources in a singe machine.

Flaws in the paper

1. Porting of Operating systems needs significant effort. The only guest OS mature with porting to Xen was Linux. Both Windows XP and FreeBSD were underway perhaps indicating the effort needed.

What is made easier?

1. Using VMMs for several applications like colocated hosting facilities, secure computing platforms, distributed web services, and application mobility became easier and positive.

2. Achieving high performance was made easier by paravirtualization.

What is made harder?

1. Porting of OSes is made harder because of para-virtualization.

Xen and the Art of Virtualization.

This paper introduces Xen, a Virtual Machine Monitor (VMM) that allows multiple different operating systems to coexist simultaneously in the same hardware machine in a protected way and offering high performance.

The goal of this research is to allow up to 100 virtual machines to run in the same hardware machine. These machines have to be isolated from each other, they must be able to support different multi-application OS, and the have to introduce little overhead. Application binaries do not need any modification, which is an essential requirement for the success of Xen.

1-Xen introduces a new approach to virtualization called paravirtualization. This technique requires a modification on the guest operating system, getting in return little performance overhead. Previously a technique called full virtualization was used, but this approach was not appropriate for x86 architecture due to the execution of supervisor instructions without enough privileges. Full virtualization did not need the modification of the guest operating system but the hypervisor needed to handle those supervisor instructions, resulting in a reduction of performance.

2-Managing memory is one of the most challenging parts of virtualization. The approach taken is that each guest OS can allocate its own pages when needed, but updates need to be verified by Xen.

3-Virtualization of the CPU is done considering the 4 privilege rings available in x86 architecture: level 0 is the most privileged and level 3 is the less privileged. Usually OS executes In level 0 and applications execute in level 3, levels 1 and 2 are not used. In Xen, guest OS execute in level 1, which prevent them from executing privileged instructions, and applications execute on level 3. Xen is executed in level 0, and all the privileged instructions need to be supervised by it.

They claim that one of the challenges of virtualization is to support a variety of OS, but in this paper only XenoLinux (a modification of the Linux 2.4) is available to test. They claim that the necessary modifications for NetBSD, and Windows XP are being implemented. The number of different operating systems that are supported by Xen is limited by the ones they have created modifications for. Xen is targeted for x86 architecture and it does not support hardware portability.

Xen has been proven to be a successful tool for providing virtualization. The design decision have been maintained and proved to be a good approach to the problem.

The paper presents the Xen hypervisor which employs para-virtualization to attain amazing scalability and performance over other contenders in the virtualization space.

The primary problem that Xen tries to solve is scalability with a goal towards running 100 domains simultaneously. Xen also strives to provide greater isolation of virtual machines, support a broad gamut of commodity operating systems, and reduce the performance overheads associated with virtualization.

The three key aspects to Xen's organization are memory management, CPU virtualization and Device I/O. Xen runs as the hypervisor layer below the operating systems and provide these three functionalities to the OS above. However, to maximize performance, xen goes the paravirtualization way and requires co-operation from the hosted operating systems; ie, the hosted OSes need to be modified to work with xen.
For memory management, XEN basically works as a gatekeeper to segmentation and paging, requiring the hosted OSes to contact XEN for these services rather than the hardware directly. And to reduce context switching overhead, XEN is mapped to the upper 64MB of every address space created.
CPU Virtualization is achieved by employing the otherwise underutilized intermediate privilege levels of the x86 architecture. Whereas, before the OS ran in ring0 and applications ran in ring 3, the hypervisor now supplants the OS in ring0 and relegates it to ring1. Thus, for many privileged instructions, the OS has to go through the hypervisor. This has the plus side of allowing a certain level of validation over the privileged instructions.
With device I/O, xen approaches the problem differently than traditional full-virtualization brotheren. Instead of emulating existing devices, xen goes for a more exokernel-ish approach of securely multiplexing without abstracting.

What it makes easier:
- users can dynamically create precise execution environments their software requires, and have multiple ABIs coexist on their system (this is more a general plus of virtualization)
- given the demonstrated abilities of scalability and performance isolation, xen could be an ideal platform for virtualizing high performance hardware to safely and flexibly share between many users.

What it makes harder:
- having to modify the OS source could be a major deployment problem for Xen given that some contemporary OSes do not allow source modification for diverse reasons.
- while one of the potential uses of virtualization is in debugging the operating system, the modified os used with xen might render xen unusable for this purpose.

contributions:
- I see the scalability of virtualization as the biggest contribution of xen; Using para-virtualization to reduce the overheads of virtualization and improve performance.
- Performance isolation as an application of virtualization is heavily promoted in the paper. It gives good reason to prefer virtualization over running concurrent processes on a single OS.

Flaws:
I agree with Mark in his pointing out that only one OS has been completely ported to XEN. The effort and complexity involved in porting the OS to work with xen looks to me to be a big barrier for widespread adoption of XEN albeit it being a wonderful idea.

Introduction:
This paper describes the Xen virtualization system, which was developed at the University of Cambridge. The authors describe the design and implementation details of the system, along with explaining the rationale behind the decisions they made. The paper also compares the performance of Zen versus other competing virtualization frameworks.

What were they trying to solve:
Users want to run different applications on the same machine at the same time, but these applications may be written for different operating systems, and must run isolated from each other. The Virtualization approach to this problem involves multiplexing the physical resources of the system between multiple operating system instances. But true Virtualization comes with a hefty performance penalty and also is disadvantageous in cases where the OS needs to see the physical resource directly(eg: accessing "real" time for accurate network packet measurements).

Contributions:
To solve some of the issues of full virtualization, the approach they follow is Paravirtualization, which exposes a slightly different interface to the OS instances than the underlying hardware. The approach allows direct access to many of the underlying features, thus increasing performance and enhancing flexibility.
A portion of the address space of every guest OS is mapped to Xen, which means that calls (or rather hypercalls) between the guest and zen don't involve a TLB flush.
Since system calls are among the most common causes of exceptions, Xen provides a "fast" exception handler, without causing a protection-mode-switch, thus improving performance. Similarly a lightweight event system is used for communicating between the hypervisor and the OS.
The control interface allows the administrator to starts new instances and monitor resource levels.

Flaws:
The guest OS cannot run out of the box on Xen, it has to be modified.(Newer versions of Xen can run unmodified OSs if there ie hardware support for it). This presents a major logistical and practical problem in most situations.
In hardware architectures with just two protection levels, both the OS and the processes run in the same (unprivileged) mode. This implies that more changes are needed to make the OS run of these machines.

OS Organization:
The Xen is a virtual machine monitor whose job is to multiplex resources between OS instances. Domain0 is the default OS which boots when Xen is started, and allows for creation of other instances. Xen hides certain things from the guest OS, while allowing direct access to other features.
Advantages:
Applications can run without any modification
It is performant compared to other VMs
Disadvantages:
Source code changes to OS is needed to make it run on Xen.

Summary:
This paper describes Xen, an x86 virtual machine monitor which allows multiple commodity operating systems share conventional hardware without sacrificing either performance or functionality. This is achieved by providing an idealized virtual machine abstraction to operating system. Xen focuses on complete isolation between virtual machines for the x86 architectures, provides an excellent platform for deploying a wide variety of network-centric services, and reduces performance costs.
The problem the paper was trying to deal with:
The main goal of this paper is to develop an x86 virtual machine monitor in which individual machines can be isolated form one another without sacrificing performance. And the virtual machine monitor is able to make the scheduling priority, memory demand, network traffic and disk accesses not conflict with one another and make performance overhead be small.
Contributions
1． Knowing the drawbacks of full virtualization, the authors of this paper present a virtual machine abstraction that is similar but not identical to the underlying hardware in order to avoid the drawbacks of full virtualization, which brings improved performance.
2． The paper provides efficient virtualization of privilege levels generally described as rings numbered form zero (most privileged) to three (least privileged), which help protect operating systems remaining safely by allowing applications to be separate from operating systems.
3． The paper describes a tagged TLB idea which makes the implementation of memory virtualization much easier. TLB entry allows the hypervisor and each guest OS to efficiently coexist in separate address spaces because there is no need to flush the entire TLB when transferring execution.
4． Xen supports a lightweight event delivery mechanism which is used for sending asynchronous notifications to a domain, which helps to lower down the overall costs.
Flaws:
The system’s support to the management and administration of XenoServers is not good enough yet. And additional VFR rules are needed to detect and prevent a wide range of antisocial network behaviors.
What it makes easier:
A tagged TLB can make the implementation of memory virtualization much easier.
What it makes harder:
Large amount of costs in I/O access are needed because data transfer from I/O devices need to be transferred through hypercall layer.

Summary: The paper describes XEN, a Virtual Machine Monitor whose target is to up to 100 VM instances (hosting various OSs) simultaneously on a single server. XEN attempts to offer Quality of Service at the OS granularity, at price of modifications to guests OSs, with particular attention to x86 architecture.

Problem: The high target of virtual machines running on a modern server bring at least a couple of Major issues. The first one is how to share the underlying hardware in a fair and accountable way (the Quality of Service problem). The second issue is that completely hiding the real resources becomes detrimental not only for performance, but for correct interaction with the real world (such as the TCP timeouts); especially in a system where real time can be highly 'diluted'. Finally, virtualization has to be done in a user-friendly way, with no changes to the user processes.

Contributions: XEN offers an abstraction which is similar, but not identical to the hardware. Paravirtualization was used before, however XEN offers a more technically advanced solution with fewer compromises: support for unmodified user code (guests' ABI), support for multi-application OSs and performance isolation among guests. In addition XEN's solutions work for x86, which is among the least virtualization friendly systems.

Organization: XEN offers execution domains where guests OS can run. In all such domains the top of the memory space is reserved for XEN and immutable for the guests. OS requests to access the hardware is forwarded to XEN. XEN must run at the highest privilege level, and OS guests a a lower one, which may require changes in such guests. Execution domains access the data offered by the XEN device abstraction through shared memory and buffer descriptor rings. Communication is done asynchronously.
Guests OS's are provided with real-time, virtual-time and wall-clock time. This is an unavoidable distinction. However, I think that this distinction is a major source of pain in porting an OS to XEN, since a decision of which XEN-timer to use has to be made for each instance of a timer in the guest code.

Weaknesses: A target of XEN is dynamic creation of precise execution environments that a user level program would require. This may lead to an explosion of the space required to store the possible components of such environment. In systems with only two privilege domains, the OS and application are forced to run in the same space which is a huge vulnerability.

Summary
Paper talk about XEN hypervisor which partition the resources of a computer between different operating system running on same system. This paper present the virtual machine interface for Memory management,CPU and Devices I/O for x86 which is expan.

Problem Trying to solve
This try to solve problem posed by partitioning of a machine to support the concurrent execution of multiple OS such as Isolation of Virtual OS , Support for different operating system and keeping performance overhead small .

Work Summary/Contribution

1. No modification is required on Guest application binary ( application running on Guest OS) as Application Binary Interface is not modified .
2. XEN use Paravirtualization instead of full virtualization . Software interface presented by XEN to virtual machine is similar but not identical to underlying hardware . One of such example is Device I/O abstraction in XEN , instead of emulating existing device XEN provide simple device abstraction .
3. Guest OS is executed in ring 2 of x86 . This way Guest OS can not execute privileged instruction on hardware and still remain safe from application running in ring 3.
4. XEN provide a hypercall interface which allow domain(Vistual OS) to perform privileged operation. This hypercall is equivalent to use of system call in conventional OS call.
5. CPU scheduling of domain is performed using Borrowed virtual time (BVT) algorithm. This algorithm enable XEN to perform low-latency wake-up of domain when it receive an event.

FLAWS
1. Virtual OS optimize the Disk access by reordering them thinking it was give to actual Disk . As Disk is exposed as VBDs so XEN has better control for Disk access so it will re-order the request received from guest OS. when we are modifying Guest OS for xen we can also disable disk request re-ordering feature and avoid this redundant task on guest OS.

What it makes Easier :
1. Computer makes it easier to run multiple OS on one system . Virtual OS has not restriction on no of no of user process it can run so administrator need not install new VOS for each process .
2. Software isolation can be achieved by running program on different virtual OS. This isolation provide effective protection from malicious Virtual OS which tries to monopolize the resource usage .
3. Multiple OS policies like scheduling,page replacement can be implemented on one system using different virtual system .

What it makes Harder :
1. Data transfer from I/O devices need to be passed through hypercall layer . which put overload in I/O access .

Summary
This paper introduces Xen, a virtual machine monitor that uses paravirtualization to provide a virtual machine that can multiplex across guest OS’s. Unlike other virtual machines, Xen designers don’t believe in compromising on features(such as configuration capabilities) or performance(slow memory updates). But this requires porting of the operating systems to optimize the performance.

Problem
The current virtual machine monitors either lack in features, performance, isolation or efficient multiplexing. The authors want to design a system which doesn’t compromise on any of these principles and provides a virtual machine that can securely multiplex different guest OS’s without totally hiding the hardware from the OS‘s, thereby allowing performance optimization in the guest OS’s too.

Contributions
- Though this concept is not new, Xen uses paravirtualization to perform virtualization without loss in performance on hostile architectures such as x86. For e.g., it doesn’t totally hide the hardware from the OS and the guest OS has direct read access to the physical table with writes being verified for isolation.
- To save on TLB flushes for each context switch to the Xen, top 64MB of every address space is always occupied by Xen. This results in a huge win during performance comparisons with VMWare as each hyper call takes a very short time.
- To reduce copy-overheads between the OS and Xen, they use the concept of an I/O ring where the guest OS reserves a buffer and transfers the pointer to the Xen as a request. Xen locks this buffer, processes the request and sends back the response in the same buffer. This ensures that the requestor is responsible for the memory required for its requests.(isolation)
- Xen associates type information with each page frame which allows quick validations. Xen also allows batching of requests which reduces the number of context switches which is specially useful while creating new address space.
- The I/O ring concept is used in disk and network access. This allows scheduling these operations at both the OS and the VMM end(useful for disk accesses as the VMM has more knowledge of the disc layout).
- The system has been thoroughly tested and benchmarked against other operating systems + VMM. The amount of effort spent deserves being mentioned here even if not a contribution.

Flaws
- The requirement of porting the OS puts some limitations on the usability of this system. For e.g. if you are experimenting with a new operating system, virtualization using Xen is not possible without porting it too. Also this limit’s the users to the OS already ported by them or by someone else.
- As they mentioned in the paper, the VM-OS-Application gets very complicated and slow on architectures without 3 hardware rings.
- Each OS is expected to allocate buffers and pass to Xen before even accepting the network packets. This makes the OS susceptible to DOS attacks unless it provides really powerful network filter rules.

Design
The VMM is designed such that instead of multiplexing across processes, it instantiates an entire OS for each request. This enables each user to run complex configurations between its processes and also ensures isolation between different OS’s.

Easier
- Its easier for an administrator to monitor the system and configure the various domains through the Domain0 control interface.
- Its easier to run complex setup of applications as each user is provided by a complete OS and can setup interactions between the applications.

Harder
- Xen VM runs in ring 0, runs the OS in hardware ring 1 while the applications still run in ring 3. This still ensures that the OS runs at a higher level than the applications. It also means that many of the registers are not directly accessible to the OS such as the page fault address register or exception stack and need extra copying. Such similar issues make porting the OS a heavyweight operation.

Summary:
This paper presents Xen, a hypervisor which provides virtualization support for hosting upto 100 guest operating systems. Apart from supporting most of the commodity operating systems with very low performance overheads (~3%) as compared to the 'bare metal' case, it provides performance isolation and accounting without significant changes for porting.

Problem:
Xen, is a hypervisor which revisits "para-virtualization" introduced in the Denali VMM. The primary problem solved is to provide performance isolation (eg. scheduling priority, memory demand, network traffic and disk access) between different guest OS without any provisioning or closed user group access, as followed in earlier approaches (such as PlanetLab slivers and OS resource containers).

Contribution:
- Paravirtualization in Xen supports virtualizing all architectural features with unmodified application binaries (unlike the Singularity approach). This is accomplished by using hypercalls and events.
- I/O rings and privilege levels, and the idea of execution domains help Xen to scale upto 100 guest OS. Though the idea of execution domains already existed prior to 2003 (microkernel and exokernels).
- Like Hydra, Xen also aims to separate policies from mechanisms. The Xen control interface and Dom0 are responisble to control the associated scheduling parameters, physical memory allocations and disk access (application management).
- Avoids TLB flushes (may be TLB shootdowns also!) by allowing guest OS to allocate and manage the hardware page tables and allocating the top 64MB of every address space to Xen - Nice trick to avoid entire TLB flushes when entering and leaving the hypervisor.
- Provides performance isolation and accounting for resource usage. The timely IO scheduling provides greater resilience to virtual machines running hostile workloads. Hence excess demand is checked for the XenoServer (usage accounting).

Flaws:
- IO data is transferred from one domain to other in the form of shared memory (asynch. buffer descriptor rings). This idea is not novel - also used for fbuf aggregates \cite{refer IOLite mechanism of fbufs OSDI '99}.

However Xen 1.0 did not completely follow this approach to make buffers read-only (immutable) or use copy-on-write semantics. In later Xen versions, it has resorted to this approach, by adding CoW semantics to virtual block devices to allow safe sharing among domains.
- Device drivers are not completely oblivious to the underlying Xen control interface in Dom0. This forces them to incorporate changes in them (1070 lines of change in virtual block-device driver in Linux - refer Table 2).

What it makes easier?
- It helps to incoroporate accounting in the block storage architecures for XenoServer and later even added support for auditing and VFR rules. This really makes Xen different from existing virtualization frameworks.
- Now Xen even supports virtual machine migration, with support for Direct IO (starting with Xen 3.2). The downtime is of the order of 60-300ms \cite{wikipedia}.
- TLB flushes are avoided to a large extent by keeping Xen in the top 64MB of address space of each guest OS.
- It provides paravirtualization without modifying the application binary interface. Though minimal changes are required to port the guest operating systems (Table 2). But the performance gains over existing virtualization frameworks (VMWare workstation, ESX Server, UML) outperforms these efforts (refer Figure 3).

What it makes harder?
- Device drivers are not completely oblivious to the underlying Xen control interface in Dom0. Also pointed as one of the flaws above (also refer Table 2 and Figure 1).
- Data sharing between different domains is not safe and controlled. However as part of the future work, they aim to introduce "universal buffer caches" with Copy on Write semantics.

Summary:

This paper talks about Xen, x86 virtual machine monitor which allows multiple operating systems to share resources in an efficient manner without sacrificing performance or functionality.
This project was designed in order to take care that, virtual machines remain isolated from each other, they are capable to support multiple operating systems to accommodate the popular applications and the performance overhead due to virtualization is small.

Contributions:

1. Guest OSes are responsible for allocating and managing hardware page tables. Xen exists at the top 64 MB section of each address space to avoid TLB flushes un-necessarily.
2. All Guest Oses execute at privilege ring 1 or 2 and Xen runs at ring 3. A table describing handler for each type of exception is registered with Xen.
3. Xen provides simple device abstractions, I/O data is transferred to and from each domain via Xen, using shared memory, asynchronous buffer-descrptor rings.
4. Synchronous calls from Guest OS to Xen can be made by Hyper calls and and asynchronous events can be send by Xen to domains.
5. Data transfer is achieved by means of I/O Rings, which is a circular queue of descriptors. Domains place requests on Ring and is answered by Xen.
6. Xen uses virtual firewall router, where each domain has one or more network interface logicacly attached to VFR and these NIFs are used to communicate.

Advantages:
1. Implementing the concept of exokernel allows users to use unmodified binaries, in resource controlled fashion. Its capable of hosting 100 OSes.
2. Mechanism of managing Virtual block devices within Xen keeps it simple and prevents complicated design.
3. The system is robust as building new system or mounting new Guest OS is the job of domain0. Thus, running something out of privilege keeps it safe.
4. Xen provides an excellent platform for deploying wide network-centric services.
5. Xen reduces the cost of installing short time usage OS on a separate dedicated machines. Capability of running 100 guest OS efficiently, with less overhead is a great advantage.

Disadvantages
Effective virtualization in x86 MMU is achieved at the cost of increased complexity and reduced performance. Porting Operating Systems on machine would require lots of effort.

The idea of sharing computer resources is as old as computers themselves. Multiple approaches have been used in dividing the resources into small shares and assign resources per task. Virtualization is one answer to those problems. The paper describes Xen, a system which allows for multiple host operating systems to share the hardware and provides guaranteed isolation and good performance.

Xen tries to focus into something radically different than systems of the past: Quality of service in environments where there might be uncooperative processes. Although they don't formally guarantee absence of starvation, they show experimentally that a malicious application can't degrade the performance of the other applications (aka. virtual machines) running on the same system. This very nice property has made virtualization a very strong player in the cloud computing environment and is used in services such as Amazon's EC2. Also I really liked the clever experimental evaluation which highlights the strengths of Xen.

One flaw of the paper is that it is tied to the x86 architecture. Porting the same idea into an environment where there are only two protection levels (privileged/unprivileged) and enforcing memory protection sounds hard. Additionally, the design choice of requiring modifications in the host operating system to work with the hypervisor, although important from a performance standpoint, makes the approach less flexible. A better strategy seems to be a hybrid monitor, which takes advantage of the Xen-specific extensions if they are there, or otherwise reverts to a slow emulated execution.

The proposed architecture allows for easy control of the resources each application is allowed to use. A virtual machine monitor can display the monitor statistics of resources usage of an application in time and can easily change the allocated resource quotas, while maintaining service guarantees. This is an elegant solution to the major problem many data centers face today, where elasticity and high utilization are very desirable. However, I believe that the idea of running one service in each virtual machine is a bad idea due to the overhead of running an operating system for each application. Finally, there might be scenarios where we want some of the properties of virtualization, like strong isolation, process migration and quota enforcement but we want to allow certain applications to share data among different virtual machines, without exposing this complexity to the application programmer.

The Xen and the Art of Virtualization discusses an abstraction that controls and virtualizes all the hardware for the overlaying operating systems through paravirtualization. Xen is a hypervisor operating as the highest privileged controller for the domains and masks the hardware with a virtual machine interface.

The Xen design is trying to create a virtualization layer for multiple operating systems to reside, while still having strong performance and resource management. Additionally it is trying to address a way to make a system capable of hosting short lived servers on a single machine with low setup cost.

The Xen hyperviser implements a working paravirtualization library with performance statistics. It also adds the idea of a control interface into the abstraction layer for management.

The design requires guest operating systems to be ported to work above the XEN hypervisor. This requirement makes operating system developers to need to create special versions of their applications to work on ZEN, which can be tedious if the OS and drivers have a very rich interface to the hardware. This is the reason why as of this time, XenoXP has not yet been fully ported to work above XEN.

The XEN hypervisor is organized to be the lowest level to the hardware, and handles all system calls to the hardware through a virtual machine interface that virtualizes the CPU, physical memory, network, and block devices. The XEN has a Domain0 control interface which the GuestOS acting as the Control OS can use to manage the domains on the system. The system makes it easier to have multiple operating systems running on a single powerful machine with the ability to quickly start additional virtual machines, and optimize the efficiency in comparison to having a virtual machine running inside another operating system. XEN makes it harder to simply migrate operating systems without needing any porting, but once ported, adds the ability to be compatible with legacy applications.

Summary: The authors of this paper present Xen, a virtual machine monitor built upon the paravirtualization abstractions. Unlike other VMM, Xen focuses on complete isolation between virtual machines for the x86 architecture, and they present detailed performance results for Xen, compared to other some other VMMs.
Problem to Solve: The main goal presented in this paper is develop a virtual machine monitor is such a way that individual machines are isolated from each other, without hindering performance while still allowing for a diverse set of operating systems to be run. Specifically, they want to ensure that network traffic, memory demands and scheduling priorities don’t conflict between virtual machines to achieve the best performance possible.
Contributions: First of all, the authors introduce the idea that Xen can handle a large number of operating systems that are used in practice today, instead of limiting the VMM to a large number of specialized operating systems. Secondly, Xen is able to handle multiplexed processes per machine user, unlike previous VMM that could only handle a single process per user. This opens up the door for users to multitask operations and increases productivity of individual machines when resources are available. Another valuable contribution is the CPU virtualization that consists of four primarily rings. This places the Xen hipervisor to reside in ring 0 and the operating system in ring 1 to allow the hipervisor to have supervisory control over all the other rings for protection and security. This ring approach also still allows applications to be separate from operating systems because they reside at different levels help control malicious applications from harming the system.
Flaws: One flaw of the paper is that it doesn’t ever mention if architectures with more than one CPU could effectively be virtualized. Although duel and quad cores were just appearing during the publication time of the paper, stating (anticipated) support for such architectures would make this VMM very useful for owners with the need to run CPU intensive applications on different OSes.
Advantages of Proposed OS: One advantage of Xen is that it is suitable for the x86 architecture, which the authors explain is one of the hardest architectures to build an VMM for. This is advantageous because if the VMM can run on a complex architecture it can likely be ported to a simpler one (or some of the ideas it’s built upon can be), and used more wide spread. Another advantage is that the Xen design provides for it’s own network firewall, further protecting the operating systems that run on it.
Disadvantages: One disadvantage of the system is that each different operating system must be port to the Xen. In general, this is probably a very few number to be converter, but it would prohibit a server administrator from installing a specific OS if they didn’t have the time to convert the code. Another disadvantage is that for the VMM to perform correctly with the operating system everything must be virtualized in the hypervisor and all operating systems must be compatible with this virtualization. Not everything can be virtualized easy (which is why this is a problem); one example is the software TLB not present on the x86 platform.

Summary
In “Xen and the Art of Virtualization”, Paul Barham et al. describe a system designed to virtualize hardware and run other operating systems, with some code modifications, concurrently upon that hardware.

Problem
Virtualization of hardware is not a new concept; indeed, there are already a variety of commercial products that provide for virtualizing a machine (VMWare, for example). Virtual machines provide some clear benefits such as allowing for concurrent use of multiple operating systems when certain features that are not all available in one OS are needed. Perhaps even more importantly, virtual machines can be set up on servers and can provide multiple users with an isolated environment, guaranteeing non interference from other software without the costs associated with isolating each user by providing independent hardware. However, virtual machines have historically suffered a loss of performance which results in inefficiency and thus hinders deployment in certain situations. The Xen system attempts to overcome this by requiring the OS that is to be virtualized to be slightly modified.

Contributions
• Demonstrating through experimental results the feasibility of modifying existing OSs as a means to improve virtualized performance almost to the point of running the OS natively.
• Creating a system in which modification of user-level programs is not necessary; all the changes needed for efficient operation are done on the guest operating system.
• Allowing the guest OS to directly access hardware in cases where such an access has no chance of adversely affecting the system (e.g. direct read access to hardware page tables).

Flaws
• The required operating system modifications may not be quite as easy to do as this paper seems to make them out to be. Only one OS has so far been fully ported (though admittedly work on others has been done, they are not yet complete, so unforeseen issues may arise) and other popular OSes (notably closed source ones) may be difficult to modify.

Organization
The Xen hypervisor virtualizes hardware components and ensures safe and fair sharing among running virtual machines, while at the same time providing facilities that promote efficient use of the system. Xen runs directly on top of the machine hardware; on top of this layer runs a Xen-modified Guest operating system which has the necessary modifications to make use of Xen properly. Finally, user-level applications are run on top of the guest operating systems with no necessary modifications.