О переключении tss

1. Можно ли без автоматического формирования особого случая вызвать iret на третьем кольце для переключения задачи.
2. Зачем при каждом особом случае процессору переключать tss?

 

конечно можно (если сможешь бит NT установить)

Код (Text):

1.     pushfd
2.     or dword [esp], 0x4000
3.     popfd ; set NT bit
4.     iretd

только есть следующие НО:
1. Поле link в текущем TSS сегменте должно содержать валидный селектор дескриптора TSS
2. В дескрипторе должны быть установлены биты P и B
3. DPL дескриптора должен быть не меньше CPL

особый случай это исключение?
не за чем кроме #TS

 

с первым вопросом понятно. Спасибо. На счет второго я так и непонял.
Я имею виду такой случай: (все обработчики вызываются через шлюзы, т.е. без задач) задача третьего кольца ловит исключение или скажем прерывание, и нужно вернутся обратно в код текущей задачи, зачем iret передаст управление задаче предку в поле связи текущей задачи? Или мне нужно тогда везде ставить в обработчиках такой код?:

Код (Text):

1. sti
2. popfd
3. ret far

 

Доп. вопрос. Если IOPL позволяет текущей задаче делать ввод/вывод сможет ли она его делать если будет карта ввода/вывода в которой все запрещено?

 

ну дык а чем просто

Код (Text):

1. iretd ; retf для шлюза вызова

не катит?
со стека будут сняты последовательно EIP, CS, [EFLAGS], ESP, SS, что вернет управление прерванному коду

передаст только в случае наличия в EFLAGS бита NT
нужно, например, вот для такого кода

Код (Text):

1. task_code:
2. ; что-нибудь делаем
3.     iretd ; автоматическое переключение на предыдущую задачу (head) (потому как NT установлен)
4.  
5. head:
6. ...
7.     call 1 SHL 3:0000h ; 1-ый дескриптор в GDT - TSS дескриптор (в сегменте TSS поле EIP содержит адрес task_code), здесь как раз идет установка NT
8. ...

 

если логически подумать, то сможет
имхо, работа с картой имеет смысл только если IOPL < CPL

 

в том то и дело что текущая программа уже имеет статус вложеннной и я нехочу переключать задачу при исключении и прерывании по iretd, сбрасывать флаг нельзя.

 

NoName
а понял, что ты хочешь
тогда используй retf, но придется со стеком повозиться

Код (Text):

1. exception_handler:
2.     push ebp
3.     mov ebp, esp
4. ...
5.     add esp, 14
6.     popfd ; restore flags
7.     mov eax, dword [ebp + 14] ; get ESP
8.     mov dword [ebp + 10], eax
9.     mov eax, dword [ebp + 18] ; get SS
10.     mov dword [ebp + 14], eax
11.     leave
12.     retf

 

интересно, из каких соображений так сделано...
ведь если используется нечто посложнее flat модели, переключение задач програмными средствами становится затруднительным, если вообще возможным

 

Кто сказал, что в новых процессорах НЕ ПОДДЕРЖИВАЕТСЯ ПЕРЕКЛЮЧЕНИЕ ЗАДАЧ? IMHO этого просто НЕ МОЖЕТ БЫТЬ !!!TermoSINteZ, во первых, если не работает у тебя, не значит что этого нет вообще? Да и где это вообще проверялось, на какой системе?

 

OioVologda

А производитель процессоров и сказал. Но это относится только к 64-му режиму. И к хардварному переключению. Да им все рано особо никто и не пользовался
Если кто-то не верит см.
Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3A, 6.2.3
AMD64 Architecture Programmer’s Manual Volume 2, 2.7, 2.8

 

если брать flat модель, а если что посложнее?

 

rei3er
Производитель настойчиво подталкивает к flat
Да и не в модели дело, просто руками переключится эффективнее получается (по мнению гуру, ибо сам я таким не страдал).

 

нет, как раз в модели дело
не уверен, что вручную получится переключать эффективнее, если использвать в полном объеме сегментацию

 

А вот напримеря я страдаю хардварным переключением, и лично я как раз и использую в полном объеме сегментацию. Это что же мне теперь ядро переписывать и руками все менять! и CR3 и LDTR и еще туеву кучу того гавна, которое процессор сохранял и восстанавливал за меня сам... Мне пофиг на то, что винда и линюха, мать их, используют flat и программную переключалку. Да и по-моему, не факт, что ручное переключение быстрее хардварного? Да и как тогда допустим IO карту менять?

 

rei3er
А чем сегментация-то страшна? Не вижу принципиальной разницы. Да и для 64 это уже не актуально

 

Сейчас не актуально. Лет 25 назад считали, что и 640 килобайт будет достаточно на всю оставшуюся жизнь.

 

И еще вопрос, получается, что в 64 архитектуре вообще нет понятия шлюз задачи, и переход на TSS ничего не дает? Если все таки переключение при загрузке в TR не работает, нафиг тогда вообще там TSS, для регистров стека могли бы что нибудь легче придумать...

 

быстрее потому как не надо сохранять/восстанавливать CS, DS, SS, ES, GS, FS, LDTR, EIP
а каждая операция загрузки сегментного регистра крайне медленная операция

ну ты же ее как-то создаешь для каждой задачи
аналогичным образом при ручном переключении задач меняешь адрес в TSS дескрипторе (адрес TSS сегмента) и делаешь LTR