Emulacja umożliwia uruchomienie na dowolnej platformie kodu przeznaczonego na dowolna inna platformę. Jest to możliwe gdyż każdy rozkaz tłumaczymy na odpowiedni rozkaz dla macierzystego procesora. Nie jest to jednak zbyt efektywne rozwiązanie. Dlatego wciąż dąży się do przyspieszenia tego procesu. Nasuwa się pytanie czy trzeba tłumaczyć wszystkie rozkazy gdy fizyczna architektura i ta wirtualna są identyczne? Z pozoru pytanie brzmi bez sensu gdyż po co mamy emulować na procesorze x86 system Linux? Załóżmy ze mamy jedna mocna maszynę i chcemy na niej uruchomić jednocześnie aplikacje dla windows XP, Linuxa, i BSD. I tu przychodzą nam z pomocą narzędzia służące do wirtualizacji -- narzędzia, które starają się jak najwięcej instrukcji wykonać na rzeczywistym sprzęcie.
My zajmiemy się tutaj wyłączenie architektura x86. Jest to jedna z najbardziej popularnych obecnie platform i jedna z tych które sprawiają najwięcej problemów podczas wirtualizacji. Widać to gdy przyjrzymy się zbiorowi instrukcji, które mogą być uruchamiane w trybie nie uprzywilejowanym, ale podczas wirtualizacji sprawiają problemy. Oczywistym jest fakt ze trzeba emulować instrukcje działające w trybie uprzywilejowanym gdyż aplikacje użytkownika nie działają w takim trybie. Z tym aspektem nie ma problemu gdyż wykonanie instrukcji uprzywilejowanej przez aplikacje generuje General Protection Fault, o ile z tymi instrukcjami radzimy sobie bez problemu to resztę niestety musimy monitorować.
Xen jest wirtualnym monitorem który umożliwia uruchomienie wielu systemów operacyjnych na jednej maszynie x86. Umożliwia on bezpieczne dzielenie fizycznych zasobów pomiędzy systemy bez utraty funkcjonalności.
Xen umożliwia uruchomienie na jednej maszynie systemy takie jak Linux, FreeBSD(w fazie tworzenia) i Windows XP(w fazie tworzenia) jednocześnie, całkowicie je izolując miedzy sobą i dając minimalny narzut na czas wykonywanych programów. Umożliwia on uruchomienie nawet do 100 SO na jednym komputerze. Każdy system operacyjny dostaje własną virtual mashine(VM) -- odpowiedzialne za przydział zasobów. VM pracują na virtual mashine monitor(VMM). Można powiedzieć ze Xen jest systemem operacyjnym działającym bezpośrednio na sprzęcie.
Niestety, aby uruchomić systemy operacyjne na Xenie trzeba je lekko zmodyfikować tak aby mogły być uruchamiane z poziomu uprzywilejowania 1. Na poziomie 0 działa jedynie VMM, z kolei aplikacje użytkowników działają na poziomie 3. Koszt takiej modyfikacji nie jest jednak zbyt wysoki.
Powyższa tabela reprezentuje ilość linii kodu jaka należy zmodyfikować w poszczególnych systemach aby uruchomić je jako Guest OS.
Są 2 sposoby przełączania kontroli pomiędzy Xen a Guest OS. Pierwszym są synchroniczne wywołania przełączające kontrole do Xen (tak zwane hypercall). Hypercall pozwalają systemowi operacyjnemu na wykonywanie uprzywilejowanych instrukcji, np: prośby o zmianę tablicy stron. Natomiast komunikacja w druga stronę(w szczególności dostarczanie przerwań sprzętowych do systemów operacyjnych) z Xen do Guest OS ma charakter asynchroniczny. Pozwala to na buforowanie zdarzeń. Do buforowania zdarzeń Xen wykorzystuje cykliczne kolejki:
Dzięki kolejkowaniu zdarzeń mamy bardziej efektywny mechanizm wymiany danych.
Do podziału procesora pomiędzy VM zastosowano algorytm Borrowed Virtual Time (BTV). Charakteryzuje się on niskim narzutem czasowym związanym z budzeniem procesów.
Xen wprowadza dla guest OS pojęcia czasu rzeczywistego, czasu wirtualnego oraz wall-cock time. Czas rzeczywisty jest mierzony w nanosekundach od momentu wystartowania maszyny. Czas wirtualny jest liczony dla każdego systemu oddzielnie - dzięki temu system operacyjny jest wstanie uczciwie podzielić czas pomiędzy aplikacje. Wall-clock time pamięta przesuniecie w stosunku do czasu rzeczywistego umożliwiając działanie SO bez konieczności modyfikacji czasu rzeczywistego w systemie. Każdy z Guest OS ma ponadto do dyspozycji 2 timery, jeden działający ,,na podstawie'' czasu rzeczywistego, drugi czasu wirtualnego.
Xen stara się maksymalnie optymalizować dostęp do pamięci. Oznacza to ze system operacyjny może bez problemu odczytywać pamięć operacyjną. Natomiast wszelkie zmiany w pamięci wprowadzane są już pod kontrola Xena. Aby taka obsługa pamięci była możliwa Xen musi zarejestrować tablice pamięci SO bezpośrednio w MMU
Poniższy rysunek prezentuje 6 scenariuszy pracy i ilustruje wydajność poszczególnych aplikacji. Pierwszy scenariusz -- opisany przez autorów jako banalny ;) -- bada wydajność procesorów(chyba wirtualnych), jednostki zarządzania pamięcią oraz kompilatorów. Ponieważ w tym teście większość operacji nie wymaga trybu uprzywilejowanego stosunkowo mało jest operacji wymagających emulacji, stąd wyniki są mocno zbliżone.
Drugi scenariusz polegał na stworzeniu domyślnej instalacji linuxa(kompilacja jądra, stworzenie partycji ext3). W przypadku Linuxa działającego bezpośrednio na sprzęcie około 7% czasu CPU było wykorzystywane, resztę czasu pochłaniały operacje plikowe I/O, oraz operacje obsługi pamięci. Narzut w przypadku Xena w tym teście wynosił około 3%. Kolejne 2 testy dotyczyły wykorzystania PostgreSQL 7.1.3 skonfigurowanego domyślnie. Wartości prezentują ilość sekund jaką zajęło zadanie. Skróty oznaczają odpowiednio:
dbench
Ostatni test polegał na zasymulowaniu serwera HTTP. Serwer miał obsłużyć: dynamiczne generowanie stron (30% zapytań), HTTP POST (16%), oraz wykonywanie skryptów CGI (0,5%). Ponadto serwer miał logować wszystkie zapytania -- czyli dostęp do dysku nie był tylko w trybie read-only co wiąże się z dodatkowymi narzutami. 