When porting our RTOS from QEMU 2.8 to 2.10/2.11, I ran into a problem
where 16-bit writes to the "bochs dispi interface" were being reported
differently depending on whether or not "-icount" was given to QEMU.
For example, info mtree:
11000500-11000515 (prio 0, i/o): bochs dispi interface
A 16-bit write to 0x11000500 was delivered to pci_vga_bochs_write() as
address 0, when -icount was not specified, but as address 2 when
-icount was specified. Correspondingly writes to 0x11000502 were 2
and 0 respectively. Essentially the words were swapped depending on
the presence of -icount.
I suspect a similar problem for the AARCH64 GIC (generic interrupt
controller), but other than observing the GIC changing from working to
non-working depending on the absence/presence of -icount I haven't
confirmed the underlying cause.
2.10 and 2.11 were built from source on Cygwin using mingw, 2.8 from a
"native" MinGW. The results are consistent for 2.10 and 2.11. 2.8
does not have the -icount dependency. The "broken" command line was:
qemu-system-aarch64 -m 1077 -name "arm" -M virt,virtualization=on
-cpu cortex-a53 -icount align=off,shift=0,sleep=on
-vga std -device secondary-vga
-kernel ...deosBoot.bin -initrd "deosBoot.qemu" -netdev
The "working" command line omitted -icount and its argument.
FWIW, the error from the GIC with -icount was:
qemu: fatal: IO on conditional branch instruction