task/context switch [ia-32]

0

potrzebuje upewnic sie co do kilku rzeczy.
manual to lanie wody i nie jestem pewien czy nie opuscilem niczego istotnego.

TSS jest struktura opisujaca context procesora. zawiera wszystko procz rejestrow x87 i sse (wlasnie, jak one sa azchowywane).

zmiana taska moze nastapic tylko raz, flaga NT jest ustawiana i busy bit w segmencie.
powrot przez iret, flagi sie czyszcza.

teraz jak dziala realizacja context switcha w osach?
jak one przelaczaja watki?

procesor ma rejestr TR, ktory zawiera informacje jak stosy dla poszczegolnych cpl'i.
jesli zmienie cpl, to ss i esp jest automatycznie pushowane na nowy stack (64bit zawsze jest) i zastepywane przez odpowiednia wartosc z TR. powrot analogicznie.

wiec jesli zrobie intX, iret, div/0, czy cokolwiek, cpu skopiuje na nowy stos stary esp i ss.
a nastepnie wykona normalne wejscie, czyli push eflags, push cs, push eip i skoczy pod cs:epi handlera.

stos handlera interruptu:
ss3
esp3
eflags
cs3
eip3

iret analogicznie, jesli popujac CS nastapi zmiana cpl, popuje stary ss, esp.
exceptiony i interrupty sa jedyne zmieniajace cpl, bo call/jmp dla conforming segmentu uruchamia go w dpl = cpl.

wiec jak wyglada multitasking?

cpu jest w cpl = 3, jest jakis interrupt. handler dziala w ring0 zazwyczaj.
po wejsciu w handlera, na stosie jest stary esp bo nastapila zmiana cpl. handler sie wykonuje, i przed iretd, jakas funkcja sprawdza, czy watek wykozystal swoj przydzielony limit cykli. jesli nie, iret, jeli tak - zmienia GPRy, cr3, fpu, sse, elfags na wartosci z jakiejs abstrakcyjnej tabeli z listy watkow.
po zmianie stosu, sprawa jest identyczna. watek zawsze jest opuszczany z ss, esp, elfags, cs, eip, wiec iret 'powraca' do innego watku i kolo sie zamyka.

i teraz co to jest ten TSS?
jak to sie ma do calosci?

jak wykonam int na task gate, badz call na TSS descriptor, kontext cpu sie zamienia z zawartoscia TSS, i ustawia busy flag. wyjscie resetuje to. po co to jest?

czym sie rozni TSS segment od TSS tabeli zawierajacel kontext cpu? jest jakis zwiazek?

ostatnia kwestia jak wyglada przekazywanie argumentow do exceptionow?
ss
esp
eflags
cs
eip
error

jak handler ma wiedziec, ze zostal mu przekazany error code?
jest jakis standard? nie doszukalem sie w manualu.

0

O tss masz w manualach wystarczajaco napisane, a jesli chodzi o przesylanie handlerom exceptionow error codes to raczej juz to powinienes wiedziec zabierajac sie za wielozadaniowosc ;)
Obsluga kodow bledow sprowadza sie do tego, iz piszesz sobie kod w asemblerze do wywolania handlera w C i za pomoca stosu przekazujesz parametry, czyli kody bledow i co tam chcesz. Oczywiscie nie musisz wywolywac kodu w C, ale wypadaloby aby w razie wyjatku byl wywolywany kod w asmie.
Ten kod to praktycznie wrzucenie ds, es i innych segmentow oraz parametrow na stos, wywolanie procedury obslugi i zdjecie ze stosu ds, es ;)

0

ze co?
jakie kur*a C? ja mam gleboko C! tylko asm!

chodzi mi o exceptiony ktory musza przed iret zdejmowac ze stosu 1 element.
teraz znalazlem to w manualu i wiem, sa chyba 4 takie. page fault, general protection, i jakies inne.

gdybym mial wystarczajaco, to nie zakladal bym tematu. a moze w zlych dzialach szukalem?
dla mnie TSS jest to obrzar pamieci = 104 bajty. zaczyna sie od SEL:0, selektor musi byc 'tss'.
system kozysta z jego wartosci (stos) przy przelaczaniu na kod w innym cpl.
i tu bylem w bledzie bo call gate nie moze byc conforming wiec call/jmp tez moga przelaczyc ten kod.

ok sory za moje nastawienie ale jestem teraz w zlym stanie, z niewiadomych przyczyn virtualbox+virtualpc nie chca modyfikowac pamieci pod IDT i nie potrafie tego wyjasnic wiec musze testowac na prawdziwym sprzecie. a skutki sa chyba oczywiste.

0

Odpowiedź na pytanie o wyjątki już masz: jedne (ściśle określone) mają kod błędu, a inne nie. Kod zdejmujesz, albo nie, zależnie od wyjątku. Nie trzeba tego nigdzie sprawdzać, bo wiadomo które wyjątki mają kod błędu.

