Re: [Qemu-devel] -icount changes physical address assignments in QEMU 2.10/2.11
"Mark Cave-Ayland" wrote on 04/06/2018 09:14:14 AM: > From: "Mark Cave-Ayland" > To: alar...@ddci.com, "Peter Maydell" > Cc: "Stefan Weil" , "QEMU Developers" > Date: 04/06/2018 09:14 AM > Subject: Re: [Qemu-devel] -icount changes physical address assignments in QEMU 2.10/2.11 > > On 06/04/18 14:28, alar...@ddci.com wrote: > > > I was not successful with the wiki instructions for "Native builds > > with MSYS2": > > > >./qemu-2.12.0-rc2/configure --python=/usr/bin/python2 \ > >'--with-pkgversion=DDCI QEMU 2.12.0-rc2' \ > >--prefix=/usr/local/qemu \ > >'--target-list=aarch64-softmmu ppc64-softmmu x86_64-softmmu' > >make > >... > >C:\msys2-x86_64_20161025\msys64\mingw64\bin\ar.exe: creating > > libfdt/libfdt.a > >make[1]: *** No rule to make target ...build/capstone/capstone.lib'. > > Stop. > >make: *** [Makefile:503: subdir-capstone] Error 2 > > Ah I believe those instructions were mine from when I had temporary > access to a Windows VM for testing last year. > > Since the instructions pre-dated the inclusion of capstone as a > dependency, is it as simple as adding: > > git submodule update --init capstone > > before running configure and make? I didn't do the "git" parts. I extracted from the source tarball. Is the tarball source supposed to work, or is it necessary to always use git?
Re: [Qemu-devel] -icount changes physical address assignments in QEMU 2.10/2.11
"Peter Maydell" wrote on 04/06/2018 12:21:37 PM: > On 6 April 2018 at 18:06, wrote: > > > > FWIW, the compile had some anomalous behavior: > > > > .../qemu-2.12.0-rc2/scripts/feature_to_c.sh: line 71: /usr/bin/sed: > > Invalid argument > > > > line 71 is: > > arrayname=xml_feature_$(echo $input | sed 's,.*/,,; s/[-.]/_/g') > > > > Not sure what the problem is, but I always use "-e" before scripts. > > That's a bit odd. (POSIX allows both "-e script" and just "script".) > What version of sed is this, and what version of /bin/sh ? I don't know what the issue is. When I execute that command from my normal bash shell, it works just fine. This is current Cygwin, so: qemu$ sed --version sed (GNU sed) 4.4 Packaged by Cygwin (4.4-1) ... qemu$ /bin/sh --version GNU bash, version 4.4.12(3)-release (x86_64-unknown-cygwin) ... Perhaps I misread the sed manual, but I thought when you used a character other than "/", you had to preface the character with a backslash, e.g., sed 's\,.*,,;' But, the above is all just speculation. I don't know what the real problem is. FWIW, I rebuilt twice more and the error didn't show up again, but I did get some other spurious errors, one from GCC "invalid argument" and another: /bin/sh: /usr/bin/x86_64-w64-mingw32-gcc: Device or resource busy make: *** [/cygdrive/c/scm/Deos/products/qemu/branches/2.12/output/qemu-2.12.0-rc2/rules.mak:66: stubs/notify-event.o] Error 126 So perhaps it is just normal Cygwin "fork" errors, or my use of "make -j8". I think you can ignore this. Sorry for the spam.
Re: [Qemu-devel] -icount changes physical address assignments in QEMU 2.10/2.11
On 6 April 2018 at 18:06, wrote: > "Peter Maydell" wrote on 04/06/2018 09:51:55 > AM: > >> I've now done this, and can reproduce the problem. So the >> issue is generic to 32-bit hosts. > > Supporting evidence: I compiled Cygwin/MINGW with x86_64 and the > resulting binaries work properly > > FWIW, the compile had some anomalous behavior: > > .../qemu-2.12.0-rc2/scripts/feature_to_c.sh: line 71: /usr/bin/sed: > Invalid argument > > line 71 is: > arrayname=xml_feature_$(echo $input | sed 's,.*/,,; s/[-.]/_/g') > > Not sure what the problem is, but I always use "-e" before scripts. That's a bit odd. (POSIX allows both "-e script" and just "script".) What version of sed is this, and what version of /bin/sh ? thanks -- PMM
Re: [Qemu-devel] -icount changes physical address assignments in QEMU 2.10/2.11
"Peter Maydell" wrote on 04/06/2018 09:51:55 AM: > I've now done this, and can reproduce the problem. So the > issue is generic to 32-bit hosts. Supporting evidence: I compiled Cygwin/MINGW with x86_64 and the resulting binaries work properly FWIW, the compile had some anomalous behavior: .../qemu-2.12.0-rc2/scripts/feature_to_c.sh: line 71: /usr/bin/sed: Invalid argument line 71 is: arrayname=xml_feature_$(echo $input | sed 's,.*/,,; s/[-.]/_/g') Not sure what the problem is, but I always use "-e" before scripts. Later the make failed with the following error: > gdbstub-xml.c:695:28: error: ‘xml_feature_’ undeclared here (not in a function) > { "i386-64bit-core.xml", xml_feature_ }, ^~~~ > gdbstub-xml.c:61:19: warning: ‘xml_feature_i386_64bit_core_xml’ defined but not used [-Wunused-const-variable=] > static const char xml_feature_i386_64bit_core_xml[] = { >^~~ > make[1]: *** [/cygdrive/c/scm/Deos/products/qemu/branches/2.12/output/qemu-2.12.0-rc2/rules.mak:66: gdbstub-xml.o] Error 1 > make: *** [Makefile:478: subdir-x86_64-softmmu] Error 2
Re: [Qemu-devel] -icount changes physical address assignments in QEMU 2.10/2.11
On 6 April 2018 at 15:51, Peter Maydell wrote: > On 6 April 2018 at 14:33, Peter Maydell wrote: >> On this end I should try this with a 32-bit Linux host. > > I've now done this, and can reproduce the problem. So the > issue is generic to 32-bit hosts. > > I'll see if I can figure out what's going wrong. I've tracked down the issue -- it is with the arm frontend's handling of the tcg_insn_start parameters. Specifically, we have a 3-operand tcg_insn_start: tcg_gen_insn_start(dc->pc, (dc->condexec_cond << 4) | (dc->condexec_mask >> 1), 0); dc->insn_start = tcg_last_op(); where we patch in the 3rd operand later sometimes in disas_set_insn_syndrome(): tcg_set_insn_param(s->insn_start, 2, syn); Unfortunately, if we're running on a setup where TARGET_LONG_BITS > TCG_TARGET_REG_BITS (ie 32 bit guest on 64 bit host), tcg_gen_insn_start() has under the hood split the 3 operands we gave it into 6, and so we end up patching the wrong one. The effect is that the first time the icount code needs to call io_recompile, we set condexec_bits to a bogus value which is also too big for its space in tb_flags and the CPSR, and execution starts to diverge from there onward. The following change fixes this: diff --git a/target/arm/translate.h b/target/arm/translate.h index c47febf99d..f04ece9cfd 100644 --- a/target/arm/translate.h +++ b/target/arm/translate.h @@ -120,7 +120,15 @@ static inline void disas_set_insn_syndrome(DisasContext *s, uint32_t syn) /* We check and clear insn_start_idx to catch multiple updates. */ assert(s->insn_start != NULL); +#if TARGET_LONG_BITS <= TCG_TARGET_REG_BITS tcg_set_insn_param(s->insn_start, 2, syn); +#else +/* tcg_gen_insn_start has split every target_ulong argument to + * op_insn_start into two 32-bit arguments, so we want the low + * half of the 3rd input argument, which is at index 4. + */ +tcg_set_insn_param(s->insn_start, 4, syn); +#endif s->insn_start = NULL; } but I'm not convinced it's the neatest way to do it. Nobody else plays this game with tcg_set_insn_param() (except icount, which doesn't do it with target_ulong sized values), so this bug is specific to the arm target. Richard: do you have a cleaner suggestion than throwing this ifdef into the arm code? thanks -- PMM
Re: [Qemu-devel] -icount changes physical address assignments in QEMU 2.10/2.11
On 6 April 2018 at 14:33, Peter Maydell wrote: > On this end I should try this with a 32-bit Linux host. I've now done this, and can reproduce the problem. So the issue is generic to 32-bit hosts. I'll see if I can figure out what's going wrong. In the meantime, you can probably work around it by building 64-bit binaries rather than 32-bit ones (they will perform a bit better I think, so unless you need to retain support for running on 32-bit Windows that would be a good idea anyway). thanks -- PMM
Re: [Qemu-devel] -icount changes physical address assignments in QEMU 2.10/2.11
On 06/04/18 14:28, alar...@ddci.com wrote: I was not successful with the wiki instructions for "Native builds with MSYS2": ./qemu-2.12.0-rc2/configure --python=/usr/bin/python2 \ '--with-pkgversion=DDCI QEMU 2.12.0-rc2' \ --prefix=/usr/local/qemu \ '--target-list=aarch64-softmmu ppc64-softmmu x86_64-softmmu' make ... C:\msys2-x86_64_20161025\msys64\mingw64\bin\ar.exe: creating libfdt/libfdt.a make[1]: *** No rule to make target ...build/capstone/capstone.lib'. Stop. make: *** [Makefile:503: subdir-capstone] Error 2 Ah I believe those instructions were mine from when I had temporary access to a Windows VM for testing last year. Since the instructions pre-dated the inclusion of capstone as a dependency, is it as simple as adding: git submodule update --init capstone before running configure and make? ATB, Mark.
Re: [Qemu-devel] -icount changes physical address assignments in QEMU 2.10/2.11
On 6 April 2018 at 14:28, wrote: > "Peter Maydell" wrote: >> On 5 April 2018 at 22:23, wrote: >> > I installed a fresh Cygwin with just the packages suggested at >> > https://wiki.qemu.org/Hosts/W32#Native_builds_with_Mingw-w64 (plus >> > some obviously missing ones like python, make, etc.) and the problem >> > persists. The updated configure line is: >> > >> > ../qemu-2.12.0-rc2/configure \ >> > '--with-pkgversion=DDCI QEMU 2.12.0-rc2' \ >> > --prefix=/usr/local/qemu \ >> > '--target-list=aarch64-softmmu ppc64-softmmu x86_64-softmmu' \ >> > --cross-prefix=i686-w64-mingw32- >> >> Hmm, if it's Windows-only that's unfortunate, since I'm not really >> in a position to debug things that only happon on Windows hosts. >> >> Stefan, does this sort of bug sound familiar at all? >> >> Looking at your --cross-prefix you seem to be building 32-bit >> binaries; was your Ubuntu VM 32 bit or 64 bit? I'm wondering >> if this might turn out to be a 32-bit host issue rather than >> necessarily a Windows one. > > 1. Ubuntu 17.10 is 64-bit, compilation was native, run on the >compilation host. I.e., I did not cross compile to windows. > 2. Cygwin was a 64-bit install, 64-bit windows 7 host. I followed the >instructions on the wiki. I was curious about the "ming32" part >myself, but cygwin package search doesn't indicate an obvious (to >me) replacement. You're building your mingw32 binaries with an i686- compiler, not an x86_64- one, so you'll end up with 32-bit Windows binaries running on your 64-bit Windows installation. If you have the 64-bit cross compiler and libraries for it you could try a --cross-prefix=x86_64-w64-mingw32- build. On this end I should try this with a 32-bit Linux host. thanks -- PMM
Re: [Qemu-devel] -icount changes physical address assignments in QEMU 2.10/2.11
"Peter Maydell" wrote on 04/06/2018 04:41:01 AM: > From: "Peter Maydell" > To: alar...@ddci.com > Cc: "QEMU Developers" , "Stefan Weil" > Date: 04/06/2018 04:41 AM > Subject: Re: [Qemu-devel] -icount changes physical address assignments in QEMU 2.10/2.11 > > On 5 April 2018 at 22:23, wrote: > > "Peter Maydell" wrote on 04/05/2018 12:28:01 > > PM: > > > >> From: "Peter Maydell" > >> To: alar...@ddci.com > >> Cc: "QEMU Developers" > >> Date: 04/05/2018 12:28 PM > >> Subject: Re: [Qemu-devel] -icount changes physical address assignments > > in QEMU 2.10/2.11 > >> > >> On 5 April 2018 at 17:44, wrote: > >> > "Peter Maydell" wrote on 04/05/2018 > > 09:05:53 > >> > AM: > >> >> I've just tried your attached test image ... > >> > > >> > Curious. I just downloaded qemu-2.12.0-rc2.tar.xz and built it using > >> > Cygwin (a version from about a month ago) using mingw compilers > >> > (mingw64-i686-gcc-g++ 6.4.0), and I still see the issue when the > >> > resulting QEMU binary is run using -icount 2 against my test binary, > >> > but not when run without -icount. Here are the commands used: > >> > > >> > ../qemu-2.12.0-rc2/configure --python=/usr/bin/python \ > >> >'--with-pkgversion=DDCI QEMU 2.12.0-rc2' \ > >> >--prefix=/usr/local/qemu \ > >> >--enable-sdl --with-sdlabi=2.0 \ > >> >'--target-list=aarch64-softmmu ppc64-softmmu x86_64-softmmu' \ > >> >--cross-prefix=i686-w64-mingw32- > >> > /usr/bin/make -Otarget -j 8 > >> > > >> > Any suggestions of things to try? > >> > >> Can you reproduce the problem on a Linux host? It would > >> be interesting to identify if this is a Windows-host > >> specific issue somehow. > > > > Linux "works". I installed ubuntu 17.10 in a VM on my windows box, > > recompiled QEMU 2.12.0-rc2 (same sources as above), using a configure > > line the same as above except omitting --cross-prefix and --with-sdlabi. > > Both with "-icount 2" and without show expected results. > > > > I installed a fresh Cygwin with just the packages suggested at > > https://wiki.qemu.org/Hosts/W32#Native_builds_with_Mingw-w64 (plus > > some obviously missing ones like python, make, etc.) and the problem > > persists. The updated configure line is: > > > > ../qemu-2.12.0-rc2/configure \ > > '--with-pkgversion=DDCI QEMU 2.12.0-rc2' \ > > --prefix=/usr/local/qemu \ > > '--target-list=aarch64-softmmu ppc64-softmmu x86_64-softmmu' \ > > --cross-prefix=i686-w64-mingw32- > > Hmm, if it's Windows-only that's unfortunate, since I'm not really > in a position to debug things that only happon on Windows hosts. > > Stefan, does this sort of bug sound familiar at all? > > Looking at your --cross-prefix you seem to be building 32-bit > binaries; was your Ubuntu VM 32 bit or 64 bit? I'm wondering > if this might turn out to be a 32-bit host issue rather than > necessarily a Windows one. 1. Ubuntu 17.10 is 64-bit, compilation was native, run on the compilation host. I.e., I did not cross compile to windows. 2. Cygwin was a 64-bit install, 64-bit windows 7 host. I followed the instructions on the wiki. I was curious about the "ming32" part myself, but cygwin package search doesn't indicate an obvious (to me) replacement. I was not successful with the wiki instructions for "Native builds with MSYS2": ./qemu-2.12.0-rc2/configure --python=/usr/bin/python2 \ '--with-pkgversion=DDCI QEMU 2.12.0-rc2' \ --prefix=/usr/local/qemu \ '--target-list=aarch64-softmmu ppc64-softmmu x86_64-softmmu' make ... C:\msys2-x86_64_20161025\msys64\mingw64\bin\ar.exe: creating libfdt/libfdt.a make[1]: *** No rule to make target ...build/capstone/capstone.lib'. Stop. make: *** [Makefile:503: subdir-capstone] Error 2
Re: [Qemu-devel] -icount changes physical address assignments in QEMU 2.10/2.11
Am 06.04.2018 um 11:41 schrieb Peter Maydell: > On 5 April 2018 at 22:23, wrote: >> Linux "works". I installed ubuntu 17.10 in a VM on my windows box, >> recompiled QEMU 2.12.0-rc2 (same sources as above), using a configure >> line the same as above except omitting --cross-prefix and --with-sdlabi. >> Both with "-icount 2" and without show expected results. >> >> I installed a fresh Cygwin with just the packages suggested at >> https://wiki.qemu.org/Hosts/W32#Native_builds_with_Mingw-w64 (plus >> some obviously missing ones like python, make, etc.) and the problem >> persists. The updated configure line is: >> >> ../qemu-2.12.0-rc2/configure \ >> '--with-pkgversion=DDCI QEMU 2.12.0-rc2' \ >> --prefix=/usr/local/qemu \ >> '--target-list=aarch64-softmmu ppc64-softmmu x86_64-softmmu' \ >> --cross-prefix=i686-w64-mingw32- > Hmm, if it's Windows-only that's unfortunate, since I'm not really > in a position to debug things that only happon on Windows hosts. > > Stefan, does this sort of bug sound familiar at all? No, It's new for me. But the last time when I used "-icount" must be several years ago, so I have to look. > Looking at your --cross-prefix you seem to be building 32-bit > binaries; was your Ubuntu VM 32 bit or 64 bit? I'm wondering > if this might turn out to be a 32-bit host issue rather than > necessarily a Windows one. That might be a possible. I think there are not many QEMU users running it on 32 bit Linux, especially not to emulate a 64 bit guest. We should test this first, as testing and debugging QEMU on Linux is much easier than on Windows. Stefan
Re: [Qemu-devel] -icount changes physical address assignments in QEMU 2.10/2.11
On 5 April 2018 at 22:23, wrote: > "Peter Maydell" wrote on 04/05/2018 12:28:01 > PM: > >> From: "Peter Maydell" >> To: alar...@ddci.com >> Cc: "QEMU Developers" >> Date: 04/05/2018 12:28 PM >> Subject: Re: [Qemu-devel] -icount changes physical address assignments > in QEMU 2.10/2.11 >> >> On 5 April 2018 at 17:44, wrote: >> > "Peter Maydell" wrote on 04/05/2018 > 09:05:53 >> > AM: >> >> I've just tried your attached test image ... >> > >> > Curious. I just downloaded qemu-2.12.0-rc2.tar.xz and built it using >> > Cygwin (a version from about a month ago) using mingw compilers >> > (mingw64-i686-gcc-g++ 6.4.0), and I still see the issue when the >> > resulting QEMU binary is run using -icount 2 against my test binary, >> > but not when run without -icount. Here are the commands used: >> > >> > ../qemu-2.12.0-rc2/configure --python=/usr/bin/python \ >> >'--with-pkgversion=DDCI QEMU 2.12.0-rc2' \ >> >--prefix=/usr/local/qemu \ >> >--enable-sdl --with-sdlabi=2.0 \ >> >'--target-list=aarch64-softmmu ppc64-softmmu x86_64-softmmu' \ >> >--cross-prefix=i686-w64-mingw32- >> > /usr/bin/make -Otarget -j 8 >> > >> > Any suggestions of things to try? >> >> Can you reproduce the problem on a Linux host? It would >> be interesting to identify if this is a Windows-host >> specific issue somehow. > > Linux "works". I installed ubuntu 17.10 in a VM on my windows box, > recompiled QEMU 2.12.0-rc2 (same sources as above), using a configure > line the same as above except omitting --cross-prefix and --with-sdlabi. > Both with "-icount 2" and without show expected results. > > I installed a fresh Cygwin with just the packages suggested at > https://wiki.qemu.org/Hosts/W32#Native_builds_with_Mingw-w64 (plus > some obviously missing ones like python, make, etc.) and the problem > persists. The updated configure line is: > > ../qemu-2.12.0-rc2/configure \ > '--with-pkgversion=DDCI QEMU 2.12.0-rc2' \ > --prefix=/usr/local/qemu \ > '--target-list=aarch64-softmmu ppc64-softmmu x86_64-softmmu' \ > --cross-prefix=i686-w64-mingw32- Hmm, if it's Windows-only that's unfortunate, since I'm not really in a position to debug things that only happon on Windows hosts. Stefan, does this sort of bug sound familiar at all? Looking at your --cross-prefix you seem to be building 32-bit binaries; was your Ubuntu VM 32 bit or 64 bit? I'm wondering if this might turn out to be a 32-bit host issue rather than necessarily a Windows one. thanks -- PMM
Re: [Qemu-devel] -icount changes physical address assignments in QEMU 2.10/2.11
"Peter Maydell" wrote on 04/05/2018 12:28:01 PM: > From: "Peter Maydell" > To: alar...@ddci.com > Cc: "QEMU Developers" > Date: 04/05/2018 12:28 PM > Subject: Re: [Qemu-devel] -icount changes physical address assignments in QEMU 2.10/2.11 > > On 5 April 2018 at 17:44, wrote: > > "Peter Maydell" wrote on 04/05/2018 09:05:53 > > AM: > >> I've just tried your attached test image ... > > > > Curious. I just downloaded qemu-2.12.0-rc2.tar.xz and built it using > > Cygwin (a version from about a month ago) using mingw compilers > > (mingw64-i686-gcc-g++ 6.4.0), and I still see the issue when the > > resulting QEMU binary is run using -icount 2 against my test binary, > > but not when run without -icount. Here are the commands used: > > > > ../qemu-2.12.0-rc2/configure --python=/usr/bin/python \ > >'--with-pkgversion=DDCI QEMU 2.12.0-rc2' \ > >--prefix=/usr/local/qemu \ > >--enable-sdl --with-sdlabi=2.0 \ > >'--target-list=aarch64-softmmu ppc64-softmmu x86_64-softmmu' \ > >--cross-prefix=i686-w64-mingw32- > > /usr/bin/make -Otarget -j 8 > > > > Any suggestions of things to try? > > Can you reproduce the problem on a Linux host? It would > be interesting to identify if this is a Windows-host > specific issue somehow. Linux "works". I installed ubuntu 17.10 in a VM on my windows box, recompiled QEMU 2.12.0-rc2 (same sources as above), using a configure line the same as above except omitting --cross-prefix and --with-sdlabi. Both with "-icount 2" and without show expected results. I installed a fresh Cygwin with just the packages suggested at https://wiki.qemu.org/Hosts/W32#Native_builds_with_Mingw-w64 (plus some obviously missing ones like python, make, etc.) and the problem persists. The updated configure line is: ../qemu-2.12.0-rc2/configure \ '--with-pkgversion=DDCI QEMU 2.12.0-rc2' \ --prefix=/usr/local/qemu \ '--target-list=aarch64-softmmu ppc64-softmmu x86_64-softmmu' \ --cross-prefix=i686-w64-mingw32-
Re: [Qemu-devel] -icount changes physical address assignments in QEMU 2.10/2.11
On 5 April 2018 at 17:44, wrote: > "Peter Maydell" wrote on 04/05/2018 09:05:53 > AM: >> I've just tried your attached test image ... > > Curious. I just downloaded qemu-2.12.0-rc2.tar.xz and built it using > Cygwin (a version from about a month ago) using mingw compilers > (mingw64-i686-gcc-g++ 6.4.0), and I still see the issue when the > resulting QEMU binary is run using -icount 2 against my test binary, > but not when run without -icount. Here are the commands used: > > ../qemu-2.12.0-rc2/configure --python=/usr/bin/python \ >'--with-pkgversion=DDCI QEMU 2.12.0-rc2' \ >--prefix=/usr/local/qemu \ >--enable-sdl --with-sdlabi=2.0 \ >'--target-list=aarch64-softmmu ppc64-softmmu x86_64-softmmu' \ >--cross-prefix=i686-w64-mingw32- > /usr/bin/make -Otarget -j 8 > > Any suggestions of things to try? Can you reproduce the problem on a Linux host? It would be interesting to identify if this is a Windows-host specific issue somehow. thanks -- PMM
Re: [Qemu-devel] -icount changes physical address assignments in QEMU 2.10/2.11
"Peter Maydell" wrote on 04/05/2018 09:05:53 AM: > From: "Peter Maydell" > To: alar...@ddci.com > Cc: "QEMU Developers" > Date: 04/05/2018 09:06 AM > Subject: Re: [Qemu-devel] -icount changes physical address assignments in QEMU 2.10/2.11 > > On 22 March 2018 at 05:31, wrote: > > Your patch (applied to 2.11 source release) changed the behavior > > somewhat, but did not fix the problem. Attached is a binary that when > > run should show a CGA fontset and color bars. > > > > This command should "work": > > > > qemu-system-aarch64 -M virt,virtualization=on -cpu cortex-a53 -vga std > > -device secondary-vga -device virtio-net,netdev=vlan0,addr=2 -kernel > > icount-bug.bin -netdev user,id=vlan0 > > > > If you add "-icount 2" the display will appear, but be mangled. > > > > I didn't spend too much time trimming the source code, so if you need > > to step by step debug walking through the guest code, I'll have to > > prune it down some more. > > > > For the record, the QEMU source I have is modified slightly to add ARM WFE > > support, something I will submit once this is all straightened out, > > but this bug appeared before I made that patch. > > Hi; sorry for the delay in testing this. I've just tried your > attached test image with current head of git QEMU (commit > 0e87fdc966d05f4e5ad86, which is the 2.12.0-rc2 release candidate), > and it gives me a correct display both with and without -icount 2. > So I think we've fixed this bug, probably with the combination > of commits 0790f86861079b19 and 87f963be66a3245, or possibly > a75a52d62418da. > > thanks > -- PMM Thank you for your help. > I've just tried your attached test image ... Curious. I just downloaded qemu-2.12.0-rc2.tar.xz and built it using Cygwin (a version from about a month ago) using mingw compilers (mingw64-i686-gcc-g++ 6.4.0), and I still see the issue when the resulting QEMU binary is run using -icount 2 against my test binary, but not when run without -icount. Here are the commands used: ../qemu-2.12.0-rc2/configure --python=/usr/bin/python \ '--with-pkgversion=DDCI QEMU 2.12.0-rc2' \ --prefix=/usr/local/qemu \ --enable-sdl --with-sdlabi=2.0 \ '--target-list=aarch64-softmmu ppc64-softmmu x86_64-softmmu' \ --cross-prefix=i686-w64-mingw32- /usr/bin/make -Otarget -j 8 Any suggestions of things to try? If you think this is a build environment issue, I can try MSYS and report my results.
Re: [Qemu-devel] -icount changes physical address assignments in QEMU 2.10/2.11
On 22 March 2018 at 05:31, wrote: > Your patch (applied to 2.11 source release) changed the behavior > somewhat, but did not fix the problem. Attached is a binary that when > run should show a CGA fontset and color bars. > > This command should "work": > > qemu-system-aarch64 -M virt,virtualization=on -cpu cortex-a53 -vga std > -device secondary-vga -device virtio-net,netdev=vlan0,addr=2 -kernel > icount-bug.bin -netdev user,id=vlan0 > > If you add "-icount 2" the display will appear, but be mangled. > > I didn't spend too much time trimming the source code, so if you need > to step by step debug walking through the guest code, I'll have to > prune it down some more. > > For the record, the QEMU source I have is modified slightly to add ARM WFE > support, something I will submit once this is all straightened out, > but this bug appeared before I made that patch. Hi; sorry for the delay in testing this. I've just tried your attached test image with current head of git QEMU (commit 0e87fdc966d05f4e5ad86, which is the 2.12.0-rc2 release candidate), and it gives me a correct display both with and without -icount 2. So I think we've fixed this bug, probably with the combination of commits 0790f86861079b19 and 87f963be66a3245, or possibly a75a52d62418da. thanks -- PMM
Re: [Qemu-devel] -icount changes physical address assignments in QEMU 2.10/2.11
"Peter Maydell" wrote on 03/15/2018 11:55:19 AM: > From: "Peter Maydell" > To: alar...@ddci.com > Cc: "QEMU Developers" > Date: 03/15/2018 11:55 AM > Subject: Re: [Qemu-devel] -icount changes physical address assignments in QEMU 2.10/2.11 > > On 23 February 2018 at 00:39, 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 Peter, thanks for the patch, and sorry for the long delay getting back to you. I was on extended travel. Your patch (applied to 2.11 source release) changed the behavior somewhat, but did not fix the problem. Attached is a binary that when run should show a CGA fontset and color bars. This command should "work": qemu-system-aarch64 -M virt,virtualization=on -cpu cortex-a53 -vga std -device secondary-vga -device virtio-net,netdev=vlan0,addr=2 -kernel icount-bug.bin -netdev user,id=vlan0 If you add "-icount 2" the display will appear, but be mangled. I didn't spend too much time trimming the source code, so if you need to step by step debug walking through the guest code, I'll have to prune it down some more. For the record, the QEMU source I have is modified slightly to add ARM WFE support, something I will submit once this is all straightened out, but this bug appeared before I made that patch. If you need me to update sources to head, or to 2.12 and re-apply your patch I can do that. md5sum: f4626a1b8edb0d64cba14fe3b43e3357 *icount-bug.bin icount-bug.bin Description: Binary data
Re: [Qemu-devel] -icount changes physical address assignments in QEMU 2.10/2.11
On 23 February 2018 at 00:39, 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
[Qemu-devel] -icount changes physical address assignments in QEMU 2.10/2.11
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?