Реальный режим DOS - непонятки

важно не то, как получена совместимость, а то, что она есть
тем более, что вопрос спорный
A20# является одним из сигналов системной шины
устройство шинного интерфейса - часть ядра процессора, поддерживающая этот сигнал
не важно, что источником его генерации является внешний по отношению к процессору компонент чипсета
если бы в ядре процессора не была предусмотрена определенная реакция (сброс старших разрядов) на этот сигнал, а функциональность достигалась засчет обычного механического воздействия на адресную шину (& 0), то тогда можно было бы говорить о полной эмуляции семантики 8086 внешними средствами

это логично
DOS - ОС реального режима, естественно не будет работать в защищенном
тут вполне естественно появление v86

лучше поздно, чем никогда

мы уже на этот счет спорили
VMWare вполне себе не эмулятор, кроме того не использует (хотя в новых версиях уже использует) аппаратную виртуализацию и работает довольно быстро
единственное, это досадная оплошность с SIDT

 

rei3er

Чушь. Интел перекладывает заботу на чужие плечи, а не сама делает то, что должна была бы сделать.

Не знаю, как это реализовано в современных процессорах, но в 80286 линия A20 "убивалась" именно совершенно внешней по отношению к процессору схемой.

Так не работала не только ДОС, не работало любое ПО, созданное для ДОС! О какой совместимости можно говорить?! Т.е. Интел забила большой и железный не только на совместимость на системном уровне, но и на чисто прикладном.

Но лучше -- всё-таки сразу. Тем более что у Интела было, на что ориентироваться: все эти вещи в разных вариациях уже многократно проходились в предшествующие три десятка лет.

Этой "досадной оплошности" вполне достаточно, чтобы лишиться гарантированной эмуляции даже отнюдь не "извращённого" софта.

А вообще, чего спорить-то? Если кому-то хочется считать, что IA-32 -- чудесная архитектура, я ничего возразить не могу: о вкусах не спорят. Хотя по мне -- отстойней трудно найти.

А начали, напомню, с того, что я предупредил человека о некоторых тонкостях адресации в реальном режиме, связанных с A20

 

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

 

rei3er

Тем не менее, с суммированием адресов отнюдь не понятно: логичнее было бы сохранить полную совместимость с 8086, а не "дарить" дополнительные почти 64 Кб памяти.

Кстати, можете вспомнить ещё инструкцию NOT, которая не изменяет флажки, хотя логично было бы предположить, что она их должна изменять, как и любая другая команда обработки данных. Судя по всему, тоже ошибка разработчиков, которую они вовремя не заметили.

Скорей всего, причина -- в обыкновенной халатности. Делали как попало, не особенно задумываясь. Тем более что с архитектурой защищённого режима явно перемудрили, вот и потратили все силы, что были, на ненужную аппаратную многозадачность и прочие "мегафичи".

Здесь можно вспомнить не только NOT, но ещё и ошибки в сопроцессорах. Ведь не только в пентиуме был глюк (о котором из обретающихся на здешнем форуме, думаю, многие если не знают достоверно, то хотя бы слышали), но ещё и в 80387 -- тоже что-то там неверно выполнял, из-за чего тоже был скандальчик среднего калибра...

 

да, если подумать логически, то ZF должен изменяться
кстати, с SGDT, такая же проблема, как и с SIDT
но вообще говоря, это все косметические ошибки и о стройности/нестройности архитектуры по ним по большому счету судить нельзя

 

наверно имелось в виду 80486?

P.S. точнее ошибка в вычислениях с плавающей запятой.

 

rei3er

Зато о стройности архитектуры (а точнее, об отсутствии таковой) легко судить по использованию регистров, гордо называемых "регистрами общего назначения". Посудите сами:

-- для хранения компонентов адресов (базы и/или индекса) можно использовать только четыре регистра из восьми (SP всё же входит в число РОН, поэтому смотрим и на него тоже): BX, BP, SI и DI;

-- в строковых операциях используются в обязательном порядке регистры SI и DI, иногда -- AX или AL;

-- в командах умножения и деления один из операндов обязательно находится в AL, AX или DX:AX;

-- в командах цикла и многоразрядного сдвига, а также префиксах повторения счётчиком может быть только регистр CX;

-- побайтно доступны только AX, BX, CX и DX, к другим регистрам побайтовый доступ невозможен;

