[Kos-dev] Double fault : ca continue

[Thomas Petazzoni]

> Plusieurs questions :

pour repondre a ces questions, je me suis muni du Volume 3 de la Doc
Intel, reference en la matiere...

>   - que se passe-t'il quand, une fois le handler de doublefault lance,
>     ce handler fait une exception (p.ex : page fault) ? Est-ce que ca
>     genere une triple fault ou une #PF (j'insiste : le handler de
>     double fault a ete appele avec succes, et est en cours
>     d'execution).

eh bien il semble que la doc Intel soit tres peu precise sur la priorite
des interruptions concernant le Double Fault. Un joli tableau 5-2,
volume 3 nous informe des priorites, mais on n'y voit nulle part cite le
Double Fault. Les Pages Fault eux sont repartis en 2 parties : les Code
Page Fault, de priorite 6 (ce qui est normal : une faute de prefetch
d'instructions est plus prioritaire qu'une faute de decodage
d'instructions), et les Data Page Fault, de priorite 8. 8 etant la
priorite la plus basse.

a mon avis, une fois que le handler du double fault a ete lance, c'est
comme si on etait dans un tache, et donc si une exception survient, elle
sera traitee en tant que telle.

>   - Est-ce bien vraiment vrai qu'il n'y a aucun moyen de recuperer
>     l'id de la fault precedente quand on est dans un doublefault ?
>     Sinon, c'est pas trop grave, du moment qu'on peut retourner dans
>     le contexte interrompu (qui est celui d'une exception). A verifier.

la aussi j'ai ete assez surpris : la doc intel classe le Double Fault
dans les exceptions de type 'abort', et insiste bien sur le fait que :

A double-fault exception falls in the abort class of exceptions. The
program or task
cannot be restarted or resumed. The double-fault handler can be used to
collect diagnostic infor-
mation about the state of the machine and/or, when possible, to shut the
application and/or
system down gracefully or restart the system.
(chapitre 5-29).

peut etre que ceci ne concerne que les donnees qui devraient etre
empilees sur la pile, et qu'en cas de switch avec un TSS, le contexte
est tout de meme sauvegarde. si effectivement on ne peut pas reprendre
le cours de la tache precedente alors il faudra trouver une autre
solution.

> Sinon, cote alternatives de realisation, on a pas trop le choix :
>   - Demand paging sur les piles cpl0 + cas particulier doublefault (task gate)
>      -> necessite d'etre sur qu'une exception dans le doublefault n'entraine
>         pas de triple fault
==> et que l'on puisse redemarrer la tache.

>   - Demand paging sur les piles cpl0 + exceptions en task-gate.

==> le page fault en task-gate serait suffisant, mais l'efficacite en
est reduite. meme intel dans ses docs, dit bien que passer par un task
gate est bien plus lent que de passer par une simple int gate ou trap
gate.

>   - Mapping statique de (petites) piles cpl0

argh, je voulais faire qque chose de tout dynamique :(

> Sinon, une interrogation : a-ce vraiment un sens de parler de threads
> noyau (donc cpl0) "stand alone", c'est a dire non associes a un
> contexte cpl3 ? En fait, je crois que si on se lance serieusement
> la-dedans, on s'oriente vers qqch de bancal.

pour moi oui. je voulais faire qque chose de tres propre de ce cote la.
uniformiser les bottom half, les threads noyau et tout ca. de toute
facon, meme les threads utilisateur ont une pile CPL0, qu'il convient de
gerer. la aussi on aurait un mapping statique ? et si un syscall
subitement se met a pomper plein de pile ? comment k'on fait ?

> Sinon, rajoute ton patch bochs sur le CVS (module kos-contrib par
> exemple).

c'est fait. patch a appliquer sur le fichier cpu/exception.cc

amicalement,

thomas

PS : est-ce que vous pouvez taper des accents dans un Xterm ? si oui
comment vous avez fait ?
-- 
PETAZZONI Thomas
thomas.petazzoni@meridon.com     UIN : 34937744
Projet KOS : http://kos.enix.org