Du befindest dich hier: FSI Informatik » Prüfungsfragen und Altklausuren » Hauptstudiumsprüfungen » Lehrstuhl 4 » Fragen   (Übersicht)

  • Prüfer: V. Sieh
  • Beisitzer: Bernhard
  • 7,5 ECTS

Fragen

Q: Gib mal einen Überblick über mögliche Virtualisierungslösungen

A:

  1. Emulator (& JIT)
  2. Hardware basiert
  3. Paravirtualisiert
  4. OS-basiert
  5. Lib-basiert

Q: Angenommen, du hast einen Server und möchtest Webspace für Kunden anbieten. Manche wollen aber Apache und manche wollen $Microsoft Webserver. Was machst du, was brauchst du?

A:

  • Kunden überzeugen, dass sie keinen Microsoft Webserver brauchen.
  • Versuchen Microsoft Webserver mit bibliotheksbasierter Virtualisierung laufen zu lassen

Q: Was muss man dafür machen?

A:

  • Microsoft Bibliotheken nachbauen und Linux Sachen (Syscalls, FS, …) verwenden
  • Loader und Linker anpassen
  • Personalities hinterlegen

Q: Was macht man bei FreeBSD, das die gleichen Syscallnummern, wie Linux verwendet?

A: Mit Ptrace „debuggen“ und abfangen. Er meinte noch irgendwie: Das Programm, das das fremde Programm startet kann das dem OS vorher sagen, dass von diesem Programm fremde Syscalls kommen.

Q: Du meintest, dass die Architektur vom Gastprogramm und dem Host die gleiche sein muss. Aber kaum ein Rechner gleicht dem anderen.

A: Es müssen nur die Instruktionen unterstützt werden, die verwendet werden.

Q: Ihr habt ja einen Atmega 32 emuliert. Was war denn da das Komplizierteste?

A: Er wollte auf irgendwas hinaus, wusste aber nicht was. Hab erzählt, dass es relativ viele Instruktionen sind zum Einbauen (P: aber das ist ja nur Fleißarbeit und nicht kompliziert), JIT war kompliziert, das man Assembler hacken musste, Debugging von geJITteten Code war kompliziert (P: Wie habt ihr das gemacht? A: int3 rein gejittet P: :) )

Q: Warum ist ein JIT besser?

A: Man holt und dekodiert Instruktionen nur einmal und kann den gejitteten Code dann öfters ausführen und dann optimieren.

Q: Warum ganze Blöcke bei JIT?

A: Damit man selten in die Hauptschleife zurück muss. Das ist schlecht, weil

  • Man vor dem Wiedereintritt Interrupts prüfen muss
  • Beim Austritt Flags, etc. evaluieren muss
  • Den Instruktion Pointer setzen muss
  • Außerdem muss man, bevor man einen Block ausführt den erst raus suchen, was ggf. langsam ist

da musste er mich paar mal treten.

Q: Was kann man bei JIT generiertem Code optimieren?

A:

  • Write after Write herausnehmen (Flags nur evaluieren, wenn man sie braucht, mehrmaliges load von state Pointer, obwohl der schon im Register steht, entfernen).
  • Zähler in Blöcke und die dann optimieren
  • Zähler in if else einbauen und ggf. umsortieren
  • Blöcke verketten

Q: Wie groß sind jetzt solche Blöcke?

A: Nicht zu groß, da man ab und zu noch auf Interrupts testen will und andere Komponenten auch mal simuliert werden wollen. Meistens so groß wie eine Page.

Q: Warum eine Page? Was macht man, wenn Code modifiziert wird?

A: Dann muss man die zugehörigen JIT Blöcke verwerfen.

Q: Wie macht man das genau? Es kann auch sein, dass ein Block größer ist als eine Page (v.A. bei CISC).

A: Ähm… …

Q: Wie läuft das mit Block raus suche ab?

A: Ah man hat da den TLB, den man verwendet, wenn auf Speicher zugegriffen wird. Und da kann man die Page austragen und im Slowcase ggf. neu jitten.

Das hätte man idealerweise vermutlich etwas tiefer und genauer erklären sollen.

