R: R: R: [PULL 0/3] ppc-for-6.1 queue 20210713

[luigi burdo]

Hi Zoltan,
i have same issue with kvm with only qemu-system-ppc -M pegasos2 -bios 
pegasos2.rom --enable-kvm
and with this command line that work great on my PC (without kvm of course)

qemu-system-ppc -M pegasos2 -bios pegasos2.rom -device ati-vga,romfile="" 
-display sdl  -rtc base=localtime -drive 
if=none,id=hd,file=/home/gigi/peggy2,format=raw -device 
ide-hd,drive=hd,bus=ide.0  -drive 
if=none,id=cd,file=/home/gigi/Chrysalis_3.15.iso -device 
ide-cd,drive=cd,bus=ide.0  -device AC97  -m 1024  -netdev user,id=mynet0 
-device sungem,netdev=mynet0 -serial stdio --enable-kvm


about:
>So does it stop here or do you get to the firmware ok prompt?
never, with kvm enable no ok promt, without kvm enabled everything work ok (on 
G5 and PC).
with kvm enabled the seriel stdio log stop and because of this i check dmesg 
where there i found this never ending looping message:
> [ 3634.418495] kvmppc_exit_pr_progint: emulation at 700 failed (0700)
> [ 3634.418525] Couldn't emulate instruction 0x0700 (op 0 xop 896)
> [ 3634.418551] Couldn't emulate instruction 0x0700 (op 0 xop 896)
> [ 3634.418577] Couldn't emulate instruction 0x0700 (op 0 xop 896)
> [ 3634.418603] Couldn't emulate instr...

>Apart from that you could also try what happens with the sc 1 calls that
is used but VOF when you use -kernel boot.img instead of -bios

i will test kvm with VOF too and report

I think to build last linux kernel just because mine last is 5.04, and im  just 
courious if somethig was fixed in last kernel for not make you creazy for 
notiing 

Ciao
Lugii

Da: BALATON Zoltan 
Inviato: martedì 20 luglio 2021 16:02
A: luigi burdo 
Cc: qemu-...@nongnu.org ; qemu-devel@nongnu.org 

Oggetto: Re: R: R: [PULL 0/3] ppc-for-6.1 queue 20210713

Hello,

On Tue, 20 Jul 2021, luigi burdo wrote:
> i was able to build on my quad qemu, a ram bank was die and make me the issue 
> with gcc..
> this is what happening if i run pegasos 2 with --enable-kvm.

OK. Can you also show the full command so we know what options you used?

> via_superio_cfg: unimplemented register 0xf2
> via_superio_cfg: unimplemented register 0xf4
> via_superio_cfg: unimplemented register 0xf6
> via_superio_cfg: unimplemented register 0xf7
> via_superio_cfg: unimplemented register 0xf4
> via_superio_cfg: unimplemented register 0xf2
> PegasosII Boot Strap (c) 2002-2003 bplan GmbH
> Running on CPU PVR:000C0209
> Enable L1 ICache...Done.
> mv64361_write: Unimplemented register write 0x108 = 0
> Reading W83194 :   FAILED.
> Setting Front Side Bus to 133MHz...FAILED.
> Invalid access at addr 0xFE000E43, size 1, region '(null)', reason: rejected

So this shows that what I've seen on emulated KVM (running QEMU in a PPC
Linux guest running on qemu-system-ppc64 -M mac99) does not match what
real hardware does so that could be a bug in emulated KVM. As shown at the
end of this message:

https://lists.nongnu.org/archive/html/qemu-ppc/2021-06/msg00146.html

I did not get the Invalid access warning but instead got endless kvm exits
with the NIP not incrementing past the instruction doing this invalid
access so probably there's a problem with handling invalid access with
emulated KVM PR but I don't know where to look for that problem or how to
fix it. It could also be a bug in guest kernel or QEMU, I'm not sure. Hope
somebody with more knowledge about PPC KVM could give some hints.
Aparently this is not a problem on real machine where it works as expected
(the Invalid address is because we don't emulate this device but it's not
needed and it boots without it and we get the same warnings with TCG).

> Invalid access at addr 0xFE000E44, size 1, region '(null)', reason: rejected
> Invalid access at addr 0xFE000E41, size 1, region '(null)', reason: rejected
> Invalid access at addr 0xFE000E42, size 1, region '(null)', reason: rejected
> Invalid access at addr 0xFE000E40, size 1, region '(null)', reason: rejected
> Configuring DDR...mv64361_write: Unimplemented register write 0x1494 = 291
[...]
> Releasing IDE reset ...Done.
> Configuring Legacy Devices
> Initializing KBD...Invalid access at addr 0xFE0003F0, size 1, region 
> '(null)', reason: rejected
>Done.
> via_superio_cfg: unimplemented register 0xf6
> via_superio_cfg: unimplemented register 0xf7
> via_superio_cfg: unimplemented register 0xf2
> Invalid access at addr 0xFE84, size 1, region '(null)', reason: rejected
> Invalid access at addr 0xFE85, size 1, region '(null)', reason: rejected
> Invalid access at addr 0xFE86, size 1, region '(null)', reason: rejected
> Invalid access at addr 0xFE88, size 1, region 

R: R: [PULL 0/3] ppc-for-6.1 queue 20210713

[luigi burdo]

: Unimplemented register read 0x10
mv64361_write: Unimplemented register write 0xc88 = 0
mv64361_read: Unimplemented register read 0x210
mv64361_write: Unimplemented register write 0xd88 = 0
mv64361_read: Unimplemented register read 0x20
mv64361_write: Unimplemented register write 0xc8c = 0
mv64361_read: Unimplemented register read 0x220
mv64361_write: Unimplemented register write 0xd8c = 0
mv64361_write: Unimplemented register write 0xc90 = 0
mv64361_write: Unimplemented register write 0xd90 = 0
mv64361_write: Unimplemented register write 0xd98 = 0
mv64361_write: Unimplemented register write 0xc94 = 0
mv64361_write: Unimplemented register write 0xd94 = 0
mv64361_write: Unimplemented register write 0xd9c = 0
mv64361_write: Unimplemented register write 0xda0 = 0
mv64361_write: Unimplemented register write 0xda4 = 0
mv64361_write: Unimplemented register write 0xda8 = 0
mv64361_write: Unimplemented register write 0xe80 = 0
Done.
Configuring ETH...mv64361_write: Unimplemented register write 0x2290 = 3f
mv64361_read: Unimplemented register read 0x10
mv64361_write: Unimplemented register write 0x2204 = 0
mv64361_write: Unimplemented register write 0x2200 = 0
mv64361_read: Unimplemented register read 0x210
mv64361_write: Unimplemented register write 0x220c = 0
mv64361_write: Unimplemented register write 0x2208 = 0
mv64361_read: Unimplemented register read 0x20
mv64361_write: Unimplemented register write 0x2214 = 0
mv64361_write: Unimplemented register write 0x2210 = 0
mv64361_read: Unimplemented register read 0x220
mv64361_write: Unimplemented register write 0x221c = 0
mv64361_write: Unimplemented register write 0x2218 = 0
mv64361_write: Unimplemented register write 0x2220 = 0
mv64361_write: Unimplemented register write 0x2224 = 0
mv64361_write: Unimplemented register write 0x2228 = 0
mv64361_write: Unimplemented register write 0x222c = 0
mv64361_write: Unimplemented register write 0x2290 = 3f
mv64361_write: Unimplemented register write 0x2000 = e0
 Done.
mv64361_write: Unimplemented register write 0xd9c = 1000
mv64361_read: Unimplemented register read 0xcbc
mv64361_write: Unimplemented register write 0xcbc = 0
mv64361_write: Unimplemented register write 0xf008 = 30011
mv64361_write: Unimplemented register write 0x1d00 = 801f0030
mv64361_read: Unimplemented register read 0xc80
mv64361_write: Unimplemented register write 0xc80 = 0
mv64361_read: Unimplemented register read 0x1424
mv64361_write: Unimplemented register write 0x1424 = 100
Releasing IDE reset ...Done.
Configuring Legacy Devices
Initializing KBD...Invalid access at addr 0xFE0003F0, size 1, region '(null)', 
reason: rejected
Done.
via_superio_cfg: unimplemented register 0xf6
via_superio_cfg: unimplemented register 0xf7
via_superio_cfg: unimplemented register 0xf2
Invalid access at addr 0xFE84, size 1, region '(null)', reason: rejected
Invalid access at addr 0xFE85, size 1, region '(null)', reason: rejected
Invalid access at addr 0xFE86, size 1, region '(null)', reason: rejected
Invalid access at addr 0xFE88, size 1, region '(null)', reason: rejected
Invalid access at addr 0xFE8C, size 1, region '(null)', reason: rejected
Invalid access at addr 0xFE8D, size 1, region '(null)', reason: rejected
Invalid access at addr 0xFE8E, size 1, region '(null)', reason: rejected
Testing 1000 Bytes, Pass:  Failed: 

In dmesg i had many of this.

[ 3634.418495] kvmppc_exit_pr_progint: emulation at 700 failed (0700)
[ 3634.418525] Couldn't emulate instruction 0x0700 (op 0 xop 896)
[ 3634.418551] Couldn't emulate instruction 0x0700 (op 0 xop 896)
[ 3634.418577] Couldn't emulate instruction 0x0700 (op 0 xop 896)
[ 3634.418603] Couldn't emulate instr...

___
i will build  latest linux kernel and do new test.
thanks
Luigi


Da: BALATON Zoltan 
Inviato: sabato 17 luglio 2021 21:55
A: luigi burdo 
Cc: David Gibson ; peter.mayd...@linaro.org 
; gr...@kaod.org ; 
qemu-...@nongnu.org ; qemu-devel@nongnu.org 

