8 - Virtuelle Maschinen [ID:10957]
50 von 922 angezeigt

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.

Teil einer Videoserie :

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

Einbetten
Wordpress FAU Plugin
iFrame
Teilen