Zanim zagłębisz się w zadania zagnieżdżane przez CALL/IRET, zacznij od normalnego przełączania zadań, czyli JMP do task-gate'a:

	jmp far [ecx]

gdzie ecx wskazuje na bramkę.
Możesz to robić wielokrotnie między zadaniami – w najprostszym modelu do następnego zadania z jakiejś tablicy task gate'ów. Spokojnie możesz to robić w przerwaniu zegarowym te 18 razy na sekundę i już masz prymitywny – ale działający! – multitasking, w którym każdy proces dostaje po równo czasu procesora. Można to dalej znacznie usprawnić dodając dodatkowe przełączanie zadań podczas operacji we-wy, np. przy oczekiwaniu na klawisz.

teraz jak dziala realizacja context switcha w osach?
jak one przelaczaja watki?

W ogóle nie używają task-gate'ów, lecz „ręcznie” zrzucają i wczytują wszystkie rejestry. W trybie 64-bitowym zresztą jest to jedyny dostępny sposób, jako że context-switching nie jest w nim już w ogóle obsługiwany.

TSS jest struktura opisujaca context procesora. zawiera wszystko procz rejestrow x87 i sse (wlasnie, jak one sa azchowywane).

Nie są, trzeba robić to samemu podczas przełączania zadań. A skoro i tak część roboty trzeba zrobić samemu, równie dobrze można zrobić całą zmianę kontekstu, i masz już jeden z kilku powodów, dlaczego w OS-ach unika się korzystania ze sprzętowego przełączania zadań.

PS. Przypomniał mi się temat ze studiów. Przełączania zadań uczono zupełnie na opak, zaczynając od przełączania za pomocą CALL/IRET, zupełnie nie wspominając że można je przełączać za pomocą JMP. W rezultacie przełączanie zadań w laborce co prawda było, ale dawało to zero wielozadaniowości, i było zupełnie niepotrzebne: zwykłe CALL/RET do podprocedury wystarczałoby w zupełności...

0

dzieki wielkie za info

czyli hardwarowe przelaczanie, z uzyciem task gatow ma jakis limit?
moge stworzyc segment TSS, i dodawac/usowac z niego 104 bajtowe struktury taskow?

i jak wykonam call pod ten segment, offset bedzie wskazywal strukture na ktora ma przelaczyc?
a co z zagniezdzeniem?
czy po przelaczeniu, moge zalozyc ze na stosie mam:
ss
esp
eflags
cs
eip

i wykonac iretd?

a softwarowe to wyglada na zasadzie ze dostaje interrupt, i bez zadnych task gatow kopiuje rejestry to pamieci okreslonej przez task register (ktory trzymammiedzy innymi stosy wykozystywane przez cpu)?
i analogicznie, zawsze wychodze na ss....eip, tylko roznych taskow?

0
asm67 napisał(a)

czyli hardwarowe przelaczanie, z uzyciem task gatow ma jakis limit?

Kilka. Maksymalnie ileś-tam tysięcy wątków (kiedyś się to wydawało dużo, ale dzisiaj...) i jest znacznie wolniejsze niż da się zrobić programowo.

czy po przelaczeniu, moge zalozyc ze na stosie mam:
ss
esp
eflags
cs
eip
i wykonac iretd?

Przy przełączeniu zagnieżdżającym (call), ale nie normalnym (jmp).

a softwarowe to wyglada na zasadzie ze dostaje interrupt, i bez zadnych task gatow kopiuje rejestry to pamieci okreslonej przez task register (ktory trzymammiedzy innymi stosy wykozystywane przez cpu)?

Mniej więcej. Podmieniasz zawartości rejestrów (zapisując je w zasadzie gdzie chcesz, wcale nie musi być w TSS) i skaczesz do cs:eip nowego zadania (np. wrzucając adres na stos i skacząc tam przez iret).

0

to musze gdzies skakac?
jak zapisuje i podmieniam ESP/RSP, to na nowym stosie mam dokladnie to co na starym, tylko adresy/selektory inne.
iret wznawia po prostu inny task zupelnie gdzie indziej.

zawsze bedzie to ring0, jesli cs z nowego stosu wskazuje rowniez na cpl = 0, znaczy ze wyzej juz nie ma stosu, bo task switch moze wystapic TYLKO w ring0 i jak nie nastapilo przelaczenie CPL to ss/esp nie zostal zapisany.

iret i jestem w nowym tasku, az do nastepnego interrupta.

0
asm123 napisał(a)

to musze gdzies skakac?
jak zapisuje i podmieniam ESP/RSP, to na nowym stosie mam dokladnie to co na starym, tylko adresy/selektory inne.
iret wznawia po prostu inny task zupelnie gdzie indziej.

I właśnie wynalazłeś software'owy context switching, udowadniający że ten sprzętowy nie jest potrzebny..

1 użytkowników online, w tym zalogowanych: 0, gości: 1