On Thu, Feb 15, 2007 at 01:16:35PM +0200, Michael Shigorin wrote: > On Thu, Feb 15, 2007 at 12:38:09PM +0200, Eugene Ostapets wrote: > > 15.02.07, Alexey Tourbin написал(а): > > > > > 2at@ Могу подхватить, но меня сейчас интересует только qemu-arm. Отдашь? > > > Ещё eostapets писал, что собирает qemu для себя и не прочь отправлять > > > свои сборки в сизиф. Не знаю, кто из вас больше заинтересован в этом > > > пакете. В любом случае, хочу его кому-нибудь отдать. > > Я заинтересован в свежем, работающем qemu и не хочу чтобы мой труд > > пропадал зря :) Если у кого-то бизнес-процессы завязаны на qemu - > > значит он более заинтересован, чем я :) Ну и всегда можно дописать > > второго в права на пакет, чтобы не было задержек:) > > Лёш, добавь их обоих -- там уже между собой разберутся :-) > > Поскольку Жене надо x86/x86_64, а Кирюше -- ARM. > Бишь интересы пересекаются только в том, что пакет один. > > PS: если кому не влом отпроксить в kernel cvs -- welcome: > http://paq.osdn.org.ua/~mike/qemu/SRPMS/ kernel* В ходе разборок с kqemu на x86_64 выяснилось следующее: 1) При использовании qemu-system-x86_64 с kqemu в гостевой ОС (пробовались Compact-3.0.4, installer-20070202 i586 и x86_64) наблюдаются segmentation faults в громадном количестве. Эта проблема исчезает после пересборки qemu с использованием gcc-3.4. Без kqemu вроде бы такого не наблюдается. Может быть, не стоит пытаться собирать qemu с использованием официально неподдерживаемой автором версии компилятора? 2) Установить installer-20070202 x86_64 с использованием kqemu не удаётся даже после пересборки и qemu, и кусков kqemu gcc-3.4 (впрочем, последнее, похоже, на результат не влияет). При использовании опции -kernel-kqemu падение происходит ещё в первой стадии инсталятора; без -kernel-kqemu падает, как правило, после создания разделов. В этом случае аварийно завершается именно kqemu; в dmesg наблюдаются сообщения вида: kqemu: aborting: Unexpected exception 0x0d in monitor space err=0000 CS:EIP=f180:00000000f0001f77 SS:SP=0000:00000000f00c6e50 Удалось выяснить, что ошибка происходит в common/monitor.c в функции mon_alloc_page(): vaddr = get_vaddr(s); /* XXX: check error */ set_vaddr_page_index(s, vaddr, page_index, host_page, 0); Комментарий с XXX тут стоит не зря - ошибка происходит, когда get_vaddr() не может найти свободную страницу виртуальной памяти в области, отведённой для монитора kqemu. Проблема, похоже, в том, что kqemu выполняет эмуляцию таблицы страниц, при этом страницы только выделяются, но никогда не освобождаются; но если в 32-разрядном режиме для таблицы страниц максимально возможного размера требовалось около 8 МБ (на самом деле таких таблиц 2, область монитора сейчас имеет размер 32 МБ, так что в этом режиме переполнение происходить не должно), то в 64-разрядном режиме теоретический максимум - 513 ГБ. Таким образом, на x86_64 такая схема управления памятью неработоспособна (впрочем, 32-разрядные системы, запущенные в qemu-system-x86_64 на хосте x86_64, всё-таки будут работать).