> сокращаются - несомненно. но таблицы трансляции остаются,Они и в 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 и видео доклада есть (это если уж совсем интересно).
