|
| Посл.отвђт | Сообщенiе |
|
|
Дата: Дек 4, 2003 23:03:11 Ну безусловно такое должно выполняться в любой многозадачной среде, но тут просто вопрос в другом, а именно как это реализовано? В процессорах Интел есть аппаратная поддержка TSS, но по некоторым причинам в виндовсе полностью все возможности этого не используются(уж почему так я не знаю), т.е. каждый процесс работает с одной и тойже копией TSS. Указатель на дескриптор всегда один и тот же(это который TR). Люди, так что, в самом деле в винде только один TSS? Или это они пьяные? |
|
|
Дата: Дек 4, 2003 23:06:47 · Поправил: volodya В какой то книге читал про обяснения причин почему МС сделала именно так, но сейчас не помню даже в какой, не говоря о самих причинах. Хотя при полной использовании аппаратного TSS переключение происходила бы быстрее(опять же идея из того же источника). Объяснение простое - аппаратная поддержка переключения задач в Интеле медленне, чем его программный аналог. Это инфа от самого Интела. Кстати насколько я понимаю большинство(а возможно и все) юниксы на x86 тоже не используют данный механизм. И еще TSS - это Интеловский Task State Segment, в Виндах используется CONTEXT структура для хранения состояния регистров потока (включает и дебаг регистры). По моему, не все так просто. А как же KPCR.TSS? А KPCR.IDT? А KPCR.GDT? Four-F, а что SwapContext в ядре? Там идет работа с KTSS |
|
|
Дата: Дек 4, 2003 23:16:40 у меня TR всегда 28h :) |
|
|
Дата: Дек 4, 2003 23:24:31 Ну что-то более-менее стало понятным. Для процесса перезагружается CR3, т.е. переключаемся на PDE процесса, и выполняется команда lldt, т.е. LDT. Переписываются некоторые поля KTSS. Я догнал. В линухе тоже самое. Они тоже отказались от аппаратного TSS. Только все равно меня некоторые смещения в SwapContext просто застрелили. |
|
|
Дата: Дек 4, 2003 23:26:28 Four-F Поправь если ошибаюсь. Итак, KPCR - один на всех. Просто в нужный момент времени берется информация из списка KTHREAD и переписываются поля KPCR. Я прав? |
|
|
Дата: Дек 4, 2003 23:39:50 volodya Вроде в винде два TSS. Предпологаю что это нужно для обработки сбоя в стеке. В первом сохраняется состояние текущей задачи. А так как стек разрушен то обрабатывать этот сбой нужно отдельной задачей. Происходит переключение на второй TSS. От туда берется корректный указатель стека. Если в IDT четырнадцатый дескриптор - шлюз задачи то скорее всего так оно и есть. Жаль SI под рукой нет. |
|
|
Дата: Дек 4, 2003 23:43:40 Что-то с номером исключения я сглючил 8( |
|
|
Дата: Дек 4, 2003 23:45:23 Не 14 а 12. |
|
|
Дата: Дек 4, 2003 23:59:37 #SS? |
|
|
Дата: Дек 5, 2003 00:06:16 Black_mirror Честно, поковырял я KiTrap0C. Что-то не узрел я там второго TSS... |
|
|
Дата: Дек 5, 2003 00:29:21 Прошу прощения. Отдельной задачей обрабатывается двойной сбой (8). А дескрипторов TSS в GDT я увидел три: 28h,50h(обработчик двойного сбоя),58h. |
|
|
Дата: Дек 5, 2003 00:33:24 Black_mirror Двойной сбой - это номер 8. Т.е. KiTrap08. Так вот, там только KeBugCheck. Все. Вообще, теоретически, то, что ты говоришь, имеет смысл. Только TSS я в этих обработчиках не вижу! Надо подумать... |
|
|
Дата: Дек 5, 2003 01:32:21 Очень похоже что из этих трех TSS используется только первый. И то, только для того, чтобы считать SS:ESP при передаче управления на нулевое кольцо. TSS нужны только для того, чтобы синий экран показать 8) |
|
|
Дата: Дек 5, 2003 05:57:40 The purpose of the TSS is to save the state of the processor during task or context switches. For performance reasons, Windows NT does not use this architectural feature and maintains one base TSS that all processes share. As noted in the previous section on the Windows NT IDT, other TSS data types exist, but are only used during exceptional conditions to ensure that the system will not spontaneously reboot before Windows NT can properly crash itself. Use the SoftICE TSS command to view the current TSS. The TSS contains the offset from the base of the TSS to the start of the I/O bitmap. The I/O bitmap determines which ports, if any, the code executing at Ring 3 can access directly. Under Windows NT 3.51, when executing in a VDM, the TSS contains a valid offset to a I/O bitmap that traps direct I/O for subsequent emulation by the operating system. When executing a Win32 application, the TSS contains an invalid offset (it points beyond the segment limit of the TSS). This forces the operating system to trap all direct I/O. Inside the actual TSS data structure, the only field of real interest is the address of the Level 0 stack. This is the stack that is used when the CPU transitions from user mode to system mode. |
|
|
Дата: Дек 5, 2003 12:09:05 volodya Вот чего я не понимаю: зачем нужен третий TSS(смещение 58h)? Там куда указывает его EIP перед вызовом KeBugCheck есть вызов HalHandleNMI. В каких случаях происходит переключение на эту задачу? |