Czym wirtualizacja różni się od emulacji pod względem struktury?

Ktoś powiedział mi, że program do wirtualizacji, taki jak VirtualBox, nie działa tak jak emulator, w tym sensie, że nie emuluje rejestrów i wykorzystuje te rzeczywiste dla danych zwirtualizowanych, które są na CPU. Emulatory muszą emulować rejestry, ponieważ służą one głównie do uruchamiania oprogramowania zależnego od obcego środowiska (np. Emulator Genesis potrzebuje rejestrów i adresów pamięci Motoroli 68000, więc deweloper musi udostępnić te zasoby jako emulowane rejestry).

Moje główne pytanie brzmi: jak rozwija się wirtualizacja? Jak umożliwić całemu systemowi operacyjnemu działanie jako proces na maszynie wirtualnej, ale sprawić, aby działał niezależnie, wciąż wykorzystując rzeczywisty procesor? Znam tylko emulację, a nie wirtualizację, więc jeśli ktokolwiek mógłby pomóc, byłoby miło!

PS: Nie pytam wyłącznie o różnicę, ale różnice w sposobie działania oprogramowania.

Początkowo nie można było pozwolić systemowi-gościowi na używanie prawdziwego sprzętu, ponieważ nie można było go kontrolować. Jeśli próbowałbyś uruchomić go na prawdziwym procesorze, nie miałeś gwarancji, że przekaże on kontrolę z powrotem do systemu operacyjnego hosta.

Wirtualizacja zgodnie z opisem jest implementowana na sprzęcie, umożliwiając stosowanie określonych reguł i ograniczeń na poziomie sprzętowym, którymi może zarządzać system operacyjny hosta. Dzięki temu system operacyjny hosta może skonfigurować reguły dotyczące tego, co gość może, a czego nie może zrobić, a następnie uruchomić gościa na prawdziwym sprzęcie. Jeśli gość spróbuje zrobić coś z prawdziwym sprzętem, który narusza reguły (np. Próbuje uzyskać dostęp do urządzenia dyskowego), sprzęt zawiesi gościa i wyśle ​​hostowi przerwanie, co pozwoli hostowi na udzielenie odpowiedzi (np. zwracanie danych z emulowanego urządzenia dyskowego), a następnie wznawianie gościa.

Oto uproszczony przykład tego procesu:

System operacyjny hosta: hej procesorze, potrzebuję, aby uruchomić ten kod zwirtualizowany. Zadzwoń do mnie, jeśli chce zrobić coś, co nie polega tylko na wykonywaniu instrukcji.

Host CPU: Masz to!
Procesor hosta zapisuje wszystkie rejestry i stan hosta, a następnie rozpoczyna wykonywanie kodu systemu operacyjnego gościa

System operacyjny gościa: żyję! Hej, czy możesz mi zdobyć ten plik?

Procesor hosta: Uh ... jasne. Jeden moment.
Procesor hosta zapisuje wszystkie rejestry i stan hosta, a następnie przywraca wszystkie rejestry hosta i stan.
Procesor hosta: Hej, Host OS, Gość chciał tego pliku!

Host OS: Och, daj im to: Plik z wirtualnego dysku twardego

Host CPU: Masz to!
Procesor hosta zapisuje wszystkie rejestry i stan hosta, przywraca rejestry i stan gościa, a następnie rozpoczyna wykonywanie kodu systemu gościa
Procesor hosta: Oto ten plik!

System operacyjny gościa: Słodki, dziękuję!

Kluczową różnicą jest tutaj emulator, system operacyjny gościa nigdy tak naprawdę nie działa na sprzęcie. Dzięki wirtualizacji system operacyjny hosta konfiguruje ograniczenia procesora, a następnie uruchamia kod gościa na fizycznym procesorze. Powyższy przykład jest niezwykle uproszczony, ale pamięcią, dyskowym wejściem / wyjściem, a nawet siecią można sterować za pomocą najnowszych współczesnych procesorów, co pozwala na ich bezpieczną komunikację bez konieczności zawracania głowy systemowi operacyjnemu za każdym razem. Dopóki gość nie próbuje wyjść poza zwirtualizowane granice, system operacyjny hosta może nie mieć uruchomionego kodu, jeśli nie ma nic do zrobienia w danym momencie.

