Какая же связь между гипервизором на «голом железе» и операционной системой, на которой он находится, с системными вызовами?

Я много читал о гипервизорах на голом железе, но так и не понял, как они взаимодействуют с ОС, которую они размещают.

Предположим, у вас есть Unix на голом железе. В пользовательском режиме вы не можете прикоснуться к внутренним компонентам ОС или повлиять на них. Вы выполняете задачи с помощью системного вызова, который попадает в ловушку, переводит машину в режим ядра, а затем выполняет эту работу за вас. Например, в C вы можете malloc () создать группу, а затем в конечном итоге исчерпать изначально выделенную память. Если память мне не изменяет, malloc - когда он знает, что не хватает памяти - должен вызвать системный вызов, который, как мне кажется, называется break (). Находясь в режиме ядра, таблица страниц вашего процесса может быть расширена, после чего она вернется, и у malloc () будет необходимая дополнительная память (или что-то в этом роде).

Но если у вас есть Unix поверх гипервизора без оболочки, как это на самом деле происходит? Казалось бы, гипервизор должен иметь фактические таблицы страниц для всей системы (даже для ОС). Таким образом, Unix не может находиться в режиме ядра при выполнении системного вызова Unix, иначе он может испортить работу других операционных систем, работающих одновременно. С другой стороны, если он работает в пользовательском режиме, как код, реализующий break, когда-либо позволит гипервизору узнать, что ему нужно больше памяти, без перезаписи кода Unix?


person eSurfsnake    schedule 03.08.2019    source источник


Ответы (1)


В большинстве архитектур помимо супервизора добавляется еще один уровень, и супервизор несколько ухудшается. Ядро полагает, что оно контролирует машину, но это иллюзия, созданная гипервизором.

В ARM пользовательский режим - 0, система - 1, гипервизор - 2. Intel была немного недальновидна (задыхалась) и имела пользователя как 3, супервизора как 0, таким образом, гипервизор - это что-то вроде -1. Очевидно, это не -1, но это удобное сокращение для чрезвычайно уродливого интерфейса, который они создали для этой обработки.

В большинстве архитектур гипервизор может установить дополнительный набор таблиц страниц, которые вступят в силу после того, как это сделают гостевые таблицы страниц. Итак, ваше ядро ​​unix думает, что оно было загружено на физическом уровне 1M, может быть по любому произвольному адресу, и каждый адрес, который ваше ядро ​​unix считает смежным на границе страницы, может быть разбросан по огромному набору фактических (шинных) адресов.

Даже если ваша архитектура не допускает дополнительный уровень таблиц страниц, гипервизору достаточно просто «уловить и эмулировать» таблицы страниц, созданные гостем, и поддерживать фактический набор полностью прозрачным образом. Однако постоянное движение к более длинным конвейерам увеличивает стоимость каждой ловушки, поэтому таблица страниц дополнительного уровня очень ценится.

Итак, ваша UNIX думает, что у нее есть все 8 Мб памяти; однако незаметно для себя, коварный гипервизор может выгружать эти 8 Мбайт на действительно большой дисковод гибких дисков и выделять ему лишь мизерные 640 Кбайт реальной оперативной памяти. Все обычные unix-y вещи работают нормально, за исключением того, что у них может быть довольно странное чувство времени, когда время замедляется и ускоряется в чередующихся фазах, поскольку гипервизор пытается притвориться, что доступ к гибкому диску 250 мс завершился во время 60нсек драм доступа.

Здесь гипервизоры усложняются.

person mevets    schedule 05.08.2019
comment
Превосходно. Я не знал, что некоторые современные чипы реализуют многоуровневую систему привилегий. Это немного назад в будущее: исторически у VAX / VMS DEC было 4 уровня привилегий, что облегчало выполнение подобных действий, поскольку ловушки могли быть указаны для каждого уровня привилегий. Но я понимаю вашу точку зрения: это всегда может быть выполнено, если не из-за ошибки ОС, а путем тщательного перекодирования системных вызовов на лету. - person eSurfsnake; 09.08.2019