[Kos-dev] double fault fonctionnel !

[Christophe Avoinne (Club-Internet)]

Ah je me disais quand même ! :))))))))))

Bon c'est une bonne chose de validée. Reste qu'il y a un cas à tester avant
de se lancer dans les piles dynamiques et autre : que se passe-t-il si c'est
un IRQ qui provoque le #DF ? là il s'agit d'une interruption externe,
autrement dit, ce n'est pas le code interrompu qui est fautif du #DF. Or
l'EIP dans le TSS system doivent être celui du code interrompu et non celui
du handler. Je présens que cet IRQ va être perdu et jamais exécuté, ce qui
est un gros problème à mon avis si on ne peut pas le détecter.

Que faire ?

soit une boucle principale dans un thread :

...
0: mov    $DEADBEEF,%esp // attention boucle infini, il ne faut pas que le
handler #DF alloue dynamiquement la pile !!!
    hlt
    jmp 0b
...

modifier temporairement le handler du #DF pour les besoins du test :

...
  if (tss_system->esp == 0xDEADBEEF)
    {
       < afficher une barre tournante bleue pour indiquer le #DF >
       tss_system->esp = < base de la pile du double fault > - 512; // on
doit donner toujours la même pile car on boucle en infini
       tss_system->eip++; // saute l'instruction "hlt"
       return cpu_context;
    }
...

le timer 0 devrait afficher une autre barre tournante d'une autre couleur à
chacune de ses exécutions.

Comme vous pouvez noter, on crée intentionnellement une pile invalide avec
la signature 0xDEADBEEF juste avant l'exécution de l'instruction "hlt" qui
devrait attendre jusqu'à ce qu'un signal d'interruption ait lieu (en
particulier celui du timer 0). Un #DF apparaîtra forcément qui donnera
provisoirement sa pile pour laisser continuer l'exécution.

De deux choses, l'une :

1°) la barre tournante du timer 0 continue de tourner : l'IRQ est bien
exécuté après ou pendant un #DF ! ca signifie que le signal IRQ a été
maintenu jusqu'à ce qu'il puisse avoir lieu.
2°) la barre tournante du timer 0 ne bouge plus : les IRQ sont
irrémédiablement perdus. Il faut envisager un système plus compliqué pour
compenser.

Pour être honnête, je crois que le 2°) est le plus probable.

Pour compenser :

Si on veut vraiment pouvoir exécuter l'IRQ, il faut arriver à déterminer
quel IRQ a eu lieu. Pour cela il nous faudrait consulter le masque des IRQ
en état d'attente (pending IRQ) et repérer l'IRQ dans le bitmap obtenu. On
simule alors un appel d'interruption à cet IRQ depuis le #DF.

Ce doit être faisable.

A la prochaine

Hlide



----- Original Message -----
From: "Thomas Petazzoni" <thomas.petazzoni@ifrance.com>
To: <kos-dev@enix.org>
Sent: Saturday, March 31, 2001 11:05 AM
Subject: [Kos-dev] double fault fonctionnel !


> salut a tous,
>
> depuis hier soir, le double fault est fonctionnel... enfin il l'etait
> depuis quelques temps deja, mais en fait nous lisions mal la valeur de
> esp :
>
> un asm("movl %%esp, %0":"=r"(new_esp)) ne mettait pas la bonne valeur.
>
> peut etre que pour lire correctement l'adresse de la pile, il vaut
> mieux faire un :
>
> pushl %esp
> popl %eax
> movl %%eax, %0
>
> enfin bref, pour etre sur, j'ai la chose qu'Hlide avait propose :
>
> 0:
> cmpl $0x4001ffdc, %esp
> je 0b
>
> donc si l'adresse de la pile est 0x4001ffdc, et bien la chose fait une
> boucle infinie. cette adresse 0X4001ffdc etait l'adresse renvoye par le
> movl %%esp, %0.
>
> et bien l'ordinateur ne fait pas une boucle infinie ! il poursuit son
> execution. pour etre sur de mon coup, j'ai carrement fait un asm("int
> $1"), avec un handler qui appelle dump_cpu_context, qui affiche entre
> autres l'adresse de la pile. resultat :
>
> pdt le double fault      ==> Double fault handler is going to return
> with new stack addr 0x5bcffe and with eip 0x5cc752
> juste apres le test cmpl ==> after testing...the value !
> generation int 1         ==> Uncaught Exception Number 1
> puis le cpu_context
>
> *** Dumping CPU Context ***
> | ESP    = 0x5bcfbe
> | EIP    = 0x5cc76b
> | CS     = 0x8
> | EFLAGS = 0x246
> | EAX    = 0x0
> | EBX    = 0x2
> | ECX    = 0x4001ff93
> | EDX    = 0x66
> | ESI    = 0x0
> | EDI    = 0x0
> *** End of CPU Context ***
>
> on remarque bien que 0x5bcffe et 0xbcfbe appartiennent a la meme page,
> et que la seconde est bien inferieure a la premiere... donc tout est bon
> !
>
> bref, il me reste deux choses : realiser le mapping de la pile au bon
> endroit (pour l'instant on change de pile pour en mettre dans l'identity
> mapping... et pas la ou il faut), puis magouiller le truc pour avoir via
> des #ifdef le choix entre piles statiques et piles dynamiques...
>
> voila la bonne nouvelle de la journee.
>
> thomas
> --
> PETAZZONI Thomas
> thomas.petazzoni@meridon.com     UIN : 34937744
> Projet KOS : http://kos.enix.org
> Page Perso : http://www.enix.org/~thomas/
>
>
> _______________________________________________
> Kos-dev mailing list
> Kos-dev@yoda.isnpro.com
> http://the-doors.enix.org/cgi-bin/mailman/listinfo/kos-dev
>