Re: [Qemu-devel] -icount changes physical address assignments in QEMU 2.10/2.11

[Peter Maydell]

On 23 February 2018 at 00:39,  <address@hidden> wrote:
> 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?

Can you try with this patch applied?
https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg06595.html
(that will go into git master within the next week or so but isn't
yet applied; it does fix at least some -icount related problems).

If that doesn't help, can you provide a demonstration test
binary that I can use to reproduce the bug?

thanks
-- PMM