[OSy] "Chyba" v simulatore prezentovana pri predvadzani...

[Lubomír Bulej]

Dobry den,

>Nasa skupinka (JuPiHo -> kernel NukleOS) prezentovala 30.11. na 
>'predvadzacom' seminary OSy, chybu v simulatore ohladne prepisovania
>EPC registra pri rekurzivnych vynimkach (pri zapnutom EXL bite). 
>Slubovali sme, ze detailne informacie posleme do par dni do mailing
>listu. Ospravedlnujeme sa tymto za oneskorenie. 
>
>Kazdopadne po debate s Lubosom Bulejom sme sa dohodli, ze hoci je
>spravanie simulatoru zrejme v rozpore s manualom k procesoru, je
>taktiez logicke (mozno dokonca viac ako spravanie, ktore popisuje
>manual) a preto nieje nutne sa touto skutocnostou extra zatazovat.
>  
>
neustale mi to vrtalo hlavou, a tak jsem se znovu podival do manualu od 
MIPS R4000 a
musim rict, ze pokud msim opravdu pri vyjimce pri EXL=1 prepisuje EPC, 
tak je to chyba.
Mnou popisovane "logicke" chovani, na kterem jsme se shodli, spociva v 
tom, ze pokud
procesor jakymkoliv zpusobem prerusi vykonavani kodu, musi uschovat 
alespon navratovou
adresu, proto mi prislo prirozene, ze pokud dojde k preruseni kodu 
obsluhujici vyjimku, je
nutne uschovat navratovou adresu.

Je ovsem nutne se na to divat mirne jinak. Pokud vyvstane vyjimka pri 
obsluze jine vyjimky a
je nastaven bit EXL, pak opravdu dojde ke ztrate pozice v puvodni 
obsluzne rutine, coz je
fatalni, pokud puvodni obsluzna rutina zacala nejakym zpusobem menit 
vnitrni struktury jadra.
Obecne se tedy da rict, ze vyjimka pri EXL=1 je neco, cemu je treba 
predchazet.

Na druhou stranu existuji vyjimky, kde to az tak nevadi, coz je pripad 
napr. TLB Refill/Invalid.
Ukolem obsluznych rutin pro tyto vyjimky je *precist* informaci o 
mapovani virtualni adresy na
fyzickou a zapsat ji do TLB. Neda se tedy hovorit o nejake zasadni 
modifikaci vnitrnich struktur
jadra. Pokud behem toho dojde k dalsi TLB vyjimce (napr. protoze 
strankovaci tabulky druhe/treti
urovne nejsou momentalne v pameti), vyvola se obsluzna rutina pro 
General Exception s
prislusnou hodnotou pole Cause.

Ztrata pozice v puvodni obsluzne rutine nepredstavuje vazny problem, 
protoze dojde k vyvolani
stejneho typu vyjimky (a je tedy mozne ucinit predpoklady napr. o 
zamcenych zamcich), a protoze
puvodni vyjimku je mozne znovu vyvolat prostym navratem do puvodniho 
kodu, kam ukazuje EPC.
Obsluha TLB vyjimek z obsluzne rutiny pro General Exception ma tedy dve 
moznosti, obslouzit
vypadek stranky druhe urovne a na zaklade informaci z prvni obsluzne 
rutiny obslouzit i vypadek
stranky prvni urovne a vratit se do programu, nebo se po obsluze vypadku 
druhe urovne proste vratit
do programu, cimz dojde k opetovnemu vyvolani puvodni vyjimky TLB 
Refill/Invalid a jeji nasledne
obsluze.

Co me osobne trochu svedlo spatnym smerem byl dojem clenu skupiny 
JuPiHo, kteri chybu
objevili, ze obsluzna rutina pro General Exception v jadre Kalisto je 
postavena kolem teto chyby.
Prestoze jsem Kalisto nepsal, nemyslim si to, naopak tato obsluzna 
rutina zhruba odpovida strukture
doporucene v manualu (pro snadnejsi pochopeni schovava vice registru nez 
je potreba) . Aby
nebylo nutne resit situaci prichodu nesouvisejici vyjimky pri EXL=1, kod 
nejprve uschova potrebne
registry a vynuluje EXL spolu s prepnutim procesoru do kernel mode a 
zakazanim preruseni. Pokud
pote dojde k vyvolani jine vyjimky, dojde k uschovani navratove adresy 
do EPC. Pri tomto zpusobu
obsluhy je celkem jedno, jestli se EPC pri EXL=1 prepisuje ci ne, 
protoze kod Kalista se teto
situaci predevsim snazi vyhnout.


Lubomir Bulej