Как подсчитать количество гостевых инструкций, выполненных QEMU от начала до конца запуска?

Question

Я хочу протестировать количество инструкций гостя в секунду QEMU, чтобы сравнить его с другими симуляторами.

Как получить счет гостевых инструкций? Меня интересует как пользовательский, так и полноценный системный режим.

Единственные решения, которые у меня есть сейчас, - это регистрировать все инструкции с помощью простой трассировки exec_tb или -d in_asm: Как использовать простую трассировку QEMU? а затем отсчитайте инструкции оттуда. Но это, вероятно, значительно снизит производительность моделирования из-за операций вывода, поэтому мне, вероятно, придется запускать тестовую программу дважды, одну с трассировкой, а другую без трассировки, и надеяться, что оба выполнения похожи (должно быть, особенно для однопоточного пользователя режим моделирования).

Я видел -icountвариант, который звучит многообещающе из названия, но когда я передал его в QEMU 4.0.0, я ничего не заметил. Должен ли он где-то печатать счетчик команд? Следующий патч не объединен и не предлагает: https://lists.gnu.org/archive/html/qemu-devel/2015-08/msg01275.html

Answer 1

Базовое профилирование

Чтобы продолжить ответ Питера, я недавно столкнулся с ситуацией, когда я хотел получить количество инструкций программы, запущенной под QEMU (я использую v4.2.0, первую, где стали доступны плагины).

Один из примеров плагинов, insn.c, делает именно то, что вы хотите, и возвращает количество выполненных инструкций при выходе из плагина.

(Я предполагаю, что вы уже знаете, как запускать QEMU, поэтому я разделю это до важных флагов)

qemu-system-arm ... -plugin qemu-install-dir/build/tests/plugin/libinsn.so,arg=inline -d plugin

Первая часть загружает плагин и передает ему единственный аргумент, "встроенный". Следующая часть позволяет распечатать плагин. Вы можете перенаправить вывод плагина в другой файл, добавив-D filename к вызову командной строки.

Более продвинутое профилирование

Когда я искал возможные способы профилирования программы, работающей под QEMU, это был один из немногих многообещающих результатов моего поиска. В духе создания хорошей записи для других поисковиков в будущем, вот несколько ссылок на код, который я написал для этого.

Код плагина профилирования, документы.

_{^{Отказ от ответственности: я написал приведенный выше код.}}

Answer 2

Текущие выпущенные версии QEMU не предоставляют никаких средств для этого. Предстоящая поддержка "плагина TCG", который должен выйти в версии 4.2 в конце года, позволит вам написать простой плагин "подсчет выполненных инструкций", но это (как и в случае с -d трассировкой) добавит накладных расходов.

Параметр -icount, конечно, сбивает с толку, но он заставляет эмулируемый ЦП (пытается) работать с определенным количеством выполняемых инструкций в секунду, в отличие от значения по умолчанию "как можно быстрее". Это имеет более высокие накладные расходы (и остановит использование QEMU нескольких потоков хоста для гостей SMP), но более детерминировано.

С философской точки зрения, "количество инструкций в секунду" является довольно вводящим в заблуждение показателем для эмуляторов, потому что время, затрачиваемое на выполнение инструкции, может сильно различаться по сравнению с аппаратным обеспечением. Загрузка и хранение происходит медленнее, чем на реальном оборудовании. Инструкции с плавающей запятой невероятно медленны (возможно, в 10 раз или хуже, чем у целочисленных арифметических инструкций, где реальное оборудование может выполнять обе за один цикл). Эмуляторы JIT, такие как QEMU, имеют профиль производительности start-stop, при котором выполнение полностью останавливается, пока мы переводим блок кода, тогда как реальный процессор или интерпретирующий эмулятор не будут иметь этих пауз. Насколько сильно влияет время JIT, будет зависеть от того, часто ли ваш код повторно запускает ранее переведенный горячий код или большую часть времени он тратит на выполнение "нового" кода,и делает ли он что-то, что приводит к тому, что JIT должна отбрасывать старый код (например, самомодифицирующийся код или частые переключения контекста между процессами). Если бы на вашем эмуляторе был "IPS-метр", вы бы увидели, что значение, которое он сообщает, сильно колеблется, когда гостевой код выполнялся и делал разные вещи. Вероятно, вам лучше просто выбрать тест, который, по вашему мнению, является репрезентативным для вашего фактического варианта использования, запустить его на различных эмуляторах и сравнить время, необходимое для выполнения на настенных часах.Вероятно, лучше просто выбрать тест, который, по вашему мнению, является репрезентативным для вашего фактического варианта использования, запустить его на различных эмуляторах и сравнить время, необходимое для завершения работы настенных часов.Возможно, лучше просто выбрать эталонный тест, который, по вашему мнению, является репрезентативным для вашего фактического варианта использования, запустить его на различных эмуляторах и сравнить время, необходимое для завершения работы настенных часов.