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

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

[alarson]

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?

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

[Peter Maydell]

On 23 February 2018 at 00:39,  <alarson@ddci.com> 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

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

[alarson]

[-- Attachment #1: Type: text/plain, Size: 3542 bytes --]

"Peter Maydell" <peter.maydell@linaro.org> wrote on 03/15/2018 11:55:19 
AM:

> From: "Peter Maydell" <peter.maydell@linaro.org>
> To: alarson@ddci.com
> Cc: "QEMU Developers" <qemu-devel@nongnu.org>
> 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,  <alarson@ddci.com> 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


[-- Attachment #2: icount-bug.bin --]
[-- Type: application/octet-stream, Size: 17712 bytes --]

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

[Peter Maydell]

On 22 March 2018 at 05:31,  <alarson@ddci.com> 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

[alarson]

"Peter Maydell" <peter.maydell@linaro.org> wrote on 04/05/2018 09:05:53 
AM:

> From: "Peter Maydell" <peter.maydell@linaro.org>
> To: alarson@ddci.com
> Cc: "QEMU Developers" <qemu-devel@nongnu.org>
> 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,  <alarson@ddci.com> 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

[Peter Maydell]

On 5 April 2018 at 17:44,  <alarson@ddci.com> wrote:
> "Peter Maydell" <peter.maydell@linaro.org> 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

[alarson]

"Peter Maydell" <peter.maydell@linaro.org> wrote on 04/05/2018 12:28:01 
PM:

> From: "Peter Maydell" <peter.maydell@linaro.org>
> To: alarson@ddci.com
> Cc: "QEMU Developers" <qemu-devel@nongnu.org>
> 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,  <alarson@ddci.com> wrote:
> > "Peter Maydell" <peter.maydell@linaro.org> 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

[Peter Maydell]

On 5 April 2018 at 22:23,  <alarson@ddci.com> wrote:
> "Peter Maydell" <peter.maydell@linaro.org> wrote on 04/05/2018 12:28:01
> PM:
>
>> From: "Peter Maydell" <peter.maydell@linaro.org>
>> To: alarson@ddci.com
>> Cc: "QEMU Developers" <qemu-devel@nongnu.org>
>> 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,  <alarson@ddci.com> wrote:
>> > "Peter Maydell" <peter.maydell@linaro.org> 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

[Stefan Weil]

Am 06.04.2018 um 11:41 schrieb Peter Maydell:
> On 5 April 2018 at 22:23,  <alarson@ddci.com> 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

[alarson]

"Peter Maydell" <peter.maydell@linaro.org> wrote on 04/06/2018 04:41:01 
AM:

> From: "Peter Maydell" <peter.maydell@linaro.org>
> To: alarson@ddci.com
> Cc: "QEMU Developers" <qemu-devel@nongnu.org>, "Stefan Weil" 
<sw@weilnetz.de>
> 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,  <alarson@ddci.com> wrote:
> > "Peter Maydell" <peter.maydell@linaro.org> wrote on 04/05/2018 
12:28:01
> > PM:
> >
> >> From: "Peter Maydell" <peter.maydell@linaro.org>
> >> To: alarson@ddci.com
> >> Cc: "QEMU Developers" <qemu-devel@nongnu.org>
> >> 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,  <alarson@ddci.com> wrote:
> >> > "Peter Maydell" <peter.maydell@linaro.org> 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

[Peter Maydell]

On 6 April 2018 at 14:28,  <alarson@ddci.com> wrote:
> "Peter Maydell" <peter.maydell@linaro.org> wrote:
>> On 5 April 2018 at 22:23,  <alarson@ddci.com> 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

[Mark Cave-Ayland]

On 06/04/18 14:28, alarson@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

[Peter Maydell]

On 6 April 2018 at 14:33, Peter Maydell <peter.maydell@linaro.org> 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

[Peter Maydell]

On 6 April 2018 at 15:51, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 6 April 2018 at 14:33, Peter Maydell <peter.maydell@linaro.org> 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

[alarson]

"Peter Maydell" <peter.maydell@linaro.org> 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

[Peter Maydell]

On 6 April 2018 at 18:06,  <alarson@ddci.com> wrote:
> "Peter Maydell" <peter.maydell@linaro.org> 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

[alarson]

"Peter Maydell" <peter.maydell@linaro.org> wrote on 04/06/2018 12:21:37 
PM:

> On 6 April 2018 at 18:06,  <alarson@ddci.com> 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

[alarson]

"Mark Cave-Ayland" <mark.cave-ayland@ilande.co.uk> wrote on 04/06/2018 
09:14:14 AM:

> From: "Mark Cave-Ayland" <mark.cave-ayland@ilande.co.uk>
> To: alarson@ddci.com, "Peter Maydell" <peter.maydell@linaro.org>
> Cc: "Stefan Weil" <sw@weilnetz.de>, "QEMU Developers" 
<qemu-devel@nongnu.org>
> 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, alarson@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?