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.

Sign up for GitHub

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

Jump to bottom

Officially reenable the R5900 o32 ABI #1

Open
frno7 opened this issue Feb 28, 2019 · 0 comments
Open

Officially reenable the R5900 o32 ABI #1

frno7 opened this issue Feb 28, 2019 · 0 comments
Labels
enhancement New feature or request

Comments

@frno7
Copy link
Owner

frno7 commented Feb 28, 2019

The R5900 o32 ABI was reverted in commit 823f289 in the main QEMU repository. Work with the QEMU community to officially enable the R5900 o32 ABI again.
@frno7 frno7 added the enhancement New feature or request label Feb 28, 2019
frno7 pushed a commit that referenced this issue Mar 2, 2019
@elmarco
monitor: avoid potential dead-lock when cleaning up
34f1f3e 
When a monitor is connected to a Spice chardev, the monitor cleanup
can dead-lock:

 #0  0x00007f43446637fd in __lll_lock_wait () at /lib64/libpthread.so.0
 #1  0x00007f434465ccf4 in pthread_mutex_lock () at /lib64/libpthread.so.0
 #2  0x0000556dd79f22ba in qemu_mutex_lock_impl (mutex=0x556dd81c9220 <monitor_lock>, file=0x556dd7ae3648 "/home/elmarco/src/qq/monitor.c", line=645) at /home/elmarco/src/qq/util/qemu-thread-posix.c:66
 #3  0x0000556dd7431bd5 in monitor_qapi_event_queue (event=QAPI_EVENT_SPICE_DISCONNECTED, qdict=0x556dd9abc850, errp=0x7fffb7bbddd8) at /home/elmarco/src/qq/monitor.c:645
 #4  0x0000556dd79d476b in qapi_event_send_spice_disconnected (server=0x556dd98ee760, client=0x556ddaaa8560, errp=0x556dd82180d0 <error_abort>) at qapi/qapi-events-ui.c:149
 #5  0x0000556dd7870fc1 in channel_event (event=3, info=0x556ddad1b590) at /home/elmarco/src/qq/ui/spice-core.c:235
 #6  0x00007f434560a6bb in reds_handle_channel_event (reds=<optimized out>, event=3, info=0x556ddad1b590) at reds.c:316
 #7  0x00007f43455f393b in main_dispatcher_self_handle_channel_event (info=0x556ddad1b590, event=3, self=0x556dd9a7d8c0) at main-dispatcher.c:197
 qemu#8  0x00007f43455f393b in main_dispatcher_channel_event (self=0x556dd9a7d8c0, event=event@entry=3, info=0x556ddad1b590) at main-dispatcher.c:197
 qemu#9  0x00007f4345612833 in red_stream_push_channel_event (s=s@entry=0x556ddae2ef40, event=event@entry=3) at red-stream.c:414
 qemu#10 0x00007f434561286b in red_stream_free (s=0x556ddae2ef40) at red-stream.c:388
 qemu#11 0x00007f43455f9ddc in red_channel_client_finalize (object=0x556dd9bb21a0) at red-channel-client.c:347
 qemu#12 0x00007f434b5f9fb9 in g_object_unref () at /lib64/libgobject-2.0.so.0
 qemu#13 0x00007f43455fc212 in red_channel_client_push (rcc=0x556dd9bb21a0) at red-channel-client.c:1341
 qemu#14 0x0000556dd76081ba in spice_port_set_fe_open (chr=0x556dd9925e20, fe_open=0) at /home/elmarco/src/qq/chardev/spice.c:241
 qemu#15 0x0000556dd796d74a in qemu_chr_fe_set_open (be=0x556dd9a37c00, fe_open=0) at /home/elmarco/src/qq/chardev/char-fe.c:340
 qemu#16 0x0000556dd796d4d9 in qemu_chr_fe_set_handlers (b=0x556dd9a37c00, fd_can_read=0x0, fd_read=0x0, fd_event=0x0, be_change=0x0, opaque=0x0, context=0x0, set_open=true) at /home/elmarco/src/qq/chardev/char-fe.c:280
 qemu#17 0x0000556dd796d359 in qemu_chr_fe_deinit (b=0x556dd9a37c00, del=false) at /home/elmarco/src/qq/chardev/char-fe.c:233
 qemu#18 0x0000556dd7432240 in monitor_data_destroy (mon=0x556dd9a37c00) at /home/elmarco/src/qq/monitor.c:786
 qemu#19 0x0000556dd743b968 in monitor_cleanup () at /home/elmarco/src/qq/monitor.c:4683
 qemu#20 0x0000556dd75ce776 in main (argc=3, argv=0x7fffb7bbe458, envp=0x7fffb7bbe478) at /home/elmarco/src/qq/vl.c:4660

Because spice code tries to emit a "disconnected" signal on the
monitors. Fix this dead-lock by releasing the monitor lock for
flush/destroy.

monitor_lock protects mon_list, monitor_qapi_event_state and
monitor_destroyed. monitor_flush() and monitor_data_destroy() don't
access any of those variables.

