updated 02-KVM, completed lab, added 2 precompiled guests and sprite example

course/02-KVM.md

@@ -1310,6 +1310,12 @@ static inline void sti() {
 }
 ```
 
+[//]: # ----------------------------------------------------------------
+## VMM: virtual PIC side effect
+
+- After a virtual PIC is created, `KVM_EXIT_HLT` is **not triggered anymore** when guest OS executes the `hlt` instruction!
+- Some deep digging into KVM is required to explain this behavior...
+
 [//]: # ----------------------------------------------------------------
 # Miscellaneous
 

labs/lab-virtual_game_machine/lab-virtual_game_machine.md

@@ -252,6 +252,7 @@ Le périphérique se programme en MMIO.
 
 **Définir le contenu du sprite:**
 
+1. Lire 32 bits depuis le registre de statut ; boucler tant que la valeur lue est différente de 64
 1. Ecrire la valeur 9, sur 32 bits, dans le registre de commande
 1. Spécifier le slot (identifiant) du sprite:
    1. écrire la valeur 27, sur 32 bits, dans le registre de commande
@@ -282,11 +283,16 @@ Le périphérique se programme en MMIO.
 
 ### (6) Clavier
 
-Ce périphérique est exposé physiquement et virtuellement. Côté guest OS, lorsque l'interruption matérielle 1 est reçue, cela signifie qu'une touche clavier à été pressée et la valeur de celle-ci peut être récupérée par le guest.
+Ce périphérique est exposé physiquement et virtuellement. Côté guest OS, lorsque l'interruption matérielle 1 est reçue, cela signifie qu'une touche clavier à été pressée et la valeur de celle-ci peut être lue.
 
 **Comportement du VMM**
 
-**TODO**: cette section sera ajoutée bientôt
+Le VMM doit récupérer toute touche pressée grâce à la librairie SDL/gfx (fonction `gfx_keypressed`).
+Si la touche ESC est pressée, l'exécution du VMM doit se terminer. Tout autre touche pressée provoque l'injection de l'interruption matérielle n°1 dans la VM.
+
+Si le VMM émule un clavier natif (physique), alors il injectera le code de la touche pressée sur 32 bits dans le port 0x60 lorsque le guest le lira.
+
+Si le VMM présente un clavier virtuel, alors il écrira le code de la touche pressée dans le buffer d'hypercall.
 
 **Guest: accès paravirtualisé**
 
@@ -298,6 +304,8 @@ Ce périphérique est exposé physiquement et virtuellement. Côté guest OS, lo
   ```
   \normalsize
 
+Le VMM écrit le code de la touche pressée dans `key` et le guest doit récupérer la valeur écrite par le VMM.
+
 **Guest: accès physique**
 
 Le périphérique se programme en PMIO.
@@ -308,6 +316,15 @@ Comment obtenir le code de la touche pressée\ ?
 
 1. Lire 32 bits (le code de la touche) depuis le registre de donnée
 
+**Comportement du guest**
+
+Ajoutez au guest la possibilité de déplacer un sprite avec les touches suivantes du clavier\ :
+
+- "a" déplace le sprite à gauche
+- "d" déplace le sprite à droite
+- "w" déplace le sprite en haut
+- "s" déplace le sprite en bas
+
 ## Cahier des charges
 
 ### Processus de build
@@ -355,7 +372,13 @@ Créez l'image disque dans le Makefile racine à l'aide de l'outil `qemu-img`. V
 
 ### Mesures de performances
 
-**TODO**: cette section sera ajoutée bientôt
+Vous aviez vu en cours de manière théorique pourquoi la paravirtualisation est plus efficace que l'émulation. Il est maintenant temps de réaliser un scénario pratique permettant de confirmer la théorie.
+
+- En vous basant sur les périphériques à disposition dans la machine virtuelle présentée par votre VMM, choisissez un périphérique pertinent et concevez un scénario permettant de comparez les performances obtenues entre le périphérique paravirtualisé et celui émulé.
+- Ajoutez une ou plusieurs cibles dans le Makefile racine permettant de réaliser ces mesures de performances afin que cela soit facilement testable.
+- Pensez à compiler avec l'option `-O3` pour indiquer à `gcc` d'optimiser votre code.
+- Décrivez la méthodologie utilisée pour réaliser cette comparaison et mesurer les temps obtenus.
+- Quel gain de performance obtenez-vous grâce à la paravirtualisation\ ?
 
 ## Code source à disposition
 
@@ -428,7 +451,7 @@ Le code lié au guest se trouve dans le répertoire `guest`. Voici la descriptio
 
 Le guest ne possède aucun moyen pour charger des données depuis un support physique. Comment donc charger les contenus utilisés pour les sprites\ ? Un moyen simple pour résoudre ce problème est d'intégrer les données des sprites dans le code source du guest, sous forme de tableaux de bytes.
 
-Le petit programme **`bin2array`**, dont le code source [se trouve ici](https://github.com/thxbb12/bin2array), permet de convertir tout fichier en un tableau de bytes en C. A vous donc de l'utiliser pour convertir des fichiers sprites (images au format `png`) en code source C.
+Le petit programme **`bin2array`**, dont le code source [se trouve ici](https://github.com/thxbb12/bin2array), permet de convertir tout fichier en un tableau de bytes en C. A vous donc de l'utiliser pour convertir des fichiers sprites (images au format `Raw image data` dans le programme de dessins `gimp`) en code source C.
 
 ## Consignes à propos de l'implémentation
 
@@ -580,3 +603,15 @@ L'affichage devrait ressembler à ceci\ :
 \vspace{-.3cm}
 
 Ce guest réalise exactement les mêmes fonctionnalités que `guest_sprites_pv.bin`, mais en utilisant des drivers natifs (physiques).
+
+### `guest_sprites_keyb_pv.bin`
+\vspace{-.3cm}
+
+Ce guest réalise les mêmes fonctionnalités que le guest `guest_sprites_pv` mais avec en plus la gestion du clavier à l'aide d'hypercalls, à savoir\ :
+
+- Les touches "a", "d", "w" et "s" permettent de déplacer le sprite "Tux jedi" à gauche, à droite, en haut et en bas.
+
+### `guest_sprites_keyb_phys.bin`
+\vspace{-.3cm}
+
+Ce guest réalise exactement les mêmes fonctionnalités que `guest_sprites_keyb_pv.bin`, mais en utilisant des drivers natifs (physiques).