Oggetto: Re: R: [PULL 0/3] ppc-for-6.1 queue 20210713

On Sat, 17 Jul 2021, luigi burdo wrote:
> Hi
> i small report
> im try to build last relesase on a PowerMac G5 quad on debian sid PPC64 but 
> ld exit with an error:

Looks like it's gcc that crashes not ld. If you're sure it's not a
hardware problem this may be a gcc bug. Sometimes big compile jobs can
break if a machine is not stable but if it always fails at the same place
and does not fail when compiling something else like a Linux kernel then
it's more likely to be an actual bug. That function has some crazy use of
macros so maybe it's exposing some bug in gcc. You could restrict what
targets you build with --target-list configure option of QEMU if you don't
actually need mips (compiling will be faster if yo

R: R: [PULL 0/3] ppc-for-6.1 queue 20210713

[luigi burdo]

Hi Zoltan can be the gcc, in past on ppc we face the same kind of issue.
 i will ask some other guys in the debian ppc ML if can try to build qemu and 
see if they have the same issue. in positive case we will report to the 
mantainer.
Thanks
Luigi


Da: BALATON Zoltan 
Inviato: sabato 17 luglio 2021 21:55
A: luigi burdo 
Cc: David Gibson ; peter.mayd...@linaro.org 
; gr...@kaod.org ; 
qemu-...@nongnu.org ; qemu-devel@nongnu.org 

Oggetto: Re: R: [PULL 0/3] ppc-for-6.1 queue 20210713

On Sat, 17 Jul 2021, luigi burdo wrote:
> Hi
> i small report
> im try to build last relesase on a PowerMac G5 quad on debian sid PPC64 but 
> ld exit with an error:

Looks like it's gcc that crashes not ld. If you're sure it's not a
hardware problem this may be a gcc bug. Sometimes big compile jobs can
break if a machine is not stable but if it always fails at the same place
and does not fail when compiling something else like a Linux kernel then
it's more likely to be an actual bug. That function has some crazy use of
macros so maybe it's exposing some bug in gcc. You could restrict what
targets you build with --target-list configure option of QEMU if you don't
actually need mips (compiling will be faster if you only build the targets
you need) or you can try with clang if available in your distro to check
if that works better. If this can be consistently reproduced you could try
reporting it to gcc as the error message suggests. Probably not much QEMU
can do about it.

Regards,
BALATON Zoltan

> gigi@debian:~/src/tags/ppc-for-6.1-20210713/build$ ninja
> [3864/9215] Compiling C object 
> libqemu-mipsel-softmmu.fa.p/target_mips_tcg_msa_helper.c.o
> FAILED: libqemu-mipsel-softmmu.fa.p/target_mips_tcg_msa_helper.c.o
> cc -Ilibqemu-mipsel-softmmu.fa.p -I. -I.. -Itarget/mips -I../target/mips 
> -I../capstone/include/capstone -Iqapi -Itrace -Iui -Iui/shader 
> -I/usr/include/pixman-1 -I/usr/include/glib-2.0 
> -I/usr/lib/powerpc64-linux-gnu/glib-2.0/include -fdiagnostics-color=auto 
> -pipe -Wall -Winvalid-pch -Werror -std=gnu11 -O2 -g -isystem 
> /home/gigi/src/tags/ppc-for-6.1-20210713/linux-headers -isystem linux-headers 
> -iquote . -iquote /home/gigi/src/tags/ppc-for-6.1-20210713 -iquote 
> /home/gigi/src/tags/ppc-for-6.1-20210713/include -iquote 
> /home/gigi/src/tags/ppc-for-6.1-20210713/disas/libvixl -iquote 
> /home/gigi/src/tags/ppc-for-6.1-20210713/tcg/ppc -pthread -U_FORTIFY_SOURCE 
> -D_FORTIFY_SOURCE=2 -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 
> -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef 
> -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv 
> -Wold-style-declaration -Wold-style-definition -Wtype-limits 
> -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempt
 y-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined 
-Wimplicit-fallthrough=2 -Wno-missing-include-dirs -Wno-shift-negative-value 
-Wno-psabi -fstack-protector-strong -fPIE -isystem../linux-headers 
-isystemlinux-headers -DNEED_CPU_H 
'-DCONFIG_TARGET="mipsel-softmmu-config-target.h"' 
'-DCONFIG_DEVICES="mipsel-softmmu-config-devices.h"' -MD -MQ 
libqemu-mipsel-softmmu.fa.p/target_mips_tcg_msa_helper.c.o -MF 
libqemu-mipsel-softmmu.fa.p/target_mips_tcg_msa_helper.c.o.d -o 
libqemu-mipsel-softmmu.fa.p/target_mips_tcg_msa_helper.c.o -c 
../target/mips/tcg/msa_helper.c
> during RTL pass: sched1
> ../target/mips/tcg/msa_helper.c: In function ‘helper_msa_fmin_df’:
> ../target/mips/tcg/msa_helper.c:7536:1: internal compiler error: Errore di 
> segmentazione
> 7536 | }
>  | ^
> 0x3fffa7b8e1c3 generic_start_main
> ../csu/libc-start.c:308
> 0x3fffa7b8e3d3 __libc_start_main
> ../sysdeps/unix/sysv/linux/powerpc/libc-start.c:98
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
> [3869/9215] Compiling C object 
> libqemu-mipsel-softmmu.fa.p/target_mips_tcg_translate.c.o
> ninja: build stopped: subcommand failed.
>
> Ciao
> Luigi
> 
> Da: Qemu-ppc  per conto 
> di David Gibson 
> Inviato: martedì 13 luglio 2021 04:07
> A: peter.mayd...@linaro.org ; gr...@kaod.org 
> 
> Cc: qemu-...@nongnu.org ; qemu-devel@nongnu.org 
> ; David Gibson 
> Oggetto: [PULL 0/3] ppc-for-6.1 queue 20210713
>
> The following changes since commit 57e28d34c0cb04abf7683ac6a12c87ede447c320:
>
>  Merge remote-tracking branch 'remotes/cohuck-gitlab/tags/s390x-20210708' 
> into staging (2021-07-12 19:15:11 +0100)
>
> are available in the Git repository at:
>
>  https://gitlab.com/dgibson/qemu.git tags/ppc-for-6.1-20210713
>
> for you to fetch changes up to c785a40179b10ce2d7a4afdb04f63c98d53a1756:
>
>  mv64361: Remove ext

R: [PULL 0/3] ppc-for-6.1 queue 20210713

[luigi burdo]

Hi
i small report
im try to build last relesase on a PowerMac G5 quad on debian sid PPC64 but ld 
exit with an error:


gigi@debian:~/src/tags/ppc-for-6.1-20210713/build$ ninja
[3864/9215] Compiling C object 
libqemu-mipsel-softmmu.fa.p/target_mips_tcg_msa_helper.c.o
FAILED: libqemu-mipsel-softmmu.fa.p/target_mips_tcg_msa_helper.c.o
cc -Ilibqemu-mipsel-softmmu.fa.p -I. -I.. -Itarget/mips -I../target/mips 
-I../capstone/include/capstone -Iqapi -Itrace -Iui -Iui/shader 
-I/usr/include/pixman-1 -I/usr/include/glib-2.0 
-I/usr/lib/powerpc64-linux-gnu/glib-2.0/include -fdiagnostics-color=auto -pipe 
-Wall -Winvalid-pch -Werror -std=gnu11 -O2 -g -isystem 
/home/gigi/src/tags/ppc-for-6.1-20210713/linux-headers -isystem linux-headers 
-iquote . -iquote /home/gigi/src/tags/ppc-for-6.1-20210713 -iquote 
/home/gigi/src/tags/ppc-for-6.1-20210713/include -iquote 
/home/gigi/src/tags/ppc-for-6.1-20210713/disas/libvixl -iquote 
/home/gigi/src/tags/ppc-for-6.1-20210713/tcg/ppc -pthread -U_FORTIFY_SOURCE 
-D_FORTIFY_SOURCE=2 -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 
-D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef 
-Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv 
-Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security 
-Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs 
-Wendif-labels -Wexpansion-to-defined -Wimplicit-fallthrough=2 
-Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi 
-fstack-protector-strong -fPIE -isystem../linux-headers -isystemlinux-headers 
-DNEED_CPU_H '-DCONFIG_TARGET="mipsel-softmmu-config-target.h"' 
'-DCONFIG_DEVICES="mipsel-softmmu-config-devices.h"' -MD -MQ 
libqemu-mipsel-softmmu.fa.p/target_mips_tcg_msa_helper.c.o -MF 
libqemu-mipsel-softmmu.fa.p/target_mips_tcg_msa_helper.c.o.d -o 
libqemu-mipsel-softmmu.fa.p/target_mips_tcg_msa_helper.c.o -c 
../target/mips/tcg/msa_helper.c
during RTL pass: sched1
../target/mips/tcg/msa_helper.c: In function ‘helper_msa_fmin_df’:
../target/mips/tcg/msa_helper.c:7536:1: internal compiler error: Errore di 
segmentazione
 7536 | }
  | ^
0x3fffa7b8e1c3 generic_start_main
../csu/libc-start.c:308
0x3fffa7b8e3d3 __libc_start_main
../sysdeps/unix/sysv/linux/powerpc/libc-start.c:98
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
[3869/9215] Compiling C object 
libqemu-mipsel-softmmu.fa.p/target_mips_tcg_translate.c.o
ninja: build stopped: subcommand failed.

Ciao
Luigi

Da: Qemu-ppc  per conto 
di David Gibson 
Inviato: martedì 13 luglio 2021 04:07
A: peter.mayd...@linaro.org ; gr...@kaod.org 

