[Kos-dev] VMM : zero, kmem, kstack, lien avec FS

[Thomas Petazzoni]

salut,

je continue a reflechir sur la VMM, et notamment sur les drivers zero,
kstack et kmem.

	- zero
Ce driver sert pour le mapping des zones allouees sur le tas par les
threads utilisateurs (via un equivalent a l'appel systeme sbrk). La
fonction raw_read se contentera d'envoyer des zeros, tnadis que la
fonction raw_write ne fera rien. La politique en cas de page fault est :
"Je verifie que je suis bien dans le tas de la zone utilisateur du
processus courant. Si oui => allocation d'une page, sinon envoi d'un
signal type SIGSEGV au thread (team ?) concerne. Reste a definir si
c'est la team ou le thread qui doit recevoir le signal.

	- kmem
Kmem sert a gerer la zone noyau, actuellement comprise entre 512M et
768M. Deux possibilites s'offrent a nous :
	- lors d'une allocation via kvalloc (donc via kmalloc ou
kslab_cache_alloc), des pages physiques sont automatiquement allouees et
mappees la ou il faut. Le handler de page fault de ce driver devra donc
toujours arreter le systeme (ou alors peut etre arret du thread noyau
incrimine, a determiner precisement).
	- lors d'une allocation via kvalloc, les pages physiques ne sont PAS
automatiquement allouees et mappees. Le Handler de page fault se charge
de verifier grace aux listes de ranges de kvalloc si la page merite
d'etre mappee. Si oui c'est fait, sinon arret du systeme (ou la aussi
arret du thread noyau incrimine).
La deuxieme possibilite correspond plus a la logique UNIX (enfin je
crois) en terme d'allocation memoire : on retarde le plus possible. Mais
peut etre que pour les donnees du noyau, ceci n'est pas vraiment
valable. Qu'en pensez-vous ?
Sinon le raw_read se chargera simplement de remplir la page allouee de
zeros. Le raw_write ne fera rien non plus ici.

	- kstack
Kstack sert a gerer les piles des differents threads (qu'ils soient
noyau ou utilisateur) au niveau noyau (piles utilisees tout le temps par
les threads noyaux, et durant les appels systemes ou IRQ poru les
threads utilisateurs). Tout page fault dans la region virtuelle des
piles doit etre severement suivi d'un arret total du systeme : ceci ne
doit pas arriver.
Les fonctions raw_read et raw_write n'auront pas besoin d'etre
implementees, elles n'ont aucune raison d'etre appelles : les pages pour
les piles seront allouees et mappees directement lors de la creation du
thread. Bref c'est un driver tres simple mais important.
Le double fault sera gere par un mecanisme exterieur, et se contentera
d'afficher des messages de debug pour comprendre pourquoi tel ou tel
thread a utilise trop de piles. Comme nos experimentations l'ont montre,
il n'est pas possible d'agrandir dynamiquement la pile.

Ces trois drivers seront implementes dans le module vmm, et ne seront
pas implementes avec Babel : ce sont des drivers VMM uniquement, c'est
derriere Babel.

Lien avec les systemes de fichiers
----------------------------------

J'aimerais exposer ma vision des choses concernant le lien entre VMM et
systeme de fichiers, pour voir si ma vision correspond a la votre (ie si
j'ai bien compris).
Tout driver de systeme de fichiers doit correspondre a une interface,
contenant au moins raw_read et raw_write, respectivement fonctions de
lecture et d'ecriture qui ne doivent pas utiliser la VMM. Lorsque la VMM
a besoin du contenu d'un fichier mappe en memoire lors d'un page fault,
alors elle utilise le translator contenu dans la shadow resource, pour
trouver l'interface du driver et appeler comme il le faut raw_read ou
raw_write.

raw_read sert a lire des donnees d'un fichier pour les placer dans la
memoire lors d'un page fault.
raw_write sert a ecrire des donnes dans le fichier par exemple quand on
desire swapper et que la region virtuelle est en r/o (pas besoin
d'utiliser de la place dans le swap).

Voila. J'espere que je recevrais vos reactions,

amicalement,

thomas
-- 
PETAZZONI Thomas
thomas.petazzoni@meridon.com     UIN : 34937744
Projet KOS : http://kos.enix.org
Page Perso : http://www.enix.org/~thomas/