Посоветуйте литературу по программированию qemu

a1ba

а что, поиск и вопрос ИИ ничего не дал? мне дал это https://sebastienbourdelin.com/2021/06/16/writing-a-custom-device-for-qemu/

Ресурсы Для изучения QEMU и разработки драйверов для устройств, эмулируемых в QEMU, доступны: Документация QEMU — на сайте qemu.org есть раздел с описанием драйверов для устройств, эмулируемых в QEMU.

Репозиторий d0u9/Linux-Device-Driver — демонстрирует примеры драйверов для устройств, эмулируемых в QEMU, и руководство по их запуску в эмуляторе.

Его исходники.

предлагается соснуть сурца, как говорится XD

И на том спасибо :)

Хочу эмулировать свою кастомную плату с произвольной периферией

Tomahawk Block V проще купить, чем эмулировать.

Получается, чтобы добавить какую-то периферию, предлагается перекомпилировать сам qemu?

Ты чо жжошь что ли? Там предельно всратая документация

для разного оборудования, очевидно по-разному. Где-то надо, где-то не надо.

Я дал 3 ссылки и сказал где взял. Я за автора писать сам драйвер не буду.

Как будто компиляция это самая сложная часть 😆

Наверное имеется в виду для конечного пользователя. При разработке он каждый раз не пересобирается весь, а только изменённые файлы.

вопрос ИИ ничего не дал?

На такие вопросы ИИ ничего не отвечает, и это в лучшем случае, в худшем какой-то пурги напишет.

Тебе скорее всего уже не надо, но для тех кто будет поиском тут искать.

Берёшь какой-нибудь предельно простой девайс, напримимер https://gitlab.com/qemu-project/qemu/-/blob/master/hw/misc/empty_slot.c , копируешь и дорабатываешь напильником. Если не нужно взаимодействие с внешним миром - достаточно имплементировать read и write, которые эмулируют чтение и запись в устройство. Если эмулируешь новую видеокарту или последовательный порт - всё немного сложнее, но посмотрев на исходники похожих - будет понятно, что делать.

«known to a bus but not connected devices» - мне не ясно, это вообще как? Как оно может быть «известно на шине», если оно не подключено? И какая именно шина имеется в виду?

Так я так и делал, но мне это не нравится. Хочется иметь хотя бы обзорную документацию по всем API, которые уже есть. Допустим, тот же доступ к памяти гостя. Я уверен, что это делается очень просто, но я не смог найти изящного решения, поэтому пришлось нагородить костылей.

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

Так что вопрос на счёт книги всё же актуальный. Даже не смотря на то, что задачу свою я решил.

Писал я это для сановской SBus, но потенциально оно может использоваться в качестве заглушки на любой шине, которая кидает прерываение, если пакет не доставлен. Т.е. родная прошивка сканирует слот, и если он пустой, QEMU кидает прерывание, потому что шины там эмулируются самым минималистичным образом. Чтобы прошивка не дурела от неожиданного прерывания, надо, чтобы она нашла пустоту, а не прерывание.

Доступ к памяти гостя - случайно

xp адрес

В мониторе qemu не подойдёт?

Книгу я бы и сам почитал. У Stefan’a кое что есть на разные темы, часто даже со слайдами: https://blog.vmsplice.net/search/label/qemu

В мониторе qemu не подойдёт?

Нужен прямой доступ из сишного кода, который эмулирует подсистему. Например, мне гость пишет в регистры DMA адрес данных, которые он хочет передать по шине SPI и мне нужно как-то «разыменовать» такой «указатель».

DMA там немного геморройно делается, это да. Не знаю, есть ли решения получше, в SPARC это делается через

address_space_ldl_be(&address_space_memory,

be - это потому что там оно BigEndian, бывает конечно ещё и le. Вообще, в Memory API были улучшения, может быть уже есть вариант чтобы сразу массив передать, а не одно слово.

И, разумеется, в гугле по запросу «address_space_ldl_be qemu» нет ссылки на официальную документацию по нему :)

Вообще, в Memory API были улучшения, может быть уже есть вариант чтобы сразу массив передать, а не одно слово.

Я вот про то же. Правильный вариант по-любому есть, только информации о нём нет.

А вот, кое что есть, и даже документировано:

https://www.qemu.org/docs/master/devel/memory.html#c.address_space_write

Очень похоже на cpu_physical_memory_read() и cpu_physical_memory_write(), но у них есть один недостаток - лишнее копирование. То есть, я сначала копирую данные в свой буфер, а потом уже делаю с ними что-то.

cpu_ это частный случай address_space_, скорее всего. А зачем копировать? Если данные где-то нужны в другом буфере - можно его сразу и отдать. А если не нужны, тогда наверное через read/write_callback/ memory_listener_register это проще выразить.

А зачем копировать?

Вот и я про то же. Эти функции используются для чтения и записи, а мне же нужен доступ по указателю. С этим мне помог memory_region_get_ram_ptr().