Чем загрузчик в виртуальных процессорах отличается от реального? Какой жизненный цикл запущенной ОС на виртулальном?
Запуститься ли обычная ос на виртуальном процессоре(не понимаю как это протестировать. так как образы ос для виртуалок, чет немного другие, а что в них другого в этом вопрос)
Не могу понять пару моментов. С распределением обязанностей.
Какой жизненный цикл у запущенной виртуалки. Там не так много основных действий. Вот не могу понять на счет распределения, что чем выполняется. Виртуальным процессором, или операционной системой запущенной на нем. Типа в чем отличия уровня ядра Ос и ядра виртуальной ос.(типа само ядро может же, сам вирт. процессор выполнять его логику)
Для аналогии с виртуальной машиной. Вот есть виртуальная машина, допустим JVM
Там логику "прерываний" выполняет сам код jvm.
Планировщик процессов так же написан на с/с++ и выполняется там.
Модель памяти, так же реализует логику сама jvm.
Для меня все понятно.
А для виртуального процессора.
Кроме системных инструкций io
Все это должен выполнять машинный код операционной системы, а процессор и знать не должен об этом, то есть код входного файла? Так ли.
Все ли инструкции должны быть аналогичными.
Точно не все, к примеру в qemu память выделяется динамически. А значит. Ram может расти. А в реальности, я не могу взять и RAM увеличить в 2 раза по команде. Значит есть инструкция, new которая берет и из неоткуда(с точки зрения вирт ос) берет память.
Вопрос. Что это за команда?Точнее, что за технология. Кто ее источник, код файла .img ассемблера, или си++ код реализации архитектуры программы. С какими-то высокоуровневыми инструкциями замены. Типа вижу такую комбинацию команд, заменяю на malloc(...);
И как вообще в виртуальных процессорах память выглядит. Реальная память virtСpu для внешней среды это сплошной массив, по типу byte[] mem=new byte[], как реальная RAM; Или это набор регионов различной длины в произвольных местах?
И таких наверное еще пару вопросов. но забыл их. К примеру, что происходит.
1.Запускаю вирт. процессор x86,
2. С образом windows в ней. и резервирую 2 гб.
3. И запускаю внутри Программу, с сегментом .bss .zero 2гб размером. И с кодом выделения памяти из кучи в добавок.
Вот что происходит для программы, какой будет порядок загрузки для .exe файла.
Как будет выделятся память, или будет распределяться. Вот сегмент .data .bss .text как для них выделяется память, кто ее выделяет Код ОС или Сpu?(В принципе может любой, но как это реализовано в qemu virtualbox....)
К примеру случай А, если памяти внутри хватает, то сама ОС, сделает то же самое что оператор new c точки зрения эмулированной ОС? И вернет память и указатель на начало из внутреннего сплошного массива памяти RAM(виртуальный адрес на страницу, которая указывает на ram).
Или же, будет вызов системной функции, и управление перейдет virt CPU, который то же самое проделает, но вернет регион памяти, который как бы не в том же массиве RAM, а за его пределами. (Но ведь это роли не играет). И выполнит в разы быстрее. так как это вызов функции, а не получения этой же функции, путем чтения кучи ассемблерных команд.
А так же, что обстоит с созданием, обновлением, выделением виртуальных таблиц памяти. Кто этим занимается. вирт процессор или ос на нем. Ведь опять же с точки зрения эмулируемой ОС, это куча прерываний, куча инструкций, а на уровне эмулированного процессора это одна функция. которую можно вызвать по какому-то одному специальному прерыванию в коде ядра эмулированной ос. Хандлер которой будет не в таблице прерываний, а в коде процессора.
1. Современные системы виртуализации используют реальный процессор. Есть конечно и системы, которые эмулируют процессор программно, но это когда речь идет об эмуляции между архитектурами - например, код для ARM запускают на x86.
2.
так как образы ос для виртуалок, чет немного другие, а что в них другого в этом вопрос
отличия в драйверах. "Обычная" ОС должна работать в виртуализации без проблем.
3.
А значит. Ram может расти.
Не вполне верно. Верхний предел RAM задается при старте машины. RAM можно уменьшить, но не увеличить.
Для современного процессора, выполнение гостевой ОС - это выполнение обычной программы, просто в какие-то моменты он перехватывает обращения к железу и подсовывает туда код гипервизора. Если же мы говорим о программной реализации процессора, то памятью может быть просто массив байтиков.
Запуститься ли обычная ос на виртуальном процессоре(не понимаю как это протестировать. так как образы ос для виртуалок, чет немного другие, а что в них другого в этом вопрос)
Есть разные варианты виртуализации.
Если мы виртуализируем всё железо - это предназначено именно для запуска ОС, ничего не знающей о виртуализации. Но за виртуализацию всякой периферии (вроде дисков и сети) расплачиваемся снижением производительности.
Можно не виртуализировать периферийные устройства - но тогда гостевая система должна уметь работать с такой периферией. Если ОС не знает как работать с диском - то она банально не сможет загрузиться.
Может вся ОС быть в режиме паравиртуализации
Точно не все, к примеру в qemu память выделяется динамически. А значит. Ram может расти. А в реальности, я не могу взять и RAM увеличить в 2 раза по команде. Значит есть инструкция, new которая берет и из неоткуда(с точки зрения вирт ос) берет память.
То что вы упускаете: виртуального процессора не существует.
Управление памятью же... Хе-хе. Если не сильно ошибусь в исторический экскурс, то в прошлом году исполнилось уже 50 лет с тех пор как память в x86 перестала работать так наивно, как вы описали. https://en.wikipedia.org/wiki/Virtual_memory
malloc гигабайтного куска памяти уже очень давно не даёт гигабайтный кусок непрерывных адресов в физической RAM. Фактически, malloc сейчас вообще не даёт память, а только обещает её дать позже. Куда и как эта память будет распределена по физической RAM - да фиг его знает, этим управляет операционная система. Виртуализация соответственно возводит сложность управления виртуальной памятью в квадрат. Это может быть как двойная работа - сначала гость в том что считает своей RAM распихивает всё что есть как нравится, затем гипервизор ничего не зная о алгоритмах управления памятью в госте распихивает занимаемую гостем память по своей виртуальной памяти. Или это может быть какая-то кооперация.
Виртуальная машина jvm и виртуальный процессор того же qemu это очень разные вещи.
Qemu буквально эмулирует физическую машину со всеми ее устройствами, есть полная эмуляция для запуска иной архитектуры и аппаратная, когда в процессоре есть специальные инструкции, помогающие в этом, т.е. код запускается на настоящем процессоре но с вызовом прерываний на определенные операции, либо запрещающие либо эмулирующие проведение (ты вызвал инструкцию, вместо ее выполнения вызывается код вм и делает всю необходимую работа так чтобы не допустить выход в чужие области памяти или симулировать работу инструкции).
Память в qemu виртуальной машины может быть полностью эмулированой, например помню были патчи, шифрующие и расшифровывающие страницы памяти по мере доступа к ним.
По умолчанию вся память выделенная вм будет использована (на самом деле до первого доступа вм к ней) поэтому если внутри вм выделить и освободить память, обратно на хост системе она не освободится, но можно установить драйвера внутри вм , которые будут об этом сообщать в хост там она будет освобождаться, позволяя нескольким вм 'использовать' больше памяти чем доступно, в.т.ч. используя своп файл подкачки.
Простой
