Kapitel 3

3 Process Virtual Machines
Erlaubt Programmen auf ungleichen ISA oder OS zu laufen.
VM ist ebenfalls wie ein Programm auf den Host aufgesetzt. ABI ist die Schnittstelle zum HW und OS
ISA.
Mapping of State, Emulation of memory addressing architecture, instructions, exceptions, OS calls.
3.1. Implementation
Vorgang:
‐ Der Lader schreibt in das Memory, die das Guest Memory Image hielt und der runtime Code ladet.
‐ Lader übergibt Kontrolle an Initialblock (Signal handlers for trap condition).
‐ Die Emulation Engine startet durch:
o Binary Translation
o Interpretation durch predecoding
und im Cache wird der Code gehalten.
‐ Code cache manager räumt auf den Speicher
‐ Profile Database: Optimierung
- OS call Emulator: übersetzt die calls
‐ Call/Trap – Exception Emulator Manager behandelt Fehler (von Interpreter, wie auch von
Übersetzer)
‐ Side Tables enthalten anfallende Daten (Struktur). Implementierung Präzisere Exceptions.
3.2. Kompatibilität
Ist das Verhalten von Host und Gast gleich?
Es wird keine Leistung verglichen: ‐ nur Funktionalität!
3.2.1. Levels of Compatibility
Intrinsische Kompatibilität ≈ komplette Transparenz (System/Codesigned VM): Das Verhalten ist bei
Gast und Host gleich.
Extrinsische Kompatibilität: Das Gastsystem hat spezielle Anforderungen an den Host. Kompatibilität
nur unten bedingte Anforderungen.
3.2.2. A Compatibility Framework
Kompatibilität ist schwierig zu testen, das gesamte System muss getestet werden. Zuerst aber teilen
wir:
i. Mapping of State ( Ressourcen): user-managed state und OS-managed state
Guest-Host registers. OS-managed state können unterschiedlich gehalten werden.
ii. Operationen: transferieren der Kontrolle
Sufficient Compatibility Conditions
1. User State soll während den Kontrollen Transfer zugänglich sein und die Stati äquivalent sein.
2. Guest Stati muss äquivalent sein.
Discussion
Welche Faktoren können bei einer extrinsisch‐kompatiblen VM zur Einschränkung der ausführbaren
Programme führen (fünf Faktoren):
1. Der Speicher: Es können Beschränkungen (z.B. des Limits) für den physischen Speicher geben.
Nur Programme die wenig Speicher nutzen sind intrinsisch kompatibel.
2. Der Compiler: Es können Versionsunterschiede auftreten, die den Funktionsumfang
reduzieren – oder bei der Binärübersetzung werden bestimmte Anweisungen (traps) eliminiert.
3. Die Instruktionen (z.B. float‐point arithmetic): Es können unterschiedliche Ausführungen
stattfinden.
4. Das Betriebssystem: Es können Funktionen auftreten, die vom Host nicht unterstützt werden.
5. Die Ein‐ bzw. Ausgabegeräte: Es kann der Zugriff auf Ein‐ bzw. Ausgabegeräte eingeschränkt
oder verweigert werden.
3.2.3. Implementation Dependences
1
Architechtur vs. Implementation. (Funktion vs design). Z.B. Instruktion and Data Cache  Instruktion
Cache flusher. Nach Selbst modifizierter Kode: funktioniert nur wenn der Cache Code explizit geleert
wird.
3.3 State Mapping
Logical Memory vs real memory
3.3.1. Register mapping
Register context Block: existiert wenn Guest ISA Register > Host ISA Register
Runtime verantwortlich für die Verwaltung der Host Register: pop, push.
Guest ISA register < Host ISA register: ok, dazu gibt’s noch den Context Block
Guest ISA register = Host ISA register
3.3.2. Memory Address Space Mapping
A kann im Position A’ gespeichert werden.
Runtime Software-Supported Translation Tables
Host: multiple of Guest Pages, im Host sind nicht naheliegende.
Translation: Mapping table
Runtime Memory Manager entscheidet welche Blocke müssen ersetzt werden: step-by-step code
intensive mapping.
If all else failes: when 64bit als Guest und 32 als Host.
Direct translation method
HD verbundene Methode: mit offset oder mit gleiche Platzierung zwischen Guest und Host.
Ein-zu-ein Übersetzung zu Ziel: load und stores.
Compatibility Issues
Kode und Data teilen die gleiche Addresse mit der Guest Apps.
Guest Process + runtime software = grosses Host address space für direct Mapping.
Intrinsische Kompatiblität 1/α performance
Strategische Platzierung von runtime um die direkte Übersetzung zu ermöglichen. Runtime Kode
kann verschoben werden während der Ausführung.
3.4 Memory Architecture Emulation
- Overall structure of the address space: linear space technique
- The access privilege types that are supported: R, W, E.
- The protection/allocation granularity: smallest size and protection granularity
3.4.1. Memory Protection
Software Translation table: correct aber langsam.
Host-Supported Memory Protection
Host OS features um das zu Emulieren:
- System call von Applikations abrufe, definition R, W, E, keine.
- Signal für Memory beim Access violation
Linux: mprotect(param1,param2,param3) und SIGSEGV signal
Page size issues
Einfach wenn Guest Seite ist multiple von Host. Sondern kann eine Host Seite mehr Guest Seiten
enthalten  allocation, reallocation die die Portabilität reduziert.
Protection Sets Übereinstimmen nicht: protecton superset, subset.
Host RW, Guest RWE. Right check als Teil des OS Übersetzungsprozess
3.4.2 Self-Referencing and Self-Modifying Code
Nicht der Originelle Kode wird ausgeführt, wenn der Originelle geändert wird muss es auch die Kopie
sein.
Basic Method
Alle load und store Adresse werden gemappt  Implementierung ist korrekt
Source ist Schreibe-geschützt, beim Versuche den Originalen Kode zu schreiben, wird die Memory
gefuscht, interpretations-modus gestartet, retranslation.
Pseudo-Self-Modifying Code
Schreibbare Areas sind mit Kode unterbrochen
2
Side Table
Schnellere alternative mit Link/Unlink von Prolog Kode. Das erste Mal Linked/write enabled und
verglichen
Fine-Grain Write-Protection
Man flusht nicht den gesamte cached Code. Code-Data Seiten (128byte granularity) Data sind nicht
schreibgeschützt  kein trap beim schreiben = kein cache flush.
True Self-Modifying Code
Idiom recognition (loop counter ist selbstmodifizierend), frequently Modified immediate Field.
Verschidene Source Codeversionen werden gespeichert = grosses Overhead aber keine Translation
Protecting Runtime Memory
Für Kompatibilität und Korrekte Resultaten: nach R&W sollte das Guest Programm nicht weiter
ausgeführt werden.
Check von kleinen Segmenten, Host Register haltet die Segmenten.
Emulation mode: übersetzte Kode wird ausgeführt  Code muss geschützt werden (ref. Zum
selbest, mit map table und link pointer werden jump, Brunch gemacht.
Runtime mode: alles anderes (binary trans), Interpretation.
Switch Mode: von Emulation zu runtime.
Registers sind nativ besser Geschütze und in VM werde ausserhalb der Guest Memory gespeichert.
Extrinsische Kompatibilität: Programm muss keine Memory zugreifen, die ausserhalb liegt.
3.5 Instruction Emulation
High Performance Process-level Machines
Performance Tradeoff
Start-up time: einmalig, um das Code in einem anderen Format zu konvertieren.
Steady-State Performance: durchschnittliche Zeit für die Emulation
S+NT = start + N * Zeit für die Emulation
Performance crossover point: wenn n > 55 Zyklen per Instruktion dann binary translation, sonst
interpretation
3.5.2. Staged Emulation
Runtime’s emulation manager. Meherere Emulationen in Stage Ausgeführt.
Profile data: sammelt Daten über der Emulation von Blöcke. Vergrössert der Steady state.
Bei exception von Interpreter, oder bei exception Kondition von Translation, die Kontrolle geht an
den exception emulator.
Start: Interpretation and move to binary translation von Blöcke oder Superblocks (Kombination von
Basic Blocks) werden kombiniert in:
- Simple Profiling: Generierung von Superblocke (Aries System, HP Dynamo)
- Skip Interpretation stage und macht einfache binäre Translation on Dynamik Blocks (Sun Wabi, IA32-EL und Mojo same ISA)
3.6. Exception Emulation
Exception: Trap oder Interrupt
Trap: produziert von spezifischer Instruktion
Interrupt: externes Ereignis
Präzis:
1. Wenn alle Instruktionen bis Fehler ausgeführt werden.
2. keine Instruktion nach den Fehler ausgeführt wird
3. Fehlerhafte Instruktion wurde nicht ausgeführt
2 Kategorien:
ABI visible: mit OS Signalen
ABI invisible: Abi bleibt „unaware“: Timer, ev. Page Fault.
3.6.1 Exception Detection
1. Interpretive trap detection: check durch Program
2. Detected by Host Platform, hängt von Semantic match des ISA
Signal calls werden von Host OS registriert und verwenden. Signal wird angepasst als Guest Quelle.
3
a. ABI trap visible in Host platform: handler invoked  proper action
b. ABI trap nicht visible in Host platform: checks in emulation code
c. ABI trap visible in Host, nicht im Guest Plattform: extraneous trap, runtime trap entscheidet
ob das zum Source Instruktion sichtbar sein wird.
Ein Host Trap (float, integer) für mehrere Guest Traps.
3.6.2. Interrupt Handling
ABI visible: Transfer to Interrupt Handler. VM wird auf einen besonderen Status gesetzt. Akzeptable
latency <100 Instruktion.
Interruptable point = code muss im runtime sein. (latency ist gross, z.B : bei loop)
Runtime bei Interrupt: lokate the Block and unlink von subsequent. Link zum „Runtime“
So: a) kein loop zu translation block, b) ende jeder Block ist interruptable
3.6.3. Determin precise Guest State
Complex by binary translation (Einfach in interpretation)
Interpretation
PC wird updated solange Interpretationen weiterlaufen.
Runtime Signal handler nutzt sourcePC
Binary translation: Locating the Program Counter
Determin the Source PC, weil das Interrupt im übersetzten PC passiert ist (Info aus der reverse
translation site table).
o Linear scan: besser bei binary search für FIFO
o Large table: grösser als übersetzte Kode. Target mit fixe-length instructions nur 1 Array[]
o Mehrere source - ein Target. Z.B. 2 RISC  1 CISC oder Rearranged, optimized Code: man finden
der korrekte Source Zustand nicht einfach
Hybrid side table Strukture: heufige trapping source PC kann gecached werden
Binary Translation: Register State
Kein reordering, keine optimization Funktionen entfernt.
Consistent register mapping (gleichzeitige Update): kann immer eingeholt werden.
Dynamische Source-Target-register Map (gleiche Ordnung des Updates): Side Table wird verwendet
Oder (wie bei trap PC) eine komplette Wiederherstellung der Registry
Binary Translation: Memory State
Memory wird wiedergeschrieben, Status will not be recovered.
Wird als Optimierung im Kapitel4 gehandelt.
3.7 OS Emulation
Emulation von Funktion call.
Es gilt, dass nur zwei typ‐ und versionsgleiche Betriebssysteme, auch den gleichen Funktionsumfang
haben. Sollte sich nun Host‐ und Gast‐Betriebssystem unterscheiden, ist der Funktionsumfang nicht
gleich. Es kann im schlimmsten Fall passieren, dass das Gastsystem einen Aufruf macht, wozu es
keine Funktion im Hostsystem gibt. Die Emulation ist damit nur unvollständig möglich.
3.7.1 Same Operating System
Operating system call Translation
Formatting arguments: match. Arguments sind im Memory stack.
System call is converted to a Jump.
Runtime-Implemented Operating System Functions
System call rufen den Runtime, der das Signal im Side table registriert.
Runtime kontrolliert die Memory direkt: z.B. die Memory Verwaltung.
Nasty Realities
Linux communicate at ABI level, windows at API (abnormal sind: call back, asynchronous procedures
call, and exception).
Events: message Queues. Event und routine werden ausgeführt. Danach geht der OS Kernel zum
nächsten Message.
In VM wichtig ist der Jump zum runtime vor der Beginn der routine. Dafur wartet der Runtime auf
besondere OS call.
4
3.7.2 Different-Operating-System Emulation
Instruction set sind logisch komplett.
Time of Day: manchmal ist nicht möglich das der Host die Funktion des Guest ausführt.
Emulation: ad hoc Process, man muss das gesamte System kennen.
Example: Enforcing File Limits
Linux: Filegrosse kann prädefiniert werden.
Lösung: z.B: Wabi system von Sun Microsystem euliert nur manche Win Apps (Word, Excel)
3.8 Code Cache
Unterschiede zum konventionellen Cache Verwaltung:
1. keine fixe länge
2. Chaining. Bei löschen von Blocken müssen link angepasst werden
3. Ist keine Copy
3.8.1 Code Cache Implementation
Braucht eine Side-Table.
- Gegeben der SourcePC finden der TargetPC. Bei Emulation control (z.B. von interpretation zu
Translated code) – mit Map Table
- Gegebne ein TargetPC, zu finden ein SourcePC – mit reverse translation side table
3.8.2 Replacement Alghorithms
Least recently used
1. Es müssten sekundär Daten (overhead) angelegt werden, der zusätzlichen Speicher benötigt.
2. Zeigerupdate müsste gelöst werden. Eine Möglichkeit wären Backpointer, wo durch alle
Referenzzeiger ermittelt werden können. In PC Map table oder side map table.
3. Wohl das größte Problem wäre, dass die Blockgröße von neuen und zu ersetzenden Block
Unterschiedlich sein kann. Defragmentierung sollte gemacht werden und Size und Lokation.
Reverse Translation table, binary search (=Anordnung) und lookup in reverse Table machen das LRU
nicht zuverlässig.
Verwendet werden Algorithmen die Brackepoint und Defragmentierung reduzieren:
Flush when Full
Einfach aber brutal, Superblocke und Orphans werden gelöscht.
Retranslation from Scratch: Hight performance overhead.
Preemptive Flush
Phase Change ist verbunden mit Instruktion working set change.
Vor der Phase Change  Flush. Übersetzung der Working set wird vermeidet.
Fine-Grained FIFO
Wie ein zirkulare Buffer. Blackpoints müssen gespeichert werden.
Coarse-Grained FIFO
Grosse FIFO Blöcke in Cache. Wenige oder fast keine Backpoiner benötigt. Optimal: cache in 1/8
teilen.
Performance
Coarse-Grained FIFO in 8 geteilt  beste overhead.
3.9 System Environment
Integration der Process VM im Host system Umgebung, alle Daten müssen integriert wrden.
Komplexe Umgebung, drei Möglichkeiten um das Korrekte Loader auszuführen:
1. Anpassung des Host kernel loader routine: binary identification  loader call
2. Installation in Konvertierten Guest-Kode von Host executable Kode, der angehängt wird.
3. Host mit spezielle loader „hook“ system calls versorgt: dynamische Prozessanpassung
während runtime. Z.B. CreateProcess (bootstrap method)
Dll?
3.10 Case Study: FX!32
Staged emulation.
Übersetzung und Optimierung zwischen Programmlauf.
Profile Information speichert das Target der indirekten Jumps.
5
Translation: Speicher auf Disk oder DB, wenn Kode fehlt, fängt die Interpretation Modus.
Trasparenty agent: enable some root process (login shell, service control manager, remote
procedure call server)
3.11 Summary
Instruction Emulation
1. Interpretation
2. Binary translation
3. Staged combination
Address mapping
1. Runtime-managed table
2. Direct mapping
Generelle method: instruction interpretation mit software memory mapping und Schreibschutz
Bedingungen:
1. Register state guest fit the host
2. Guest memory fit in host
3. Guest Seitengrösse ist multiple von Host
4. Guest Privilege sind subset von Host privilege
Schnellste: binary translation mit hardware Address mapping
6