Wenn ich hier die virtuelle Adresse eintrage und zusätzlich noch ein Bitset in den hinteren
10 Bits, also hier die vorderen 20, dann fehlen noch 12, 2 da von hinten müssen 0 sein und
für den Alignment Test dazwischen habe ich noch 10 Nullen. Egal welches Bit von diesen
10 Bits ich hier auf 1 setze, dann wird der Test pehlschlagen. Soll heißen, die Idee ist,
immer wenn von dieser virtuellen Adresse Code gelesen worden ist, dann trage ich an der Stelle
eine 1 ein. In irgendeines dieser 10 Bits, egal in welches. Und wenn ich dann schreiben
will, wird dieser Vergleich schief laufen. Ja gut, dann denken wir mal länger drüber nach.
Soll heißen, wir machen mit einem YF drei Tests. Und das sind alle drei, bzw. wir können
sogar noch einen vierten Test mit einbauen. Nämlich, je nachdem wie gesagt, wir haben
hier 10 Bits und wir können ein Bit setzen um anzuzeigen, das ist komponiert der Code
von der Page. Wir haben ein Bit, da können wir sagen, das ist Read-Only-Memory, also
für ROM beispielsweise. Dann schreibt er nicht aus Versehen ins ROM. Wir haben ein
Bit, damit können wir noch anzeigen, das ist jetzt kein normaler Speicher, das ist beispielsweise
IO-Grafikkarte. Also je nachdem, welche Bits man hier setzt, wir machen letztendlich mindestens
mal drei Tests, wir können sogar vier, fünf, sechs verschiedene Tests mit einem YF ausmachen.
Und das ist, behaupte ich mal, die Idee schlechthin von den QEMO-Leuten. Hätten sie die nicht
gehabt, würde QEMO nicht funktionieren. Dann wäre die Performance so grottenschlecht,
man kann es vergessen. Mit der Idee, jetzt ist natürlich die Frage, wie oft schlägt
das hier fehl? Also Fast Case heißt ja, ich schreibe direkt auf diese Page, ohne groß
darüber nachzudenken. Das ist natürlich der Fall, den wollen wir eigentlich haben. Wie
oft geht das denn in die Hose?
Genau, also Alignment, wenn man GCC verwendet, ist Alignment da. Also alles, was in der GNU-Welt,
Linux-Welt an Code da ist, ist Aligned. Bis auf die Teile, die irgendjemand in der Semla
gehackt hat. Aber wer schreibt heutzutage noch Semla? Kein Mensch, nicht freiwillig.
Also Alignment, die hinteren drei Bits, das passt eigentlich immer. Die vorderen, gut,
da hast du recht, TLB, wir müssen mal Glück haben, dass es passt. Da können wir allerdings
auch nicht viel dran drehen. Und die mittleren zehn Bits, ja, dass ich auf eine Code-Seite
schreibe, das kommt auch in der Linux-GCC-Welt eigentlich nicht vor. Wir haben keinen selbst
modifizierenden Code. Einzig, wenn man jetzt Code umlädt, also sprich das Betriebssystem,
ein neues Programm nachlädt, dann wird ein altes überschrieben. Macht in dem Falle aber
auch nichts, weil wenn das alte überschrieben ist, das alte weg sein soll, wird überschrieben.
Naja, dann wird einmal der Code aus dem alten Programm sozusagen aus meinem Cache rausgehauen.
Das will ich ja eigentlich auch, den brauch ich ja nicht mehr, ist also auch nicht so
schlimm. Ja, und das mit der Grafikkarte, gut, da kommt man nicht drum rum, da müssen wir
die Simulation eh anders machen. Einen berühmten Fall gibt es, wo das in die Hose geht. Muss
man wissen, wir haben das so implementiert. Linux flutscht, PSD flutscht, MS-DOS flutscht,
Windows geht nicht. Warum geht es nicht? Die Windows-Leute in ihrer Weisheit haben einen
Timerinterrupt geschrieben, Timer-EHQ, der macht alle möglichen Sachen, macht unter
anderem ein Increment-Counter, macht noch ein bisschen was anderes und ein Irette und hier
steht Counter, was weiß ich, Data 0. Sie haben vergessen. Genau, das Dumme ist natürlich,
dieser Timerinterrupt, der kommt jetzt mit 1000 Hz, er fängt an zu laufen, ok, beim ersten
Mal ist das Code nicht kompiliert, also kompilieren wir ihn mal. Er trifft auf diese Encounter-Instruktion,
er soll schreiben, das Dumme ist, gleiche Page, also haut er den Code weg, also fliegt alles
raus. Er muss wieder neu kompilieren und 1000 Mal pro Sekunde muss diese Page neu kompiliert
werden und dann sind wir leider nicht mehr bei diesem 10%-Kompilzeit, sondern dann sind
wir plötzlich bei 90%-Kompilzeit oder so. Das läuft nicht mehr. Windows läuft mit der
Methode nicht. Das ist sowas von langsam, er schafft einfach, naja, in dieser 1000-Zul-Sekunde,
er schafft gerade die Page zu kompilieren, sie auszuführen und wieder wegzuschmeißen.
Wenn er damit fertig ist, dann ist der nächste Interrupt schon fast wieder da.
Das wäre nicht so aufwendig, da so einen Punkt Data reinzuschreiben, keine Frage.
Presenters
Zugänglich über
Offener Zugang
Dauer
01:26:04 Min
Aufnahmedatum
2012-11-16
Hochgeladen am
2019-05-05 07:09:03
Sprache
de-DE
Vorgestellt werden verschiedene Virtualisierungs-Ansätze:
-
Emulation
-
Just-In-Time-Compiler
-
Para-Virtualisierung
-
Bibliotheks-basierte Virtualisierung
-
OS-Virtualisierung
Lernziele und Kompetenzen:
Studierende, die das Modul erfolgreich abgeschlossen haben:
-
erläutern verschiedene Motivationen für den Einsatz von VMs
-
unterscheiden verschiedene VMs
-
klassifizieren verschiedene Ziele unterschiedlicher VMs (z.B. Performance, Konfigurierbarkeit, Genauigkeit, ...)
-
hinterfragen verschiedene Simulationansätze für MMUs
-
erstellen virtuelle Komponenten und Busse
-
strukturieren Callbacks und entsprechendes Forwarding und Caching
-
unterscheiden zwischen Architektur, Chip und Komponente
-
klassifizieren unterschiedliche Just-In-Time-Compiler-Ansätze
-
erzeugen JIT Code aus vorgefertigten Code-Teilen
-
bewerten unterschiedliche JIT-Code-Optimierungen
-
erläutern Probleme bei der JIT-Code-Invalidierung
-
nennen JIT Probleme mit Exceptions/Interrupts sowie berechnete Sprüngen und Return-Instruktionen
-
unterscheiden verschiedene JIT Cache-Verwaltungen
-
beschreiben Möglichkeiten der Fehlerinjektion durch VMs
-
entwickeln ein an JIT angepasstes virtuelles "Hardware"-Design
-
erläutern die Java-VM Instruktionssatz-Architektur
-
nutzen Hardware-basierte Virtualisierung
-
entwickeln Verfahren zum Ausfiltern bestimmter Befehle
-
erläutern Probleme der Speicherverwaltung bei HW-basierter Virtualisierung
-
nutzen User-Mode-Emulation zur Paravirtualisierung
-
diskutieren Möglichkeiten von Debuggern für die Umleitung von System-Calls und die Ausfilterung von Befehlen
-
nutzen einen Hypervisor zur Paravirtualisierung
-
unterscheiden verschiedene Ansätze zur Geräteverwaltung in paravirtualisierten Systemen
-
erläutern Betriebssystem-basierte Virtualisierung
-
entwickeln unterschiedliche Bibliotheks-basierte Virtualisierungen
-
erläutern Probleme beim Speicher-Layout bei Bibliotheks-basierte Virtualisierung
-
konzipieren Personalities für Bibliotheks-basierte Virtualisierungen
-
beurteilen Probleme bei der korrekten Zeit-Simulation
-
nennen Ideen für die dynamische Anpassung der Zeit-Simulation
-
klassifizieren bekannte VMs (z.B. VICE, FAUmachine, QEMU, Bochs, JVM, KVM, User-Mode-Linux, Xen, VServer, Wine)
-
diskutieren in der Gruppe Vor- und Nachteile von bestimmten VM-Ansätzen
-
untersuchen CPU-Emulationen
-
untersuchen Geräte-Emulationen