Просмотр полной версии : Виртуализация ZX
Всем привет, пора переводить активность форума из раздела флейм.
По простому: виртуализация появилась задолго до первых OS-ов для того чтобы на одном компе работали одновременно сразу несколько программ. Для этого комп мог "притвориться" что он не один а их много. Программа работающая на таком компе не знает и не может узнать о других программах работающих тут же параллельно. (Для примера: linux запущенный на мэнфрейме IBM не знает работает ли он 1 на голом железе, либо совместно с другой OS в разных логических разделах, либо в одном разделе но на zVM-е в котором крутятся еще 1000 OS-ов. Кроме того эти самые OS-ы тоже могут быть zVM-ами в которых могут крутится другие zVM-ы а в тех linux-ы...)
Сейчас x86 платформа активно осваивает "виртуализацию", движение началось лет 7 назад и сейчас уже есть довольно неплохие достижения. Между тем IMAK и другие высказывали предложение ввести данное новшевство в спектрум еще в далеких 90-х. Есть даже некоторые наработки в разных клонах (например виртуальные диски в ATM).
Вопросы:
Это нужно? Это возможно для типичного клона? Как это сделать?
Поставить между z80 и всем остальным компьютером какой-нибудь современный скоростной микроконтроллер типа STM32F103, и виртуализировать что угодно, вплоть до маппинга памяти и внешних устройств.
---------- Post added at 16:33 ---------- Previous post was at 16:31 ----------
Ну, это если поставить задачей ни в коем случае не эмулировать процессор.
Поставить PC, и не долбать себе мозк.
NovaStorm
13.10.2013, 15:10
Вопросы:
Это нужно? Это возможно для типичного клона? Как это сделать?
Нет. Нет(без эмуляции). Гипервизору нужна защита от гостя.
Нет. Нет(без эмуляции). Гипервизору нужна защита от гостя.
А если гипервизор - внешнее устройство?
А какова конечная цель сей идеи (имею некоторое отношение к "большой" виртуализации)?
NovaStorm
13.10.2013, 16:16
А если гипервизор - внешнее устройство?
Ну тогда твори, что хочешь. Но если ставить даже мелкий арм, эмулировать становится проще, чем городить что-то ещё.
Ну тогда твори, что хочешь. Но если ставить даже мелкий арм, эмулировать становится проще, чем городить что-то ещё.
А если требуется оставить внешний ZX-Bus, на который хочется вешать устройства? Плюс сам Z80 может и не на 3.5 Мгц работать. Эмулировать 20 МГц z80 на 72 Мгц arm мне видится едва ли не невозможным.
NovaStorm
13.10.2013, 17:03
Ну тогда надо делать(как минимум) аппаратную доработку, MMU, чтобы была память гипервизора и память виртуалок.
А какова конечная цель сей идеи (имею некоторое отношение к "большой" виртуализации)?
А это ещё один хороший вопрос к топику. Что может от этого спектрум получить (snapshot-ы, переключение контекстов между паралельно запущенной isdos и cp/m или играми демами) ?
Про виртуализацию на виртуальном спекки железе просьба не думать, идея не предпологает "профанации". Нет смысла\интереса в навешивании мега-куска силикона на котором можно было бы весь ibm/370 завести только ради виртуализации спектрума.
Нет смысла\интереса в навешивании мега-куска силикона на котором можно было бы весь ibm/370 завести только ради виртуализации спектрума.
Какой-то кусок силикона всё равно понадобится, т.к. при переключении задачи надо считывать текущее состояние регистров процессора и куда-то сохранять.
0. Работает задача T1, пришло время переключиться на T2.
1. Подсунули процессору другую (временную) память, в которой по адресу #0066 (обработчик NMI) лежит процедура сохранения всех регистров в известную область память (пусть она, скажем, кидает всё на стек).
2. Сгенерировали NMI
3. По состоянию M1 и шине адреса отследили когда процедура выполнилась до конца, переложили все значения регистров в удобное место.
4. Выполняем процедуру, восстанавливающую значение регистров для продолжения выполнения задачи T2.
5. Подсовываем процессору память процесса T2.
Всё, переключились.
В п.1 есть вероятность, что указатель стека смотрит на адреса, где находится сама процедура обработки NMI, и придется всё чуть усложнить, подсовывая процессору по M1 код процедуры, не храня его в ОЗУ. В принципе, можно и запись в память точно так же перехватывать, ничего не реальности не сохраняя.
И вот это описанное можно сделать, как мне кажется, только через микроконтроллер. Причем довольно быстрый - всё же ему предстоит заниматься мультиплексированием памяти, а запросы к ней идут с частотой порядка мегагерца.
ИМХО нормальная виртуализация возможна и нужна только в современных клонах, таких как PentEvo.
Памяти много, можно организовать на ПЛИС схему виртуальных адресов и переключения страниц при обращении по нужным RST.
Задача интересная, но и сложная. ПО для такого режима нет.
как доступ к железу разруливать? памяти много, ее можно поделить, а железо - одно.
схему виртуальных адресов
для виртуальной адресации не хватает одной мелочи, исключения у процессора (выскакивают если не прошли какие либо проверки ДО выполнения инструкции)
Схема может подсунуть пустышку вместо памяти, к которой незаконно обращается процесс. Так что проблема не в этом. Проблема в командах IM 0/1/2, DI, от которых невозможно защититься.
А хотя... схема может подменять опкоды во время их чтения.
Нужно или нужно - вопрос 90-х, когда действительно было актуальным запустить на одном спеке несколько системных программ. Сейчас - только и исключительно ради спортивного интереса.
Для з80 есть несколько проблем:
- непростой отлов состояния проца (включенные страницы, IM, стек наконец, который обязан быть в ОЗУ, иначе в задачу не вернемся, хорошо, если не грохнем ядро).
- отстутствие терминации кванта задачи, чтоб вернуть управление ядру или другим задачам, если задача не занимается полезным делом. ОК, можно отлавливать халт, но если задача будет висеть в цикле (опрашивая например клавишу), она будет просто грузить проц и ждать окончание своего заскедьюленого времени.
- банальная слоупочность зетника, которая в сочетании с предыдущим пунктом сильно уменьшит комфорт от работы. Ну допустим, турба, ОК.
- необходимость аппаратной доработки, которая будет а) помогать подменять/сохранять контекст, б) обеспечивать прерывание таски по скедьюлеру (приходит на ум только NMI).
Если очень захотеть, реализовать можно. Например ФПГА может вообще отлавливать все критичные изменения контекста процом (паги, стек, режим ИНТа) и хранить внутри доступными для чтения. Но это какбэ не то, а сделать подобное на ЛА3 - надо куча МГТФа.
---------- Post added at 10:15 ---------- Previous post was at 10:12 ----------
А, еще забыл про периферию. Придется виртуализировать все устройства, та же ВГ93 сойдет с ума, если ее трогать из 1+ задач.
Error404
17.10.2013, 21:07
А, еще забыл про периферию. Придется виртуализировать все устройства, та же ВГ93 сойдет с ума, если ее трогать из 1+ задач.
Как вариант, не виртуализировать - а сериализировать: устроить очередь на входе таких устройств: порезать обращения на неразрывные "кадры", которые выполнять последовательно в очереди. Ну собственно, как делается во всех многозадачных ОС (один хрен какая-то же программная прослойка все обеспечивающая там же будет?).
Если очень захотеть, реализовать можно. Например ФПГА может вообще отлавливать все критичные изменения контекста процом (паги, стек, режим ИНТа) и хранить внутри доступными для чтения. Но это какбэ не то, а сделать подобное на ЛА3 - надо куча МГТФа.
Не проще ли для этих целей заюзать уже готовые решения? Тот же i386, в котором все вышеуказанные проблемы решены? Когда у нас для виртуальных процев (или машин) есть свои адресные пространства, свои пространства портов ВВ. Когда проц может сам это регулировать, оперируя реальным ОЗУ? Естественно не без помощи ОСи? Зачем велосипед изобретать? Я вот к чему. Всё равно в итоге вы придёте к общеизвестным механизмам. На базе Z80 это просто не сделать, в апофеозе, вы всё таки придёте к тому, что было сделано ещё в 1982-м году. К MP/M. Не стоит ли почитать как там это организовано?
---------- Post added at 23:22 ---------- Previous post was at 23:19 ----------
Схема может подсунуть пустышку вместо памяти, к которой незаконно обращается процесс.
Защита ОЗУ в простейшем варианте реализована в Z-280. Когда нельзя обратиться к странице, если у тебя нет прав на неё. Зачем изобретать велосипед? Читаем доки Алоний, читаем доки и учимся. Потом думаем, как это применить и надо ли оно нам?
Я говорю про решения, которые можно применить в ZX Evo. Процессор там заменить не получится.
Тогда советую тебе ознакомиться с ОСями, на Z80, где это уже давным давно реализовано. Да, у них есть недостатки, но они опирались на железо какое? Начала 80-х. У нас сейчас возможности шире. Подумай. Но далее того, что было сделан уйти вряд ли удастся, т.е. будет более красивее но не более.
Powered by vBulletin® Version 4.2.5 Copyright © 2026 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot