A kernel hack to try to get realtime in Windows (NT/XP)

В заголовок вынесено название одного исследования, размещенного на страничке товарища
Micah Richert http://www.snl.salk.edu/~micah/RTInterrupt/
Прокомментируйте плиз сие творение, самостоятельно мало что понял.

 

Читал когда-то эти сорцы и там есть некот некорректные моменты но не буду писать тк как понял вопрос не в том что тут некорректно а втом что там происходит. если интересно однако могу потом написать. у меня даже сорцы этого дела на компе вроде валялись

 

Компилировал и запускал, система иногда повисает, а если не повисает то всёже непонятно где там realtime.
В чем суть метода я вроде бы понял, на уровне своего знания англицкого, благо у автора подробные комменты.
Жизнеспособен ли вообще подобный метод?
SashaTalakin
Очень хотелось бы по-подробнее...

 

1) первое замечаение по детекту apic маппинг ioapic. не знаю возможно применительно к windows конкретно это в 100% случаях корректно, но на самом деле это делается по другому
2) он делает поддержку apic а поддержку многоядрености/многопроцессорности не делает. тобиж код абсолютно не годится под такие системы
3) перехват прерывания сделан СТРАННО. не то что он не работает, просто на самом деле это делается проще - если нужно перейти к старому прерыванию делается jmp на него, а тут зачем-то регистрируется новый якобы незанятый обработчик и переход осуществляется по int. Другое дело что он делает после какуюто проверку после этого int по возвращении из него, но мне не позволяет оценить целесообразность этой проверки давность за которой я ковырялся в планировщике виндоус, прерываниях таймера и прочих делах. мне кажется там чтото ненужное делается.
4) Далее почему-то для PIC систем он вешает дополнительный таймер вместо того чтобы врезаться в уже существующий - с какой целью непонятно. Т.е. его манипуляции идут как бы параллельно вместе с обычной планировкой виндоус в тех системах где используется pit вместо rtc (помоему он правильно это состыковал с тем pic или apic контролирует прерывания в системе)
5) Может и еще чото там было но я не могу сказать ксательно его взаимодействия с ОС потому что уже все это выветрелось щас. Это к клерку он я так понимаю не вылазит из отладчика

 

*по детекту apic и маппингу ioapic
6) это все не будет работать под 64битные ОС

 

Допустим, много процессорность/ядерность убираем за скобки.
64 бита туда же.
А сама по себе идея-то вроде бы не плоха?

 

Не смотрел пока что там, название не понятно. В общем что это ?(не как оно апик програмирует и тп., а без воды про что тут ?).

 

вот комментарий из файла rtinterrupt.c

Код (Text):

1. The basic idea behind this driver is that we program a timer to tick at 8Khz (1/8 ms).
2.     On each tick we check to see which thread is running.  If it is not our thread,
3.     we cause the current thread to yield execution (sleep for a while) and set our priority
4.     to the highest.  From window's perspective, the yield function call is run from
5.     the current thread's context.  In other words, windows thinks that the current
6.     thread requirest the yield (not our code).  Thus the scheduler will automatically switch
7.     to our thread when the current one sleeps, because it should be the highest priority
8.     thread which is available to run.  From the current thread's prospective, the Yield
9.     function doesn't return until the scheduler runs the current thread again.  So,
10.     as a result, half of our interrupt handler will not be executed until after the current
11.     thread is rescheduled.  This means that we can have multiple tail ends or "stubs"
12.     waiting to run and cleanup the handler and return back to the thread which was
13.     interrupted in the first place.
14.  
15.     Example:
16.         Other Thread
17.         Begin Interrupt
18.         Yield               ----------> Our Thread
19.                                             .
20.                                             .
21.                                             .
22.         Finish Interrupt    <---------- (Scheduler)
23.         Other Thread

 

Посмотрел на код из int.c и взгрустнул.

 