Cc: qemu-...@nongnu.org ; qemu-devel@nongnu.org 
; David Gibson 
Oggetto: [PULL 0/3] ppc-for-6.1 queue 20210713

The following changes since commit 57e28d34c0cb04abf7683ac6a12c87ede447c320:

  Merge remote-tracking branch 'remotes/cohuck-gitlab/tags/s390x-20210708' into 
staging (2021-07-12 19:15:11 +0100)

are available in the Git repository at:

  https://gitlab.com/dgibson/qemu.git tags/ppc-for-6.1-20210713

for you to fetch changes up to c785a40179b10ce2d7a4afdb04f63c98d53a1756:

  mv64361: Remove extra break from a switch case (2021-07-13 10:12:17 +1000)


ppc patch queue 2021-07-13

I thought I'd sent the last PR before the 6.1 soft freeze, but
unfortunately I need one more.  This last minute one puts in a SLOF
update, along with a couple of bugfixes.


Alexey Kardashevskiy (1):
  pseries: Update SLOF firmware image

BALATON Zoltan (2):
  ppc/pegasos2: Allow setprop in VOF
  mv64361: Remove extra break from a switch case

 hw/pci-host/mv64361.c |   1 -
 hw/ppc/pegasos2.c |  10 ++
 pc-bios/README|   2 +-
 pc-bios/slof.bin  | Bin 96 -> 991744 bytes
 roms/SLOF |   2 +-
 5 files changed, 12 insertions(+), 3 deletions(-)

R: [RFC PATCH 0/5] ppc/Pegasos2 VOF

[luigi burdo]

Hi Zoltan,
i dont know if you know and if in the docs is described the pegasos II can 
support smp dual G4 cpu.
Here some hystorical info about this great machine from the past Phase 5 A\BOX 
(kosmoplovci.net).
i remember really good that period (when i was young man)... the  caipirinha 
become one of my best cocktail 

Ciao
Luigi


Da: Qemu-ppc  per conto 
di BALATON Zoltan 
Inviato: giovedì 10 giugno 2021 12:04
A: David Gibson 
Cc: qemu-...@nongnu.org ; qemu-devel@nongnu.org 

Oggetto: Re: [RFC PATCH 0/5] ppc/Pegasos2 VOF



On Thu, 10 Jun 2021, David Gibson wrote:

> On Thu, Jun 10, 2021 at 05:14:45PM +1000, Alexey Kardashevskiy wrote:
>>
>>
>> On 6/9/21 20:28, BALATON Zoltan wrote:
>>> On Wed, 9 Jun 2021, Alexey Kardashevskiy wrote:
 On 6/7/21 01:46, BALATON Zoltan wrote:
> Based-on: <20210520090557.435689-1-...@ozlabs.ru>
> ^ That is v20 of Alexey's VOF patch
>
> Hello,
>
> Posting these for early review now. I plan to rebase on the next VOF
> patch that hopefully fixes those points that I had to circumvent in
> patch 1 for now. I've reported these before but now all of those that
> are needed for pegasos2 are in one place. Other points I've reported
> could be clean ups but not sttictly needed.
>
> With this series on top of VOF v20 I can now boot Linux and MorphOS on
> pegasos2 without needing a firmware blob so I hope this is enough to
> get this board in 6.1 and also have it enabled so users can start
> using it. That means that VOF will also be merged by then. This now
> gives VOF another use case that may help it getting finished.
>
> I've also updated my development tree with this series here:
>
> https://osdn.net/projects/qmiga/scm/git/qemu/tree/pegasos2/
>
> Please review so I can do any needed changes together with the rebase
> on next VOF patch so we don't miss 6.1 this time.


 It would help if you provided the disk or/and kernel or/and
 initramdisk images and the example command line to give this a try.
 And said a few words who is this Pegasos2 guy :) The series looks ok
 to me otherwise. Thanks,
>>>
>>> These were in the original series adding this board:
>>>
>>> https://patchew.org/QEMU/cover.1616680239.git.bala...@eik.bme.hu/
>>
>>
>> Ah ok. Thanks!
>>
>>
>>> For testing I've used the kernel from debian 8.11.0 powerpc iso which is
>>> known to work on real hardware and MorphOS demo iso available from
>>> www.morphos-team.net. For debian look into 
>>> install/pegasos to find the
>>> right vmlinuz-chrp.initrd kernel, for MorphOS use the boot.img from root
>>> of the iso as -kernel.
>>>
>>> What's still missing is some rtas functions like get-time-of-day. Are
>>> these any kind of standard and is there a doc about their parameters and
>>> returns or I'll heave to find out from kernel sources? I plan to add
>>> these later but not needed to get it boot.
>>
>> pseries guests use what the LoPAPR spec (derived from sPAPR - "server PAPR")
>> describes:
>>
>> https://openpowerfoundation.org/?resource_lib=linux-on-power-architecture-platform-reference
>
> Of course pegasos won't remotely be PAPR, but you could look at how
> the RTAS functions are defined there.
>
> I'm not really sure of the origins of RTAS.  It's not in plain
> IEEE1275 (the original OF spec), but the fact pegasos uses it suggests
> it's not purely a PAPR thing, either.

Pegasos is supposed to be a CHRP platform so maybe there's something on it
in that doc, I haven't checked yet but now you mentioned these I should
probably look there.

Thenks,
BALATON Zoltan

R: Program counter stuck at 0xFFFFFFFC when emulating e5500 processor on T4240-RDB board

[luigi burdo]

HI Devid,
the kvm full work on e5500 cpu personally tested this on P5020 and P5040 when i 
had the varisys beta boards AmigaOne
But is  not possible made kvm-pr from an e5500 to and e6500 and vice versa.
the e5500 was not kvm-pr compatible with 604e instructions set, probably 
something is missing or locked in the cpu? just because i was using on the 
board standard PPC linux distros with only kernel with modules made for the 
e5500 machine and the system was working right.

Probably the e6500 is more compatible with 604e G3/G4 and 970 in Kvm-pr
Ciao
Luigi



Da: Qemu-ppc per conto di David Gibson
Inviato: Mercoledì, 11 Marzo, 2020 06:03
A: Philippe Mathieu-Daudé
Cc: Wayne Li; qemu-ppc; QEMU Developers
Oggetto: Re: Program counter stuck at 0xFFFC when emulating e5500 processor 
on T4240-RDB board

On Thu, Feb 20, 2020 at 09:44:13AM +0100, Philippe Mathieu-Daudé wrote:
> Hello,
>
> On 2/20/20 6:40 AM, Wayne Li wrote:
> > Dear QEMU list members,
>
> No subject: it is unlikely your question get noticed...
>
> Also you didn't Cc'ed the people who might help you (doing that for you):
>
> ./scripts/get_maintainer.pl -f target/ppc/cpu-models.c
> David Gibson  (maintainer:PowerPC TCG CPUs)
> qemu-...@nongnu.org (open list:PowerPC TCG CPUs)
> qemu-devel@nongnu.org (open list:All patches CC here)

Right.  Unfortunately the embedded cpu support is barely maintained,
so there's only a little bit of help I can give.

> > This will kind of be a repost but I'd like to post my question again
> > because I've gained some more knowledge that makes me feel that my
> > question would be easier to answer.  So we developed a custom-made QEMU
> > VM that emulates a custom machine that has an e5500 processor.  I'm
> > running this VM on a T4240-RDB board which has an e6500 processor and
> > I'm trying to get the VM running with KVM enabled.  The problem I'm
> > having is the program counter refuses to increment at all.  It just
> > stays at the address 0xFFFC.  On a run without KVM enabled, the VM
> > will also start executing at this same address but the program counter
> > beings to increment immediately.  I know this is a custom QEMU VM and
> > maybe some of the startup stuff we do could be causing problems, but
> > what could possibly stop the program counter from incrementing
> > altogether?
> >
> > Also, I do have another side question.  When running with KVM enabled, I
> > see the kernel-level ioctl call KVM_RUN running and then returning over
> > and over again (by the way before the VM kinda grinds to a halt I only
> > see QEMU make the KVM_RUN call twice, but the kernel-level ioctl
> > function is being called over and over again for some reason).  And each
> > time the KVM_RUN call returns, the return-from-interrupt takes the VM to
> > the address 0xFFFC.  What is the KVM_RUN ioctl call used for?  Why
> > is it being called over and over again?  Maybe if I understood this
> > better I'd be able to figure out what's stopping my program counter from
> > incrementing.

I don't really know if KVM even attempts to support e5500 cpus.  We'd
need to at least know what your host kernel is and what KVM variant it
is using.  What's the instruction at 0xfffc which seems not to be
handled here properly?  It sounds like you might be getting some sort
of rolling trap, because KVM isn't handling that instruction correctly.

The KVM_RUN is what causes KVM to actual enter the guest and execute
instructions.  It returns when something triggers a guest exit - a
trap or various other events can do this.

--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson

R: [RFC PATCH v2] target/ppc: Enable hardfloat for PPC

[luigi burdo]

Hi Zoltan,
i can say MacOs Leopard use multiple cores on PowerMac G5 Quad the most of the 
apps did for  Panter/Tiger/leopard use for sure 2 Core in smtp only apps did 
for Tiger/leopard use more than 2 Cores.
Ciao and thenks
 Luigi



Da: Qemu-ppc  per conto 
di BALATON Zoltan 
Inviato: mercoledì 26 febbraio 2020 12:28
A: Programmingkid 
Cc: Howard Spoelstra ; qemu-...@nongnu.org 
; qemu-devel qemu-devel ; David 
Gibson 
Oggetto: Re: [RFC PATCH v2] target/ppc: Enable hardfloat for PPC

