====== Virtuelle Maschinen (7.5 ECTS) ======
Prüfer: Volkmar Sieh, Beisitzer: Bernhard Heinloth

Wie immer sehr entspannte Atmosphaere. Ein oder zwei Fragen fallen mir leider nicht mehr ein...

{{indexmenu>:pruefungen:hauptstudium:ls4:vm-2022-02-17#1|navbar}}

==== Allgemeines ====
**Was haben wir denn so in der Vorlesung gemacht? Welche Virtualisierungsmethoden haben wir besprochen**

Emulator, JIT, hardwarebasiert, betriebssystembasiert, bibliotheksbasiert jeweils kurz erklaert

==== Bibliothekesbasierte Virtualisierung ====
**Bleiben wir doch mal bei bibliotheksbasierter Virtualisierung. Was muss man dafuer tun?**

  * Instruction set muss passen, Speichermapping muss moeglich sein, libraries umbauen
  * Evtl reicht es nur die unterste Bibliothek umzubauen wenn die darueberliegenden keine syscalls machen, sondern nur die unterste Bibliothek nutzen

**Wann nutzen denn Programme keine Bibliotheksfunktionen?**

  * statisch gebundene Programme
  * Warum? Integritaet von Bibliotheken, Updater (der wuerde sich seine eigene lib wegupdaten)

**Was macht mann dann?**

Personalities (+ Erklaerung was ist das)

**Was sind die Vorteile und Nachteile bibliotheksbasierter Virtualisierung?**
  
Vorteile:
  * Programm laeuft als normales Window im Host, man kann nebenbei weitere Sachen machen, copy-paste funktioniert, ...
Nachteile:
  * Bibliotheken muesen umgebaut werden. Ohne sourcen/mit schlechter Doku macht das wenig Spass
  * Update der lib erfordert ein update von der umgebauten lib
  * Fehler muessen mit umgebaut werden (komische Programme nutzen bugs als feature)

**Wie schaut das mit der Performance aus?**
  * geringer Overhead (man muss kein ganzes BS simulieren obwohl man nur eine Anwendung braucht)
  * ABER: Wenn Programme/hoehere Bibliotheken Sachen nutzen die unter dem Guest-OS performant sind, sind sie nicht unbeding performant unter dem Host (z.B. Signale, fork() unter Windows schlecht)

**Du hast vorhin etwas davon gesagt, dass das Instruction Set passen muss. Sparc Programme unter Intel funktioniert natuerlich nicht. Aber funktioniert z.B. jedes Intel Programm unter Intel?**

  * gemeinsames Instruction-Set muss vorhanden sein
  * Wenn Programme Extensions nutzen (z.B. SSE, AVX, ...) und die unter dem Host nicht vorhanden sind (und das Programm kein Fallback ohne Extensions hat) kann man das Programm nicht ausfuehren

==== Emulation ====
**Du hattest Eingangs erwaehnt, dass die Emulation langsam ist. Warum?**

  * Operationen mehrfach dekodieren, Operanden mehrfach rausfriemeln, ...
  * Flags berechnung ist in Software teuer - Flags werden aber selten gebraucht
  * Speicherzugriff ueber Bus langsam

**Warum ist der Speicherzugriff ueber den Bus langsam. Erklaere mal wie das funktioniert.**

Hier gab es noch den Hinweis, dass es in einem System ja mehrere Busse gibt

  * Beispiel out genommen
  * Value mit Port-Nr. an Bus geben
  * Bus ruft alle Komponenten, die sich im init() mit Callback und State registriert haben auf. Jede Komponente prueft ob sie angesprochen wurde
  * Evtl gehen Aufrufe auch an andere Busse. Es werden also viele Komponenten aufgerufen, obwohl nur eine angesprochen ist.
  * Komponenten/Ports aendern sich eigentlich nicht. Die Zuordnung Port <-> Callback koennte man also Cachen

**Was macht man wenn sich jetzt doch ein Port aendert**

Das Geraet muss der CPU mitteilen, dass sich Callbacks geaendert haben

**Und woher weiss das Geraet wer die CPU ist?**

Das weiss das Geraet wahrscheinlich gar nicht. Also im Zweifellsfall Broadcast-Nachricht an alle, dass sich etwas geaendert hat.

**Selbst wenn man Adressen cachet. Warum ist der Speicherzugriff langsam trotzdem langsam? Was wird da alles ueberprueft?**
  * Debug Einheit (Basis/Limit pruefen)
  * Alignment-Check
  * Debug/Watchpoint pruefen
  * MMU: TLB nachschauen, virtuelle Adresse in physikalische Adresse umrechnen, Zugriffskontrolle, Rechte (rwx), Access-/Dirtybits setzen
  * Caches (falls sie mitsimuliert werden sollen): Datum vorhanden? Falls nein: Verdraenungsstrategie, Write-Back/Write-through
  * Irgendwas habe ich bestimmt vergessen

**Ja passt. War auch schon eine ganze Menge**
**Wie kann man diese Abfragen noch mit in seinen Cache einbauen?**

Mehrdimensionalen Cache erklaeren. Siehe Foliensatz "Speicherhierarchie" Folie 20ff.

**Beim Alignment-Check. Motiviere doch mal warum zwischen den oberen Einsen (Seitenadresse) und den unteren beiden Einsen (Alignment) noch Platz sein muss?**
  * Cached man Seiten: unteren 12 Bits = 0 (hier ist auf jeden Fall noch Platz)
  * Cached man weniger (z.B. nur Cachelines) schaut das anders aus
  * ABER: Integer ist schon 4 Bytes gross. Man wird nicht weniger als einen int cachen => also ist noch Platz vorhanden

==== JIT ====

**Du hattest auch schon dem Just-in-Time Compiler erwaehnt. Warum wird das schneller?**

  * Dekodieren nur einmal beim Compile
  * CC-Flags wegoptimieren
  * PC nur einmal am Ende eines Basic-Blocks erhoehen
  * Halbkonstanten wegoptimieren
  * ...

**Wie kann uns der JIT bei den Speicherchecks von vorhin helfen?**
  * JIT kann Segmentbasisadresse, da sie sich i.d.R. nicht aendert gleich mit reinkompilieren
  * Alignmentcheck, Debugcheck, ... koennen wegkompiliert werden wenn sie nicht gebraucht werden

**Was macht man wenn sich eine der Bedinungen aendert. Z.B. wenn die Segmentbasisadresse umgesetzt wird?**
Kompilierten Code invalidieren und beim naechsten Zugriff drauf neu Kompilieren.

**Bei pthreads ist die Segmentbasisadresse meistens null. Wenn sie aber auf threadlocal storage haben aendert sie sich.**

  * Neu kompilieren ist dann potentiell bloed. Weil man sehr oft Code invalidert
  * Code doppelt kompilieren. Einmal mit Basisadresse null und einmal mit anderem Wert. Je nach Segmentbasisadresse wird der eine oder der andere Code angesprungen