Aby dodać trochę perspektywy, jest to tylko kolejny krok w długiej historii wirtualizacji i kontroli. (Nie ma gwarancji, że jest to w prawidłowej kolejności lub wyczerpujące, ale powinno dać dobry przegląd początkowy)

Pierwotnie nie było wirtualizacji. Wszystkie procesy współużytkowały tę samą przestrzeń pamięci, wszystkie miały pełny dostęp do sprzętu, a zdolność do wykonywania wielu zadań była całkowicie zależna od zatrzymania się jednego procesu i przekazania kontroli nad kolejnym procesem. Jeśli system operacyjny chciał mieć jakąkolwiek kontrolę nad procesem, musiał uruchomić proces w emulatorze (nikt tego nie zrobił, ponieważ był zbyt boleśnie powolny).

Najpierw była pamięć uprzywilejowana : niektóre działania, które mogą być wykonywane tylko przez specjalne regiony pamięci. Regiony te są zajęte przez system operacyjny, co pozwala mu działać jako brama do tych uprzywilejowanych działań. Przykładem jest możliwość odczytu / zapisu danych na sprzęcie. Zapobiega to odczytywaniu / zapisywaniu procesów bezpośrednio na dysk twardy, a zamiast tego zmusza je do poproszenia systemu operacyjnego o odczyt / zapis. Oznacza to, że system operacyjny może sprawdzić, czy proces ma uprawnienia przed wykonaniem akcji.

Następnie nadeszła zwirtualizowana „godzina”. System operacyjny może skonfigurować procesor tak, aby przerywał aktywny proces w określonych odstępach czasu, pozwalając mu przejąć kontrolę nad harmonogramem i przełączać się między procesami. System operacyjny może teraz uruchamiać procesy bezpośrednio na sprzęcie i nadal zapobiegać niewłaściwemu wykorzystaniu czasu procesora. Zostało to dostarczone przez sprzętowy zegar .

Następnie pojawiła się zwirtualizowana pamięć : Problem z pamięcią współdzieloną polega na tym, że każdy proces może odczytać pamięć dowolnego innego procesu. Co się stanie, gdy program Mary odczyta hasło Boba z jego przeglądarki internetowej? Pamięć wirtualna umożliwia systemowi operacyjnemu mapowanie pamięci, którą proces widzi na różne części pamięci fizycznej, a nawet całkowite przeniesienie ich z pamięci fizycznej (do pliku strony). Za każdym razem, gdy proces próbuje odczytać lub zapisać w pamięci, VMMU (jednostka zarządzania pamięcią wirtualną) CPU sprawdza, gdzie jest zamapowane w pamięci fizycznej, i wykonuje tam akcję. Jeśli jest zamapowany w pamięci, procesor wywołuje system operacyjny, aby pobrać stronę do pamięci z pliku strony.

W porządku, więc w tym momencie dotarliśmy do początków procesora X86, w którym możemy bezpiecznie uruchamiać procesy i aktywnie zapobiegać przejmowaniu przez nie systemu, chyba że system operacyjny na to pozwala. W tym momencie procesy są skutecznie „zwirtualizowane”. Wsparcie to istnieje od dawna , więc tak naprawdę nie słyszysz ludzi rozmawiających o zwirtualizowanych procesach, ponieważ zakłada się, że wszystkie procesy są teraz zwirtualizowane.

