Представлен (https://lkml.org/lkml/2015/5/11/539) второй выпуск (https://github.com/siemens/jailhouse/releases) свободного гипервизора Jailhouse (https://github.com/siemens/jailhouse), развиваемого компанией Siemens. Как и KVM гипервизор Jailhouse обеспечивает виртуализацию на уровне ядра Linux, но отличается от KVM более легковесной реализацией и ориентацией на привязку виртуальных машин к фиксированному CPU, области ОЗУ и аппаратным устройствам. Такой поход позволяет на одном физическом многопроцессорном сервере обеспечить работу нескольких независимых виртуальных окружений, каждое из которых закреплено за своим процессорным ядром. Код проекта распространяется (https://github.com/siemens/jailhouse) под лицензией GPLv2.При жесткой привязке к CPU накладные расходы от работы гипервизора сводятся к минимуму и существенно упрощается его реализация, так как нет необходимости выполнения сложного планировщика распределения ресурсов - выделение отдельного ядра CPU позволяет гарантировать отсутствие выполнения на данном CPU других задач. Плюсом подобного подхода является возможность обеспечить гарантированный доступ к ресурсам и предсказуемую производительность, что делает Jailhouse отличным решением для создания решений виртуализации для задач режима реального времени. Минусом является ограниченная масштабируемость, упирающаяся в число ядер CPU.
В терминологии Jailhouse виртуальные окружения именуются ячейками. Внутри ячейки система выглядит как однопроцессорный сервер, показывающий производительность близкую (https://docs.google.com/file/d/0B6HTUUWSPdd-Zl93MVhlMnRJRjg/...) к производительности выделенного ядра CPU. В ячейке может быть запущено окружение произвольной операционной системы, урезанные окружения для запуска одного приложения и специально подготовленные отдельные приложения, предназначенные для решения задач реального времени. Конфигурация задаётся в .cell-файлах (https://github.com/siemens/jailhouse/blob/master/config/), определяющих выделяемые окружению CPU, регионы памяти и порты ввода/вывода. Для управления изоляцией используются предоставляемые современными CPU аппаратные механизмы виртуализации. Гипервизор реализован в виде модуля для ядра Linux.
Во втором выпуске проведена адаптация гипервизора для архитектур AMD64 и ARMv7 (Banana Pi, NVIDIA Jetson TK1 и Versatile Express). Реализован механизм ivshmem для организации связи между ячейками. Задействованы дополнительные средства изоляции на архитектуре x86. Обеспечена поддержка крупных серверных систем x86. В качестве экспериментальных возможностей реализована поддержка верифицированной загрузки и запуска в ячейках экземпляров ОС на базе обособленных ядер Linux с пробросом устройств PCI (изначально, ячейки были нацелены на запуск обособленных приложений, а Linux мог загружаться только в корневой ячейке).
<center><img src="http://www.opennet.me/opennews/pics_base/0_1384888400.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;" title="" border="0"></center>
URL: https://lkml.org/lkml/2015/5/11/539
Новость: http://www.opennet.me/opennews/art.shtml?num=42207
Годно, надо будет попробовать
А на маке можно будет запустить? Просто на Linux опасаюсь что-либо запускать, да и ставить его боюсь что-то, слишком запутанный он какой-то.. Да и мак понадёжней будет то
А новость прочитать не хотите?
Там же ясно написано, что нужно ядро linix. Правда, даже на такое убогое железо, как мак можно линукс поставить, хотя бы ОС будет там нормальной. Но потом всё равно надо будет покупать нормальный матовый монитор и нормальную удобную клавиатуру с полноценным набором кнопок.
> А новость прочитать не хотите?Глянул другие сообщения персонажа -- похоже, не за тем сюда ходит: http://www.opennet.me/openforum/vsluhforumID3/102407.html#122
Так это очередной Ваня, только из мира Apple.
> только из мира Apple.Вряд ли.
Задача то какая? Дискредитация линуха (ну или просто троллинг. Тупой, но тут уж каков интыклект, таков и троллинг).
С позиции другого конкурента это делать в 2 раза выгодней.
Вон и жабисто-бздишнег например (жабу под бсди то оракл не делает, а опенждк под гпл, но его это под вантузом не смущает) всю "жизнь" положил, чтобы опенсорс на 2 противоборствующих лагеря поделить.
> Задача то какая? Дискредитация линуха (ну или просто троллинг. Тупой, но тут
> уж каков интыклект, таков и троллинг).Ну вот и получается что такие кадры дискредитируют винду и мак. Наглядно демонстрируя что ими пользуются только полные дeбилы. А черный пиар - тоже пиар. Так вот глядишь, технические специалисты посмотрят на все это и сделают выводы куда им :). А даже слоупок стиви таки просек что все решают "девелоперс, девелоперс, девелоперс" :). С чем у мака и винды - не то что не очень. Там с ними - никак. Разработчиков для разработки системы там тyпо не ждут.
>> Задача то какая? Дискредитация линуха
>> С позиции другого конкурента это делать в 2 раза выгодней.
> Ну вот и получается что такие кадры дискредитируют винду и мак.Первое. Раз вопрос возник, значит далеко не все это понимают.
Второе, расчёт то на молодых и/или на не определившихся. С определившимися себестоимость такого процесса не соизмерима настолько, что вообще никого не интересует.
Третье. Не винду и мак, а либо винда, либо мак, либо ещё что (если есть что. ну вот солярщики вроде были с такими же закидонами. Угу, спарки дома их не останавливали). Эта поправка не сильно важна, но существенна.
Технические специалисты потому и стали специалистами, что ориентировались не на пиар, а на логику. Логика же подсказывает, что в любой семье не без урода, а возможности системы важнее сообщества. Не разработчиков, но сообщества. Русскоязычное же Линукс-сообщество выглядит хуже всех других мне известных. Как из-за ненависти ко всем необращенным в их веру, так и из-за элементарного неумения/нежелания вести себя корректно. В результате, за последние началась сегментация среди всей массы на условных детей, которые гадят и условных взрослых, которые пытаются корректировать поведение детей, либо отказываются от взаимодействия с сообществом по вышеописанным причинам. Сколько времени ещё такие как Шигорин смогут вытаскивать сообщество из болота - большой вопрос.Теперь перечитайте свой пост. Скажите, вы любите шоколад? (с)
> Сколько времени ещё такие как *** смогут вытаскивать сообщество из болота -При чём тут "такие"? Когда есть накопившиеся за минимум пару десятков лет проблемы, расползшиеся по головам -- исправлять их получается только самим владельцам голов, осознав и решив.
Скажем, мне в конце девяностых точно так же вправляли мозги разные люди вроде того же Виктора Вагнера, который писал не только технически грамотно, а и грамматически/орфографически/стилистически. На всякое поколение хватает оболтусов, главное, чтоб хоть у кого-то возникала тяга раз уж делать -- так красиво.
> возможности системы важнее сообщества. Не разработчиков, но сообщества
Не могу согласиться: сколь-нибудь сложные системы без здоровых мозгов вокруг -- груда металлолома (или байтолома, если программные).
> Так это очередной Ваня, только из мира Apple.неа, это скучный, тупой и неизобретательный гуанотролль. подвид троллей, которые из еды предпочитают исключительно гуано, и радостно пожирают его в любых объёмах.
> Глянул другие сообщения персонажа -- похоже, не за тем сюда ходит: http://www.opennet.me/openforum/vsluhforumID3/102407.html#122блин.. надеюсь ты не следишь тут за каждым...
ещё ведь и анализ тут сделать умудрился. о как!
> блин.. надеюсь ты не следишь тут за каждым...Это имеет смысл для изучения посылающего противоречивые сигналы с целью попытаться определить, тролит ли, сбит ли собственный компАс, или не найден ли, а вдруг?, уникальный образчик, чистый как слеза, но пишущий Такое.
> ещё ведь и анализ тут сделать умудрился. о как!
Это ещё что, Михаих, 8-O вона, "Аноним"-ов по почеркам {у,распо}знаёт.
Любой дeбил должен помнить как минимум про логи.
В инете никогда ничего полностью не пропадает.
> Любой дeбил долженВ прочтении "Любой аноним должен" наводит на мысли о рекурсии.
Угу. А знание всяких там кукей и тд (ну и наглядной буквы "я" в красном прямоугольнике выше) — нет.
> блин.. надеюсь ты не следишь тут за каждым...
> ещё ведь и анализ тут сделать умудрился. о как!Да тут за собой бы уследить и порой по рукам выдать до отправки... а анализ крайне нехитрый, на него ушло что-то в пределах минуты вместе с поиском и разметкой, помнится: достаточно было в публичную историю сообщений заглянуть.
Такие персонажи по неконкретности высказываний отлично заметны после некоторого навыка. И нет, эта подсказка им не поможет -- если говоришь предметно, то всё тем более становится на места :)
> А на маке можно будет запустить?На Macintosh -- да, на OS X -- нет.
> Просто на Linux опасаюсь что-либо запускать, да и ставить его боюсь что-то,
> слишком запутанный он какой-то.. Да и мак понадёжней будет тоИли пробуйте с флэшки в режиме LiveCD (как собрать таковую с jailhouse -- наверное, даже могу подсказать, но это совсем не "одной кнопкой"), или прекратите мазохизм в виде шараханья по сайтам про _открытые_ системы с предпочтением/рекламой _закрытых_.
Очень много частей OS X являются открытыми
P.S. А за совет спасибо, буду думать, как LiveCD сделать
> Очень много частей OS X являются открытымиМакось - проприетарная система. Там действительно вывален сорц некоторых ошметков (Darwin), но - без драйверов. И к тому же эппл 2 раза закрывал-открывал это с аргументом "хакинтоши жить помешали". После чего все кто не полный имбецил - выводы сделали. И сообщество выводы о перспективах таких взаимоотношений сделало, по сути самоустранившись.
Поэтому де факто макось - проприетарь, от которой местами вывалили исходники. Это разрабатывает по сути только эппл. И там будет только то что надо эпплу. Со всеми вытекающими.
Радует поддержка ARMv7. Это же единственное известное решение для ARMv7?
Embox.
Xen
KVM
qemu
> Это же единственное известное решение для ARMv7?А QEMU/KVM куда дели? oO
Тюрьма-дом - классное название.
просто - тюрьма
/fxd
> Тюрьма-дом - классное название."дом" -- в значении домашнего места обитания хомосапиенса -- "home" .
"дом" -- в значении просто некоторого здания (например стоящего на улице где-то там) -- "house".
"jail house" -- можно было бы перевести как -- "тюремное здание".
>[оверквотинг удален]
>гарантировать отсутствие выполнения на данном
>CPU других задач. Плюсом подобного подхода
>является возможность обеспечить
>гарантированный доступ к ресурсам и
>предсказуемую производительность, что делает
>Jailhouse отличным решением для создания
>решений виртуализации для задач режима
>реального времени. Минусом является
>ограниченная масштабируемость, упирающаяся в
>число ядер CPU.При жесткой привязке к кирпичам, накладные расходы от работы двигателя сводятся к минимуму и существенно упрощается его реализация, так как нет необходимости выполнения сложного вращения колес - холостой ход двигателя позволяет гарантировать отсутствие вращения двигателем чего либо еще. Плюсом подобного подхода является возможность обеспечить гарантированный доступ к ресурсам и предсказуемую производительность, что делает запорожец на кирпичах отличным решением для создания решений перемещения для задач режима потерянного времени. Минусом является ограниченная масштабируемость, упирающаяся в то, что на этой фигне не проехать ни сантиметра.
эй джегит vasa, иды к сэбэ пиши аналог лучше.
> эй джегит vasa, иды к сэбэ пиши аналог лучше.ара зачЭм? Уже есть KVM
> ара зачЭм? Уже есть KVMА знаешь, джигит, есть такая фигня - генератор называется. Ну там бензиновый, или дизельный. Вот ему - ездить совершенно не обязательно! И там все как ты и сказал :). Что не означает бесполезности этого прибора :)
> Минусом является ограниченная масштабируемость, упирающаяся в то, что на этой фигне не проехать ни сантиметра.И зачем дизельгенератору куда-то ехать на своей тяге?
В статье:
> это делает Jailhouse отличным решением для создания решений виртуализации для задач режима реального времениДанный гипервизор сделан не для шаред хостинга с картинками котиков, а для управления промышленными приборами. Для этого управления нужно иметь:
- интерфейс взаимодействия с человеками (экран-клавиатура, SD карты, внешнее сетевое подключение)
- управление одним или несколькими устройствами в реальном времени. Если для работы требуются расчёты в этом реальном времени, то atmega8 уже может не хватать и сименсы используют процессоры по-серьёзней. В этих системах уже много ядер и оперативы. Если создать надёжный способ разделения этих ресурсов между linux и rtos, то можно использовать один вычислительный модуль вместо двух-трёх-пяти. Меньше деталей - выше надёжность.Без Jailhouse можно запускать linux на части CPU и игнорировать диапазоны адресов RAM. Это уже работает. Если устройств и RTOS систем больше двух, работать становится очень не удобно (например - нет защиты памяти linux и остальных RTOS от ошибок в одной из RTOS).
> Данный гипервизор сделан не для шаред хостинга с картинками котиков,
> а для управления промышленными приборами.Спасибо; не хотите дополнить статью?
>[оверквотинг удален]
> - управление одним или несколькими устройствами в реальном времени. Если для работы
> требуются расчёты в этом реальном времени, то atmega8 уже может не
> хватать и сименсы используют процессоры по-серьёзней. В этих системах уже много
> ядер и оперативы. Если создать надёжный способ разделения этих ресурсов между
> linux и rtos, то можно использовать один вычислительный модуль вместо двух-трёх-пяти.
> Меньше деталей - выше надёжность.
> Без Jailhouse можно запускать linux на части CPU и игнорировать диапазоны адресов
> RAM. Это уже работает. Если устройств и RTOS систем больше
> двух, работать становится очень не удобно (например - нет защиты памяти
> linux и остальных RTOS от ошибок в одной из RTOS).Проблема в том, что на интел процах нельзя контроллировать работу кэша, нельзя взять кусочек кэша и закрепить за определённым ядром(возможно, что в новых процах какое-то управление добавили). Без контроля кэша, время отклика и безопасность под вопросом.
Гипервизор все равно должен выполнять трансляцию адресов памяти так или иначе, все равно должен пропускать черезз себя io, и т.д. а значит задержки и гарантии выполнения RTOS быть не может, может быть только максимально оптимизорованная установка, которую с тем же успехом можно сделать и на любом другом гипервизоре поддерживающем cpu pinning. Вон, Windriver вовсю продают решение на KVM, видимо классический RT уже не так сильно завязан на точность времени исполнения.
> Гипервизор все равно должен выполнять трансляцию адресов памяти так или иначеГипервизор должен настроить EPT/NPT, чтобы трансляция адресов выполнялась в железе. Это делается один раз при старте ячейки.
> все равно должен пропускать черезз себя io
Да, если он его эмулирует. Нет, если просто сегрегирует и пробрасывает - опять же, достаточно настроить I/O bitmap и таблицы VTD/AMD-Vi. И это опять же делается один раз.
В общем, если коротко: и Intel (в несколько большей степени), и AMD (в чуть меньшей) за последние пару-тройку лет худо-бедно продвинулись в направлении "Zero VM exits" - в смысле, выполнения гостя с минимальными (желательно, нулевыми) выходами в гипервизор.
Хотя в одном Вы правы - именно по этим причинам KVM не подходит для всех RT-задач. Кое для каких - подходит, и успешно работает. Собственно, если послушать первые презентации Jailhouse, там прямо говорится, что проект запустили после того, как не удалось решить на KVM все имеющиеся задачи.
> Гипервизор должен настроить EPT/NPT, чтобы трансляция адресов выполнялась в железе. Это
> делается один раз при старте ячейки.насколько я помню, все не так просто, особенно при учете NUMA, нестандартных размеров страниц и всяческих методик экономии памяти (ksm, balooning etc)
> Да, если он его эмулирует. Нет, если просто сегрегирует и пробрасывает -
> опять же, достаточно настроить I/O bitmap и таблицы VTD/AMD-Vi. И это
> опять же делается один раз.сегрегация и проброс - все равно имеют оверхед. сейчас как раз работаю над vfio и наблюдаю все эти чудеса
> В общем, если коротко: и Intel (в несколько большей степени), и AMD
> (в чуть меньшей) за последние пару-тройку лет худо-бедно продвинулись в направлении
> "Zero VM exits" - в смысле, выполнения гостя с минимальными (желательно,
> нулевыми) выходами в гипервизор.само собой, и именно поэтому нет смысла городить клоны KVM, с урезанным функционалом.
> Хотя в одном Вы правы - именно по этим причинам KVM не
> подходит для всех RT-задач. Кое для каких - подходит, и успешно
> работает. Собственно, если послушать первые презентации Jailhouse, там прямо говорится,
> что проект запустили после того, как не удалось решить на KVM
> все имеющиеся задачи.объясните мне, в чем принципиальная разница jailhouse и kvm, помимо того что jailhouse сильно отстает по возможностям применения. что такого можно сделать с jailhouse, чего я не смогу сделать с KVM?
> насколько я помню, все не так просто, особенно при учете NUMA, нестандартных размеров страниц и всяческих методик экономии памяти (ksm, balooning etc)Правильно помните. И универсальный гипервизор (KVM, Xen или любой другой) должен это уметь. А специализированный, то есть Jailhouse, не должен - для задач, которые он призван решать, это не нужно. В итоге кодовая база и накладные расходы сокращаются - в этом одна из идей.
> сегрегация и проброс - все равно имеют оверхед. сейчас как раз работаю над vfio и наблюдаю все эти чудеса
vfio - это немножко не проброс и сегрегация, точнее, немножко не те проброс и сегрегация, о которых говорится выше. Речь шла примерно о следующем: вот две сетевушки (а в реальности, скорее - одна многопоротовая). Linux - бери порт 1, ячейка X - бери порт 2, а гипервизор последит, чтобы вы не выстрелили друг другу в ногу. Разумеется, IOMMU добавит накладных расходов, но как вы только что подтвердили, товарищи из Intel, AMD и прочих следят, чтобы они не выходили за рамки разумного. Тесты (и здравый смысл) показывают, что чисто аппаратные расходы существенно меньше, чем то, что добавляет KVM (Xen, ...), который должен уметь намного больше. Для интереса можете снять трейс с KVM, f потом запустить то же ядро в ячейке Jailhouse, и сравнить статистику выходов.
> объясните мне, в чем принципиальная разница jailhouse и kvm, помимо того что jailhouse сильно отстает по возможностям применения. что такого можно сделать с jailhouse, чего я не смогу сделать с KVM?
Объясняю (заодно отвечу на вопрос, зачем городить "клоны KVM с урезанным функционалом"). Принципиальная разница между Jailhouse и KVM, как между пушкой и единорогом: пушка сама по себе, единорог сам по себе. :-) Они не являются клонами друг друга ни архитектурно, ни на уровне кода, и не конкурируют по области применения. Более того, была идея запускать в Jailhouse-ячейках KVM для случаев, когда без него не обойтись - но за эту задачу пока никто толком не брался. Однако, в отличие от KVM, Jailhouse:
- Имеет предсказуемую latency в задачах реального времени, причем меньше ~300 мкс, до которых иногда деградирует KVM. Это удобно для индустриальных задач, телекома, NFV и т.п.
- Относительно легко формально верифицируется (что тоже хорошо для индустриальных применений). Справедливости ради, AFAIK никто не пробовал это сделать, но есть подозрение что заверифицировать ~10 тыс. изолированных строк (вопреки написанному в новости, Jailhouse использует ядро Linux только для загрузки себя, а далее полностью автономен) и связку KVM+ядро Linux (планировщик, virtio и пр.) - это немного разные задачи.Подробнее можно почитать здесь: http://www.linux-kvm.org/images/b/b1/Kvm-forum-2013-Static-P.... Презентация старенькая, но годненькая.
Если задержек KVM вполне хватает (а есть много задач, где их хватает - даже ребята из Siemens, которые задумали Jailhouse, как-то худо-бедно дотянули до 2013 года) и формальная верификация не нужна - то и прекрасно. Мне вот в обычной жизни не нужно ни то, ни другое, так что я неплохо пользуюсь KVM для большинства (ключевое слово) своих задач.
Ну и в качестве резюме для желающих посравнивать KVM и Jailhouse. KVM - универсальный гипервизор, который (поскольку он универсальный) можно с разной степенью успешности доточить до любой задачи, включая RT-виртуализацию. Jailhouse - специализированный инструмент, созданный для того, чтобы хорошо решать одну конкретную задачу. Ни у кого, насколько мне известно, нет идей делать на его базе универсальный гипервизор.
> Правильно помните. И универсальный гипервизор (KVM, Xen или любой другой) должен это
> уметь. А специализированный, то есть Jailhouse, не должен - для задач,
> которые он призван решать, это не нужно. В итоге кодовая база
> и накладные расходы сокращаются - в этом одна из идей.сокращаются - несомненно. но таблицы трансляции остаются, IO, даже при пробросе, все равно должны обработаться гипервизором, и т.д. (может я не уловил, и это не гипервизор а контейнер? тогда все станет намного логичнее, и возникнет совсем другое "зачем")
> vfio - это немножко не проброс и сегрегация, точнее, немножко не те
> проброс и сегрегация, о которых говорится выше. Речь шла примерно о
> следующем: вот две сетевушки (а в реальности, скорее - одна многопоротовая).
> Linux - бери порт 1, ячейка X - бери порт 2,
> а гипервизор последит, чтобы вы не выстрелили друг другу в ногу.
> Разумеется, IOMMU добавит накладных расходов, но как вы только что подтвердили,
> товарищи из Intel, AMD и прочих следят, чтобы они не выходили
> за рамки разумного.само собой, и KVM (как и прочие) прекрасно это поддерживает, от IOMMU и до всяких локальных извращений типа 802.1Qbh
> Тесты (и здравый смысл) показывают, что чисто аппаратные
> расходы существенно меньше, чем то, что добавляет KVM (Xen, ...), который
> должен уметь намного больше. Для интереса можете снять трейс с KVM,
> f потом запустить то же ядро в ячейке Jailhouse, и сравнить
> статистику выходов.хорошая идея кстати. проще конечно было бы, если бы имелся jailhouse_trace по типу kvm_trace, нагляднее. Но как я писал выше - пробросы, pinning и прочие оптимизации умеет и KVM, его не обязательно использовать в максимально универсальном режиме.
> Объясняю (заодно отвечу на вопрос, зачем городить "клоны KVM с урезанным функционалом").
> Принципиальная разница между Jailhouse и KVM, как между пушкой и единорогом:
> пушка сама по себе, единорог сам по себе. :-) Они не
> являются клонами друг друга ни архитектурно, ни на уровне кода, и
> не конкурируют по области применения. Более того, была идея запускать в
> Jailhouse-ячейках KVM для случаев, когда без него не обойтись - но
> за эту задачу пока никто толком не брался.Тут опять возникает вопрос насчет "а не о контейнерах ли мы тут говорим?". Если так, то я свои вопросы перенаправлю в сторону LXC и всяческих надстроек нам ним
> Однако, в отличие от KVM, Jailhouse:
> - Имеет предсказуемую latency в задачах реального времени, причем меньше ~300
> мкс, до которых иногда деградирует KVM. Это удобно для индустриальных задач,
> телекома, NFV и т.п.за счет эксклюзивного доступа к ядру/треду плюс стабильный оверхед? если так, то как гарантируется эксклюзивность и стабильность?
> - Относительно легко формально верифицируется (что тоже хорошо для индустриальных применений).
> Справедливости ради, AFAIK никто не пробовал это сделать, но есть подозрение
> что заверифицировать ~10 тыс. изолированных строк (вопреки написанному в новости, Jailhouse
> использует ядро Linux только для загрузки себя, а далее полностью автономен)
> и связку KVM+ядро Linux (планировщик, virtio и пр.) - это немного
> разные задачи.т.е. jailhouse использует собственный планировщик в отличии от KVM который пользуется стандартным в ядре?
> Подробнее можно почитать здесь: http://www.linux-kvm.org/images/b/b1/Kvm-forum-2013-Static-P....
> Презентация старенькая, но годненькая.спасибо, и впрямь полезно
> Если задержек KVM вполне хватает (а есть много задач, где их хватает
> - даже ребята из Siemens, которые задумали Jailhouse, как-то худо-бедно дотянули
> до 2013 года) и формальная верификация не нужна - то и
> прекрасно. Мне вот в обычной жизни не нужно ни то, ни
> другое, так что я неплохо пользуюсь KVM для большинства (ключевое слово)
> своих задач.ну, как я уже писал, ребята из Windriver на жалуются
> Ну и в качестве резюме для желающих посравнивать KVM и Jailhouse. KVM
> - универсальный гипервизор, который (поскольку он универсальный) можно с разной степенью
> успешности доточить до любой задачи, включая RT-виртуализацию. Jailhouse - специализированный
> инструмент, созданный для того, чтобы хорошо решать одну конкретную задачу. Ни
> у кого, насколько мне известно, нет идей делать на его базе
> универсальный гипервизор.мне как раз и было интересно, зачем городить специализированный гипервизор, если можно доточить KVM до того же состояния, все таки он уже 9 лет существует, оптимизирован и развивается очень быстро.
в любом случае, спасибо за развернутые ответы, я многое для себя прояснил (плюс, приятная штука - нормальное общение, особенно на сайте где сначала швыряются какашками а потом разбираются)
> сокращаются - несомненно. но таблицы трансляции остаются,Они и в KVM остаются, если специально не выключать - теневые таблицы страниц обходятся гораздо дороже. Только в KVM поверх них еще будут работать почти 5000 строк кода собственного программного MMU, поскольку он умеет вложенную виртуализацию и разные другие штуки. Впрочем, эту часть KVM я знаю постольку-поскольку.
> IO, даже при пробросе, все
> равно должны обработаться гипервизором, и т.д. (может я не уловил, иЗачем? Гипервизор перехватывает обращения к PCI capabilities, т.е. участвует на моменте настройки устройства. DMA, безопасная доставка прерываний, обращение к портам происходит нативно.
> это не гипервизор а контейнер? тогда все станет намного логичнее, и
> возникнет совсем другое "зачем")Я не знаю, что Вы имеете в виду под словом "контейнер" в данном контексте - обычно этот термин употребляется для изоляции на уровне процессов (т.е. гораздо выше, чем работает KVM и Jailhouse). Это статический гипревизор, нет resource overcommitting, нет виртуализации в чистом виде - т.е. нельзя взять одну сетевую карту и раздать пяти "гостям" как пять разных карт других моделей. Все устройства чисто физические, включая процессоры (в отличие от KVM/Xen/VirtualBox/whatever, который по сути создает под гостя vcpu).
> хорошая идея кстати. проще конечно было бы, если бы имелся jailhouse_trace по
> типу kvm_trace, нагляднее. Но как я писал выше - пробросы, pinning
> и прочие оптимизации умеет и KVM, его не обязательно использовать в
> максимально универсальном режиме.jailhouse_trace существовать не может - за исключением загрузчика, Jailhouse не является частью ядра Linux и работает уровнем ниже него. Собственная статистика есть и доступна, инфраструктура, конечно, другая.
Говоря о Jailhouse как об альтернативе KVM для задач реального времени, разумеется, не имеют в виду "максимально универсальный" вариант. Речь об RT-ветках. Пиннинг спасает, но не до конца, потому что есть другие задачи (и еще прерывания), которые Linux может захотеть запустить на том же ядре. Гарантий (в смысле RT), которые здесь предоставляет Linux, может не хватить. Еще раз уточню - может и хватить, тогда все хорошо.
> Тут опять возникает вопрос насчет "а не о контейнерах ли мы тут
> говорим?". Если так, то я свои вопросы перенаправлю в сторону LXC
> и всяческих надстроек нам нимОтвет выше. Если коротко повториться: в LXC запускаются процессы Linux. В Jailhouse Linux в качестве гостя запустили вообще шутки ради пару недель назад, а основная задача - запускать bare-metal приложения и ОС реального времени. Пока в LXC нельзя будет запустить, к примеру, RTEMS, сравнение будет бессмысленным. Есть ощущение, что нельзя будет всегда, поскольку LXC проектировали совсем не для этого.
Впрочем, если желаете, Jailhouse можно считать переложением идеи контейнера с уровня пользовательских процессов на уровень оборудования.
> за счет эксклюзивного доступа к ядру/треду плюс стабильный оверхед? если так, то
> как гарантируется эксклюзивность и стабильность?Да, за счет гарантии, что "гостя" никто не потревожит. "Стабильность и эксклюзивность" гарантируется, как я уже писал, на аппаратном уровне - ядро просто "выводится" из Linux и целиком отдается ячейке (cell). С периферией та же история. В исходниках есть статья о том, как это работает, если интересны детали.
// По ходу изложения подумалось, что в контексте Jailhouse слово "cell" уместнее переводить как "клетка" или "камера". Надо будет над этим поразмышлять.
> т.е. jailhouse использует собственный планировщик в отличии от KVM который пользуется стандартным
> в ядре?Т.е. jailhouse не использует планировщик by design. Задача планировщика - обеспечивать доступ нескольких задач к разделяемым вычислительным ресурсам (т.е. процессору). Дизайн Jailhouse - не разделять ресурсы. Если ядро процессора целиком отдано ячейке A, 99% времени на нем выполняется ячейка A. Остальное время - выходы в гипервизор по необходимости или из-за гипервызовов. И то и другое происходит по требованию, так что планировать нечего.
Это не отменяет того, что ОС, выполняющаяся в ячейке может иметь свой собственный планировщике со своими гарантиями времени отклика. Это уже не дело Jailhouse, важно лишь, что он этому планировщику мешает минимально (как минимум, меньше KVM).
> мне как раз и было интересно, зачем городить специализированный гипервизор, если можно
> доточить KVM до того же состояния, все таки он уже 9
> лет существует, оптимизирован и развивается очень быстро.Ответ простой: потому что KVM доточить до "того же состояния" не получилось. О причинах можно почитать в презентации, на YouTube и видео доклада есть (это если уж совсем интересно).
> Гипервизор все равно должен выполнять трансляцию адресов памяти так или иначе,Вообще-то пойнт аппаратной виртуализации - в том чтобы по максимуму выгрузить это на железо. В этом случае вполне можно увидеть >=95% производительности от bare metal по CPU и работе с памятью.
У многих людей ядер больше, чем виртуалок?
В разработке да, в продакшене нет :)
А как дальше юзать? Где образа брать? Как и с чем есть .челл-файл? Прямых мануалов так и не нашёл.Кстати, билдится и ставится с полу-пинка.
> А как дальше юзать? Где образа брать? Как и с чем есть
> .челл-файл? Прямых мануалов так и не нашёл.
> Кстати, билдится и ставится с полу-пинка.если эта хрень не умеет грузить GRUB-2 (который в свою очередь должен грузить что-то другое)...
...то весь сомнительной нужности штука :-)
>> А как дальше юзать? Где образа брать? Как и с чем есть
>> .челл-файл? Прямых мануалов так и не нашёл.
>> Кстати, билдится и ставится с полу-пинка.
> если эта хрень не умеет грузить GRUB-2 (который в свою очередь должен
> грузить что-то другое)...
> ...то весь сомнительной нужности штука :-)Не умеет. Как я соседу отвечал, для RT-приложений GRUB как-то не прижился. У них и операционки как таковой частенько нет. В Jailhouse загрузчик, можно сказать, встроен: он сам располагает образ по нужному адресу и прыгает на точку входа. Одна из идей - иметь кодовую базу компактной засчет отсутствия необходимости эмулировать штатный процесс загрузки x86 (как с этим в ARM, не в курсе).
> ...то весь сомнительной нужности штука :-)Да, для хипстоты не подойдет. Это больше надо брутальным индустриальщикам (ты вообще в курсе чем Siemens знаменит?). Это не про тебя.
> А как дальше юзать? Где образа брать? Как и с чем есть
> .челл-файл? Прямых мануалов так и не нашёл.
> Кстати, билдится и ставится с полу-пинка.Образа чего? Реалтаймовых приложений - ну, с завалявшейся у вас промышленной железки, вестимо :) Девелоперская сборка Jailhouse умеет запускать Linux поверх Linux, но опять же - если Вас интересует обычная настольная/серверная виртуализация, имеет смысл смотреть в сторону KVM, VirtualBox, Xen и далее по вкусу. Это специализированное решение.
Процедура запуска пары игрушечных RT-приложений в параллель с Linux описана в README. Там же, в том числе, рассказано, как запустить демо-стенд внутри KVM, чтобы не заморачиваться с созданием .cell для вашего железа.
