OSDev

Приветствую сообщество!

На днях пересматривал архитектуру обработки исключений в своем ядре. На этой почве у меня возникло несколько вопросов по поводу прерываний генерируемых собственно LAPIC-ом. В частности хотелось бы обсудить:
1) Spurious interrupts
2) APIC Error interrupts

1) Если я правильно понимаю, spurious прерывания по сути и не являются прерываниями, поскольку не требуют EOI. Более того у меня есть стойкое ощущение, что они поставляются процессору в обход приоритета установленного в TPR. То есть по сути их можно рассматривать как специфические исключения. Специфические потому, что они не требуют обработки. Если я правильно понял, то идеальный обработчик, для таких прерываний должен быть просто пуританским:
VOID ASMCODE HandleSpuriousInt(VOID)
{
__asm iretd;
}
Правильно ли я понимаю суть этих прерываний их их обработку?

2) APIC Error interrupts уже являются настоящими прерываниями. То есть требуют EOI и поставляются с учетом приоритета TPR. В связи с этим они должны обрабатываться. Или не должны? Правильным ли будет полностью игнорировать их и какие последствия это может повлечь?

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

Как в ПК, не помню, но вообще spurious -- это ложные прерывания. Возникают, если контроллер прерывания выдал процу запрос прерывания и тот успел дать ответ (мол, давай сюда вектор прерывания), и в этот момент обнаружилось, что прерывания-то нету (например, устройство, выдавшее запрос контроллеру прерываний, успело снять этот запрос). Обычный PIC, помнится, в такой ситуации кидал свой старший вектор (IRQ 7 и IRQ 15 -- изначально ж использовались две микросхемы, каждая по 8 линий обслуживала, это потом всё загнали в чипсет).

По этой причине не нужно и выдавать EOI: реального прерывания не было, было ложное, и надо лишь просто выполнить возврат из прерывания (ну и, возможно, увеличить некий счётчик, чтоб вести статистику: часто ли происходят подобные прерывания).

Ок. Спасибо за пояснение относительно природы ложных прерываний. Однако меня больше интересует случай LAPIC прерываний. Но ваше пояснение, несомненно было полезным (по крайней мере для меня ).

Итак, если я правильно понял ложные прерывания не имеют никакого смысла. То есть это фальстарт со стороны контроллера прерываний. То есть они теоретически могут появляться в системе, которая функционирует не совсем корректно, но они должны игнорироваться со стороны ОС. Вопрос, который для меня действительно интересен на данный момент - это могут ли они доставляться в обход логики приоритизатора LAPIC. То есть могут ли такие прерывания запускать механизм обработки прерываний процессора при следующих настройках LAPIC:
1) вектор для ложных прерываний в регистре Spurious Interrupt Vector Register (SVR) выставлен в значение 0х1F
2) приоритет принимаемых прерываний в регистре Task Priority Register (TPR) установлен в 0x7F.
Так вот будет ли когда-нибудь вызван обработчик из дескриптора 0х1F в IDT или нет. Можно ли ожидать, что при таких настройках ложные прерывания зависнут на уровне логики LAPIC и никогда не дойдут до процессора?

Как я понял исходя из чтения мануалов Intel-а, Spurious прерывания могут генерироваться LAPIC-ом, только в случае манипуляций с регистром TPR.



И только в том случае, когда в TPR выставляется приоритет выше, чем текущий приоритет кода выполняемого процессором. Например, когда в TPR записывается 0xFF из system call, который выполняется с приоритетом 0х00. Однако с другой стороны, если манипуляции с TPR будут проводиться ТОЛЬКО в обработчиках аппаратных прерываний и ТОЛЬКО таким образом, что в TPR будет выставляться приоритет ниже приоритета кода обработчика из которого этот приоритет будет выставляться, то spurious прерываний мы не увидим вообще.

Вывод: избежать spurious прерываний можно за счет соответствующей организации кода OS.

А APIC Error прерывания можно отключить/замаскировать (как минимум в Release версии) за ненадобностью. В корректно спроектированной системе они никогда не должны появляться, хотя и могут оказаться полезными во время разработки-отладки подсистемы межпроцессорных взаимодействий.


То есть по финалу, можно сказать, что систему можно спроектировать и реализовать таким образом, что ни spurious ни error прерываний в ней не будет. Соответственно и обработчики для этих прерываний будут не нужны.

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

А есть где посмотреть? Может быть вы знаете, где можно взять какие-нибудь детальные мануалы?