[Kos-dev] Quelques idées

[Thomas Petazzoni]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig21DC7C5410C5DD2313A6B36D
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit

Hello,

> Utiliser une machine virtuelle pour detecter les acces aux variables
> non initialisees dans une machine virtuelle ? Mouf, c'est un peu de
> l'empilage violent je trouve. Vaudrait mieux inserer un plugin pour
> bochs qui se contente de rajouter une bitmap des adresses physiques,
> par defaut toutes positionnees a 0 (non ecrites), puis de
> court-circuiter les acces memoire (doit bien y avoir un mem.cc) pour
> mettre le bitmap a jour a chaque write, et verifier que le bit
> correspondant est a 1 a chaque read (c'est ce que fait valgrind, mais
> lui le fait au niveau du bit, pas de l'octet).

Ma proposition de plugin pour Bochs c'était ça en gros, parce
qu'effectivement, rajouter encore une couche de machine virtuelle c'est
un peu bourrin, et Bochs peut très bien faire le boulot.

Il y a effectivement des fonctions d'accès à la mémoire, je me souviens
plus exactement où, mais je les bidouillais à une époque pour faire des
watchpoint (je ne sais pas si c'est possible avec le débuggeur de Bochs,
et si c'est possible, j'ai du essayer, j'y suis jamais arrivé), donc ça
doit tout à fait être possible.

Je pense qu'au début on va se chopper pas mal de trucs non initialisés,
mais par la suite, ça pourra nous éviter des bugs à 2 francs.

> Tu veux parler des slab ? Car a priori pour les demandes de pages
> physiques y'a pas de pb (mappees en VM => on a la liste => on sait
> quoi desallouer a la fin de la team). Le principe est toujours le meme
> (maintenir une liste ou une hash des objets alloues/supprimes), la
> difficulte est que maintenir cette liste necessite des appels a de
> l'alloc/liberation (danger oeuf/poule). Faudrait voir, mais ca peut
> peut-etre se faire plus simplement en associant a chaque objet du slab
> un identifiant (pas un pointeur ! il faut que ca soit persistant apres
> la mort du team) vers le team proprietaire (suffirait de parcourir les
> slabs pour recuperer les objets qui correspondent a des teams morts) =>
> pas de mecanisme parallele (tout integre dans slab).

Effectivement, j'avais pas pensé au problème d'oeuf et de poule, mais à
mon avis il arrive jamais : les slabs n'attendent pas d'être
complètement à sec en mémoire pour allouer une nouvelle page, justement
pour éviter le problème d'oeuf et de poule qu'on avait. La limite à
partir de laquelle ils vont allouer la nouvelle page est configurable
par un #define si mes souvenirs sont corrects.

Une autre solution pour éviter l'oeuf et la poule et d'allouer
statiquement un gros tableau, en supposant qu'il n'y aura pas plus
d'allocations que d'entrées du tableau. Etant donné que c'est juste pour
des fins de débuggage, je pense que cette solution est envisageable.

Je crois (me souviens plus trop de tout le code) qu'on passe tout le
temps par kmem pour allouer de la mémoire, et kmalloc() fait la
redirection soit vers des slabs si size <= 2048, sinon alloue page par
page pour size > 2048.

Il faut donc placer notre enregistrement au niveau de kslab_cache_alloc
et kslab_cache_free (ce qui nous permet de chopper tous les appels
directs à ces fonctions, et les allocations de mémoire <= 2048), et un
autre enregistrement au niveau de kmalloc pour le cas ou size > 2048.

Bref, c'est jouable tout ça. Faudra noter dans le TODO ;)

Thomas
-- 
PETAZZONI Thomas - thomas.petazzoni@enix.org - UIN : 34937744
Web: http://www.enix.org/~thomas/
KOS: http://kos.enix.org/ - Lolut: http://lolut.utbm.info
Fingerprint : 0BE1 4CF3 CEA4 AC9D CC6E  1624 F653 CB30 98D3 F7A7

--------------enig21DC7C5410C5DD2313A6B36D
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+rnuN9lPLMJjT96cRAkTdAJ0U6JKg6fkMJVamIlyrfsBOgfCpTgCfdl5u
3Kw2v2XI1Iic9v/zqJA0I4U=
=nAc4
-----END PGP SIGNATURE-----

--------------enig21DC7C5410C5DD2313A6B36D--