8 - Virtuelle Maschinen [ID:10982]
50 von 617 angezeigt

Die Mannschaft ist heute etwas kleiner.

Wir fangen an.

Wir haben uns eine Reihe von Instruktionen angeguckt.

Wenn man erst einmal die Instruktionen alle holt und komponiert, dann können die Exceptions in andere Reihenfolge kommen.

Eine echte CPU schaut sich ihre Interrupts vor jedem Befehl an.

Aus Performance Gründen wäre eine Idee, nur einmal am Anfang eines komponierten Blockes in die Interrupts rein zu gucken.

Man komponiert einen Block und zwischen Instruktionen fügt man immer etwas ein.

Wenn man die Flex und Instruction Pointer nachgerechnet hat, kann man die Interrupts in die Hauptschleife zurückziehen.

Das ist die eigentliche Addition.

Wenn man einen Compare und Jump If Modikel hinter den Instruktoren schreibt, wird aus einer Instruktion plötzlich drei ausgeführt.

Das ist nicht so viel, das wollen wir nicht.

Die Idee war, wie man merkt, wenn externe Interrupts um wenige verzögert werden.

Wenn man überlegt, ob aus dem Internet ein Päckchen zur Netzwerkkarte und degenerierten Interrupts kommt,

dann geht es um 1 Millisekunden, wenn ein Päckchen auf dem Internet kommt.

Das ist ein Tastendruck von der Tastatur.

Es wird man nicht merken, wenn ein Tastendruck verarbeitet wird.

Einziges Problem sind von der CPU selbst ausgelöste Interrupts.

Wie kann eine CPU selbst Interrupts generieren?

Das macht doch keinen Sinn.

Das ist ein Interrupt, das heißt, ich möchte meinen Nachbarn einen Schubs geben.

Die Befehle heißen Interrupt 80.

Er tut dann auch das, was er beim Interrupt tun würde, aber wenn man auf einen Int 80 trifft, ist das ein Sprungbefehl.

Das sehe ich dem Ding ja an.

Insofern kann ich sagen, ich beende es im Moment, wenn ich den Int 80 zu viel kompiliere.

Dann sage ich, ok, da ist der Block zu Ende.

Das wäre eine Lösung dafür, weil da sehe ich, dass der Intensivsystem dringt.

Also nach dem Sprung machen wir Ende.

Das müssen wir aus anderen Gründen auch noch tun, weil ein Int 80 ein Exit System Call sein kann.

Alles, was danach steht, ist gar kein Code mehr. Da kommt er nie wieder hin.

Aber auf der anderen Seite ist es eigentlich kein Interrupt, der selbst eine Exception produziert.

Das wäre jetzt kein selbst ausgelöster Interrupt, sondern selbst ausgelöste Exceptions.

Exceptions müssen wir ja eh behandeln können, im Sinne von Division durch Null.

Da hat es auch vorher noch gesagt, die Interprozessinterrupt, die IPs in der Intel Welt. In dem Sinne jetzt allerdings mehr von Interprozess.

Aber da gibt es auch Interprozess vor Interrupt. Da kann man sagen, gibt mal eine Gruppe von Prozessoren einen Schubs.

Und in dieser Gruppe kann man auch selber drin sein.

Das Dumme ist, man sieht es jetzt nicht durch so einen speziellen Befehl wie bei Int 80 oder so, sondern das ist eine ganz normale Move Instruktion.

Ich schreibe es nämlich per Move in meinen Epic rein. Wobei das auch nicht nur eine Move sein muss, das kann auch ein Setze Bit oder so.

Verordere das konstante Bit sowieso mit dem Epic Person.

Also das jetzt dem Code anzusehen, dass das jetzt einen Interrupt auslöst, schwierig.

Ja und die andere Geschichte, es gibt noch System Management Interrupts.

Okay, das sind eigentlich Externe. Typischerweise, wenn jemand hier so den Power Off-Button drückt, das ist eigentlich ein System Management Interrupt.

Worauf die dann den Rechner runterführt.

Da kann man sich allerdings auch SNIs selber schicken. Braucht man um, das führt ein bisschen zu weit, dass der System Management Interrupt sich selber konfiguriert.

Standardmäßig ist er erstmal auf eine ganz merkwürdige Adresse konfiguriert. Hex 30.000. Warum 30.000? Frag mich nicht.

Alle wählen das der Meinung, da wollen wir keinen Interrupt an der Stelle. Und was man da machen kann, ja man kann da mal schnell was hinlegen.

Ein kleiner Händler kann den SNI auslösen, dann wird der Händler ausgeführt und der Händler kann sagen, ja ab sofort nicht mehr bei Hex 30.000, sondern woanders.

Dann wenn die Rats zurückkehrt, dann kriegt er beim nächsten Interrupt, sprich dann woanders hin. Da muss man einmal am Anfang ein System Management selber auslösen.

Ja, das ist an sich, also jedenfalls NV-Maschinen, QEMU, alle die ich kenne, ist das nicht wirklich gelöst, das Problem.

Was man natürlich, das ist nicht so schlimm, weil System Management Interrupt, also diese Initialisierung von diesem Händler passiert im BIOS.

Im BIOS, da kann man ja selber reinschreiben was lustig ist. Zum Beispiel kann man an, nach dem Aufruf des System Management Interrupt natürlich eine Sprung Instruktion einbauen.

Teil einer Videoserie :

Zugänglich über

Offener Zugang

Dauer

01:29:01 Min

Aufnahmedatum

2015-11-11

Hochgeladen am

2019-05-06 08:49: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

  • entwickeln selbst CPU-Emulationen

  • entwickeln selbst Geräte-Emulationen

  • verteilen Implementierungsaufgaben in ihrer Gruppe

Einbetten
Wordpress FAU Plugin
iFrame
Teilen