[Kos-dev] kvalloc, synchronisation des PDE, port-e8-hack

[Thomas Petazzoni]

salut a tous,

1. De l'implementation du kvalloc

j'ai commence a implementer le kvalloc, qui a priori fonctionne, mais
pas de kvfree pour le moment. par contre il y a un mechant probleme avec
kmalloc : le bitmap primaire est stocke dans le gpfme_t de la page
physique associee ! jusqu'a maintenant on allouait les pages avec
get_physical_page() donc il n'y avait pas de probleme, on pouvait
directement acceder au bitmap primaire dans le gpfme_t de la page.
maintenant c'est beaucoup plus complique avec le kvalloc, car celui-ci
retourne une adresse virtuelle !

plusieurs choix s'offrent a nous :
	1. laisser le kmalloc allouer directement dans les pages physiques, ce
qui est pas top vu l'objectif initial du kvalloc : permettre de tout
bouger dans la memoire physique (meme si c'est assez couteux en copie,
deplacement, etc...) au cas ou l'allocation de buffer physiques contigus
soit necessaire. cette allocation n'est pas critique au niveau temps
processeur, car elle n'aura pas lieu trop souvent, mais elle est
importante si on veut pouvoir faire du DMA pepère.

	2. realiser un allocateur kvalloc totalement different : chaque page
virtuelle de la zone 512M-768M a, a l'image des gpfme_t une structure
associee. a mon avis, solution pas top, ca risque de prendre mechament
de la place inutilement.

	3. kmalloc alloue des pages virtuelles, via kvalloc (qui lui mappe tout
de suite en physique), puis stocke quand meme le bitmap primaire dans la
page physique associee. c'est tout a fait possible comme solution, la
seule condition c'est que lorsqu'on deplace des pages physiques, on
oublie pas de deplacer le bitmap primaire. de toute facon, si on decide
de demapper une page pour la remapper sur une autre, il faut forcement
mettre a jour correctement les pointeurs et tout ca. c'est a mon avis la
solution la plus acceptable.

(commentaire de l'auteur du mail : c'est etonnant j'avais pas trouve
autant de solutions quand j'etais devant le probleme. le simple fait de
rediger le mail pour vous exposer le plus clairement possible le
probleme doit faire le menage dans ma tete, et fait apparaitre de
nouvelles solutions. surprenant)

personnellement, la solution 3 me parait envisageable.

concernant le kvalloc, j'ai defini un range pour le GPFM, un range pour
chaque module (ainsi pour liberer l'espace pris par un module un simple
kvfree(module->start) suffit !), et un range pour les sections .init. il
y a aussi des ranges pour les pages qui ne contiennent que des ranges !

finalement, je viens de penser encore a une autre solution. il me semble
peu coherent de stocker le bitmap primaire dans le gpfme_t, ce n'est pas
vraiment lie a la page physique, mais plutot a la page virtuelle nan ?
on pourrait envisager que kmalloc, au lieu de faire des listes de
gpfme_t, fasse des listes de kmem_page_t, definie comme suit :

typedef struct kmem_page kmem_page_t;

struct kmem_page {
	addr_t virt_page_addr;
	k_ui32_t primary_bitmap;
	kmem_page_t *next, *prev;
};

le seul hic, c'est que kmalloc ne doit pas dependre de kmalloc, donc
l'allocation de telles structures devra se faire sans kmalloc, via une
astuce equivalente a celle utilisee pour le kvmem (kvalloc/kvfree). 
ceci etant dit cela est toujours faisable. ca permet de supprimer le
bitmap primaire et les champ next et prev utilise pour le kmalloc des
gpfme_t.

par contre, il faut bien reflechir comment va se passer le deplacement
de pages physiques, cad prevoir un moyen pour remonter d'une page
physique a tous ses mapping lineaires. ca doit pas etre trop la mort
avec une liste chainee...
le fait de pas avoir les champ next, prev et bitmap primaire dans les
gpfme_t permet de simplifier la deplacement de pages physiques.

peut etre est-ce la meilleure solution... conceptuellement c'est la plus
belle, mais je pense pas que ce soit la plus efficace, qu'en pensez-vous
?

2. De la synchronisation des PDE

j'ai bien lu ton mail hlide, mais dans tous les cas, le probleme de la
synchronisation des PDE se pose, donc a mon avis c'est un faux probleme.
de toute facon, nous n'aurons pas besoin de changer de CR3, car nous
envisageons la solution dont nous avions discute l'annee derniere au
MacDo a Paris (si tu te souviens) : le dernier PDE du noyau pointe vers
une page qui contient les adresses des PDE des 1024 premiers contexte
memoire. on peut ainsi acceder aux PDs de toutes les teams, et la mettre
a jour assez facilement. la synchronisation des PDE demande donc du
temps processeur, mais pas de changement de CR3, donc c'est -moins- pire
que prevu, et dans tous les cas on pourra difficelement faire mieux.

3. du port-e8-hack

le patch que j'ai mis hier sur kos-contrib implemente un nouveau truc
assez sympa dans Bochs, qui devra etre recompile apres application du
patch avec l'option --enable-port-e8-hack.

un systeme de commandes sur le port e7 permet d'ouvrir des fichiers, et
tout caractere ecrit sur le port e8 sera envoye dans le fichier courant
(on peut avoir jusqu'a 8 fichiers ouverts en meme temps). ca permet
d'envoyer des messages de debug non seulement sur la console, mais aussi
dans un fichier. j'ai fait ca surtout pour les adresses des symboles
affiches lors du loader.

on dispose donc des primitives suivantes (et dans le loader et dans le
module debug)
	__bochs_file_open(char *name) qui ouvre un fichier et retourne un
identifiant dessus
	__bochs_file_putchar(int file, int c) qui met le caractere c dans le
fichier file
	__bochs_file_printl/k(int file, char *fmt, ...) sans commentaires
	__bochs_file_close(int file) qui permet de fermer un fichier

un exemple d'utilisation se situe dans loader/elf32/elf32_dump.c

boah voila, j'ai pense que ca pouvait etre utile, par contre j'ai pas
verifie si les ports E7 et E8 n'etaient pas utilise... peut etre que sur
une machine reelle ca  peut potentiellement merder. Manu Marty a utilise
un port utilise du machin ISA (voir les sources de bochs), mais moi j'ai
pas du tout fait attention a ca. de toute facon, c'etait plutot pour
m'amuser. mais j'ai pense que ca pouvait toujours servir pour dumper de
grosse quantites de donnees, sans qu'elles se melangent sur la console.
bref, c'est anecdotique, mais ca peut servir.

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