On Wed, 26 Feb 2020, Programmingkid wrote:
> I think a timeout takes place and that is why audio stops playing. It is
> probably an USB OHCI issue. The other USB controller seems to work
> better.

Which other USB controller? Maybe you could try enabling some usb_ohci*
traces and see if they reveal anything.

>> The Amiga like OSes I'm interested in don't use multiple cores so I'm
>> mainly interested in improving single core performance. Also I'm not
>> sure if (part of) your problem is slow FPU preventing fast enough audio
>> decoding then having multiple CPUs with slow FPU would help as this may
>> use a single thread anyway.
>
> Good point. MTTCG might be the option that really helps with speed 
> improvements.

Only if you have multithreaded workload in the guest because AFAIK MTTCG
only runs different vcpus in parallel, it won't make single emulated CPU
faster in any way. OSX probably can benefit from having multiple cores
emulated but I don't think MacOS would use it apart from some apps maybe.

Regards,
BALATON Zoltan

Re: [Qemu-devel] [Qemu-ppc] [PATCH for-2.13 02/10] spapr: Remove support for PowerPC 970 with pseries machine type

[luigi burdo]

(because testing if we broke it means finding
a real 970 host).

Hi, i have a real 970 host if you need an hand to test just ask

Luigi

Re: [Qemu-devel] [Qemu-ppc] [PULL 00/30] ppc-for-2.12 queue 20180306

[luigi burdo]

HI,

i had test last git with Zoltan sam emultation but at start i recive this


./qemu-system-ppc -M sam460ex
qemu-system-ppc: 
/home/gigi/src/tags/ppc-for-2.12-20180306/include/qemu/rcu.h:89: 
rcu_read_unlock: asserzione "p_rcu_reader->depth != 0" non riuscita.
Annullato (core dump creato)


My machie is a Threadripper 1950x the distro is Ubuntu mate 17.10


Thanks

Luigi



Da: Qemu-ppc  per conto 
di Thomas Huth 
Inviato: martedì 6 marzo 2018 17:48
A: David Gibson; Mark Cave-Ayland
Cc: qemu-...@nongnu.org; qemu-devel@nongnu.org
Oggetto: Re: [Qemu-ppc] [Qemu-devel] [PULL 00/30] ppc-for-2.12 queue 20180306

On 06.03.2018 05:01, David Gibson wrote:
> The following changes since commit f2bb2d14c2958f3f5aef456bd2cdb1ff99f4a562:
>
>   Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' 
> into staging (2018-03-05 16:41:20 +)
>
> are available in the Git repository at:
>
>   git://github.com/dgibson/qemu.git tags/ppc-for-2.12-20180306
>
> for you to fetch changes up to 21b786f607b11d888f90bbb8c3414500515d11e7:
>
>   PowerPC: Add TS bits into msr_mask (2018-03-06 13:16:29 +1100)
>
> 
> ppc patch queue 2018-03-06
>
> This pull request supersedes ppc-for-2.12-20180302 which had compile
> problems with some gcc versions.  It also contains a few additional
> patches.
>
> Highlights are:
> * New Sam460ex machine type
> * Yet more fixes related to vcpu id allocation for spapr
> * Numerous macio cleanupsr
> * Some enhancements to the Spectre/Meltdown fixes for pseries,
>   allowing use of a better mitigation for indirect branch based
>   exploits
> * New pseries machine types with Spectre/Meltdown mitigations
>   enabled (stop gap until libvirt and management understands the
>   machine options)
> * A handful of other fixes
>
> 
> BALATON Zoltan (5):
>   ppc440_uc: Fix unintialized variable warning with older gcc
>   ppc440: Add emulation of plb-pcix controller found in some 440 SoCs
>   roms: Added git submodule for u-boot-sam460 (firmware for sam460ex)
>   pc-bios: Added u-boot-sam460 firmware binary
>   ppc: Add aCube Sam460ex board
>
> David Engraf (1):
>   PPC: e500: Fix duplicate kernel load and device tree overlap
>
> Greg Kurz (3):
>   spapr: fix missing CPU core nodes in DT when running with TCG
>   spapr: register dummy ICPs later
>   spapr: harden code that depends on VSMT
>
> Mark Cave-Ayland (13):
>   macio: embed DBDMA device directly within macio
>   macio: move ESCC device within the macio device
>   heathrow: QOMify heathrow PIC
>   heathrow: convert to trace-events
>   heathrow: change heathrow_pic_init() to return the heathrow device
>   macio: move macio related structures and defines into separate macio.h 
> file
>   mac_oldworld: use object link to pass heathrow PIC object to macio
>   openpic: move KVM-specific declarations into separate openpic_kvm.h file
>   openpic: move OpenPIC state and related definitions to openpic.h
>   mac_newworld: use object link to pass OpenPIC object to macio
>   macio: move setting of CUDA timebase frequency to macio_common_realize()
>   macio: remove macio_init() function
>   adb: add trace-events for monitoring keyboard/mouse during bus 
> enumeration

Something in the recent commits introduced a new way to cause unexpected
aborts of QEMU:

$ ppc64-softmmu/qemu-system-ppc64 -monitor stdio
QEMU 2.11.50 monitor - type 'help' for more information
(qemu) device_add macio-newworld
Unexpected error in qemu_chr_fe_init() at
/home/thuth/devel/qemu/chardev/char-fe.c:222:
Device 'serial0' is in use
Aborted (core dumped)

Of course it does not make sense to add a macio-newworld device on the
pseries machine, but QEMU should not abort in this case - it should just
print an error message and continue afterwards. Any ideas how to fix this?

 Thomas

Re: [Qemu-devel] [Qemu-ppc] [PULL 00/12] ppc-for-2.12 queue 20180108

[luigi burdo]

Hi Peter,

thanks for reply.

I will check the ram banks and will try again to build it .

but i have more fear about gcc now because the issue come exactly in the same 
point every time i try to rebuild everyting.


Thankyou

Luigi




This means that gcc crashed. This is either:
 (a) a hardware problem with your machine (eg bad memory)
or
 (b) a bug in gcc (which you can report to the gcc team
as they suggest in the error message)

You should check whether gcc reliably crashes in the
same way every time you try to build that source file.
If it does, that suggests a gcc bug is more likely. If
it sometimes works and sometimes doesn't, I would suspect
hardware problems.

thanks
-- PMM

Re: [Qemu-devel] [Qemu-ppc] [PULL 00/12] ppc-for-2.12 queue 20180108

[luigi burdo]

Hi devs sorry if i enter in the discussion about.

gcc gave errors in building this queue.

here i paste my build log.

https://pastebin.com/fXw2Whrq



This is my machine infos and so and so


Architecture:ppc64
CPU op-mode(s):  32-bit, 64-bit
Byte Order:  Big Endian
CPU(s):  4
On-line CPU(s) list: 0-3
Thread(s) per core:  1
Core(s) per socket:  1
Socket(s):   4
NUMA node(s):1
Model:   1.1 (pvr 0044 0101)
Model name:  PPC970MP, altivec supported
CPU max MHz: 2500.
CPU min MHz: 1250.
L1d cache:   32K
L1i cache:   64K
L2 cache:1024K
NUMA node0 CPU(s):   0-3


uname -a
Linux debian 4.9.67 #1 SMP Sat Dec 9 12:20:20 CET 2017 ppc64 GNU/Linux

gcc --version
gcc (Debian 7.2.0-19) 7.2.0



Regards
Luigi


Da: Qemu-ppc  per conto 
di David Gibson 
Inviato: martedì 9 gennaio 2018 13:16
A: Peter Maydell
Cc: Michael Roth; QEMU Developers; qemu-...@nongnu.org; Greg Kurz; 
sura...@au1.ibm.com
Oggetto: Re: [Qemu-ppc] [PULL 00/12] ppc-for-2.12 queue 20180108

On Tue, Jan 09, 2018 at 11:46:41AM +, Peter Maydell wrote:
> On 8 January 2018 at 05:53, David Gibson  wrote:
> > The following changes since commit 281f327487c9c9b1599f93c589a408bbf4a651b8:
> >
> >   Merge remote-tracking branch 
> > 'remotes/vivier/tags/m68k-for-2.12-pull-request' into staging (2017-12-22 
> > 00:11:36 +)
> >
> > are available in the Git repository at:
> >
> >   git://github.com/dgibson/qemu.git tags/ppc-for-2.12-20180108
> >
> > for you to fetch changes up to 9f173585d3f35345b2facce50620ce2cdda05f2f:
> >
> >   spapr: Correct compatibility mode setting for hotplugged CPUs (2018-01-08 
> > 13:33:17 +1100)
> >
> > 
> > ppc patch queue 2018-01-08
> >
> > This pull requests supersedes both ppc-for-2.12-20180103 and
> > ppc-for-2.12-20171219.  We've discovered that some substantial
> > extensions to the proposed capabilities infrastructure will be
> > valuable, amongst other things for managing/advertising workarounds
> > for the dreaded Meltdown/Spectre bugs.
> >
> > Although that could be done as follow on changes, since the caps
> > infrastructure hasn't been merged yet, we might as well pull it out
> > while we rework, and just merge the unrelated bugfixes.
> >
> > The last two pull requests apparently had problems on some arm32
> > systems.  I haven't been able to reproduce those, so I have no idea
> > which patch is causing them.  If we get lucky and it was one of the
> > patches I've removed from this series, this may also serve to unjam
> > the other fixes.
>
> This still hangs on my arm32 setup in the migration test. I'll see
> if I can identify what is going wrong.

Thanks.  Even if you can identify which patch it is and we can
postpone that one would be a bug help.

