OSDev http://osdev.su/ |
|
Local APIC owned interrupt handling http://osdev.su/viewtopic.php?f=6&t=730 |
Страница 1 из 1 |
Автор: | ZarathustrA [ 21 мар 2013, 11:46 ] |
Заголовок сообщения: | Local APIC owned interrupt handling |
Приветствую сообщество! На днях пересматривал архитектуру обработки исключений в своем ядре. На этой почве у меня возникло несколько вопросов по поводу прерываний генерируемых собственно LAPIC-ом. В частности хотелось бы обсудить: 1) Spurious interrupts 2) APIC Error interrupts 1) Если я правильно понимаю, spurious прерывания по сути и не являются прерываниями, поскольку не требуют EOI. Более того у меня есть стойкое ощущение, что они поставляются процессору в обход приоритета установленного в TPR. То есть по сути их можно рассматривать как специфические исключения. Специфические потому, что они не требуют обработки. Если я правильно понял, то идеальный обработчик, для таких прерываний должен быть просто пуританским: VOID ASMCODE HandleSpuriousInt(VOID) { __asm iretd; } Правильно ли я понимаю суть этих прерываний их их обработку? 2) APIC Error interrupts уже являются настоящими прерываниями. То есть требуют EOI и поставляются с учетом приоритета TPR. В связи с этим они должны обрабатываться. Или не должны? Правильным ли будет полностью игнорировать их и какие последствия это может повлечь? В общем, я был бы рад, если бы все кто уже разобрались с этой темой и имеют ясное представления по поводу природы этих прерываний и что должна с ними делать ОС поделились своими знаниями. |
Автор: | SII [ 21 мар 2013, 11:50 ] |
Заголовок сообщения: | Re: Local APIC owned interrupt handling |
Как в ПК, не помню, но вообще spurious -- это ложные прерывания. Возникают, если контроллер прерывания выдал процу запрос прерывания и тот успел дать ответ (мол, давай сюда вектор прерывания), и в этот момент обнаружилось, что прерывания-то нету (например, устройство, выдавшее запрос контроллеру прерываний, успело снять этот запрос). Обычный PIC, помнится, в такой ситуации кидал свой старший вектор (IRQ 7 и IRQ 15 -- изначально ж использовались две микросхемы, каждая по 8 линий обслуживала, это потом всё загнали в чипсет). По этой причине не нужно и выдавать EOI: реального прерывания не было, было ложное, и надо лишь просто выполнить возврат из прерывания (ну и, возможно, увеличить некий счётчик, чтоб вести статистику: часто ли происходят подобные прерывания). |
Автор: | ZarathustrA [ 21 мар 2013, 12:24 ] |
Заголовок сообщения: | Re: Local APIC owned interrupt handling |
Ок. Спасибо за пояснение относительно природы ложных прерываний. Однако меня больше интересует случай LAPIC прерываний. Но ваше пояснение, несомненно было полезным (по крайней мере для меня ). |
Автор: | ZarathustrA [ 21 мар 2013, 14:14 ] |
Заголовок сообщения: | Re: Local APIC owned interrupt handling |
Итак, если я правильно понял ложные прерывания не имеют никакого смысла. То есть это фальстарт со стороны контроллера прерываний. То есть они теоретически могут появляться в системе, которая функционирует не совсем корректно, но они должны игнорироваться со стороны ОС. Вопрос, который для меня действительно интересен на данный момент - это могут ли они доставляться в обход логики приоритизатора LAPIC. То есть могут ли такие прерывания запускать механизм обработки прерываний процессора при следующих настройках LAPIC: 1) вектор для ложных прерываний в регистре Spurious Interrupt Vector Register (SVR) выставлен в значение 0х1F 2) приоритет принимаемых прерываний в регистре Task Priority Register (TPR) установлен в 0x7F. Так вот будет ли когда-нибудь вызван обработчик из дескриптора 0х1F в IDT или нет. Можно ли ожидать, что при таких настройках ложные прерывания зависнут на уровне логики LAPIC и никогда не дойдут до процессора? |
Автор: | ZarathustrA [ 21 мар 2013, 21:21 ] |
Заголовок сообщения: | Re: Local APIC owned interrupt handling |
Как я понял исходя из чтения мануалов Intel-а, Spurious прерывания могут генерироваться LAPIC-ом, только в случае манипуляций с регистром TPR. Intel Corporation писал(а): "A special situation may occur when a processor raises its task priority to be greater than or equal to the level of the interrupt for which the processor INTR signal is currently being asserted." И только в том случае, когда в TPR выставляется приоритет выше, чем текущий приоритет кода выполняемого процессором. Например, когда в TPR записывается 0xFF из system call, который выполняется с приоритетом 0х00. Однако с другой стороны, если манипуляции с TPR будут проводиться ТОЛЬКО в обработчиках аппаратных прерываний и ТОЛЬКО таким образом, что в TPR будет выставляться приоритет ниже приоритета кода обработчика из которого этот приоритет будет выставляться, то spurious прерываний мы не увидим вообще. Вывод: избежать spurious прерываний можно за счет соответствующей организации кода OS. |
Автор: | ZarathustrA [ 21 мар 2013, 21:52 ] |
Заголовок сообщения: | Re: Local APIC owned interrupt handling |
А APIC Error прерывания можно отключить/замаскировать (как минимум в Release версии) за ненадобностью. В корректно спроектированной системе они никогда не должны появляться, хотя и могут оказаться полезными во время разработки-отладки подсистемы межпроцессорных взаимодействий. То есть по финалу, можно сказать, что систему можно спроектировать и реализовать таким образом, что ни spurious ни error прерываний в ней не будет. Соответственно и обработчики для этих прерываний будут не нужны. |
Автор: | SII [ 21 мар 2013, 22:31 ] |
Заголовок сообщения: | Re: Local APIC owned interrupt handling |
ZarathustrA писал(а): Вывод: избежать spurious прерываний можно за счет соответствующей организации кода OS. Не уверен, поскольку в реальной жизни основная причина, причём не всегда устранимая, их возникновения связана с вводом-выводом. Надо смотреть, как IOAPIC обрабатывает запросы прерываний от периферии. |
Автор: | ZarathustrA [ 21 мар 2013, 23:04 ] |
Заголовок сообщения: | Re: Local APIC owned interrupt handling |
А есть где посмотреть? Может быть вы знаете, где можно взять какие-нибудь детальные мануалы? |
Страница 1 из 1 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |