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 having 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 -device virtio-net,netdev=vlan0,addr=2,disable-modern=false,mac=52:54:00:12:67:56 -kernel ...deosBoot.bin -initrd "deosBoot.qemu" -netdev tap,id=vlan0,ifname="DDCI-tap0" 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 Any pointers?
