Comments 16
Причина 1. Если роцессор работает на ядрах разной битности
Во-первых, очепятка в этом подзаголовке :)
А во-вторых, правильней говорить всё ж о разных архитектурах, а не "битности" (разрядности). Например, в STM32MP15x имеется одно или два 32-разрядных ядра Cortex-A7 и одно 32-разрядное ядро Cortex-M4. "Битности" совпадают, но архитектуры-то реально разные (ARMv7-A и ARMv7-M).
Неверно, тут речь идет именно о "битности":
System (SYS) — группа процессорных ядер, принимающих всю нагрузку; на них запускается Linux, пользовательские приложения, они 64-битные.
System Control Unit (SCU) — процессорное ядро, среди прочих функций которого — управление системой питания и загрузкой ОС. Оно 32-битное.
Архитектура у них одинаковая RISC-V. Есть AMP с одной разрядностью, но разным функционалом например Sifive Unmatched, там и разрядность одинаковая, но например на 0 харте отсутвует MMU, и они как раз эмулируются в размках одной машины QEMU.
И все же в данном примере лучше говорить о разных архитектурах :) Да и сам автор пишет:"Так как у ядер чипа разная битность — читай, разная архитектура ".
Ну, вообще-то самое понятие "архитектура" подразумевает программную совместимость -- по меньшей мере, "снизу вверх". Если прогу, написанную для 32-разрядного RISC-V, можно без перекомпиляции запустить на 64-разрядном, тогда можно считать их одной архитектурой, если нет -- то нет. (Я с RISC-V реально не знаком, поэтому и говорю про "если")
Ну а если сравнить с тем же ARMом одинаковой разрядности, то с одной стороны имеем M-профиль, а с другой -- A- и R-. Хотя почти все собственно команды из M-профиля будут нормально выполняться на процах A- или R-профиля, считать эти разновидности одной архитектурой, как по мне, всё же неправильно: у них кардинально отличается, так сказать, системная архитектура -- в первую очередь, обработка прерываний, и соответствующий код абсолютно непереносим. С другой стороны, A- и R-профили можно считать одной архитектурой: основная разница -- наличие MMU (A) или MPU (R). Ну а 64-разрядная архитектура ARM, понятно, имеет к M-профилю ещё меньшее отношение.
В общем, подозреваю, что с RISC-V примерно так же, как и с ARM: типа одна архитектура, а реально -- несколько, имеющих как общие, так и кардинально различающиеся элементы. Но, как уже сказал, пока в этом вопросе некомпетентен.
Прокомментирую -
Если прогу, написанную для 32-разрядного RISC-V, можно без
перекомпиляции запустить на 64-разрядном, тогда можно считать их одной
архитектурой, если нет -- то нет. (Я с RISC-V реально не знаком, поэтому
и говорю про "если")
И да, и нет. Общим кодом можно в три команды определить разрядность и сделать jmp на нужный вариант, но что-то сложнее этого требует раздельного кода.
addi t0, x0, 2
sll t0, 31
bne t0, x0, is_64bitТак намеренно сделали. Но я не видел, например, двухархитектурных бинарников в ELF с компанией.
Хуже то, что архитектура подразумевает 100500 профилей, составляющих ориентированный граф добавления фич, некоторые из них можно получить стандартными средствами вроде чтения служебного регистра misa, но многие - нет, и надо выкапывать где-то отдельно (device tree, ACPI и тому подобное). Грануляция серьёзнее в разы чем с ARM. Но оно на 25-30 лет моложе, так что пока наблюдаем, что выживет из этих промежуточных уровней...
Мы привели пример, когда мы не можем запустить ядра с разной битностью внутри одной виртуальной машины, так как QEMU не позволяет это сделать.
Однако, Вы правы, что и системы с разными архитектурами также нельзя запустить в рамках одного процесса.
Как организована общая память для виртуальных машин? (shared memory)
Как по ссылке ниже или как-то по-другому?
https://www.qemu.org/docs/master/system/devices/ivshmem.html
"Linux на такой конфигурации не запустить — он будет неделю стартовать и в итоге вообще не запустится."
Смотря какой Linux. Простой консольный Линукс на CPU без MMU даже на Icarus Verilog за пол часа стартует. А с верилатором думаю 10 секунд будет.
Для ответа на этот вопрос нужен отдельный эксперимент. Возможно, вы такой проводили? Было бы интересно ознакомиться с результатами.
Когда-то давным давно я пытался запустить Amber ARM v2a SoC в ПЛИС.
Как часть той работы была симуляция работы процессора и запуск какого-то усеченного Линукс.
https://marsohod.org/projects/marsohod2/amber-arm-soc/396-amber-arm-v2a-soc-verilator
Там в конце моей статьи написано такое:
Самое интересное, что если с Icarus Verilog на подобную симуляцию загрузки ядра Linux уходило минут сорок пять, то теперь, с Verilator, полный старт симулируемой системы происходит секунд за 30! Невероятно. Я честно говоря очень впечатлен получившимся быстродействием. Очень рекомендую присмотреться к Verilator. В некоторых случаях - отличный инструмент.
А чем Synopsys Virtualizer не угодил ? Ну кроме цены (либо сложности поиска китайского кряка учитывая политику). Или аналоги от Cadence/Siemens/Imperas/Windriver....Там хоть сразу десяток разных архитектур можно в одном прототипе. И анализ узких мест в интерконнекте из коробки. И RTL косимуляция, и с HAPS оно замечательно косуществует.
Я пришел к выводу, что санкции это хороший повод и шанс послать к чертям всю проприетарщину и начать работу с СПО, постепенно расширяя его возможности. От офиса до симуляции вычислительных ядер.
Короткий ответ: проблема в сложности закупки лицензированного продукта, а использование неофициального ПО или его взлом противоречат позиции компании. А вы используете какой-то из перечисленных инструментов? Расскажите, какие задачи решаете.
Спасибо за статью, очень интересно. Мне доводилось симулировать RISC-V (VexRiscV без MMU) + небольшой кусочек своего железа (Verilog) с помощью Verilotor-а, потактово исполняя программу в ПЗУ. При отсутствии опыта задача оказалась не из легких, не смотря на то, что в Сети много материала на эту тему.
Автор, у тебя ошибка.
Симуляция - это точное копирование действий, насколько возможно.
Эмуляция - это предоставление конечного результата, без разницы каким способом.
Не критично, но знать надо.
Игра в имитацию: как разрабатывать и отлаживать ПО для процессора, которого нет