Благодарю за ответы. Попробую ответить на возникшие вопросы: В соответствии

Благодарю за ответы.
Попробую ответить на возникшие вопросы:
В соответствии с тегами в качестве подопытного был выбран Award BIOS от платы Q35M-S2 . Версия F7. Чипсет - Q35 (в официальной ветке QEMU уже года 2-3 в качестве альтернативы 440-му). Собственно решение задачи запуска реального BIOS на QEMU сводится именно к дописыванию в QEMU недостающей функциональности. В частности в QEMU был неполностью реализован механизм PAM. Из-за этого BIOS зависал сильно раньше. После самодельного исправления - появился определенный прогресс. Очередной затык случился на описанном выше месте. Так как никаких изменений в BIOS не вносилось, то не работать сам по себе он не может, но, зато, QEMU может некорректно имитировать реальную систему, что тут, очевидно, и произошло. Также, все значения которые есть в ОЗУ и в регистрах являются следствием работы QEMU и BIOS, вручную никакие области памяти не менялись.

Переходы в 0xe8000 случались и раньше, но конфигурация PAM была другой, обрабатывался код из ОЗУ. Сейчас исполняется код из флешки и есть мысль что тут что-то не так, как надо. Очередная идея - автор BIOS рассчитывал на те инструкции, которые попали в кэш (в самом QEMU кэш как сущность не очень заметен). Но, во-первых: как это проверить, во-вторых: странным выглядит рассчет на то, что некие данные должны быть в кэше (а если их нет, а если было прерывание и т.д....).
Гугление по адресу 0xe8000, как и по ioport 0xA2 ничего не принесло -не удалось найти упоминаний о том, что это какие-либо особенные значения.
QEMU сейчас вполне корректно интерпретирует значения записанные в PAM и перенаправление в PCI вполне законно с точки зрения логики работы PAM регистров. Но есть подозрение что на маппинг может влиять что-то еще. Что именно - пока не знаю. Думал в сторону MTRR регистров проца, но там задается только политика кэширования, конкретно ремаппингом эти регистры не занимаются.