9 - Virtuelle Maschinen [ID:10958]
50 von 984 angezeigt

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

Teil einer Videoserie :

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

Einbetten
Wordpress FAU Plugin
iFrame
Teilen