[devel] Новый qemu

[Sergey Vlasov]

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<at altlinux.ru> написал(а):
> > > > > 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, всё-таки
   будут работать).
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: Digital signature
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20070218/772e47e1/attachment-0001.bin>