[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] -icount changes physical address assignments in QEMU 2.10/2
From: |
alarson |
Subject: |
[Qemu-devel] -icount changes physical address assignments in QEMU 2.10/2.11 |
Date: |
Thu, 22 Feb 2018 18:39:19 -0600 |
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?
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Qemu-devel] -icount changes physical address assignments in QEMU 2.10/2.11,
alarson <=