-- в командах ввода-вывода используются регистры AX и DX.

Ну и сравните это с, например, Z8000, который появился примерно в то же время, что и 8086 (конец 1970-х), и к моменту создания IBM PC был уже достаточно широко известен. С регистрами там дело обстоит примерно так (пишу по памяти, мануал доставать лень):

-- имеется шестнадцать регистров, пронумерованных с 0 до 15;

-- имеется возможность доступа к младшему байту каждого регистра, а также объединения регистров в пары и четвёрки для хранения операндов соответствующей разрядности; ограничение -- кратность номера первого регистра соответствующей величине (т.е. 32-разрядные величины хранятся в регистровых парах 0, 2, 4 и т.д., а 64-разрядные -- 0, 4...);

-- все команды (кроме, может, каких-то привилегированных) используют регистры в качестве операндов совершенно равноправным образом, т.е. если можно использовать регистр 0, то можно и любой другой;

-- компоненты адресов могут храниться во всех регистрах, кроме регистра 0. Если в коде команды на месте регистра, содержащего компонент адреса, содержится 0, это означает, что соответствующий компонент равен нулю (вполне логичное ограничение; такой же механизм был принят в мэйнфреймах IBM, но бывали и машины, где и такого ограничения не было -- например, PDP-11 и VAX-11);

-- указателем стека является регистр 15 или регистровая пара 14:15 (последний случай соответствует сегментированному режиму работы микропроцессора -- отдельных сегментных регистров он не имеет), но в плане любых операций, кроме прямо связанных с аппаратным стеком, он равноправен с прочими регистрами.

 

t00x

Насчёт 486 я не помню, но вот про 387 -- помню. Читал про это статью, если память не изменяет, в одном из первых номеров "Мира ПК", а может, ещё где... Интернета у нас тогда ещё не было вовсе, да и на Западе он только-только появлялся, так что не уверен, что инфу об этом можно легко найти в сети.

 

SII
многое объясняется "экономичным" форматом инструкций
хотя тут с вами не могу не согласиться

 

rei3er

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

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

 

При такой системе команд как у машин DEC процессор может представлять (и часто представляет) собой простое ПЗУ. Кстати большинство отечественных ЭВМ имели и имеют такую систему команд. Система команд ПЭВМ МежДелМаш действительно далека от совершенства, но следут учесть что они и не задумывались как полноценные ЭВМ и вошли в массы не благодаря своим преимуществам или недостаткам, а благодаря умелой политике разработчиков.

 

Vov4ick

Простое ПЗУ точно представлять не может -- слишком много комбинаций помнить надо. Но что он получается весьма простым -- это точно.

 

Может, набор команд небольшой. Одна из таких машин - микрокомпьютер Электроника МК90, совместимая с PDP-11 по набору команд. Её процессор состоит из четырёх микросхем ПЗУ и одной АЛУ. Регистры просто отображаются в память.

 

Vov4ick

Знаю такие машины. Но, во-первых, уже имеем не только ПЗУ, но ещё и АЛУ. А во-вторых, эти ПЗУ включают в себя кой-какую логику для реализации микропрограммного управления и т.п., т.е. это не "чистая" память (насколько помню, именно так).

 

SII

я тут подумал и понял, что "оплошность" с SIDT в принципе устранима, и даже легко
смотри
можно просто всегда отображать хостовую IDT по адресам в контексте VM
в соответствующем PTE сбрасывать бит U
дальше перехватывать #PF при любом обращении к IDT
в обработчике временно восстанавливать хостовое значение IDTR, а также изменять PTE таким образом, чтобы он указывал на действительную физическую страницу, где расположена гостевая IDT
дальше выполнить инструкцию и произвести обратные действия
при вызове LIDT переотображать хостовую IDT по указанному в операнде адресу

 

rei3er

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

Но это ещё не всё. Предположим, гостевая система загружает в CS или другой сегментный регистр нужное ей значение -- и естественно, оно оказывается недопустимым с точки зрения системы-хозяина. Сфальсифицировать значение, подкорректировать таблицу дескрипторов и т.п. она сможет. Ну а если через несколько команд гостевая ОС выполняет, например, длинный CALL? В стек попадёт уже неверное с точки зрения гостевой системы значение сегментного регистра, что может либо привести к прямой ошибке (например, гостевая система использует поля сохранённого селектора для какого-то анализа), либо проявиться позднее, когда будет выполнен возврат из подпрограммы (система-хозяин к тому времени вполне может отобразить на тот же липовый селектор совершенно другой сегмент гостевой системы: селекторов-то, доступных для использования гостевой системой, значительно меньше, чем потенциально возможных).