--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[http://www.ozlabs.org/~dgibson/dgibson-small.jpg]

David Gibson's Home Page - OzLabs
www.ozlabs.org
Home; Papers; Junk code; PGP Key; Ozlabs. David Gibson's Home Page. I'm a Linux 
kernel hacker, mostly, though I've also worked on other projects including, 
recently ...

Re: [Qemu-devel] ppce500 usb-ehci-pci issue on last uboot

[luigi burdo]

Hi Gerd,


>How can this be reproduced?


you need to build last uboot with the ehci pci option enabled and the usb 
command line enabled.

or just download my last e500 uboot build from here 
https://www.dropbox.com/s/xxlu6ivg3izlqvu/u-boot?dl=0


Run it as:

qemu-system-ppc64 -M ppce500 -cpu e5500 -m 512 -bios (path to the uboot image) 
-device usb-ehci (or another qemulated ehci pci device)  -serial stdio

you can attach some device on it for your tests


when the machine  run and you have the uboot prompt just do "usb start" and you 
will see the hang for some second of the machine and after the report from 
uboot of an error of the ehci.


Ciao
Luigi

Re: [Qemu-devel] ppce500 usb-ehci-pci issue on last uboot

[luigi burdo]

Hi Gerd,
i had test it yesterday on Little Endian machine host (Apple  Osx Sierra)
the issue is present there too.

Ciao
Luigi




hi Gerd,
yes the host is a big endian but i can test it on an little endian host too and 
report.
About xhci or ohci the uboot dont recognize it . ehci-pci are the only usb pci 
board from where uboot on ppce500 vm  can make the load from device or use 
directly the device attached on  it if cmd reset work for initislize the board.


> Il giorno 27 set 2017, alle ore 13:34, Gerd Hoffmann  ha 
> scritto:
>
>  Hi,
>
>> "actually, I tried it yesterday and it seems to be a bug in qemu in
>> case you reset the EHCI controller, it doesn't come out of reset for
>> whatever reason ... so you probably want to talk to the qemu guys,
>> it's when U-Boot sets USBCMD RESET bit and then does handshake, the
>> controller is stuck with reset bit asserted"
>>
>>
>> i ask if possible to fix it?
>
> Nothing obvious in the ehci reset code.  Needs someone debugging it ...
>
> Is this on a bigendian host?  If so this could be endian bugs in the
> ehci emulation.
>
> You could also try xhci or ohci instead, these are known-working on
> bigendian hosts (used by ppc64 pseries).
>
> cheers,
>  Gerd
>
>

Re: [Qemu-devel] ppce500 usb-ehci-pci issue on last uboot

[luigi burdo]

hi Gerd,
yes the host is a big endian but i can test it on an little endian host too and 
report.
About xhci or ohci the uboot dont recognize it . ehci-pci are the only usb pci 
board from where uboot on ppce500 vm  can make the load from device or use 
directly the device attached on  it if cmd reset work for initislize the board.

regards
luigi

Inviato da iPad

> Il giorno 27 set 2017, alle ore 13:34, Gerd Hoffmann  ha 
> scritto:
> 
>  Hi,
> 
>> "actually, I tried it yesterday and it seems to be a bug in qemu in
>> case you reset the EHCI controller, it doesn't come out of reset for
>> whatever reason ... so you probably want to talk to the qemu guys,
>> it's when U-Boot sets USBCMD RESET bit and then does handshake, the
>> controller is stuck with reset bit asserted"
>> 
>> 
>> i ask if possible to fix it?
> 
> Nothing obvious in the ehci reset code.  Needs someone debugging it ...
> 
> Is this on a bigendian host?  If so this could be endian bugs in the
> ehci emulation.
> 
> You could also try xhci or ohci instead, these are known-working on
> bigendian hosts (used by ppc64 pseries).
> 
> cheers,
>  Gerd
> 
> 

[Qemu-devel] ppce500 usb-ehci-pci issue on last uboot

[luigi burdo]

Hi all,

the last uboot git mainstream gave the opportunity to made usb ehci-pci work 
and gave to the vm the opportunity to load from

usb pendrive files, configurations, use a use mouse and keyboard.

i build the uboot with qemu-ppce500_defconfig  machine this feature was 
configured without problem and uboot build without issue.

just adding to the  .config

CONFIG_CMD_USB=y

CONFIG_USB=y

CONFIG_USB_EHCI_HCD=y

CONFIG_USB_EHCI_PCI=y




here the new uboot console working on ppce500 -cpu e5500

U-Boot 2017.09-00322-g1f6049e (Sep 25 2017 - 20:50:48 +0200)


BusDevFun  VendorId   DeviceId   Device Class   Sub-Class
_
00.01.00   0x8086 0x24cd Serial bus controller   0x03
00.02.00   0x8086 0x2922 Mass storage controller 0x06
00.03.00   0x1234 0x Display controller  0x00
00.06.00   0x1af4 0x1000 Network controller  0x00


when i  run the command usb start inside the uboot console:

=> usb start
starting USB...
USB0:   EHCI fail to reset
lowlevel init failed
USB error: all controllers failed lowlevel init


I been meet uboot developers and after one afternoon in drilling inside the 
code of uboot they assume the issue was come in qemu and not in uboot.


from an uboot dev:
"actually, I tried it yesterday and it seems to be a bug in qemu in case you 
reset the EHCI controller, it doesn't come out of reset for whatever reason ... 
so you probably want to talk to the qemu guys, it's when U-Boot sets USBCMD 
RESET bit and then does handshake, the controller is stuck with reset bit 
asserted"


i ask if possible to fix it?

here some past of drilling inside uboot

https://pastebin.com/93DRFGcM

https://pastebin.com/g5j2XN6R

https://pastebin.com/KDMCU7C5

https://pastebin.com/ndLtNQxS


Thanks

Luigi

Re: [Qemu-devel] [Qemu-ppc] e5500 pcce500 disabled network and no video on device virtio-gpu or virtio gpu-pci

[luigi burdo]

i found probably another issue,

i cant made the img boot if i run qemu 2.10 build on an X86_64 (endianess?).

tested on qemu 2.10 on MacOsx 10.12 and on Ubuntu Mate 17.04 (amd64)


this issue is present if i choose -hda instead -device file= too


[8.564326] ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 300)

[8.569373] ata6.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, 
err_mask=0x80)

[8.575744] ata6: limiting SATA link speed to 1.5 Gbps

[   14.195086] ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 310)

[   14.200326] ata6.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, 
err_mask=0x80)

[   19.828186] ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 310)[   
19.867419] VFS: Cannot open root device "sda2" or unknown-block(0,0): error -6

[   19.872611] Please append a correct "root=" boot option; here are the availa

[   19.967119] Kernel panic - not syncing: VFS: Unable to mount root fs on 
unknown-block(0,0)


Luigi




Oggetto: [Qemu-ppc] e5500 pcce500 disabled network and no video on device 
virtio-gpu or virtio gpu-pci


Hi all,

like the topic i cant made the machine goes online plus the video output don 
work.

on this email i made the links with

kernel 411 with virtio,bochs etc etc .

a base of distro with kernel modules

my usual lines configuration.


Note i tested all on real e5500 machine and all is working there.

Hope my job will help in fixing and developing


ubuntu base : 
https://www.dropbox.com/s/yzp657yad3cp48n/Amigaone_Ubuntu_16.04-Base-1.img.gz?dl=0


Kernel 411:https://www.dropbox.com/s/ne49j5bo62680l0/u411.gz?dl=0


qemu line config: https://www.dropbox.com/s/j5kekeut75ogs9r/qemu_config.gz?dl=0


Thanks

Luigi

[Qemu-devel] e5500 pcce500 disabled network and no video on device virtio-gpu or virtio gpu-pci

[luigi burdo]

Hi all,

like the topic i cant made the machine goes online plus the video output don 
work.

on this email i made the links with

kernel 411 with virtio,bochs etc etc .

a base of distro with kernel modules

my usual lines configuration.


Note i tested all on real e5500 machine and all is working there.

Hope my job will help in fixing and developing


ubuntu base : 
https://www.dropbox.com/s/yzp657yad3cp48n/Amigaone_Ubuntu_16.04-Base-1.img.gz?dl=0


Kernel 411:https://www.dropbox.com/s/ne49j5bo62680l0/u411.gz?dl=0


qemu line config: https://www.dropbox.com/s/j5kekeut75ogs9r/qemu_config.gz?dl=0


Thanks

Luigi

Re: [Qemu-devel] [Qemu-ppc] Qemu 2.10 rc4 build issue on BE

[luigi burdo]

Hi Thomas,

i will check again and report.

Luigi



In your log there is:


But if you have a look at the freshly unpacked sources, that line
clearly reads "goto out;" and not "gCto out;" ... so it looks like
something messed up your sources very badly.
Can you reproduce this problem when starting again from scratch?

 Thomas

Re: [Qemu-devel] Qemu 2.10 rc4 build issue on BE (luigi burdo)

[luigi burdo]

Ok igor,

i will download and build again and report

Luigi



Da: Igor Mammedov <imamm...@redhat.com>
Inviato: lunedì 28 agosto 2017 11:32
A: luigi burdo
Cc: Programmingkid; qemu-...@nongnu.org; qemu-devel@nongnu.org qemu-devel
Oggetto: Re: [Qemu-devel] Qemu 2.10 rc4 build issue on BE (luigi burdo)

On Mon, 28 Aug 2017 09:14:48 +
luigi burdo <intermedi...@hotmail.com> wrote:

