|
| |
| |
| 3.7, fi (ok), 16:35, 21/12/2016 [^] [^^] [^^^] [ответить]
| –10 +/– |
 вот в этом и вопрос, точно тот или там своя ветка qemu?
| | |
| |
| 4.8, Мяут (ok), 17:22, 21/12/2016 [^] [^^] [^^^] [ответить]
| +3 +/– |
 Ну учитывая, что некоторые компоненты QEMU есть в QEMU-KVM (обвиусли), в Xen, и даже в VirtualBox, чтобы не использовать QEMU, это надо на оффтопики переходить ;)
| | |
| 4.14, Аноним (-), 20:05, 21/12/2016 [^] [^^] [^^^] [ответить]
| +12 +/– | |
> вот в этом и вопрос, точно тот или там своя ветка qemu?
1. «Виртуальная машина» выполняется на ЦП в «виртуализированном режиме». У Intel аппаратная реализация этого режима называется VT-x, у AMD - AMD-V, у других производителей - по-своему.
2. Для всех ЦП, поддерживаемых Linux и поддерживающих виртуализацию, ядро предоставляет унифицированный API для доступа к аппаратной поддержке виртуализации - KVM.
3.1. Очевидно, пользователю неудобно напрямую использовать псевдоустройство /dev/kvm для подачи ЦП команд на запуск и останов виртуальных машин.
3.2. Очевидно, на практике виртуальные машины бесполезны без предоставления им некоторых виртуальных или реальных периферийных устройств.
Проблемы 3.1 и 3.2 решают такие программы, как QEMU: они предоставляют пользователю удобный интерфейс для управления состоянием виртуальных машин, эмулируют виртуальные периферийные устройства, облегчают пользователю взаимодействие с ядром для «проброса» в виртуальную машину реальных периферийных устройств.
4. Пользователь может располагать целым парком различных виртуальных машин, управление которыми хотелось бы, с одной стороны, упростить, с другой - автоматизировать. Эту задачу решают такие программы, как libvirtd (с использованием библиотеки libvirt): предоставляют пользователю единый удобный интерфейс для управления разнородными средствами виртуализации и контейнерной изоляции.
5. Пользователь может располагать целым парком _серверов_ различных виртуальных машин, управление которыми хотелось бы, с одной стороны, упростить, с другой - автоматизировать (!). Эту задачу решают такие программы, как virt-manager и virsh: предоставляют пользователю единый удобный командный или графический интерфейс для управления виртуальными машинами, работающими на различных физических машинах; интерфейс для управления пулами дисковых хранилищ; интерфейс для изменения конфигурации машин, их добавления и удаления.
Нет в virt-manager никакой «своей ветки qemu» и быть не может, это просто пользовательский интерфейс к libvirtd.
И выполняет виртуальную машину не virt-manager, не libvirtd, не qemu и не KVM, а непосредственно ЦП.
Так понятно?
| | |
|
|
|
| 1.10, Игорь (??), 17:36, 21/12/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
 Я как всегда спрошу, а оно уже может написанное для SPARC64 запустить на x86_64?
| | |
| |
| 2.13, IB (?), 19:45, 21/12/2016 [^] [^^] [^^^] [ответить]
| +4 +/– |
> Я как всегда спрошу, а оно уже может написанное для SPARC64 запустить
> на x86_64?
Если вы запостили баг, то можете посмотреть его статус.
Ваш К.О.
| | |
|
| 1.15, Андрей (??), 22:21, 21/12/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> Добавлена поддержка платы STM32F2xx (Netduino 2) и улучшена поддержка платы Aspeed;
А что-нибудь такое народное типа STM32F4 Discovery есть?
| | |
| |
| |
| 3.18, Андрей (??), 00:07, 22/12/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
Да, это гуглом я нашёл. Интересно, каким макаром Netduino вдруг попал в mainline.
| | |
| |
| 4.21, doom (ok), 00:32, 22/12/2016 [^] [^^] [^^^] [ответить]
| +/– |
 Впринципе, ему там всё правильно сказали.
