Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feature request: MIPS P5600 CPU emulation #3

Open
lalrae opened this issue Aug 20, 2014 · 0 comments
Open

feature request: MIPS P5600 CPU emulation #3

lalrae opened this issue Aug 20, 2014 · 0 comments

Comments

@lalrae
Copy link

lalrae commented Aug 20, 2014

Add R5 features to allow MIPS P5600 CPU emulation: http://www.imgtec.com/mips/warrior/pclass.asp

yongbok pushed a commit that referenced this issue Nov 19, 2014
The docs for glfs_init suggest that the function sets errno on every
failure. In fact it doesn't. As other functions such as
qemu_gluster_open() in the gluster block code report their errors based
on this fact we need to make sure that errno is set on each failure.

This fixes a crash of qemu-img/qemu when a gluster brick isn't
accessible from given host while the server serving the volume
description is.

Thread 1 (Thread 0x7ffff7fba740 (LWP 203880)):
 #0  0x00007ffff77673f8 in glfs_lseek () from /usr/lib64/libgfapi.so.0
 #1  0x0000555555574a68 in qemu_gluster_getlength ()
 #2  0x0000555555565742 in refresh_total_sectors ()
 #3  0x000055555556914f in bdrv_open_common ()
 #4  0x000055555556e8e8 in bdrv_open ()
 #5  0x000055555556f02f in bdrv_open_image ()
 #6  0x000055555556e5f6 in bdrv_open ()
 #7  0x00005555555c5775 in bdrv_new_open ()
 #8  0x00005555555c5b91 in img_info ()
 #9  0x00007ffff62c9c05 in __libc_start_main () from /lib64/libc.so.6
 #10 0x00005555555648ad in _start ()

Signed-off-by: Stefan Hajnoczi <[email protected]>
yongbok pushed a commit that referenced this issue Nov 19, 2014
If libusb_get_device_list() fails, the uninitialized local variable
libusb_device would be passed to libusb_free_device_list(), that
will cause a crash, like:
(gdb) bt
 #0  0x00007fbbb4bafc10 in pthread_mutex_lock () from /lib64/libpthread.so.0
 #1  0x00007fbbb233e653 in libusb_unref_device (dev=0x6275682d627375)
     at core.c:902
 #2  0x00007fbbb233e739 in libusb_free_device_list (list=0x7fbbb6e8436e,
     unref_devices=<optimized out>) at core.c:653
 #3  0x00007fbbb6cd80a4 in usb_host_auto_check (unused=unused@entry=0x0)
     at hw/usb/host-libusb.c:1446
 #4  0x00007fbbb6cd8525 in usb_host_initfn (udev=0x7fbbbd3c5670)
     at hw/usb/host-libusb.c:912
 #5  0x00007fbbb6cc123b in usb_device_init (dev=0x7fbbbd3c5670)
     at hw/usb/bus.c:106
 ...

So initialize libusb_device at the begin time.

Signed-off-by: Jincheng Miao <[email protected]>
Reviewed-by: Gonglei <[email protected]>
Signed-off-by: Gerd Hoffmann <[email protected]>
yongbok pushed a commit that referenced this issue Nov 19, 2014
VirtIOBlockReq is freed later by virtio_blk_free_request() in
hw/block/virtio-blk.c.  Remove this extraneous g_slice_free().

This patch fixes the following segfault:

  0x00005555556373af in virtio_blk_rw_complete (opaque=0x5555565ff5e0, ret=0) at hw/block/virtio-blk.c:99
  99          bdrv_acct_done(req->dev->bs, &req->acct);
  (gdb) print req
  $1 = (VirtIOBlockReq *) 0x5555565ff5e0
  (gdb) print req->dev
  $2 = (VirtIOBlock *) 0x0
  (gdb) bt
  #0  0x00005555556373af in virtio_blk_rw_complete (opaque=0x5555565ff5e0, ret=0) at hw/block/virtio-blk.c:99
  #1  0x0000555555840ebe in bdrv_co_em_bh (opaque=0x5555566152d0) at block.c:4675
  #2  0x000055555583de77 in aio_bh_poll (ctx=ctx@entry=0x5555563a8150) at async.c:81
  #3  0x000055555584b7a7 in aio_poll (ctx=0x5555563a8150, blocking=blocking@entry=true) at aio-posix.c:188
  #4  0x00005555556e520e in iothread_run (opaque=0x5555563a7fd8) at iothread.c:41
  #5  0x00007ffff42ba124 in start_thread () from /usr/lib/libpthread.so.0
  #6  0x00007ffff16d14bd in clone () from /usr/lib/libc.so.6