monitor_cleanup()'s loop is safe because it uses
QTAILQ_FOREACH_SAFE(), and no further monitor can be added after
calling monitor_cleanup() thanks to monitor_destroyed check in
monitor_list_append().

Signed-off-by: Marc-André Lureau <[email protected]>
Reviewed-by: Markus Armbruster <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Markus Armbruster <[email protected]>
frno7 pushed a commit that referenced this issue Mar 2, 2019
@farosas @stefanhaRH
tracetool: Include thread id information in log backend
8fbc12f 
Currently the log backend prints the process id of QEMU at the start
of each output line, but since threads share the same PID there is no
clear distinction between their outputs.

Having the thread id present in the log makes it easier to see when
output comes from different threads. E.g.:

[email protected]:qemu_mutex_lock waiting on mutex 0x1103ee60 (/root/qemu/util/main-loop.c:236)
...
[email protected]:qemu_mutex_unlock released mutex 0x1103ee60 (/root/qemu/cpus.c:1238)
[email protected]:qemu_mutex_locked taken mutex 0x1103ee60 (/root/qemu/cpus.c:1257)
^here

In the above, 12423 is the main process id and 12430 & 12431 are the
two vcpu threads.

 (qemu) info cpus
 * CPU #0: thread_id=12430
   CPU #1: thread_id=12431

Suggested-by: Murilo Opsfelder Araujo <[email protected]>
Signed-off-by: Fabiano Rosas <[email protected]>
Signed-off-by: Stefan Hajnoczi <[email protected]>
frno7 pushed a commit that referenced this issue Mar 2, 2019
json: Fix to reject duplicate object member names
00382fa 
The JSON parser happily accepts duplicate object member names.  The
last value wins.  Reproducer #1:

    $ qemu-system-x86_64 -qmp stdio
    {"QMP": {"version": {"qemu": {"micro": 93, "minor": 0, "major": 3},
    "package": "v3.1.0-rc3-7-g87a45d86ed"}, "capabilities": []}}
    {'execute':'qmp_capabilities'}
    {"return": {}}
    {'execute':'blockdev-add','arguments':{'driver':'null-co',
     'node-name':'foo','node-name':'bar'}}
    {"return": {}}
    {'execute':'query-named-block-nodes'}
    {"return": [{ [...] "node-name": "bar" [...] }]}

Reproducer #2 is iotest 229.

Fix the parser to reject duplicates, and fix iotest 229 not to use
them.

Reported-by: Max Reitz <[email protected]>
Signed-off-by: Markus Armbruster <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Daniel P. Berrangé <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
[Trailing whitespace tidied up]
Signed-off-by: Markus Armbruster <[email protected]>
frno7 pushed a commit that referenced this issue Mar 2, 2019
@elmarco @ehabkost
qdev: fix -device scsi-hd,help regression
ab94c6b 
Since commit ea9ce89, device_post_init() applies globals directly
from machines and accelerator classes.

There are cases, such as -device scsi-hd,help, where the machine is
setup but there in no accelerator.

Let's skip accelerator globals in this case.

Fixes SEGV:
 #0  0x0000555558ea04ff in object_get_class (obj=0x0) at /home/elmarco/src/qemu/build/../qom/object.c:857
 #1  0x000055555854c797 in object_apply_compat_props (obj=0x616000078980) at /home/elmarco/src/qemu/build/../hw/core/qdev.c:978
 #2  0x000055555854c797 in object_apply_compat_props (obj=0x616000078980) at /home/elmarco/src/qemu/build/../hw/core/qdev.c:973
 #3  0x000055555854c959 in device_post_init (obj=0x616000078980) at /home/elmarco/src/qemu/build/../hw/core/qdev.c:989
 #4  0x0000555558e9e250 in object_post_init_with_type (ti=<optimized out>, obj=0x616000078980) at /home/elmarco/src/qemu/build/../qom/object.c:365
 #5  0x0000555558e9e250 in object_initialize_with_type (data=0x616000078980, size=616, type=<optimized out>) at /home/elmarco/src/qemu/build/../qom/object.c:425
 #6  0x0000555558e9e571 in object_new_with_type (type=0x613000031900) at /home/elmarco/src/qemu/build/../qom/object.c:588
 #7  0x000055555830c048 in qmp_device_list_properties (typename=typename@entry=0x60200000c2d0 "scsi-hd", errp=errp@entry=0x7fffffffc540) at /home/elmarco/src/qemu/qmp.c:519
 qemu#8  0x00005555582c4027 in qdev_device_help (opts=<optimized out>) at /home/elmarco/src/qemu/qdev-monitor.c:283
 qemu#9  0x0000555559378fa2 in qemu_opts_foreach (list=<optimized out>, func=func@entry=0x5555582cfca0 <device_help_func>, opaque=opaque@entry=0x0, errp=errp@entry=0x0) at /home/elmarco/src/qemu/util/qemu-option.c:1171

https://bugzilla.redhat.com/show_bug.cgi?id=1664364

Signed-off-by: Marc-André Lureau <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Cornelia Huck <[email protected]>
Reviewed-by: Lukáš Doktor <[email protected]>
Reviewed-by: Igor Mammedov <[email protected]>
Signed-off-by: Eduardo Habkost <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@frno7