alexeiЦитата:
Проблема с PnP и ACPI высосана из пальца. Если даже BIOS окажется не способным сконфигурировать все устройства, Вы можете сконфигурировать их "вручную" (BIOS setup) или подготовить специальный "сервер", который это сделает это при запуске системы.
...
Linux также обычно не пытается делать реконфигурацию PnP
Любая ОС, поддерживающая PnP, имеет полное право переконфигурировать всю аппаратуру по своему усмотрению, и то, что конкретная ОС это не делает, ещё не значит, что это не делает никто. А значит, необходимо обеспечить всем гостевым системам возможность осуществить конфигурирование
виртуальных' устройств, а для этого нужно их эмулировать правильным образом. Так что, извиняюсь, проблема не в начальном конфигурировании устройств (при загрузке системы, реально работающей с аппаратурой, т.е. гипервизора), а в том, что гостевые системы считают, что работают на реальном "железе" со всеми вытекающими.
Цитата:
Но, на самом деле, всё это - совершенно не важно, потому что "химера" строится в соотстветствии с простым принципом: "перехватывает Гипервизор, а эмулируют - Сервера". Таким образом, необходиость преодоления проблем связанных с управлением и распределеним оборудования (если таковые возникнут) не приведёт к усложнению Гипервизора
Похоже, Вы абсолютно не представляете себе, что такое виртуализация и как работает аппаратура. Как ваши любимые сервера будут что-то эмулировать, если эти сервера, как Вы утверждали несколькими постами раньше, могут быть обычными операционками типа Винды или Линуха? Эти системы понятия не имеют о том, что они кого-то должны эмулировать -- они уверены, что работают на реальной аппаратуре, а поэтому будут обращаться к ней, не задумываясь о наличии какого-то там гипервизора. В частности, в процессе загрузки все эти системы будут требовать наличия правильно построенных информационных блоков ACPI, из которых определят конфигурацию оборудования на материнской плате, затем будут настраивать APIC, возможно, перенастроят устройства PnP, подключённые к PCI и другим шинам... Причём каждая ОС-"сервер" будет уверена, что она выполняется на "голом" железе и машина находится в её полном распоряжении, а соответственно, и настройку будет производить под себя. Как Вы эту проблему собираетесь решать, не обеспечив эмуляции всех без исключения устройств, используемых каждой из систем?
Цитата:
С другой стороны, я совсем не уверен, что Как раз управление памятью и разделение процессора не представляют никаких сложностей и реализуются очень просто. Дело в том, что если "обычная" ОС может зафиксировать в физической памяти страницы, которые ей необходимы для обработки системных событий в реальном времени, то все страницы "сервера" могут оказаться выгружены из физической памяти на диск (если не принять специальных мер)
Увы, не сомневаюсь, что для Вас это кажется проблематичным: своё слабое знакомство с "железными реалиями", непонимание многих важных принципов работы аппаратуры Вы уже неоднократно демонстрировали, поэтому я просто вынужден предположить, что и с функционированием виртуальной памяти Вы не слишком хорошо знакомы (если ошибаюсь -- прошу прощения). Не буду тут расписывать, как же осуществляется управление памятью и процессором в таких случаях, лишь повторю, что это по сравнению с управлением устройствами -- сущие пустяки. Правда, эффективность может прилично упасть, ведь обычные ОС, использующие виртуальную память, уверены, что вся память ПК принадлежит им, а поэтому создаваемые ими таблицы страниц гипервизор будет вынужден корректировать под реальное распределение памяти, причём так корректировать, чтобы гостевые системы этого не замечали, а это -- приличные накладные расходы. Как их уменьшить и всё такое прочее, можно обсуждать в отдельной теме, причём скорей в разделе "теоретические вопросы". Кроме того, прежде чем обсуждать подобные вещи, надо сначала понять, что Ваша идея в том виде, в каком она есть, абсолютно нежизнеспособна -- как раз из-за аппаратуры, которую нельзя просто так взять и разделить между различными осями-"серверами".
Цитата:
Кроме того, "сервер" может закрыть прерывания только на своей ВМ, а не на физическом ПК
Вообще-то прерывания запрещают, а не закрывают, но это так -- лингвистические придирки. Однако проблема существует, причём проблема не только с запретом прерываний вообще (установкой или сбросом соответствующего флага), но и запретом конкретных прерываний путём манипуляций с APIC. Ну и как, скажите, Вы будете решать эту проблему без полной эмуляции APIC? Оси-сервера -- они понятия не имеют, что работают под Вашим гипервизором, они уверены, что работают на самом настоящем ПК, с которым могут творить всё, что захотят.
Цитата:
Обычные ВМ виртуализируют всю аппаратуру ПК. Это сильно снижает еффективность гостевой ОС
Сильно -- не сильно, а снижает, тут не поспоришь.
Цитата:
Почему-бы не разрешить гостевой ОС напрямую работать с аппаратурой не используемой хост ОС ?
По одной простой причине: вся' аппаратура ПК взаимосвязана, и "выдрать" какое-то устройство и передать контроль над ним одной системе, а остальные оставить другой, нельзя. Первая из причин: конфликт в настройке адресов ресурсов, потому что ОС
не обязаны' довольствоваться той настройкой, что выполнила BIOS, и могут перенастраивать устройства на свой лад, а это чревато возникновением конфликтов. Вторая причина: есть устройства, которые невозможно разделить. К ним гарантированно относятся APIC, системные таймеры, по крайней мере часть мостов между шинами, контроллеры жёстких дисков (все оси используют жёсткие диски, причём не с помощью каких-то там "серверов", а напрямую обращаясь к аппаратуре); вероятно, сюда же пойдут и хост-контроллеры USB. Ну а поскольку разделить эти устройства нельзя, а они нужны всем осям, то придётся их эмулировать программными средствами (в простейшем случае -- отображать запросы гостевых систем к виртуальным ресурсам на соответствующие физические).
Цитата:
Тогда гостевая ОС будет работать как с виртуальной, так и с физической аппаратурой
Не получится, как уже сказал. С физической можно только в том случае, если эта аппаратура: а) абсолютно никому больше не нужна; б) настраивается всегда стандартным образом. А пункт "б" соблюдается разве что для COM- и LPT-портов, клавиатуры и мыши PS/2 да контроллера гибких дисков.
Цитата:
Таких гостевых ОС может быть несколько (каждой выделена своя часть аппаратуры).
На гостевой ОС может выполняться программа-емулятор, которая виртуализирует выделенную ей аппаратуру для других гостей.
Получается, что гостевые ОС могут снабжать друг друга виртуальными ресурсами
Только вот гостевые оси понятия не имеют, что кто-то их снабжает "виртуальными ресурсами" -- им подавай реальные
шины и контроллеры (ну или их точную программную эмуляцию). Так что никак Вы не сможете "виртуализировать" аппаратуру для "других гостей" -- эти "другие гости" сначала должны уметь пользоваться виртуализированной аппаратурой.
Цитата:
Нужно иметь "схему соединения" ВМ в общую систему и "план распределения аппаратуры"
Угу, только Вы забываете про один малюсенький нюанс: ни одна из обычных осей не знает ни о каких "схемах соединения" и "планах распределения аппаратуры". А значит, Ваша идея будет работать только в том случае, если "серверами" будут специально' написанные под Ваш гипервизор системы. Что фактически превращается в разработку традиционной ОС с микроядерной архитектурой.
Цитата:
Рассмотрим крайний случай с двумя ВМ. Вся аппаратура у одной ВМ (А), а у другой ВМ (Б) вся аппаратура виртуальная, обеспечиваемая эмуляторами, выполняющимися на ВМ-А. Схема, очевидно работоспособная.
Теперь заберём физический дисплей у ВМ-А и отдадим его ВМ-Б, добавив к её ОС программный эмулятор SVGA
Похоже, Вы не заметили противоречия у самого себя. Схема, когда всё реальное "железо" у одного, а другой (или другие) пользуются только виртуальным -- действительно работоспособна. Только эти виртуальные "железяки" придётся эмулировать, что Вы, собственно, и сами говорите, например: "добавив к её ОС программный эмулятор SVGA". Вот и получается, что "добавив" всюду программные эмуляторы всех железяк, мы получим работающую систему виртуальных машин. Только здесь одно "но": либо вся эмуляция сосредоточена в гипервизоре, либо сервисы, осуществляющие эмуляцию, являются специально написанными, а отнюдь не стандартными осями, к чему Вы призывали в самом начале. В любом случае всё сводится к разработке полной операционной системы.
Цитата:
Неужели и теперь не врубились?
С полным основанием переадресую этот вопрос Вам :)