Reported-by: Max Reitz <[email protected]>
Cc: Fam Zheng <[email protected]>
Signed-off-by: Stefan Hajnoczi <[email protected]>
Tested-by: Christian Borntraeger <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
yongbok pushed a commit to yongbok/prpl-qemu that referenced this issue Dec 10, 2014
If the pci bridge enters in error flow as part
of init process it will only delete the shpc mmio
subregion but not remove it from the properties list,
resulting in segmentation fault when the bridge runs
the exit function.

Example: add a pci bridge without specifing the chassis number:
    <qemu-bin> ... -device pci-bridge,id=p1
Result:
    (qemu) qemu-system-x86_64: -device pci-bridge,id=p1: Bridge chassis not specified. Each bridge is required to be assigned a unique chassis id > 0.
    qemu-system-x86_64: -device pci-bridge,id=p1: Device
    initialization failed.
    Segmentation fault (core dumped)

    if (child->class->unparent) {
    #0  0x00005555558d629b in object_finalize_child_property (obj=0x555556d2e830, name=0x555556d30630 "shpc-mmio[0]", opaque=0x555556a42fc8) at qom/object.c:1078
    prplfoundation#1  0x00005555558d4b1f in object_property_del_all (obj=0x555556d2e830) at qom/object.c:367
    prplfoundation#2  0x00005555558d4ca1 in object_finalize (data=0x555556d2e830) at qom/object.c:412
    prplfoundation#3  0x00005555558d55a1 in object_unref (obj=0x555556d2e830) at qom/object.c:720
    prplfoundation#4  0x000055555572c907 in qdev_device_add (opts=0x5555563544f0) at qdev-monitor.c:566
    prplfoundation#5  0x0000555555744f16 in device_init_func (opts=0x5555563544f0, opaque=0x0) at vl.c:2213
    prplfoundation#6  0x00005555559cf5f0 in qemu_opts_foreach (list=0x555555e0f8e0 <qemu_device_opts>, func=0x555555744efa <device_init_func>, opaque=0x0, abort_on_failure=1) at util/qemu-option.c:1057
    prplfoundation#7  0x000055555574a11b in main (argc=16, argv=0x7fffffffdde8, envp=0x7fffffffde70) at vl.c:423

Unparent the shpc mmio region as part of shpc cleanup.

Signed-off-by: Marcel Apfelbaum <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
Reviewed-by: Amos Kong <[email protected]>
yongbok pushed a commit to yongbok/prpl-qemu that referenced this issue Aug 6, 2015
This fixes the following crash, introduced by commit
49d2e64:

  $ gdb --args qemu-system-x86_64 -machine pc,mem-merge=off -object memory-backend-ram,id=ram-node0,size=1024
  [...]
  Program received signal SIGABRT, Aborted.
  (gdb) bt
  #0  0x00007ffff253b8c7 in raise () at /lib64/libc.so.6
  prplfoundation#1  0x00007ffff253d52a in abort () at /lib64/libc.so.6
  prplfoundation#2  0x00007ffff253446d in __assert_fail_base () at /lib64/libc.so.6
  prplfoundation#3  0x00007ffff2534522 in  () at /lib64/libc.so.6
  prplfoundation#4  0x00005555558bb80a in qemu_opt_get_bool_helper (opts=0x55555621b650, name=name@entry=0x5555558ec922 "mem-merge", defval=defval@entry=true, del=del@entry=false) at qemu/util/qemu-option.c:388
  prplfoundation#5  0x00005555558bbb5a in qemu_opt_get_bool (opts=<optimized out>, name=name@entry=0x5555558ec922 "mem-merge", defval=defval@entry=true) at qemu/util/qemu-option.c:398
  prplfoundation#6  0x0000555555720a24 in host_memory_backend_init (obj=0x5555562ac970) at qemu/backends/hostmem.c:226

Instead of using qemu_opt_get_bool(), that didn't work with
qemu_machine_opts for a long time, we can use the corresponding
MachineState fields.

Reviewed-by: Marcel Apfelbaum <[email protected]>
Signed-off-by: Eduardo Habkost <[email protected]>
lalrae pushed a commit that referenced this issue Jan 12, 2016
qpci_msix_pending() writes on pba region, causing qemu to SEGV:

  Program received signal SIGSEGV, Segmentation fault.
  [Switching to Thread 0x7ffff7fba8c0 (LWP 25882)]
  0x0000000000000000 in ?? ()
  (gdb) bt
  #0  0x0000000000000000 in  ()
  #1  0x00005555556556c5 in memory_region_oldmmio_write_accessor (mr=0x5555579f3f80, addr=0, value=0x7fffffffbf68, size=4, shift=0, mask=4294967295, attrs=...) at /home/elmarco/src/qemu/memory.c:434
  #2  0x00005555556558e1 in access_with_adjusted_size (addr=0, value=0x7fffffffbf68, size=4, access_size_min=1, access_size_max=4, access=0x55555565563e <memory_region_oldmmio_write_accessor>, mr=0x5555579f3f80, attrs=...) at /home/elmarco/src/qemu/memory.c:506
  #3  0x00005555556581eb in memory_region_dispatch_write (mr=0x5555579f3f80, addr=0, data=0, size=4, attrs=...) at /home/elmarco/src/qemu/memory.c:1176
  #4  0x000055555560b6f9 in address_space_rw (as=0x555555eff4e0 <address_space_memory>, addr=3759147008, attrs=..., buf=0x7fffffffc1b0 "", len=4, is_write=true) at /home/elmarco/src/qemu/exec.c:2439
  #5  0x000055555560baa2 in cpu_physical_memory_rw (addr=3759147008, buf=0x7fffffffc1b0 "", len=4, is_write=1) at /home/elmarco/src/qemu/exec.c:2534
  #6  0x000055555564c005 in cpu_physical_memory_write (addr=3759147008, buf=0x7fffffffc1b0, len=4) at /home/elmarco/src/qemu/include/exec/cpu-common.h:80
  #7  0x000055555564cd9c in qtest_process_command (chr=0x55555642b890, words=0x5555578de4b0) at /home/elmarco/src/qemu/qtest.c:378
  #8  0x000055555564db77 in qtest_process_inbuf (chr=0x55555642b890, inbuf=0x55555641b340) at /home/elmarco/src/qemu/qtest.c:569
  #9  0x000055555564dc07 in qtest_read (opaque=0x55555642b890, buf=0x7fffffffc2e0 "writel 0xe0100800 0x0\n", size=22) at /home/elmarco/src/qemu/qtest.c:581
  #10 0x000055555574ce3e in qemu_chr_be_write (s=0x55555642b890, buf=0x7fffffffc2e0 "writel 0xe0100800 0x0\n", len=22) at qemu-char.c:306
  #11 0x0000555555751263 in tcp_chr_read (chan=0x55555642bcf0, cond=G_IO_IN, opaque=0x55555642b890) at qemu-char.c:2876
  #12 0x00007ffff64c9a8a in g_main_context_dispatch (context=0x55555641c400) at gmain.c:3122

(without this patch, this can be reproduced with the ivshmem qtest)

Implement an empty mmio write to avoid the crash.

Signed-off-by: Marc-André Lureau <[email protected]>
Reviewed-by: Paolo Bonzini <[email protected]>
lalrae pushed a commit that referenced this issue Jan 12, 2016
A new gdb commands are added:

  qemu handlers

     That dumps an AioContext list (by default qemu_aio_context)
     possibly including a backtrace for cases it knows about
     (with the verbose option).  Intended to help find why something
     is hanging waiting for IO.

  Use 'qemu handlers --verbose iohandler_ctx'  to find out why
your incoming migration is stuck.

Signed-off-by: Dr. David Alan Gilbert <[email protected]>
Message-id: [email protected]

V2:
  Merge into one command with optional handlers arg, and only do
    backtrace in verbose mode

 (gdb) qemu handlers
 ----
 {pfd = {fd = 6, events = 25, revents = 0}, io_read = 0x55869656ffd0
 <event_notifier_dummy_cb>, io_write = 0x0, deleted = 0, opaque =
 0x558698c4ce08, node = {le_next = 0x0, le_prev = 0x558698c4cdc0}}

 (gdb) qemu handlers iohandler_ctx
 ----
 {pfd = {fd = 9, events = 25, revents = 0}, io_read = 0x558696581380
 <fd_coroutine_enter>, io_write = 0x0, deleted = 0, opaque =
 0x558698dc99d0, node = {le_next = 0x558698c4cca0, le_prev =
 0x558698c4c1d0}}
 ----
 {pfd = {fd = 4, events = 25, revents = 0}, io_read = 0x55869657b330
 <sigfd_handler>, io_write = 0x0, deleted = 0, opaque = 0x4, node =
 {le_next = 0x558698c4c260, le_prev = 0x558699f72508}}
 ----
 {pfd = {fd = 5, events = 25, revents = 0}, io_read = 0x55869656ffd0
 <event_notifier_dummy_cb>, io_write = 0x0, deleted = 0, opaque =
 0x558698c4c218, node = {le_next = 0x0, le_prev = 0x558698c4ccc8}}
 ----
 (gdb) qemu handlers --verbose iohandler_ctx
 ----
 {pfd = {fd = 9, events = 25, revents = 0}, io_read = 0x558696581380
 <fd_coroutine_enter>, io_write = 0x0, deleted = 0, opaque =
 0x558698dc99d0, node = {le_next = 0x558698c4cca0, le_prev =
 0x558698c4c1d0}}
 #0  0x0000558696581820 in qemu_coroutine_switch
 (from_=from_@entry=0x558698cb3cf0, to_=to_@entry=0x7f421c37eac8,
 action=action@entry=COROUTINE_YIELD) at
 /home/dgilbert/git/qemu/coroutine-ucontext.c:177
 #1  0x0000558696580c00 in qemu_coroutine_yield () at
 /home/dgilbert/git/qemu/qemu-coroutine.c:145
 #2  0x00005586965814f5 in yield_until_fd_readable (fd=9) at
 /home/dgilbert/git/qemu/qemu-coroutine-io.c:90
 #3  0x0000558696523937 in socket_get_buffer (opaque=0x55869a3dc620,
 buf=0x558698c505a0 "", pos=<optimized out>, size=32768) at
 /home/dgilbert/git/qemu/migration/qemu-file-unix.c:101
 #4  0x0000558696521fac in qemu_fill_buffer (f=0x558698c50570) at
 /home/dgilbert/git/qemu/migration/qemu-file.c:227
 #5  0x0000558696522989 in qemu_peek_byte (f=0x558698c50570, offset=0)
     at /home/dgilbert/git/qemu/migration/qemu-file.c:507
 #6  0x0000558696522bf4 in qemu_get_be32 (f=0x558698c50570) at
 /home/dgilbert/git/qemu/migration/qemu-file.c:520
 #7  0x0000558696522bf4 in qemu_get_be32 (f=f@entry=0x558698c50570)
     at /home/dgilbert/git/qemu/migration/qemu-file.c:604
 #8  0x0000558696347e5c in qemu_loadvm_state (f=f@entry=0x558698c50570)
     at /home/dgilbert/git/qemu/migration/savevm.c:1821
 #9  0x000055869651de8c in process_incoming_migration_co
 (opaque=0x558698c50570)
     at /home/dgilbert/git/qemu/migration/migration.c:336
 #10 0x000055869658188a in coroutine_trampoline (i0=<optimized out>,
 i1=<optimized out>)
     at /home/dgilbert/git/qemu/coroutine-ucontext.c:80
 #11 0x00007f420f05df10 in __start_context () at /lib64/libc.so.6
 #12 0x00007ffc40815f50 in  ()
 #13 0x0000000000000000 in  ()

  ----
Signed-off-by: Stefan Hajnoczi <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant