elve писал(а): ↑24.06.2011 14:53
В связи с этим вопрос - верно ли у меня указано, что ядро dom0 должно обращаться к PCI через XEN?. Может лучше выставить Direct Access? Гипервизор с ядром при этом не подерутся за доступ к устройствам?
не подерутся, т.к гипервизор к pci, равно как к остальным шинам ввода-вывода, прямого отношения не имеет, все управление устройствами выполняется драйвер-доменом, который чаще всего есть dom0. соответственно, при конфигурации ядра dom0 нужно ставить CONFIG_PCI_DIRECT=y, для конфигураций domU - возможны варианты
... я не до конца понимаю как взаимодействует гипервизор с ядром
гипервизор - суть планировщик процессора и памяти, а также acpi в смысле энергопотребления, если это указано в конфигурации. конфигурацией же определяется управление другими acpi-ресурсами, при наличии аппаратной поддержки vt-d (intel) или аналога от amd. гипервизор работает на уровне ядра (protection
ring0). согласно правилам собственного планировщика, гипервизор выделяет кванты времени для работы управляемым ресурсам, называемыми в xen доменами
каждый домен, кроме виртуального процессора, наделяется некоторым фиксированным объемом физической памяти. по поводу памяти - есть варианты, т.н memory ballooning, когда память одного домена, может передаваться другому домену с помощью гипервизора: balloon - воздушный шарик с памятью, который может сдуваться и накачиваться, таким образом подпитывая памятью домены. в xen memory ballooning реализован только для dom0, причем только в сторону "сдувания": при старте системы вся память находится у dom0, а по мере старта domU, memory balloon dom0 отдает память стартованному домену. при завершении работы domU, память в balloon dom0 не возвращается и остается под управлением гипервизора. в настоящее время делаются попытки более эффективного управления памятью в xen: технологии memory overcommit (когда сумма памятей всех работающих domU больше объема физической памяти машины). кажется, это только эксперименты - по крайней мере "живьем" я такого никогда не видел. понятно, что говорится только о физической памяти, понятия swap в xen нет, по причине того, что ни с какими внешними устройствами гипервизор не работает
со стороны доменов обращения к гипервизору бывают явные - позволяется только привилегированным доменам: dom0 и/или driver domains) через xen api, на практике реализованный административными утилитами xm (xi для xcp) или, для xen 4.1+ - xl, а также - libvirt (практически никогда не пробовал). кстати, ресурсы системы кроме как внутри xen, отображаются в dom0, в том, что называется xenstore, и в этом складе, кроме того что знает только xen, есть и специфичные вещи для конкретной инсталляции - устройства ввода-вывода. там есть данные - какому domU что делегировано
обработчики прерываний регистрируются при старте dom0, и драйвер-домена, который управляет делегированными устройствами
неявные обращения к гипервизору, это системные вызовы (попытка выполнения привилегированных инструкций) операционных систем доменов. xen поддерживает два типа domU
- паравиртуальные или pv
- аппаратной виртуализации, hvm
также могут комбинации pv и hvm. паравиртуальные domU не управляют ничем физическим, и управляются операционной системой, которая "знает" о том, что работает под управлением гипервизора. это "знание" - прежде всего подмена системных вызовов (выполнение прилегированной инструкции) обращением к гипервизору. например,
системный вызов номер 1, который должен обращаться к ядру domU, подменяется на обращение к гипервизору
гипервизор, получая это обращение реализует его либо самостоятельно (трудно придумать пример в случае xen, разве что получения значения hardware clock), либо - вызывает ядро domU обычным call, т.е без изменения аппаратных контекстов. кроме этого, к неявным обращениям к гипервизору относятся программные прерывания
для hvm ничего ничем не подменятеся, однако требуется аппаратная поддержка vmx. в этом случае гипервизор после старта работает в режиме vmx, а ядро операционной системы domU ничего не подозревая работает себе в ring0. при попытке выполнения привилегированной команды в ring0, управление передается гипервизору, на vmx-уровень, где выполняется примерно описанное для pv domU. в современных процессорах, появилась аппаратная технология nested paging, которая теоретически позволяет делать описанное рекурсивно, например выполнять гипервизор под управлением гипервизора с любой степенью вложенности
hvm domU в xen могут, если требуется для работы, использовать qemu, который нужен для виртуализации i/o: qemu имитирует сетевые карты, дисковые контроллеры, а также видео-адаптер domU. при наличии в процессора поддержки аппаратной виртуализации vt-d (есть аналог у amd - не помню как называется), hvm domU можно передать управление реальным устройством, таким образом необходимость в использовании qemu теоретически отпадает