Можно вспомнить и регистр флагов. Помнится, POPF может изменить значение IOPL только при работе в режиме системы, однако никаких прерываний не происходит: просто поле IOPL не меняется. Как с этим будет система-хозяин бороться?

 

похоже, только GDT
с ней можно точно таким же образом поступить

да, про легко я погарячился
скажем так, становится возможным

почему?
сохранится правильное значение CS, потому что в самом CS будет правильное значение до выполнения call
первое, что необходимо сделать - реализовать механизм, при котором любая инструкция записи в сегментный регистр вызовет исключение
для конкретной хостовой системы известны дескрипторы GDT/LDT и их DPL
при переключении контекста на процесс, реализующий виртуальную машину, сбрасываем DPL каждого дескриптора
т. к виртуализация происходит при CPL = 0, этим можно достичь нужного эффекта
в обработчике исключения по селектору (найденного по операнду инструкции записи в сегментный регистр) записываем в хостовую GDT/LDT дескриптор (валидный с точки зрения гостевой ОС) и меняем селектор в стеке
также при необходимости корректируем таблицы страниц
при возврате из обработчика CS полностью (и селектор, и дескриптор) валиден
тут есть один тонкий момент
необходимо каким-то образом отслеживать переключение контекста в хостовой ОС
(чтобы восстановить таблицы)
думаю, этто можно сделать модификацией кода функции планировщика (или другим способом)

первое, что в голову приходит, поиграться с DPL дескриптора сегмента стека
выставить его в 0, тогда выполнение любой использующей его инструкции приведет к исключению
дальше дизассемблировать и т. д

 

rei3er

Поясняю. Ядро гостевой системы делает длинный переход внутри себя. В младших трёх разрядах CS, с его точки зрения, должны быть нули (нулевой уровень привилегий и извлечение дескриптора сегмента из GDT). Естесно, такой переход оказывается запрещённым, поскольку ядро в реале работает на виртуальной машине с третьим уровнем привилегий. ОС-хозяин, проанализировав вызвавший прерывание селектор сегмента, может склепать фальшивый дескриптор; возможно, даже поместить его в GDT на то же место (для этого ядру оси-хозяина надо уметь себя перекидывать с одного сегмента на другой, что технически возможно, но очень геморройно). Однако дать нулевой уровень привилегий ядру гостевой системы нельзя по вполне понятным причинам. Поэтому при сохранении селектора, загруженного в сегментный регистр, ядро гостевой системы получит в младших битах уровень привилегий 3, а не 0, как оно того ожидает. Причём предотвратить это нельзя. Да, можно заблокировать запись куда угодно, но нельзя -- из регистра в регистр. А если гостевая ось выполняет что-то вроде mov ax, cs, а затем что-то делает с этим селектором, при этом будучи зависимой от значения указанных там привилегий?

Кстати, вам не кажется, что если генерировать прерывание на каждый чих, то полная эмуляция будет работать быстрее подобной "виртуализации"? Хотя бы потому, что обработка прерываний связана с большими накладными расходами?

 

SII
да, похоже с CS засада
тогда остается полная эмуляция нулевого кольца
мне интересно, каким образом тогда возможна виртуализация без специальных аппаратных средств на других архитектурах, которые вы все время приводите в качестве примеров
неужели а них принципиально невозможно находясь на пользовательском уровне получить хоть какую-нибудь системную информацию (наподобие SIDT), что затруднит или сделает невозможным полную виртуализацию?

во всяком случае, обработка происходит аппаратно в отличие от полной эмуляции

 

rei3er

О чём и речь. Уровни 1--3, возможно, и удастся полуэмулировать -- полувиртуализировать, если ещё каких подводных камней не обнаружится.

Если действительно интересуют "интимные подробности", можно пообсуждать (хоть здесь -- всё равно зафлудили, хоть в отдельной теме). Ну а если интересует просто краткий ответ -- то да, в нормальных архитектурах пользовательская программа в принципе не может ничего такого сотворить. Конечно, там свои сложности тоже могут возникнуть, но, в отличие от IA-32, они успешно преодолеваются.

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