OSDev

А по-моему наоборот PIC обычно программируется в таком режиме, когда прерывания с меньшим номером (более приоритные) блокируют прерывания с большим номером, поэтому без EOI в обработчике IRQ0 прерывания от клавиатуры обрабатываться не будут. Я не понимаю одного, автору топика сместить "базу" за зарезервированный диапазон 0-0x1F религия что ли не позволяет? Или он это уже сделал? Если да, тогда твое предложение неуместно. Если нет, что ему мешает это сделать?

Да, я перепутал приоритеты, клавиатура отменяется.
А автору можно добавить только, что раз проходят прерывания PIC, значит APIC "недопрограммирован", он работает в режиме совместимости с PIC.

В некотором смысле да. По моему мнению, ядро не отвечает за IO APIC с одной стороны (модульность, портируемость). И с другой стороны должно быть готово к разгендяйскому поведению программ программирующих IO APIC. Поэтому задача ставиться таким образом: нормально работать, при любом режиме работы IO APIC. Перепрограммировать IO APIC я могу в загрузчике, но это стабовый загрузчик, и в идеале он должен разрабатываться полноценно и не обязательно разработчиком ядра.

В целом мало что понял. Чтобы аппаратура нормально работала, ей нужно нормально управлять. Не хочешь программировать в ядре, программируй в драйвере или загрузчике - дело твое, только где-нибудь все-таки сделай это. Прерываниями должно управлять ядро, непосредственно или опосредованно. "Разгендяйские" программы программировать I/O APIC не должны, иначе получится "разгендяйская" система.

Извиняюсь, что снова обращаюсь к этой теме. Как я понял, изначально IO APIC был сконфигурирован так что для системного таймера использовал восьмое прерывание. Проблема разрешилась явной маскировкой всех прерываний на его стороне. Однако возник другой вопрос: в коде инициализации я повышал "приоритет задачи", то есть писал в регистр TPR Local APIC-а значение 0x1F, что по документации Intel должно было заблокировать получение прерываний с приоритетом ниже второго (то есть 0x00 - 0x1F). Однако проблему с системным таймером это не решало. VmWare не могли бы проигнорировать нормальную реализацию этого регистра, т.к. он используется большинством операционных систем для изменения уровня IRQ. Так вот собственно вопрос: чего я не понимаю и почему манипуляции с TPR не приносят желаемого эффекта?

P.S.:To phantom-84
Ядро проектируется как отдельный, самодостаточный, неубиваемый модуль. В каких условиях он будет применяться неизвестно. Кто будет прогать драйверы и другое системное ПО тоже вопрос. Однако требуется спроектировать ядро таким образом, чтобы было невозможно его вынести никаким способом кроме аппаратного. Соответственно никакие действия совершенные целенаправленно или не целенаправленно не должны нарушать работу операционной системы в целом, они могут нарушить работу какой-либо подсистемы, вынести кусок ОСи, но не всю. Тем более, что система предполагается как долгоиграющая с динамическим обновлением, поэтому фактор накапливающейся ошибки будет играть важную роль. В общем ядро должно представлять собой абсолютно надежный черный ящик имеющий зависимость только на процессор.

Очень хорошо! Только для идеального микроядра нужны другие контролирующие подсистемы - в них или через них нужно управлять аппаратурой. Например, можно сделать менеджер системных модулей, который бы их загружал и связывал между собой, тогда ядро при загрузке может опираться на настройки аппаратуры, выполненные другой службой или обращаться к ней самостоятельно. У меня вообще монолитное ядро (модульное), но оно тоже является независимым и еще более самодостаточным модулем, хотя конечно существуют разные его вариации (оптимизированные под опред. процессоры и другую базовую аппаратуру).

Да-да-да. Так оно и происходит. Определенные функции вынесены на уровень системных служб (управление памятью, системный таймер и т.д.). Однако рассчитывается, что системная служба не может нарушить работу ядра. Например, хоть управление памятью и вынесено за пределы ядра, первичное управлении осуществляется в нем, но оно решает только две задачи: защищает память ядра (чтоб никто не мог его поломать) и следит, чтобы страницы памяти не "потерялись". То же самое и с прерываниями.

Так что вы думаете по-поводу TPR?

По поводу TPR ничего не знаю. Но по поводу распределения прерываний IOAPIC обрати внимание на последнее предложение из спецификации.

7:0 Interrupt Vector (INTVEC)—R/W: The vector field is an 8 bit field containing the interrupt
vector for this interrupt. Vector values range from 10h to FEh.

Что делает отображение 1 к 1 прерываний для IRQ 0...Fh невозможным в принципе.

Vmware Workstation - невозможное возможно!

P.S.: Я просто еще не тестил на реальном железе. В шаге от этого. Осталось только приобрести KVM :)

Мне удалось найти корень проблемы с TPR. Как выяснилось на практике, при сочетании однопроцессорный хост + VmWare. Создается ситуация, в которой APIC отсутствует в системе. Похоже на то, что VmWare в таком случае отказывается эмулировать APIC, причем как процессорную так и материнскую часть. Материнская часть не эмулируется вовсе, в то время как процессорная часть эмулируется частично. Например при записи значения в регистр TPR автоматически изменяются значения регистров PPR и APR, но в то же время это значение никак не влияет на прием прерываний процессором, регистры ISR, TMR и IRR не отображают картины обслуживания прерываний (всегда равны нулю). Регистр EOI бесполезен. Для того чтобы подтвердить завершение обработки прерывания нужно напрямую писать в порт PIC-а. Похоже ребята из VmWare решили не заморачиваться над виртуализацией процессора из расчета на то, что Linux чрезвычайно консервативная ОС и еще лет двадцать будет поддерживать железо выпущенное до революции (в том числе PIC), а Windows традиционно носит с собой четыре ядра, два из которых рассчитаны на допотопные системы такого рода и, соответственно, сможет загрузиться под виртуальным окружением.

Исходя из этого несколько вопросов к знатокам:
1) Возможны ли реальные многопроцессорные системы без APIC-а от 1995 года выпуска
2) Может быть систему APIC нужно как-то явно включать/программировать?
3) Неужели все до сих пор разрабатывают из расчета на PIC и никто не использует для тестирования виртуальные машины (ту же VmWare)?