Представлен релиз проекта QEMU 6.0. В качестве эмулятора QEMU позволяет запустить программу, собранную для одной аппаратной платформы, на системе с совершенно иной архитектурой, например, выполнить приложение для ARM на x86-совместимом ПК. В режиме виртуализации в QEMU производительность выполнения кода в изолированном окружении близка к аппаратной системе за счёт прямого выполнения инструкций на CPU и задействования гипервизора Xen или модуля KVM...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=55055
Предлагаю замену: "на системах с новым ARM-чипом Apple M1" -> "на системах с SoC Apple M1".
Лучший!
да, ты умничка!
> Изначально проект был создан Фабрисом Белларом (Fabrice Bellard) с целью обеспечения возможности запуска собранных для платформы x86 исполняемых файлов Linux на архитектурах, отличных от x86.Я первый раз встретил упоминание QEMU в статье Криса Касперски о x86_64. Когда архитектура была нова, а у него ещё не было этого процессора, он запустил QEMU и попробовал x86_64 на нём. Второй раз я встретил упоминание QEMU в ностальгическом видео на ютюбе, где автор вспоминал, как году в 2003 при помощи QEMU ломали винду, имитируя сервер активации Windows. Ну а третий раз я встретил QEMU в своей openSUSE 12.1, когда я узнал, что можно пробрасывать видеокарту в гостевую винду. В системе уже были программы для виртуализации, и я обнаружил, что виртуалка называется не Xen, а именно QEMU.
Здоровья проекту и успехов.
Хм. Как-то пассивно выглядит. Все три столкновения произошли не по твоей инициативе. Ты мужик или нет? Столкновения с чем-либо должны происходить потому, что ты в активном поиске столкновения. История должна быть типа такого: мне потребовалось сделать X и я начал искать способов, перебрал несколько, и выбрал qemu.Я впервые столкнулся с qemu году эдак в 2005, когда мне на рабочем компе не удавалось обойтись без венды, а я хотел линукса. Я тогда венду запускал в qemu, работая преимущественно под линём. Венда тормозила, конечно, никакого kqemu не было, но это было лучше, чем гонять линуксовый софт под cygwin. (Хотя не... я ж тогда как раз разочаровался в дебиане, потому как мне пришлось пересобирать ядро и qemu, а дебьян не позволял встроить сборку двух пакетов из сорцов в обновление системы, так чтоб apt-get автоматически скачивал бы мне сорцы и предлагал бы собрать, после того как он обновит все депендансы. И по-моему всё происходило как раз из-за kqemu)
Я говорю это к тому, что активная жизненная позиция такого рода -- это единственный способ не скатываться в потреблятство. Либо ты пассивно ждёшь когда мир скажет тебе, что тебе нужно, либо ты активно решаешь за себя сам.
>В режиме виртуализации в QEMU производительность выполнения кода в изолированном окружении близка к аппаратной системе за счёт прямого выполнения инструкций на CPU и задействования гипервизора Xen или модуля KVMЕсли это так, то почему он тогда умудряется работать хуже ритуалбокса? Сколько завожу его, то грузит всё медленнее, то графика лагает, хотя KVM включал.. Я может не так что делаю?
Да.
> то графика лагает, хотя KVM включал
> Я может не так что делаюУгу, кое что. Не понимаешь зачем нужен KVM как минимум.
А нормально объяснить тебе религия не позволяет? Я спросил, что я не так делаю, а не для чего KVM нужен, который VurtalBox почему-то заводит нормально
По умолчанию qemu-kvm работает довольно плохо, но вот если удариться в тонкости конфигурирования - вполне можно получить 97% от хоста. Но это займет очень, очень много времени и сил!
5…10% пенальти на более-менее современных x86_64 железках.
Это когда несколько десятков ВМ делят несколько десятков ядер ЦП и несколько сотен ГБ ОЗУ хост-системы.
Хуже сделать легко, "надавив" на сеть/диски. Лучше — ?* Для тех кто в теме, типовая нагрузка у меня — "когерентная".
AHV на базе quemu-kvm
> почему он тогда умудряется работать хуже ритуалбокса
> то грузит всё медленнее, то графика лагает,Погаси Виртуалбокс модули ядра и т.д. Всё вернётся в норм. Дерутся они.
> хотя KVM включал.. Я может не так что делаю?GPU попробуй хотя-бы virtio, чтоли (2D only, ютуб в 1080p позырить точно хватает).
Лучше создать универсальную архитектуру для всего и не париться с эмуляторами.
с нетерпением ждём твоих разработоквангую либо это будет:
* умные часы с избыточной производительностью размером и с комбайн на архитектуре, схожей с x86_64
* либо ПК с производительностью графики как у мобилки на архитектуре, схожей с ARM
* либо просто ничего
>с нетерпением ждём твоих разработокне надо, не надо мотивировать его на плохие идеи. Люди и так много де....ьма уже придумали
Ой, ты ж Эльбрус описал.
https://xkcd.com/927/
Но тогда как чесать собственное величие рисквешникам?
Ну так RISC-V и прнинять за универсальную архитектуру для всего. Наверное, что-то проще уже трудно придумать.
Как там с производительностью? Пока что эльбрусы жизнеспособнее и конкурентоспособнее (особенно топовая модель -- уже выпустили?).
Че за "рисквешники"? Архитектура процессора называется risk-five, если об этом.
https://xkcd.com/927/
Аппаратное ускорение графики в виртуалки еще не завезли?
> Аппаратное ускорение графики в виртуалки еще не завезли?Virtgl отлично работает
Какие видяхи поддерживаются?
Intel. Может быть nvidia.
У меня отлично работает на Intel и AMD. Само собой гости - Gnu/Linux. В проприетарных поделках всё очевидно печально. (либо я чего-то не знаю и есть способ кроме интелоавского vGPU или проброса GPU с хоста)
Звук терщит и в этой версии.
/* Добавлены новые QMP-команды load-snapshot, save-snapshot и delete-snapshot для управления снапшотами qcow2. */
Ну наконец-то, 3 года (или больше) приходилось самому патчить, а в апстрим не принимали
QMP: {"error": {"class": "CommandNotFound", "desc": "The command save-snapshot has not been found"}}Нас обманули - расходимся...
и в исходниках нет этого кода, кругом обман :D
Разгадка оказалась проста: перепутали написание команд в ченжлоге:
migration: introduce snapshot-{save, load, delete} QMP commands
неужели osx big sur стартанёт? было бы здорово если б x86 стартанула, у меня что-то это ни в qemu, ни в vmware на линуксе не удалось. Проблема именно с этой версией osx
Самое простое ( при поддерживаемом железе ) - поставить хакинтош с опенкор
Самое лучшее и элегантное решение - купить новый Mac.
Продать себя в рабство ради покупки макета компьютера?
єто самое тупое решение, ну или решение от "маковода"... кому какое название больше нравится)
> Самое лучшее и элегантное решение - купить новый Mac.Нет, ведь это не позволит просто взять и собрать себе комп по сходной цене и с нужными параметрами - только выбирать из того, что яблоко предлагает..
Чего только стОит посредственная оперативка:
8 Гб DDR4 2,66 / 10 тыс руб
>> Самое лучшее и элегантное решение - купить новый Mac.
> Нет, ведь это не позволит просто взять и собрать себе комп по
> сходной цене и с нужными параметрами - только выбирать из того,
> что яблоко предлагает..
> Чего только стОит посредственная оперативка:
> 8 Гб DDR4 2,66 / 10 тыс рубСамое смешное в этом раскладе, что я как-то покупал DDR3 с наклейкой "специально для Мак" за полцены от обычной DDR3. Магазин её уценил, поскольку мало кто брал - в описании сказано "на обычном железе не работает" (на самом деле работает).
У меня именно big sur заработал даже на 5.2 с этими скриптами: https://github.com/kholia/OSX-KVM
Это кто пробовал?
https://mac.getutm.app/
Вроде на Qemu же?
Ох, даже и не знаю. Пятая ветка заметно тормозная с вложенной виртуализацией... четвертая пока что лучшая.
Вы какую-то бнссмыслецу сказали. Как вы измеряете производительность? И какие примерно сиделки вы получили на 4ой и 5ой ветках?
Признаться, сам ничего не понимаю. Под Pop!OS Cosmic c 5 веткой полный порядок, а в убунте 21.04 все очень плохо. Проверял в cpu-bound игре 58 против 40 фпс в Windows 10 20H2 c WSL2 - не особо жалую синтетику. Фс, набор твиков в sysctl(планировщик) и конфиг виртуальной машины - набор один и тот же. Может вы сможете хоть что-то прояснить?
А ARM андроид он запускать умеет без установки в систему каких-то дополонительных специальных модулей ядра как это требует Anbox и тому подобное? И без всяких snap и flatpak.
Просветите чем эмулятор от гипервизора отличаются и как они связаны?
тутошняя аудитория способна тебе втирать только про крутой раст.
Имеется программа для ARM и процессор AMD64. Они не совместимы. Программа-эмулятор читает из программы для ARM одну команду для ARM и вместо неё выполняет какие-то похожие для AMD64. Это медленно, зато работает.Имеется Android x86 и процессор AMD64. Такой Android можно запустить на AMD64 непосредственно, но там уже запущена другая ОС (Linux). Блок процессора "Гипервизор" делает вид, что другой ОС нет, железо "голое". Это работает быстро, но не всегда возможно.
Что бы пользователь не парился вопросом "что на чём запускать", оба эти режима объединили в QEMU, по возможности используется быстрый.
> Android x86 и процессор AMD64 ... Это работает быстроСовсем не быстро. Жутко тормозит. Всё еле шевелится, даже если выделишь 4 ядра и гигабайты памяти.
>> Android x86 и процессор AMD64 ... Это работает быстро
> Совсем не быстро. Жутко тормозит. Всё еле шевелится, даже если выделишь 4
> ядра и гигабайты памяти.Вы явно что-то не так делаете. Если речь про неудачный опыт с QEMU, то Android-x86 следует запускать штатным скриптом из rpm пакета и убедиться, что отрабатывает именно ветка с -vga virtio. ОЗУ достаточно и 2 Гб.
> Просветите чем эмулятор от гипервизора отличаются и как они связаны?Под гипервизором обычно понимают "программу уровнем выше ядра". Если ядро - supervisor mode, то над ним может быть hypervisor mode. Супервизор супервизоров. Взаимоотношение ядро <-> гипервизор немного похоже на взаимоотношение программа <-> супервизор (aka ядро). Только теперь caller - ядро, а исполнитель - железо и, вот, гипервизор.
Идея в том что железо, конечно, рубит привилегированые операции guest'а. А обрабатывает исключения гипервизор, который арбитрирует потуги, делит ресурсы, а при случае подвирает ОС и их ядрам что вон те привилегированные запросы к железу - прокатили. Хоть они и ни разу не - проц кинул исключение, гипервизор пришел, посмотрел, что-то сделал, вернул результат как будто и правда сработало. Операционка не заметила подвоха и ее ядро работае как будто всем и рулит, хоть это уже и не так. Плюс этого подхода в том что большую часть операций guest все же напрямую или почти напрямую делает на реальном железе - и скорость выполнения близка к железной.
Если guest явно в курсе что его на...вают, он вообще может юзать короткий и эффективный интерфейс запросов к гипервизору, по типу virtio, вместо того чтобы думать что это настоящие железки.
Под эмулятором же обычно понимают "программную реализацию оборудования". Простой пример: запускаем программу, программа читает опкоды из вон того бинарного потока и глядя на них делает то же что делал бы настоящий железный проц (меняет внутреннее состояние так же как настоящий проц). При этом совершенно не обязательно обладать тем процом, проц хоста может быть любым, лишь бы программу эмулятора мог запустить. Этот номер можно провернуть и с всеми остальными железками, так что эмулятор может эмулировать и вообще целиком всю систему. Поэтому какой-нибудь x86 может на раз прикинуться Raspberry Pi, хоть у него и нет ARM'овского процессора (точность и полнота эмуляции отдельный вопрос, но все же).
Эмуляция сильно гибче - можно изобразить вообще совсем все, незвисимо от возможностей и архитектуры своего железа. Вопрос в том с какой скоростью. Некто на AtMega сэмулировал ARMv5 с MMU и загрузил там убунту наример. Просто это был очень медленный "ARM" из-за того что "хост" убогий по фичам и слабосильный.
Реально подходы можно сочетать. Скажем получив вон те команды к той железке гипервизор может сделать какую-то фильтрацию, выпилив откровенно вредные и опасные, а потом взяв да и отдав это железке выполнять напрямую. При этом скорость лучше чистой эмуляции а гибкость лучше, можно что-то и совсем софтварно отлупить, если там потеря скорости была ОК.
Теперь точно накатим максимальную