Dlaczego jednak zwirtualizowane systemy operacyjne są wyjątkowe? Dlaczego nie możemy po prostu uruchomić jednego procesu i pozwolić mu robić to samo? Problem polega na tym, że jako system operacyjny, system-gość oczekuje, że będzie mógł uzyskać dostęp i używać tych samych elementów sterujących, których host używa do sterowania procesami - w zasadzie system operacyjny oczekuje, że będzie najwyższym władcą komputera i po prostu nie będzie działa, jeśli tak nie jest. Rozszerzenia „Hardware Virtualization” (AMD-V dla AMD i VT-x dla Intela) umożliwiają systemowi operacyjnemu hosta zwirtualizowany zestaw wirtualnych kontroli procesów (wirtualna pamięć uprzywilejowana, wirtualne zegary sprzętowe, wirtualna pamięć wirtualna).

Jak umożliwić całemu systemowi operacyjnemu działanie jako proces na maszynie wirtualnej, ale sprawić, aby działał niezależnie, wciąż wykorzystując rzeczywisty procesor?

(Poniższe jest bardzo uproszczone.)

Wykorzystując ten sam lub podobny mechanizm, którego używa system operacyjny, aby utrzymać procesy w trybie użytkownika w szeregu, głównie.

Procesy w trybie użytkownika powodują wyjątki procesora, gdy próbują zrobić coś, czego nie wolno im robić.

Tak więc, jeśli jądro systemu operacyjnego działa w trybie użytkownika, za każdym razem, gdy próbuje zrobić coś takiego, jak bezpośredni dostęp do sprzętu, spowoduje to wyjątek. Hiperwizor może wychwycić ten wyjątek i odpowiedzieć emulowanym lub zwirtualizowanym zachowaniem, zamiast powodować awarię systemu, tak jak normalne jądro.

Może wykonywać dostęp sprzętowy w imieniu tego jądra, modyfikować dostęp sprzętowy (tj. Uzyskiwać dostęp do części pliku zamiast bezpośredniego dostępu do sektora dysku) lub cokolwiek innego, co sobie wymarzysz.

Rozszerzenia maszyny wirtualnej CPU w zasadzie rozszerzają cały tryb „nadzorcy” lub „chronionego” procesora o jeden poziom, aby dokładnie to zrobić, a także zapewniają dodatkowy „poziom zagnieżdżenia” pamięci wirtualnej, dzięki czemu stronicowanie jest łatwiejsze do wirtualizacji.

Wirtualizacja polega na symulacji części sprzętu komputerowego - wystarczającej do działania niezmodyfikowanego systemu operacyjnego gościa - ale większość operacji wciąż odbywa się na prawdziwym sprzęcie ze względu na wydajność. Wirtualizacja jest zatem zwykle szybsza niż emulacja, ale prawdziwy system musi mieć architekturę identyczną z systemem gościa. Na przykład VMWare może zapewnić środowisko wirtualne do uruchamiania wirtualnej maszyny z systemem Windows XP „wewnątrz” prawdziwej. Jednak VMWare nie może działać na żadnym prawdziwym sprzęcie innym niż prawdziwy komputer x86.

W emulacji maszyna wirtualna symuluje cały sprzęt w oprogramowaniu. Pozwala to na uruchomienie systemu operacyjnego dla architektury jednego komputera na architekturze, dla której napisany jest emulator. Ponieważ wszystkie operacje są wykonywane w oprogramowaniu, emulacja jest zwykle wolniejsza, jednak może obsługiwać więcej platform, ponieważ jest niezależna od sprzętu.

Dla kompletności istnieje również symulacja , w której działania maszyny są powielane, ale przy użyciu kodu, którego elementy wewnętrzne mogą być radykalnie różne od „prawdziwej” maszyny. (Pomyśl o „symulatorze lotów”). Często symulatory kompilują „prawdziwy” kod źródłowy maszyny, ale są ukierunkowane na zupełnie inną architekturę procesora, z zupełnie innymi systemami operacyjnymi i urządzeniami we / wy.