> Если разработчик _эмулятора_ пошёл, как вы говорите, на компромисс, и не стал
> точь-в-точь что-то эмулировать (не важно, по каким причинам!), то это его
> ответственность за такое решение. Да. И в реально существующем софте на такой tradeoff идут осмысленно. Собственно, чтобы сделать идеально точную эмуляцию по хорошему надо чуть не сорц железки.
Как пример: а идите вон узнайте чего у интеля в uCode ROM?! Это не описано никак и нигде, это уровнем ниже чем bios developers и проч - набор команд определяет. Они это шифруют вообще, ибо нефиг. Так что вы не узнаете какие реально микрооперации он там делает для вот этой x86 команды. И уж тем более удачи сделать точную эмуляцию, способную, допустим, вгрузить апдейченый uCode ROM и поменять свое поведение так, как это оригинал с таким апдейтом сделает.
Поэтому как абсолютный максимум, вы сможете сделать очень приблизительный клон. Который, внезапно, не умеет реально жевать апдейт uCode ROM и честно менять свое поведение как оригинальная железка :)
> И поэтому его вина, если из-за этого компромисса софт, исправно работающий
> на реальном железе, начинает сбоить с этим самым компромиссом.
Ну а слабо описать как, допустим, реализовать "апдейт микрокода" на "виртуальном проце"? :)
> не надо при этом снимать ответственность и перекладывать с больной головы на здоровую.
> Ну или прекратите называть QEMU-KVM эмулятором.
Перфекционизм это прекрасно. Я для перфекционистов придумал сценарий в котором не смог бы сам победить, даже если б очень сильно захотел. Как пример того что идеальная эмуляция в определенных случаях вообще совсем из области научной фантастики.