Q: Warum ist die JVM so schnell?

A:

  • Keine Interrupts (da müsste man Block verlassen)
  • wenige Exceptions bzw. wenige Instruktionen, die Exceptions erzeugen können
  • sichere Pointer (keine berechneten Pointer und tableswitch und virtualcall)

…und da war doch noch mehr…

Q: Speicherverwaltung?

A: Ah, das braucht man nicht, da man nur eine Anwendung hat und man die nicht schützen muss, da man sichere Pointer hat.

Q: Wie ist das nochmal genau mit den Exceptions?

A: Man muss nur Tests einbauen, wenn eine (der wenigen) Instruktionen kommt, die Exceptions auslösen kann.

Q: Bei JVM braucht man nicht mal Tests.

A: öhm… ah bei Nullptr Exception sendet die Hardware einen Trap. Ähm und bei Division by Zero ja auch.

Q: Selbstmodifizierender Code?

A: Gibts nicht, weil Java das nicht braucht.

Q: Wann wird selbstmodifizierender Code noch gebraucht?

A: Wenn ein Debugger int3 einbaut, wenn man als Programm nicht gedebuggt werden will (Virus oder komisches Lizenzzeug), Linux, wenn es die Pipelinelänge herausfinden will.

Q: Genau, also nur in komischen Situationen. Wie funktioniert denn Hardware basierte Virtualisierung?

A:

Die Idee ist: Wenn die gleiche Architektur simuliert wird, kann man einfach die Gast VM einfach in so etwas wie dem Usermode ausführt, weil dann die Hardware verhindert, dass privilegierte Instruktionen ausgeführt werden. Aber x86 ist nicht virtualisierbar (nach Popek: nicht privilegierte aber sensitive Instruktionen). Deshalb Hardwareerweiterung (Vanderpool, Pacifica): Es gibt einen virtuellen Modus, in dem die VM läuft. Bei besonderen Ereignissen (z. B. kritische Instruktion): VMEXIT. Problem: VMEXIT/VMRESUME ist Kontextwechsel → langsam → muss vermieden werden. Hardwareerweiterungen helfen, das zu beschleunigen:

  • eingestellte Exceptions und Interrupts werden direkt in der VM erledigt
  • manche kritischen Instruktionen direkt in der VM erlaubt, haben aber andere Auswirkung (CLI schaltet Interrupt nur für VM aus)

Q: Wie macht man da die Speicherverwaltung

A:

  1. Man mappt Pagetable (PT) weder les, noch schreibbar, wenn darauf zugegriffen wird → Pagefault → RW mappen → (Singlestep →) Adresse, austauschen → nicht les- & schreibbar mappen, weiter
  2. besser: Wenn eine PT Modifikation kommt, ist es wahrscheinlich, dass mehrere folgen. Deshalb bei Modifikation PT-Ast aushängen → RW mappen → VM machen lassen. Bei Pagefault prüfen, ob es daher kommt, dass Ast ausgehängt ist und wenn VM TLB flusht → Veränderungen von VM prüfen und und anpassen → Einhängen → nicht les- und schreibbar mappen, laufen lassen

Q: Wie macht man das bei Paravirtualisierung?

A:

  1. also noch besser als die 2. Möglichkeit wäre: Die VM komplett auf einer PT Schattenkopie arbeiten lassen, die aber nicht im CR3/PT-Base-Register eingehängt ist. Bei Pagefault und TLB-Flush schauen, was in der Schattenkopie steht und Anpassung in der eigentlichen Pagetable machen.
  2. Bei Paravirtualisierung außerdem: VM weiß, dass sie auf Hypervisor läuft und wurde angepasst: Hypercalls verwenden, damit Hypervisor das Mapping machen kann.

Q: Jetzt gibt es aber u.U. sehr viele Veränderungen in der PT zu machen.

A: Deswegen hat man Multicalls eingeführt, in denen man mehrere Hypercalls auf einmal absetzen kann.

Bewertung

Ich dachte, dass ich zu viele Hints gebraucht hab und Antworten nicht immer vollständig waren. Das wurde in der Bewertung aber anscheinend ignoriert und die Note war sehr gut.