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

Support the R5900 floating-point unit (FPU) #5

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

Support the R5900 floating-point unit (FPU) #5

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 floating-point unit (FPU) is not compliant with the IEEE 754 standard. To comply with the o32 and n32 Linux ABIs, the FPU is therefore emulated in software by the Linux kernel. This emulation is accurate but very slow. One suggestion is to introduce a new ELF ABI annotation that switches the floating-point environment between IEEE 754 emulation and the R5900 FPU in hardware.

In particular, with the R5900 FPU

  • NaN (not a number) and plus/minus infinities are not supported;
  • exception mechanisms are not fully supported;
  • denormalized numbers are not supported;
  • rounding towards nearest and plus/minus infinities are not supported;
  • computed results usually differs in the least significant bit;
  • saturating instructions can differ more than the least significant bit.

Since only rounding towards zero is supported, the two least significant bits of FCR31 are hardwired to 01.

Finally, the R5900 FPU has some anomalies in the instruction set; not all opcode encodings are standard and some opcodes are extra. The output of the command grep 'FP_.*EE' binutils/opcodes/mips-opc.c with EE in the membership field are extra, and those with EE in the exclusions field are missing. See [PATCH] Support for MIPS R5900 (Sony Playstation 2).

See also PlayStation 2 Linux #3.

@frno7 frno7 added the enhancement New feature or request label Feb 28, 2019
frno7 pushed a commit that referenced this issue Mar 2, 2019
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 <marcandre.lureau@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20181205203737.9011-8-marcandre.lureau@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
frno7 pushed a commit that referenced this issue Mar 2, 2019
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 <marcandre.lureau@redhat.com>
Message-Id: <20190109102311.7635-1-marcandre.lureau@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Lukáš Doktor <ldoktor@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant