Ja, dann begrüße ich euch drei. Was möchte ich mit euch heute machen? Zum einen das Fertigbringen,
was wir letzten Freitag angefangen hatten. Ihr erinnert euch, wie konnte man abprüfen, ob in der
MMU eine Adresse eingetragen ist, die erstens aligned ist, zweitens beim Schreiben nicht
codeinvalidiert und auch noch die Page eingetragen ist, die wir eigentlich suchen. Das waren drei
Abfragen, da sind drei Tests, die wir eigentlich mit einem IF machen können. Einfach die hinteren
zwei Bit müssen passen fürs Alignment, die vorderen müssen passen, dass sie richtig gepätscht ist und
die in der Mitte müssen passen, dass es nicht protected ist. Jetzt haben wir natürlich das
Problem, das ist jetzt diese Store Funktion. Wenn wir jetzt grundsätzlich diese Variante nehmen,
um unsere Adressen umzurechnen, dann haben wir jetzt unnötig häufig diese Slow Cases,
ganz einfach, weil wir natürlich jetzt auch was, was ich code lese, dann steht hier vielleicht
drin, der ist protected, soll heißen, da darfst du nicht direkt drauf zugreifen. Wenn wir lesen und
da sind so ein paar Protection Pits gesetzt, dann darfst du auch nicht lesen, nicht schnell. Das ist
natürlich jetzt nicht der witzige Sache, das soll ja flott gehen. Dementsprechend kann man dann sagen,
wir trennen das Ganze einfach dreimal. Eine echte MMU, die hat eigentlich einen TLB, aber wir machen
das jetzt nicht mit einem TLB, sondern wir bauen jetzt einfach drei ein. Wir haben das Datenwrite
Ding, das habt ihr gerade gesehen, das ist das mit dieser konstruierten Abfrage, drei Abfragen in
einem IF. Bei dem Daten TLB im Prinzip genau das gleiche, nur dass diese Protection Pits nicht
drin stehen müssen. Ja, an sich wird es erst mal reichen, es in zwei aufzudröseln, allerdings
werden wir jetzt noch merken, normalerweise ist das, was natürlich im Daten TLB überhaupt drin steht,
was völlig anderes als das, was in dem Code TLB oder Cache drin steht. Das eine hat mit dem anderen
nichts zu tun, insofern kann man den jetzt noch gut noch als zusätzlichen TLB einbauen. Ja,
dann haben wir drei Stück. Muss ja mal denken, wir haben nur einen sozusagen Direct mapped Cache,
wir haben ja kein Mehrfach Assoziativ. Dann können sich immer Code TLB und Daten TLB eventuell
gegenseitig rausschmeißen, wenn wir den noch extra haben, dann haben wir sozusagen einmal
Assoziativ mehr. Ja und damit flutscht es jetzt relativ gut. Wir können relativ gut abprüfen,
modifizieren wir gerade Code, ja oder nein und soll heißen, ja wir haben einen Fast Case,
die Frage ist, er ist zwar schnell, aber kommt er jetzt auch häufig dran oder ist jetzt der Slow
Case der Fall, den wir eigentlich meistens durchlaufen. Ja und da muss man dann sagen,
wenn man sich heute Compiler anguckt, ein normaler Compiler generiert Code, mischt den aber in
keinster Weise mit Daten. Einzige Ausnahme Read-only-Daten, also irgendwelche Streams
oder so, die sind beim GCC mit in den Code Pages mit drin, was im Prinzip hier aber auch
nichts ausmacht, die ändern sich ja auch nicht. Normalerweise der GCC, wenn man selber ist nicht
gerade vergurkt, dann macht der GCC auch richtiges Alignment. Wenn man natürlich selber einen Pointer
zurecht bastelt mit plus plus eins oder irgend sowas, dann vielleicht nicht, aber normalerweise schon.
Ja und dann haben wir auch diesen Fast Case als Normalfall, also wenn man uns Fahrmaschinen laufen
lässt und mal guckt, wie häufig dann invalidiert werden muss, fast gar nicht. Einzige Ausnahme
natürlich beim Kontextwechsel oder so, aber dann ist klar, dann ist halt alles anders.
Ja, Linux und BSD, die sind beide, also sowohl alle Linux-Varianten, Suze, Red Hat, Debian,
wie sie alle heißen, als auch die BSD-Varianten FreeBSD, NetBSD, OpenBSD sind alle mit dem GCC
gemacht und dementsprechend haben sie auch keine Ausnahmen. Windows, habe ich euch letzte Woche
erzählt, eine Macke und normalerweise auch nicht, keine Ahnung, eine Macke im, ich sage mal, Word-Programm,
das wäre ja halb so wild, sondern eine Macke im Kern und die auch noch an der Stelle, die ständig
durchlaufen wird. Okay, ein bisschen anders sieht das aus, so in der ganzen DOS-Welt, also sowohl der
DOS-Kern, also das was man da lädt, dieses Command-Comm, oder so, als auch die ganzen
normalen DOS-Programme, das wimmelt nur von Ausnahmen. Die haben halt alle getrickst versucht,
irgendwie Bits und Bites zu sparen, soll heißen, die haben hier nicht aligned, nicht noch ein paar
extra Bites spendiert, damit das aligned ist, sondern die haben alles so eng zusammengepackt,
wie irgendwie geht, da waren wir mit Alignment gar nichts. Dementsprechend Ausnahmen ohne Ende.
Machen uns die Ausnahmen was? Also die ja, habe ich schon erzählt, da geht überhaupt nichts voran,
könnte echt knicken, da geht gar nichts. Schafft dann mal gerade seinen Interupt-Händler, wenn er damit
Presenters
Zugänglich über
Offener Zugang
Dauer
01:37:14 Min
Aufnahmedatum
2012-11-22
Hochgeladen am
2019-05-05 13:59: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