Netduino я думаю попала, т.к. у stm32F2 ядро cortex-m3, которое уже давно успешно эмулируется.
| | |
| |
| 5.22, Андрей (??), 00:51, 22/12/2016 [^] [^^] [^^^] [ответить]
| +/– | |
> Впринципе, ему там всё правильно сказали.
Если у меня есть куча кода, который не использует явно фичи M4, но скомпилирован под M0, M3, M4, так почему бы не запустить такой код без перекомпиляции?
> Netduino я думаю попала
Процесс публикации патчей пошёл:
https://lists.nongnu.org/archive/html/qemu-devel/2014-09/msg01638.html
v1: Tue, 9 Sep 2014 18:23:48 +1000
...
https://lists.nongnu.org/archive/html/qemu-devel/2015-02/msg05010.html
v11: Thu, 26 Feb 2015 15:33:35 +0900
Полгода ушло на то, что уже было в принципе готовым.
И вот сегодня более 2 лет спустя релиз. Да... Долговато. Может, я бегло глянув что-то упустил.
| | |
| |
| 6.25, doom (ok), 11:35, 22/12/2016 [^] [^^] [^^^] [ответить]
| +/– |
> Если у меня есть куча кода, который не использует явно фичи M4,
> но скомпилирован под M0, M3, M4, так почему бы не запустить
> такой код без перекомпиляции?
Ну так ему и заметили, что нет смысла пихать в апстрим кучу не полноценного кода.
Ну и вообще профили Mx между собой не 100% совместимы. У них давно уже появилась эмуляция stellaris младших серий, но там CM3 и периферия простая + singe-cycle Flash. Эмулировать stm32f4 намного сложнее.
> И вот сегодня более 2 лет спустя релиз. Да... Долговато. Может, я
> бегло глянув что-то упустил.
Да, такая скорость обработки патчей печалит. С openocd такая же фигня, приходится держать пяток форков.
| | |
| |
| 7.29, Андрей (??), 15:22, 22/12/2016 [^] [^^] [^^^] [ответить]
| +/– | |
> Ну так ему и заметили, что нет смысла пихать в апстрим кучу не полноценного кода.
Не, я о том ARM-коде. А ему - о том, что в qemu не хотят кода-заглушек, который как бы и есть, но как бы и не отработает специфичные команды. А я о том, что лучше, чтобы одна из нескольких программок пусть и сбойнула с not implemented opcode но зато другие работали бы без пересборки.
> С openocd такая же фигня, приходится держать пяток форков.
Какое-то время назад глядя на git и медленную разработку, я заглянул в gerrit. И обалдел: там просто море, непочатый край. И не понял, разработчики не комитят просто по принципу "не я написал" (по аналогии с not invented here) или как это понимать?..
| | |
|
|
|
| 4.26, Аноним (-), 12:42, 22/12/2016 [^] [^^] [^^^] [ответить]
| +/– | |
>> but if you are not interested, no problem, I'll keep everything local in my branch.
А в чем интерес сферического cortex M3 в вакууме? Чтобы лишний раз подтвердить что такие эмуляторы бесполезны для отладки? Большинство коммерческих софтварных эмуляторов по мере усложнения чипов банально вышли из употребления. Никому не надо приблизительную третьесортную эмуляцию в которой прога вроде работает, а на реальном железе - швах.
Вот и получается что проще всего на реальной железке отлаживаться. Иначе есть риск получить очень специфичный класс трудноуловимых глюков.
| | |
| |
| 5.31, doom (ok), 19:15, 22/12/2016 [^] [^^] [^^^] [ответить]
| +/– |
> А в чем интерес сферического cortex M3 в вакууме? Чтобы лишний раз
> подтвердить что такие эмуляторы бесполезны для отладки? Большинство коммерческих софтварных
> эмуляторов по мере усложнения чипов банально вышли из употребления. Никому не
> надо приблизительную третьесортную эмуляцию в которой прога вроде работает, а на
> реальном железе - швах.
Вцелом да, т.к. там где Cortex-M применяются всё сильно завязано на периферию. Но если есть хороший эмулятор ядра, то почему и нет - unit tests, замеры по тактам, да и просто при портировании всяких библиотек полезно.
Ну и насчет того, что эмуляторы вышли из употребления - это не так. Для того же ARM 8 появился эмулятор, и народ бодро запилил поддержку компиляторов, операционок не имея на руках реального железа. C RISCV та же история.
| | |
|
|
|
|
| 1.16, Аноним (-), 23:12, 21/12/2016 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– | |
> В реализацию протокола SPICE добавлена полноценная поддержка рендеринга с использованием OpenGL при указании "gl=on";
Подскажите, это имеется ввиду, что рендеринг opengl будет выполняться на клиенте? Или что vm сможет использовать virgil?
> клиенту выдаются ответы от первой, первичной, виртуальной машины (PVM), а вторая, запасная, виртуальная машина (SVM) работает на холостом ходу. Если оборудование PVM даёт сбой, то пользователь переключается на SVM, которая находится в точно таком же состоянии, как и PVM;
Т.е. они не раму синхронизируют, а клонируют взаимодействие с внешним миром? А как обошли всяческие случайные числа, временные ключи и т.п.?
| | |
| |
| 2.23, Аноним (-), 00:56, 22/12/2016 [^] [^^] [^^^] [ответить]
| +/– | |
> Т.е. они не раму синхронизируют, а клонируют взаимодействие с внешним миром? А как обошли всяческие случайные числа, временные ключи и т.п.?
Одной памяти не достаточно. Надо идентичное состояние системы, включая регистры и состояние виртуальных устройств. Соответственно, все "случайные" числа и часы будут синхронизированы между двумя машинами.
| | |
| |
| |
| 4.27, Аноним (-), 13:41, 22/12/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
Выбросить, а железо, на котором работал PVM, отдать в сервис.
| | |
|
|
|
| 1.19, Андрей (??), 00:13, 22/12/2016 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Кстати, недавно устанавливал Debian на флешку через Qemu то ли 2.6, то ли 2.7 и удивился, что OpenGL работает. Хотя я вообще ничего не настраивал (и без spice). А у меня ни какой не распоследний интел (sandy bridge) да и меса была то ли 10, то ли 11. Единственный глюк: внутри qemu не было vsync'а. И glxgears выдавал сотни кадров вместо 60.
| | |
| 1.30, Аноним (-), 17:05, 22/12/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> Суть технолгии в том, что на двух хостах запускаются две идентичные копии виртуальной машины
Штука в том, что когда две машины начинают вести себя по-разному, нет возможности сказать, какая из них "врет". Поэтому обычно запускают три машины.
| | |
|
