Re: [Qemu-devel] Status of my hacks on the MTTCG WIP branch

[Alex Bennée]

Pranith Kumar <address@hidden> writes:

> Hi Alex,
>
> On Tue, Jan 12, 2016 at 12:29 PM, Alex Bennée <address@hidden>
> wrote:
>
>>
> https://github.com/stsquad/qemu/tree/mttcg/multi_tcg_v8_wip_ajb_fix_locks
>>
>
> I built this branch and ran an arm64 guest. It seems to be failing
> similarly to what I reported earlier:
>
> #0  0x00007ffff2211cc9 in __GI_raise (address@hidden) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:56
> #1  0x00007ffff22150d8 in __GI_abort () at abort.c:89
> #2  0x000055555572014c in qemu_ram_addr_from_host_nofail
> (ptr=0xffffffc000187863) at /home/pranith/devops/code/qemu/cputlb.c:357
> #3  0x00005555557209dd in get_page_addr_code (env1=0x555556702058,
> addr=18446743798833248356) at /home/pranith/devops/code/qemu/cputlb.c:568
> #4  0x00005555556db98c in tb_find_physical (cpu=0x5555566f9dd0,
> pc=18446743798833248356, cs_base=0, flags=18446744071830503424) at
> /home/pranith/devops/code/qemu/cpu-exec.c:224
> #5  0x00005555556dbaf4 in tb_find_slow (cpu=0x5555566f9dd0,
> pc=18446743798833248356, cs_base=0, flags=18446744071830503424) at
> /home/pranith/devops/code/qemu/cpu-exec.c:268
> #6  0x00005555556dbc77 in tb_find_fast (cpu=0x5555566f9dd0) at
> /home/pranith/devops/code/qemu/cpu-exec.c:311
> #7  0x00005555556dc0f1 in cpu_arm_exec (cpu=0x5555566f9dd0) at
> /home/pranith/devops/code/qemu/cpu-exec.c:492
> #8  0x00005555557050ee in tcg_cpu_exec (cpu=0x5555566f9dd0) at
> /home/pranith/devops/code/qemu/cpus.c:1486
> #9  0x00005555557051af in tcg_exec_all (cpu=0x5555566f9dd0) at
> /home/pranith/devops/code/qemu/cpus.c:1515
> #10 0x0000555555704800 in qemu_tcg_cpu_thread_fn (arg=0x5555566f9dd0) at
> /home/pranith/devops/code/qemu/cpus.c:1187
> #11 0x00007ffff25a8182 in start_thread (arg=0x7fffd20c8700) at
> pthread_create.c:312
> #12 0x00007ffff22d547d in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
>
> The arguments I used are as follows:
>
> (gdb) show args
>
> Argument list to give program being debugged when it is started is "-m
> 1024M -M virt -cpu cortex-a57 -global virtio-blk-device.scsi=off -device
> virtio-scsi-device,id=scsi -drive
> file=arm64disk.qcow2,id=coreimg,cache=unsafe,if=none -device
> scsi-hd,drive=coreimg -netdev user,id=unet -device
> virtio-net-device,netdev=unet -kernel vmlinuz -initrd initrd.img -append
> root=/dev/sda2 -display sdl -redir tcp:2222::22 -smp 2".

With my command line:

/home/alex/lsrc/qemu/qemu.git/aarch64-softmmu/qemu-system-aarch64
-machine type=virt -display none -smp 1 -m 4096 -cpu cortex-a57 -serial
telnet:127.0.0.1:4444 -monitor stdio -netdev
user,id=unet,hostfwd=tcp::2222-:22 -device virtio-net-device,netdev=unet
-drive
file=/home/alex/lsrc/qemu/images/jessie-arm64.qcow2,id=myblock,index=0,if=none
-device virtio-blk-device,drive=myblock -kernel
/home/alex/lsrc/qemu/images/aarch64-current-linux-kernel-only.img
-append console=ttyAMA0 root=/dev/vda1 -s -name arm,debug-threads=on
-smp 4

I see the bad ram pointer failure in aarch64. It work in plain arm. Time
to dig out the debugging tools again ;-)

>
> Does something look obviously wrong to you in the arg list?
>
> Thanks!


--
Alex Bennée