ИМХО: переход на ОРИГИНАЛЬНЫЙ ISR... Так: чтобы jmp случайно не порушил стэк, а это вполне может произойти, мы же НЕ ЗНАЕМ куда передаём управление... Просто адрес... Допустим: Он (origISR) может, например, думать что все регистры процессора уже в стеке, и он хочет ими воспользоваться. А там наша какая-то хрень зависла. Я понимаю, что во-первых, переход по jmp на оригинал будет быстрее. Но надЁжнее (сократит вероятность появления ошибок программиста) всё-таки способ вызова ориг. ISR путём int[перенесен]

 

diombre, перед вызовом оригинального обработчика нужно все восстановить естественно. Восстановить всеравно все придется иначе ничего не будет работать. Просто он восстанавливает все перед своим собственным iretd. Так что надежность тут непричем

 

помогите!!1 наваял скрипт примерна на такуюже тему. http://pastebin.com/f359ca7bf вот.. но трабла в том что для его работы надо выбирать hal.dll на базе PIC-а, (опция /hal=halpic.dll) , потомушто я не знаю как замаскировать вектора апика, от левых срабатываний (с PIC-ом то боле менее понятно). а то таймерок с клавой хочеться :'(

 

bugaga

Код (Text):

1. procedure callR0(proc:pointer);
2. asm pop  ecx
3.     int  $2a //make for self dpl3 backdor:)
4.     push $30    //
5.     pop  fs     // XCHG ECX, [ESP]
6.     call eax    // JMP  ECX
7.     push $38    //
8.     pop  fs     // hook by driver, kernel patch, etc..
9.     iretd
10. end;

Будет сгенерирован экцепшин, так как CPL>DPL дескриптора. И ядерный тред с юзермодным стеком работать не будет. Точно скрипт, иначе этот мусор назвать нельзя.

 

у дятлов, не читающих каментов будет.. а мну дров http://pastebin.com/f77d47833 DPL3 доставляет, каллбак обратный..

 

Надо промапить IO APIC и редактировать его redirection table.
см. тут http://wiki.osdev.ru/index.php/I/O_APIC). Там правда ненаписано как корректно определять адрес ioapic если он отличен от дефолтного

 

да промаплен APIC жестко на FFFE0000.. вот.. работает тихо мирно цикл со STI... вся IDT перебита на единственый обработчик

Код (Text):

1. procedure rise;
2. asm pushad
3.     call msg
4.     mov eax, 0FFFE00B0h
5.     mov [eax],0
6.     popad
7.     iretd
8. end;

регистрирую два тика - и тишина.. фик сним.. цикл свое отсчитывает, востанавливает idt, а винда виснит..

 

Вообщем у меня нет желания читать код на паскале, поэтому я отвечаю просто на ваш вопрос

Надо промапить IOAPIC и отредактировать редирекшн тейбл. Дальше вы пишите

Во-первых я тавкой информацией не располагаю. Вы часом локал апик с ио апик не попутали? Во-вторых ну промаплен допустим это не проблема а шаг к ее разрешению. Проблема где начинается? Вы редирекшн тейбл редактировали? Там есть бит маскировки

 

SashaTalakin извините конешно, ну раз уж вы асмЪ (что я тут привел) от паскаля отличить не можете, огромная просьба, не затрудняться, с жеванием соплей, уровня детского сада. Тем более толком не вьехав в проблему..


не до масок, разборки c "APIC EOI"

прерывания бац - и усё... потом кудато пропадают!!1

причем код отрабатывает в R0, возвращаеться в R3 выводит там мессагу, тока тиков с часиков больше нет :'(
и хрен отладишь...

 

bugaga
сраться не обязательно

 

bugaga
дайте весь код чтоль где вы с апиком работаете посмотреть.

а пока:
1) точно локал паик с ио апиком не попутан?
2) вы в курсах что с в системах с апик никто не обещал вам по 0x30 вектору размещать PIT и по 0x38 RTC?
3) вы в курсах что в системах с apic используется RTC как таймер планировщика, а в pic системах используется PIT?
4) вы в курсах что чтобы продолжить получать прерывания от rtc нужно считать 0x0c порт?