[Kos-dev] Double fault : ca continue

[Thomas Petazzoni]

salut,

bon comme vous le savez, l'instruction int $8 lance bien le handler du
double fault, comme prevu, ce qui signifie que l'ensemble
TaskGate->Selecteur_de_TSS->TSS fonctionne bien. (il y a encore un
probleme lors du retour, mais on verra ca plus tard).

Avec Bochs, ca chie, car effectivement, il ne genere aucun  Double
Fault, comme vous pouvez le voir sur le log suivant :

**********************************************************
i=19 (addr 0x4017f0c0)
i=18 (addr 0x4017f090)
::exception(14)
PAGE FAULT !!!
::exception(14)
PAGE FAULT !!!
We had two exceptions ... first was 2 and second was 2
setting curr_exception[1] to double fault
::exception(14)
bochs(panic) : bochs exited, log file was './bochs.out'
**********************************************************

La panic etant bien sur : 3rd exception with no resolution. le bug de
bochs est bien confirme. pourtant il detecte bien qu'il devrait faire un
Double Fault, mais ne le fais pas. j'ai pas encore eu le temps de
corriger ce foutu bug, parce que leur fonction exception() m'est encore
assez obscure. 
je vais tenter de faire ca ce soir.

le hic, c'est que lorsque l'on teste avec une machine normal (aka dd
if=image of=/dev/fd0, puis reboot), et bien ca reboote aussi. alors je
me demande quelle est la difference entre faire int $8 et le lancement
d'un double fault !

concernant l'extension de la pile, j'ai lu pas mal de critiques a propos
de l'utilisation de notre methode. pourtant je me demande comment on
peut faire autrement. extraits :

**** Mail recent de Hlide (hier) ******
Thomas posait la question :
> mais pourtant ils arrivent a faire marcher linux et windows sous bochs.
> alors comment font-ils ?
et Hlide repondit :
Parce que ni Linux ni Windows ne se trouvent réellement dans cette
situation
quand tu les lances (ce serait un bug majeur dans la conception du OS),
car
c'est pour un cas normalement non envisageable.
****** Fin mail de Hlide **************

****** Questions d'une personne sur la pmode-l, et reponses par Leif
**************
> I have some doubts about cpl0 stack and page fault.
> 
> In the existing OS, can the task's cpl0 stack cause a page fault?

I don't think so. We had a discussion about that a while ago. It will
cause a double-fault instead of a page-fault. In a segmented OS,
you will get a stack-fault instead of a double-fault. If you handle this
stack-fault with a task, it's possible (but not a good idea) to expand
the stack.
 
> If not, the cpl0 stack is limited and can't be expanded.

It's not, but you better not expand it.

> Worst, this
> mem area must be blocked even so the task is suspend or something,
> right?

If cpl0 stack overflows, you better terminate the offending app or
let the OS "panic".
 
> Suppose that a cpl0 code is running. And the next push to the stack
> will cause a page fault.
> 
> Suppose too that the system's page fault handler runs in a new task.
> (It uses a task gate in the IDT)

You shouldn't run page-fault handler in a new task. It should run in the
contents of the current task. Double-fault and stack fault shoud be
run in a new task.
 
> In this scenery, what will happen if a hardware interruption occurs?

It would be lost. That's one reason not to allow the cpl0 stack to
expand. Another is that you want be able to catch recursive loops
in cpl0 code that causes cpl0 stack overflows.
 
> Will the system lose the interruption?

Yes, but using the error codes you know the cause of the exception
and the int number in case of an interrupt error, so you could
re-invoke a failed interrupt. I don't know if this information would be
available if you get a double-fault, but for stack-fault it would be 
possible to re-invoke the interrupt.
 
> Cause the int will cause a page fault due to stack. The page fault
> handler will run. But the EIP on the stack will point to
> what? It can't restart the instruction (was a hardware interruption).

Page-fault handler can't run on cpl0 stack faults since it can't invoke
itself unless it's handled with a task, and that's a bad idea. Instead
of
invoking page-fault handler a second time, double fault handler will
be invoked instead.
*********************** Fin mail ****************************

voila, alors avec ca... je me demande comment font les autres OS ? ils
limitent la pile de leur thread noyau a 128k ? ou directement ils
mappent 16 ou 32k en physique ?
et pour les applis utilisateurs, ils font comment si un SYSCALL prend un
peu plus de pile que prevu ? bref, pour l'instant je comprends pas
tout... pour moi notre solution est l'unique solution, mais il
semblerait que non. quelqu'un pour m'expliquer ?

amicalement,

thomas

PS : je peux envoyer un patch pour Bochs, permettant d'avoir des
messages de debug un peu plus interessants que la normale. ca peut vous
aider si vous voulez debugger vous aussi :o)
-- 
PETAZZONI Thomas
thomas.petazzoni@meridon.com     UIN : 34937744
Projet KOS : http://kos.enix.org