> Hi Igor,
>
>
> below errors look like corrupted source files
>
> >
>
>
> i ust dowloaded the compressed file from qemu website,unzipped with tar from 
> console (like i usually did)  and run configure and make.
>
> can be the file of rc4 from qemu website not right and need a repack?
I've just downloaded it from 
http://download.qemu-project.org/qemu-2.10.0-rc4.tar.xz
and unpacked, it works for me (i.e. hw/i386/pc.c isn't corrupted).

>
> Luigi
>

Re: [Qemu-devel] Qemu 2.10 rc4 build issue on BE (luigi burdo)

[luigi burdo]

Hi Igor,


below errors look like corrupted source files

>


i ust dowloaded the compressed file from qemu website,unzipped with tar from 
console (like i usually did)  and run configure and make.

can be the file of rc4 from qemu website not right and need a repack?


Luigi

Re: [Qemu-devel] Qemu 2.10 rc4 build issue on BE (luigi burdo)

[luigi burdo]

Hi,

this is the log that was attached in my email.

i will test only i386 softmmu when will return at home

thanks

Luigi


./configure 
--target-list=ppc64-softmmu,ppc-softmmu,x86_64-softmmu,arm-softmmu,i386-softmmu 
--with-sdlabi=2.0 --with-gtkabi=3.0 --audio-drv-list=pa,sdl,alsa 
--disable-werror
Install prefix/usr/local
BIOS directory/usr/local/share/qemu
binary directory  /usr/local/bin
library directory /usr/local/lib
module directory  /usr/local/lib/qemu
libexec directory /usr/local/libexec
include directory /usr/local/include
config directory  /usr/local/etc
local state directory   /usr/local/var
Manual directory  /usr/local/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path   /home/amigaone/Downloads/qemu-2.10.0-rc4
C compilercc
Host C compiler   cc
C++ compiler  c++
Objective-C compiler clang
ARFLAGS   rv
CFLAGS-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g
QEMU_CFLAGS   -I/usr/include/pixman-1  -pthread -I/usr/include/glib-2.0 
-I/usr/lib64/glib-2.0/include -DNCURSES_WIDECHAR -D_GNU_SOURCE -m64 
-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes 
-Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes 
-fno-strict-aliasing -fno-common -fwrapv  -Wendif-labels 
-Wno-shift-negative-value -Wno-missing-include-dirs -Wempty-body 
-Wnested-externs -Wformat-security -Wformat-y2k -Winit-self 
-Wignored-qualifiers -Wold-style-declaration -Wold-style-definition 
-Wtype-limits -fstack-protector-strong -I/usr/include/p11-kit-1   
-I/usr/include/libpng16 -I/usr/include/libdrm  -I/usr/include/libusb-1.0
LDFLAGS   -Wl,--warn-common -m64 -g
make  make
install   install
pythonpython -B
smbd  /usr/sbin/smbd
module supportno
host CPU  ppc64
host big endian   yes
target list   ppc64-softmmu ppc-softmmu x86_64-softmmu arm-softmmu 
i386-softmmu
gprof enabled no
sparse enabledno
strip binariesyes
profiler  no
static build  no
pixmansystem
SDL support   yes (2.0.5)
GTK support   yes (3.22.17)
GTK GL supportyes
VTE support   no
TLS priority  NORMAL
GNUTLS supportyes
GNUTLS rndyes
libgcrypt no
libgcrypt kdf no
nettleyes (3.3)
nettle kdfyes
libtasn1  yes
curses supportyes
virgl support yes
curl support  no
mingw32 support   no
Audio drivers pa sdl alsa
Block whitelist (rw)
Block whitelist (ro)
VirtFS supportyes
VNC support   yes
VNC SASL support  no
VNC JPEG support  yes
VNC PNG support   yes
xen support   no
brlapi supportno
bluez  supportno
Documentation no
PIE   no
vde support   no
netmap supportno
Linux AIO support yes
ATTR/XATTR support yes
Install blobs yes
KVM support   yes
HAX support   no
TCG support   yes
TCG debug enabled no
TCG interpreter   no
RDMA support  no
fdt support   yes
preadv supportyes
fdatasync yes
madvise   yes
posix_madvise yes
libcap-ng support no
vhost-net support yes
vhost-scsi support yes
vhost-vsock support yes
vhost-user support yes
Trace backendslog
spice support no
rbd support   no
xfsctl supportno
smartcard support no
libusbyes
usb net redir no
OpenGL supportyes
OpenGL dmabufsyes
libiscsi support  no
libnfs supportno
build guest agent yes
QGA VSS support   no
QGA w32 disk info no
QGA MSI support   no
seccomp support   no
coroutine backend ucontext
coroutine poolyes
debug stack usage no
crypto afalg  no
GlusterFS support no
gcov  gcov
gcov enabled  no
TPM support   yes
libssh2 support   no
TPM passthrough   no
QOM debugging yes
Live block migration yes
lzo support   no
snappy supportyes
bzip2 support yes
NUMA host support yes
tcmalloc support  no
jemalloc support  no
avx2 optimization no
replication support yes
VxHS block device no




[$ make -j4
  GEN ppc64-softmmu/config-devices.mak.tmp
  GEN ppc-softmmu/config-devices.mak.tmp
  GEN x86_64-softmmu/config-devices.mak.tmp
  GEN arm-softmmu/config-devices.mak.tmp
  GEN arm-softmmu/config-devices.mak
  GEN x86_64-softmmu/config-devices.mak
  GEN ppc-softmmu/config-devices.mak
  GEN ppc64-softmmu/config-devices.mak
  GEN i386-softmmu/config-devices.mak.tmp
  GEN config-host.h
  GEN qemu-options.def
  GEN qmp-commands.h
  GEN i386-softmmu/config-devices.mak
  GEN qapi-types.h
  GEN qapi-visit.h
  GEN qapi-event.h
  GEN qmp-marshal.c
  GEN qapi-types.c
  GEN qapi-visit.c
  GEN qapi-event.c
  GEN qmp-introspect.h
  GEN qmp-introspect.c
  GEN trace/generated-tcg-tracers.h
  GEN trace/generated-helpers-wrappers.h
  GEN trace/generated-helpers.h
  GEN trace/generated-helpers.c
  GEN module_block.h
  GEN tests/test-qapi-types.h
  GEN tests/test-qapi-visit.h
  GEN 

[Qemu-devel] Qemu 2.10 rc4 build issue on BE

[luigi burdo]

Hi all,

the last rc4 from the qemu website fail in build in some parts on BE hardware.

attached on this email there is the configure and the build log hope it helps


My machine is : PowerMac G5 Quad .

Distro is Ferdora 25 PPC64.



Thanks

Luigi

 ./configure 
--target-list=ppc64-softmmu,ppc-softmmu,x86_64-softmmu,arm-softmmu,i386-softmmu 
--with-sdlabi=2.0 --with-gtkabi=3.0 --audio-drv-list=pa,sdl,alsa 
--disable-werror
Install prefix/usr/local
BIOS directory/usr/local/share/qemu
binary directory  /usr/local/bin
library directory /usr/local/lib
module directory  /usr/local/lib/qemu
libexec directory /usr/local/libexec
include directory /usr/local/include
config directory  /usr/local/etc
local state directory   /usr/local/var
Manual directory  /usr/local/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path   /home/amigaone/Downloads/qemu-2.10.0-rc4
C compilercc
Host C compiler   cc
C++ compiler  c++
Objective-C compiler clang
ARFLAGS   rv
CFLAGS-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g 
QEMU_CFLAGS   -I/usr/include/pixman-1  -pthread -I/usr/include/glib-2.0 
-I/usr/lib64/glib-2.0/include -DNCURSES_WIDECHAR -D_GNU_SOURCE -m64 
-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes 
-Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes 
-fno-strict-aliasing -fno-common -fwrapv  -Wendif-labels 
-Wno-shift-negative-value -Wno-missing-include-dirs -Wempty-body 
-Wnested-externs -Wformat-security -Wformat-y2k -Winit-self 
-Wignored-qualifiers -Wold-style-declaration -Wold-style-definition 
-Wtype-limits -fstack-protector-strong -I/usr/include/p11-kit-1   
-I/usr/include/libpng16 -I/usr/include/libdrm  -I/usr/include/libusb-1.0
LDFLAGS   -Wl,--warn-common -m64 -g 
make  make
install   install
pythonpython -B
smbd  /usr/sbin/smbd
module supportno
host CPU  ppc64
host big endian   yes
target list   ppc64-softmmu ppc-softmmu x86_64-softmmu arm-softmmu 
i386-softmmu
gprof enabled no
sparse enabledno
strip binariesyes
profiler  no
static build  no
pixmansystem
SDL support   yes (2.0.5)
GTK support   yes (3.22.17)
GTK GL supportyes
VTE support   no 
TLS priority  NORMAL
GNUTLS supportyes
GNUTLS rndyes
libgcrypt no
libgcrypt kdf no
nettleyes (3.3)
nettle kdfyes
libtasn1  yes
curses supportyes
virgl support yes
curl support  no
mingw32 support   no
Audio drivers pa sdl alsa
Block whitelist (rw) 
Block whitelist (ro) 
VirtFS supportyes
VNC support   yes
VNC SASL support  no
VNC JPEG support  yes
VNC PNG support   yes
xen support   no
brlapi supportno
bluez  supportno
Documentation no
PIE   no
vde support   no
netmap supportno
Linux AIO support yes
ATTR/XATTR support yes
Install blobs yes
KVM support   yes
HAX support   no
TCG support   yes
TCG debug enabled no
TCG interpreter   no
RDMA support  no
fdt support   yes
preadv supportyes
fdatasync yes
madvise   yes
posix_madvise yes
libcap-ng support no
vhost-net support yes
vhost-scsi support yes
vhost-vsock support yes
vhost-user support yes
Trace backendslog
spice support no 
rbd support   no
xfsctl supportno
smartcard support no
libusbyes
usb net redir no
OpenGL supportyes
OpenGL dmabufsyes
libiscsi support  no
libnfs supportno
build guest agent yes
QGA VSS support   no
QGA w32 disk info no
QGA MSI support   no
seccomp support   no
coroutine backend ucontext
coroutine poolyes
debug stack usage no
crypto afalg  no
GlusterFS support no
gcov  gcov
gcov enabled  no
TPM support   yes
libssh2 support   no
TPM passthrough   no
QOM debugging yes
Live block migration yes
lzo support   no
snappy supportyes
bzip2 support yes
NUMA host support yes
tcmalloc support  no
jemalloc support  no
avx2 optimization no
replication support yes
VxHS block device no




[$ make -j4
  GEN ppc64-softmmu/config-devices.mak.tmp
  GEN ppc-softmmu/config-devices.mak.tmp
  GEN x86_64-softmmu/config-devices.mak.tmp
  GEN arm-softmmu/config-devices.mak.tmp
  GEN arm-softmmu/config-devices.mak
  GEN x86_64-softmmu/config-devices.mak
  GEN ppc-softmmu/config-devices.mak
  GEN ppc64-softmmu/config-devices.mak
  GEN i386-softmmu/config-devices.mak.tmp
  GEN config-host.h
  GEN qemu-options.def
  GEN qmp-commands.h
  GEN i386-softmmu/config-devices.mak
  GEN qapi-types.h
  GEN qapi-visit.h
  GEN qapi-event.h
  GEN qmp-marshal.c
  GEN qapi-types.c
  GEN qapi-visit.c
  GEN qapi-event.c
  GEN qmp-introspect.h
  GEN qmp-introspect.c
  GEN trace/generated-tcg-tracers.h
  GEN trace/generated-helpers-wrappers.h
  GEN trace/generated-helpers.h
  GEN 

Re: [Qemu-devel] [Qemu-ppc] [PATCH 15/15] ppc: Add aCube Sam460ex board

[luigi burdo]

Hi Zoltan,

>So I chose to

>use the sii3112 by default.
right chooice because internal sata on sam460 had issue and wont boot 
os4,morphos... only the cdrom was booting if i remember  good from internal 
sata 0.
personally when i had a Sam460ex i was using a sii3114 or internal micro sd for 
boot... the sii was perfect compatible with sam uboot.

Thanks
Luigi

Re: [Qemu-devel] [Qemu-ppc] [RFC PATCH 09/12] ppc440: Add emulation of plb-pcix controller found in some 440 SoCs

[luigi burdo]

hi Balaton,
> I know about this and if you read the cover message (RFC PATCH 00/12) I link 
> to a fixed version of that U-Boot firmware (rebuilt from source with the 
> mentioned patches) which works with this emulation. (The original one from 
> the updater also starts but cannot boot due to some problems which are fixed 
> by these patches in my image. This is described in the cover message.) With 
> that fixed firmware image it should be possible to at least try booting 
> AmigaOS on the emulation and get some logs. I'd be surprised if it also 
> worked at this point but I could not try it as it needs an appropriate 
> AmigaOS version that runs on the Sam460. It should produce some logs though 
> with -serial stdio which may help finding what is missing.

i have sam460 amigaos cdrom iso as my backup and can test it inside qemu. 
sharing the logs if you needed.

> I think it would not be possible to use the U-Boot in QEMU now as that is for 
> e500 CPU but this is not needed either. See above, we are aiming to emulate 
> enough of the board that it can run the original firmware which should be 
> able to boot these Amiga like OSes and normal Linux images used on the 
> Sam460ex. This already works but things fail after or during boot currently. 
> This is what needs to be debugged. So we'd need someone who has a Sam460 (ex 
> or cr) board and can test on that to get logs from OSes on real hardware for 
> comparison.

 about real hardware no problem i will ask inside amigan community if someone 
have the opportunity to share the serial debug of sam 460 runinng amigaos.

can i ask you something ?
why you dont try to integrate in qemu the pegasos 2 or the efika machine. i 
have the feeling that probably it can be more simple because more old machine 
and components.

bye 
luigi

Re: [Qemu-devel] [Qemu-ppc] [RFC PATCH 09/12] ppc440: Add emulation of plb-pcix controller found in some 440 SoCs

[luigi burdo]

hi Balaton,
i can help with amigaos4 for sam .
i can test it on P5040 book3e and on G5 quad book3s machine.
note sam for boot amigaos need a special modified version of uboot that is 
available on acube website it is a firmware update. without modified uboot will 
be not posdible auto boot amigaos.
idont know if is possible use standard uboot incuded in qemu for boot amigaos 
from uboot command line. i can ask help to Enrico Vidale as my FB friend but i 
dont know if he will be available for this kind of helping.

bye
luigi

Inviato da iPad

> Il giorno 14 ago 2017, alle ore 01:30, BALATON Zoltan  ha 
> scritto:
> 
> Signed-off-by: BALATON Zoltan 
> ---
> hw/ppc/Makefile.objs |   2 +-
> hw/ppc/ppc440_pcix.c | 506 +++
> 2 files changed, 507 insertions(+), 1 deletion(-)
> create mode 100644 hw/ppc/ppc440_pcix.c
> 
> diff --git a/hw/ppc/Makefile.objs b/hw/ppc/Makefile.objs
> index 2077216..9c5d58a 100644
> --- a/hw/ppc/Makefile.objs
> +++ b/hw/ppc/Makefile.objs
> @@ -13,7 +13,7 @@ endif
> obj-$(CONFIG_PSERIES) += spapr_rtas_ddw.o
> # PowerPC 4xx boards
> obj-y += ppc405_boards.o ppc4xx_devs.o ppc405_uc.o ppc440_bamboo.o
> -obj-y += ppc4xx_pci.o ppc4xx_i2c.o
> +obj-y += ppc4xx_pci.o ppc440_pcix.o ppc4xx_i2c.o
> # PReP
> obj-$(CONFIG_PREP) += prep.o
> obj-$(CONFIG_PREP) += prep_systemio.o
> diff --git a/hw/ppc/ppc440_pcix.c b/hw/ppc/ppc440_pcix.c
> new file mode 100644
> index 000..3abd0d0
> --- /dev/null
> +++ b/hw/ppc/ppc440_pcix.c
> @@ -0,0 +1,506 @@
> +/*
> + * Emulation of the ibm,plb-pcix PCI controller
> + * This is found in some 440 SoCs e.g. the 460EX.
> + *
> + * Copyright (c) 2016 BALATON Zoltan
> + *
> + * Derived from ppc4xx_pci.c and pci-host/ppce500.c
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License, version 2, as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, see .
> + */
> +
> +#include "qemu/osdep.h"
> +#include "hw/hw.h"
> +#include "hw/ppc/ppc.h"
> +#include "hw/ppc/ppc4xx.h"
> +#include "hw/pci/pci.h"
> +#include "hw/pci/pci_host.h"
> +#include "exec/address-spaces.h"
> +
> +/*#define DEBUG_PCI*/
> +
> +#ifdef DEBUG_PCI
> +#define DPRINTF(fmt, ...) fprintf(stderr, fmt, ## __VA_ARGS__);
> +#else
> +#define DPRINTF(fmt, ...)
> +#endif /* DEBUG */
> +
> +struct PLBOutMap {
> +uint64_t la;
> +uint64_t pcia;
> +uint32_t sa;
> +MemoryRegion mr;
> +};
> +
> +struct PLBInMap {
> +uint64_t sa;
> +uint64_t la;
> +MemoryRegion mr;
> +};
> +
> +#define TYPE_PPC440_PCIX_HOST_BRIDGE "ppc440-pcix-host"
> +#define PPC440_PCIX_HOST_BRIDGE(obj) \
> +OBJECT_CHECK(PPC440PCIXState, (obj), TYPE_PPC440_PCIX_HOST_BRIDGE)
> +
> +#define PPC440_PCIX_NR_POMS 3
> +#define PPC440_PCIX_NR_PIMS 3
> +
> +typedef struct PPC440PCIXState {
> +PCIHostState parent_obj;
> +
> +PCIDevice *dev;
> +struct PLBOutMap pom[PPC440_PCIX_NR_POMS];
> +struct PLBInMap pim[PPC440_PCIX_NR_PIMS];
> +uint32_t sts;
> +qemu_irq irq[PCI_NUM_PINS];
> +AddressSpace bm_as;
> +MemoryRegion bm;
> +
> +MemoryRegion container;
> +MemoryRegion iomem;
> +MemoryRegion busmem;
> +} PPC440PCIXState;
> +
> +#define PPC440_REG_BASE 0x8
> +#define PPC440_REG_SIZE 0xff
> +
> +#define PCIC0_CFGADDR   0x0
> +#define PCIC0_CFGDATA   0x4
> +
> +#define PCIX0_POM0LAL   0x68
> +#define PCIX0_POM0LAH   0x6c
> +#define PCIX0_POM0SA0x70
> +#define PCIX0_POM0PCIAL 0x74
> +#define PCIX0_POM0PCIAH 0x78
> +#define PCIX0_POM1LAL   0x7c
> +#define PCIX0_POM1LAH   0x80
> +#define PCIX0_POM1SA0x84
> +#define PCIX0_POM1PCIAL 0x88
> +#define PCIX0_POM1PCIAH 0x8c
> +#define PCIX0_POM2SA0x90
> +
> +#define PCIX0_PIM0SAL   0x98
> +#define PCIX0_PIM0LAL   0x9c
> +#define PCIX0_PIM0LAH   0xa0
> +#define PCIX0_PIM1SA0xa4
> +#define PCIX0_PIM1LAL   0xa8
> +#define PCIX0_PIM1LAH   0xac
> +#define PCIX0_PIM2SAL   0xb0
> +#define PCIX0_PIM2LAL   0xb4
> +#define PCIX0_PIM2LAH   0xb8
> +#define PCIX0_PIM0SAH   0xf8
> +#define PCIX0_PIM2SAH   0xfc
> +
> +#define PCIX0_STS   0xe0
> +
> +#define PCI_ALL_SIZE(PPC440_REG_BASE + PPC440_REG_SIZE)
> +
> +/* DMA mapping */
> +static void ppc440_pcix_update_pim(PPC440PCIXState *s, int idx)
> +{
> +MemoryRegion *mem = >pim[idx].mr;
> +char *name;
> +uint64_t size;
> +
> +if (memory_region_is_mapped(mem)) {
> +/* Before we modify 

Re: [Qemu-devel] [Qemu-ppc] [PATCH v2 0/3] Enable MTTCG on PPC64

[luigi burdo]

Hi Alex,

>Have you declared the memory ordering for the guest?

Nope didnt know was necessary i just add the standard -m 2047


>See ca759f9e387db87e1719911f019bc60c74be9ed8 for an example.

watching it about

Thanks
Luigi

Re: [Qemu-devel] [Qemu-ppc] [PATCH v2 0/3] Enable MTTCG on PPC64

[luigi burdo]

Hi David and Nikuji,

can i suggest to remove the message:


Guest not yet converted to MTTCG - you may get unexpected results
where the mttcg is enabled?

another thing im finding  is this message
Guest expects a stronger memory ordering than the host provides
This may cause strange/hard to debug errors


I have 8 gb on my machine and this message come if i gave 512mb on the guest 
too.

Is possible know where the mttcg is already enabled?

i see on x86,i386,arm too if i set thread=multy the qemu start using the other 
host cores is on this guest system enabled?

if yes i have the same messages of ppc64 too :

Guest not yet converted to MTTCG - you may get unexpected results

and

Guest expects a stronger memory ordering than the host provides
This may cause strange/hard to debug errors


Ciao

Luigi


Applied to ppc-for-2.10.  Anyone object to that for 2/3, which isn't
within ppc code?

--
David Gibson

Re: [Qemu-devel] [Qemu-ppc] [PATCH v2 0/3] Enable MTTCG on PPC64

[luigi burdo]

Hi, on info is mttcg using an amouth of ram for cpu caching and translating 
operations like was did in past by emulators like virtualpc,realpc, bluelabel 
or softwindows?

in case of yes is possible increase it from the command line?

Thanks

Luigi

Re: [Qemu-devel] [Qemu-ppc] [PATCH v2 0/3] Enable MTTCG on PPC64

[luigi burdo]

Hi i dint made much tests,

but for sure all is faster compared one thread only.

Fore sure tcg need to be optimized (in all emulated architectures) compared 
some old commercial emulators but all is better than before.

I will made more tests tomorrow and report.

ciao

Luigi


Do you have any timings? Did the guest run faster?

Re: [Qemu-devel] [Qemu-ppc] [PATCH v2 0/3] Enable MTTCG on PPC64

[luigi burdo]

Tested on PowerMac G5 Quad  and 380% of system load and working on

Fedora 25 PPC64 host and Ubuntu Mate 17.04 guest  (patched the 2.9 rc3)


The machine configuration was this

sudo ./qemu-system-ppc64 -cpu POWER8 -vga none -machine pseries-2.5,usb=off -m 
2G  -smp 4,cores=4,threads=1 -accel tcg,thread=multi  -kerne vmlinuz-append 
root=/dev/sda   -device ich9-ahci,id=ahci   -device ide-drive,drive=disk0 
-drive file=/dev/sda4,if=none,id=disk0   -net nic,model=pcnet -net user 
-soundhw hda  -display sdl -vga virtio


vga virtio working too

here a shot

https://scontent-mxp1-1.xx.fbcdn.net/v/t1.0-9/17796379_10208795258860396_7825547329794577576_n.jpg?oh=526d6ddeb67c817053582d5b9ee56c71=594D7BDF


Thanks

Luigi

Re: [Qemu-devel] [Qemu-ppc] [PATCH RFC v1 0/3] Enable MTTCG on PPC64

[luigi burdo]

Hi i can help test it too on my two Be machine.

If some one help me to find where is the patch or where i can download  the 
commits


Thanks

Luigi

Re: [Qemu-devel] [Qemu-ppc] Bug in qemu-system-ppc in Windows using the SDL2 GUI

[luigi burdo]

Hi Thomas,

i had been patched the qemu 2.8.91 on the git repository too and the patch gave 
positive result.

i have no more the exit of qemu when a key was pressed .


Thanks

Luigi



Da: Thomas Huth <th...@redhat.com>
Inviato: venerdì 24 marzo 2017 10.33
A: Mark Cave-Ayland; Howard Spoelstra; qemu-...@nongnu.org; luigi burdo; Alex 
Bennée; QEMU Developers
Oggetto: Re: [Qemu-ppc] Bug in qemu-system-ppc in Windows using the SDL2 GUI

On 24.03.2017 09:56, Mark Cave-Ayland wrote:
> On 24/03/17 08:47, Howard Spoelstra wrote:
>
>> Hi,
>>
>> Running qemu-system-ppc.exe in windows with the SDL2 GUI results in a
>> hangup. I bisected to this commit:
>>
>> 8bb93c6f99a42c2e0943bc904b283cd622d302c5 is the first bad commit
>> commit 8bb93c6f99a42c2e0943bc904b283cd622d302c5
>> Author: Alex Bennée <alex.ben...@linaro.org>
>> Date:   Wed Mar 15 14:48:25 2017 +
>>
>> ui/console: ensure graphic updates don't race with TCG vCPUs
>>
>> Commit 8d04fb55..
>>
>>   tcg: drop global lock during TCG code execution
>>
>> ..broke the assumption that updates to the GUI couldn't happen at the
>> same time as TCG vCPUs where running. As a result the TCG vCPU could
>> still be updating a directly mapped frame-buffer while the display
>> side was updating. This would cause artefacts to appear when the
>> update code assumed that memory block hadn't changed.
>>
>> The simplest solution is to ensure the two things can't happen at the
>> same time like the old BQL locking scheme. Here we use the solution
>> introduced for MTTCG and schedule the update as async_safe_work when
>> we know no vCPUs can be running.
>>
>> Reported-by: Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk>
>> Signed-off-by: Alex Bennée <alex.ben...@linaro.org>
>> Message-id: 20170315144825.3108-1-alex.ben...@linaro.org
>> Cc: BALATON Zoltan <bala...@eik.bme.hu>
>> Cc: Gerd Hoffmann <kra...@redhat.com>
>> Cc: Paolo Bonzini <pbonz...@redhat.com>
>> Signed-off-by: Alex Bennée <alex.ben...@linaro.org>
>>
>> [ kraxel: updated comment clarifying the display adapters are buggy
>>   and this is a temporary workaround ]
>>
>> Signed-off-by: Gerd Hoffmann <kra...@redhat.com>
>
> Hi Howard,
>
> Alex posted another patch yesterday to resolve a similar issue:
> https://lists.nongnu.org/archive/html/qemu-devel/2017-03/msg04474.html.
>
> Does applying the above patch help at all?

Luigi Burdo reported a similar issue here:

https://bugs.launchpad.net/qemu/+bug/1675549
Bug #1675549 “tcg softmmu i386 crashes on BE hardware " : Bugs : 
QEMU<https://bugs.launchpad.net/qemu/+bug/1675549>
bugs.launchpad.net
Hi, today i try to test qemu 2.9rc 1 with qemu-system-i386 if i set display as 
sdl and i push a key on keyboard qemu exit with an error 
translate-common.c:34:tcg_handle_interrupt: assertion failed: 
(qemu_mutex_iothread_locked()) This issue was not present on qemu 2.8.0 Test 
Machine PowerMac G5 Quad Fedora 25 Server PPC64 Qemu build with 
target-list=i386-softmuu --with-sdlabi=2.0 Ciao Luigi



Luigi, could you please try Alex' patch to see whether it fixes your crash?

 Thanks,
  Thomas

Re: [Qemu-devel] [Qemu-ppc] Bug in qemu-system-ppc in Windows using the SDL2 GUI

[luigi burdo]

Hi Thomas,
i will check ASAP in launch break.
Ciao
Luigi


>Luigi, could you please try Alex' patch to see whether it fixes your crash?
> Thanks,
  >Thomas

Re: [Qemu-devel] [Qemu-ppc] qemu-system-ppc video artifacts since "tcg: drop global lock during TCG code execution"

[luigi burdo]

Zoltan,

i tested on ppcel  debian there isnt issue reported . i think is only a BE 
issue.


Luigi


Like from the display controller models that use memory_region_get_dirty()
to check if the frambuffer needs to be updated? But all display adaptors
seem to do this and the problem was only seem on ppc so it may be related
to something ppc specific.

Regards,
BALATON Zoltan

Re: [Qemu-devel] [Qemu-ppc] qemu-system-ppc video artifacts since "tcg: drop global lock during TCG code execution"

[luigi burdo]

framebuffer memory which is used to decide when a scan line needs update?

Hi Balton i have this artifacts since 2.20 on Linux PPC.
are more evident if the sdl driver is used, much less on GTK but still present 
there too plus GTK have issue with pointer if gl is enabled (reported in past 
in bugzilla)
I found it in STD when kvm is enabled on ppc32, virtio-vga gave this issue much 
less . (qemu-system-PPC64 have virtio enabled),
The strange thing is the std dont gave this issue on x86 emulation via tcg...

I hope one day we will have virtio on ppc32 too.

Luigi