hw/misc: applesmc: use host osk as default on macs #1
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When running on a Mac, QEMU is able to get the host OSK and use it as the default value for the AppleSMC device. The OSK query operation doesn't require administrator privileges and can be executed by any user on the system. This patch is based on open-source code from Apple, just like the implementation from VirtualBox. Apple: https://opensource.apple.com/source/IOKitUser/IOKitUser-647.6.13/pwr_mgt.subproj/IOPMLibPrivate.c https://opensource.apple.com/source/PowerManagement/PowerManagement-637.60.1/pmconfigd/PrivateLib.c VirtualBox: https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Devices/EFI/DevSmc.cpp#L516 Signed-off-by: Pedro Tôrres <t0rr3sp3dr0@gmail.com>
|
This patch has also been submitted to QEMU: https://patchew.org/QEMU/4E271071-0799-4948-A445-134E7FAAD48D@gmail.com/ It will allow macOS to run on UTM by using the host OSK instead of setting its value manually. |
|
@t0rr3sp3dr0 Thanks for the pull request. Can you ping me once the conversation with QEMU is resolved? Even if they don't accept the patch, I can still merge it in this branch. But I just want things to be as consistent as possible so if they do accept it, I don't want to diverge on the implementation with QEMU master. |
asdfugil
pushed a commit
to asdfugil/qemu
that referenced
this pull request
Apr 29, 2022
osy
pushed a commit
that referenced
this pull request
Dec 18, 2022
Fix warnings such:
disas/nanomips.c:3251:64: warning: format specifies type 'char *' but the argument has type 'int64' (aka 'long long') [-Wformat]
return img_format("CACHE 0x%" PRIx64 ", %s(%s)", op_value, s_value, rs);
~~ ^~~~~~~
%lld
To avoid crashes such (kernel from commit f375ad6):
$ qemu-system-mipsel -cpu I7200 -d in_asm -kernel generic_nano32r6el_page4k
...
----------------
IN: __bzero
0x805c6084: 20c4 6950 ADDU r13, a0, a2
0x805c6088: 9089 ADDIU a0, 1
Process 70261 stopped
* thread qemu#6, stop reason = EXC_BAD_ACCESS (code=1, address=0xfffffffffffffff0)
frame #0: 0x00000001bfe38864 libsystem_platform.dylib`_platform_strlen + 4
libsystem_platform.dylib`:
-> 0x1bfe38864 <+4>: ldr q0, [x1]
0x1bfe38868 <+8>: adr x3, #-0xc8 ; ___lldb_unnamed_symbol314
0x1bfe3886c <+12>: ldr q2, [x3], #0x10
0x1bfe38870 <+16>: and x2, x0, #0xf
Target 0: (qemu-system-mipsel) stopped.
(lldb) bt
* thread qemu#6, stop reason = EXC_BAD_ACCESS (code=1, address=0xfffffffffffffff0)
* frame #0: 0x00000001bfe38864 libsystem_platform.dylib`_platform_strlen + 4
frame #1: 0x00000001bfce76a0 libsystem_c.dylib`__vfprintf + 4544
frame #2: 0x00000001bfd158b4 libsystem_c.dylib`_vasprintf + 280
frame #3: 0x0000000101c22fb0 libglib-2.0.0.dylib`g_vasprintf + 28
frame qemu#4: 0x0000000101bfb7d8 libglib-2.0.0.dylib`g_strdup_vprintf + 32
frame qemu#5: 0x000000010000fb70 qemu-system-mipsel`img_format(format=<unavailable>) at nanomips.c:103:14 [opt]
frame qemu#6: 0x0000000100018868 qemu-system-mipsel`SB_S9_(instruction=<unavailable>, info=<unavailable>) at nanomips.c:12616:12 [opt]
frame qemu#7: 0x000000010000f90c qemu-system-mipsel`print_insn_nanomips at nanomips.c:589:28 [opt]
Fixes: 4066c15 ("disas/nanomips: Remove IMMEDIATE functions")
Reported-by: Stefan Weil <sw@weilnetz.de>
Reviewed-by: Stefan Weil <sw@weilnetz.de>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20221101114458.25756-2-philmd@linaro.org>
osy
pushed a commit
that referenced
this pull request
Nov 24, 2024
Since commit e99441a ("ui/curses: Do not use console_select()") qemu_text_console_put_keysym() no longer checks for NULL console argument, which leads to a later crash: Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. 0x00005555559ee186 in qemu_text_console_handle_keysym (s=0x0, keysym=31) at ../ui/console-vc.c:332 332 } else if (s->echo && (keysym == '\r' || keysym == '\n')) { (gdb) bt #0 0x00005555559ee186 in qemu_text_console_handle_keysym (s=0x0, keysym=31) at ../ui/console-vc.c:332 #1 0x00005555559e18e5 in qemu_text_console_put_keysym (s=<optimized out>, keysym=<optimized out>) at ../ui/console.c:303 #2 0x00005555559f2e88 in do_key_event (vs=vs@entry=0x5555579045c0, down=down@entry=1, keycode=keycode@entry=60, sym=sym@entry=65471) at ../ui/vnc.c:2034 #3 0x00005555559f845c in ext_key_event (vs=0x5555579045c0, down=1, sym=65471, keycode=<optimized out>) at ../ui/vnc.c:2070 qemu#4 protocol_client_msg (vs=0x5555579045c0, data=<optimized out>, len=<optimized out>) at ../ui/vnc.c:2514 qemu#5 0x00005555559f515c in vnc_client_read (vs=0x5555579045c0) at ../ui/vnc.c:1607 Fixes: e99441a ("ui/curses: Do not use console_select()") Fixes: https://issues.redhat.com/browse/RHEL-50529 Cc: qemu-stable@nongnu.org Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (cherry picked from commit 0e60fc8) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
osy
pushed a commit
that referenced
this pull request
Nov 24, 2024
When SET_STREAM_FORMAT is called, we should clear the existing setup.
Factor out common function to close a stream.
Direct leak of 144 byte(s) in 3 object(s) allocated from:
#0 0x7f91d38f7350 in calloc (/lib64/libasan.so.8+0xf7350) (BuildId: a4ad7eb954b390cf00f07fa10952988a41d9fc7a)
#1 0x7f91d2ab7871 in g_malloc0 (/lib64/libglib-2.0.so.0+0x64871) (BuildId: 36b60dbd02e796145a982d0151ce37202ec05649)
#2 0x562fa2f447ee in timer_new_full /home/elmarco/src/qemu/include/qemu/timer.h:538
#3 0x562fa2f4486f in timer_new /home/elmarco/src/qemu/include/qemu/timer.h:559
qemu#4 0x562fa2f448a9 in timer_new_ns /home/elmarco/src/qemu/include/qemu/timer.h:577
qemu#5 0x562fa2f47955 in hda_audio_setup ../hw/audio/hda-codec.c:490
qemu#6 0x562fa2f4897e in hda_audio_command ../hw/audio/hda-codec.c:605
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Message-ID: <20241008125028.1177932-3-marcandre.lureau@redhat.com>
(cherry picked from commit 6d6e233)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
osy
pushed a commit
that referenced
this pull request
Nov 24, 2024
qemu-ga on a NetBSD -current VM terminates with a SIGSEGV upon receiving
'guest-set-time' command...
Core was generated by `qemu-ga'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000000000cd37a40 in ga_pipe_read_str (fd=fd@entry=0xffffff922a20, str=str@entry=0xffffff922a18)
at ../qga/commands-posix.c:88
88 *str[len] = '\0';
[Current thread is 1 (process 1112)]
(gdb) bt
#0 0x000000000cd37a40 in ga_pipe_read_str (fd=fd@entry=0xffffff922a20, str=str@entry=0xffffff922a18)
at ../qga/commands-posix.c:88
#1 0x000000000cd37b60 in ga_run_command (argv=argv@entry=0xffffff922a90,
action=action@entry=0xcda34b8 "set hardware clock to system time", errp=errp@entry=0xffffff922a70, in_str=0x0)
at ../qga/commands-posix.c:164
#2 0x000000000cd380c4 in qmp_guest_set_time (has_time=<optimized out>, time_ns=<optimized out>,
errp=errp@entry=0xffffff922ad0) at ../qga/commands-posix.c:304
#3 0x000000000cd253d8 in qmp_marshal_guest_set_time (args=<optimized out>, ret=<optimized out>, errp=0xffffff922b48)
at qga/qga-qapi-commands.c:193
qemu#4 0x000000000cd4e71c in qmp_dispatch (cmds=cmds@entry=0xcdf5b18 <ga_commands>, request=request@entry=0xf3c711a4b000,
allow_oob=allow_oob@entry=false, cur_mon=cur_mon@entry=0x0) at ../qapi/qmp-dispatch.c:220
qemu#5 0x000000000cd36524 in process_event (opaque=0xf3c711a79000, obj=0xf3c711a4b000, err=0x0) at ../qga/main.c:677
qemu#6 0x000000000cd526f0 in json_message_process_token (lexer=lexer@entry=0xf3c711a79018, input=0xf3c712072480,
type=type@entry=JSON_RCURLY, x=28, y=1) at ../qobject/json-streamer.c:99
qemu#7 0x000000000cd93860 in json_lexer_feed_char (lexer=lexer@entry=0xf3c711a79018, ch=125 '}', flush=flush@entry=false)
at ../qobject/json-lexer.c:313
qemu#8 0x000000000cd93a00 in json_lexer_feed (lexer=lexer@entry=0xf3c711a79018,
buffer=buffer@entry=0xffffff922d10 "{\"execute\":\"guest-set-time\"}\n", size=<optimized out>)
at ../qobject/json-lexer.c:350
qemu#9 0x000000000cd5290c in json_message_parser_feed (parser=parser@entry=0xf3c711a79000,
buffer=buffer@entry=0xffffff922d10 "{\"execute\":\"guest-set-time\"}\n", size=<optimized out>)
at ../qobject/json-streamer.c:121
qemu#10 0x000000000cd361fc in channel_event_cb (condition=<optimized out>, data=0xf3c711a79000) at ../qga/main.c:703
qemu#11 0x000000000cd3710c in ga_channel_client_event (channel=<optimized out>, condition=<optimized out>, data=0xf3c711b2d300)
at ../qga/channel-posix.c:94
qemu#12 0x0000f3c7120d9bec in g_main_dispatch () from /usr/pkg/lib/libglib-2.0.so.0
qemu#13 0x0000f3c7120dd25c in g_main_context_iterate_unlocked.constprop () from /usr/pkg/lib/libglib-2.0.so.0
qemu#14 0x0000f3c7120ddbf0 in g_main_loop_run () from /usr/pkg/lib/libglib-2.0.so.0
qemu#15 0x000000000cda00d8 in run_agent_once (s=0xf3c711a79000) at ../qga/main.c:1522
qemu#16 run_agent (s=0xf3c711a79000) at ../qga/main.c:1559
qemu#17 main (argc=<optimized out>, argv=<optimized out>) at ../qga/main.c:1671
(gdb)
The commandline options used on the host machine...
qemu-system-aarch64 \
-machine type=virt,pflash0=rom \
-m 8G \
-cpu host \
-smp 8 \
-accel hvf \
-device virtio-net-pci,netdev=unet \
-device virtio-blk-pci,drive=hd \
-drive file=netbsd.qcow2,if=none,id=hd \
-netdev user,id=unet,hostfwd=tcp::2223-:22 \
-object rng-random,filename=/dev/urandom,id=viornd0 \
-device virtio-rng-pci,rng=viornd0 \
-serial mon:stdio \
-display none \
-blockdev node-name=rom,driver=file,filename=/opt/homebrew/Cellar/qemu/9.0.2/share/qemu/edk2-aarch64-code.fd,read-only=true \
-chardev socket,path=/tmp/qga_netbsd.sock,server=on,wait=off,id=qga0 \
-device virtio-serial \
-device virtconsole,chardev=qga0,name=org.qemu.guest_agent.0
This patch rectifies the operator precedence while assigning the NUL
terminator.
Fixes: c3f32c1
Signed-off-by: Sunil Nimmagadda <sunil@nimmagadda.net>
Reviewed-by: Konstantin Kostiuk <kkostiuk@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Link: https://lore.kernel.org/r/m15xppk9qg.fsf@nimmagadda.net
Signed-off-by: Konstantin Kostiuk <kkostiuk@redhat.com>
(cherry picked from commit 9cfe110)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
osy
pushed a commit
that referenced
this pull request
Nov 24, 2024
A bad (broken or malicious) 9p client (guest) could cause QEMU host to
crash by sending a 9p 'Treaddir' request with a numeric file ID (FID) that
was previously opened for a file instead of an expected directory:
#0 0x0000762aff8f4919 in __GI___rewinddir (dirp=0xf) at
../sysdeps/unix/sysv/linux/rewinddir.c:29
#1 0x0000557b7625fb40 in do_readdir_many (pdu=0x557bb67d2eb0,
fidp=0x557bb67955b0, entries=0x762afe9fff58, offset=0, maxsize=131072,
dostat=<optimized out>) at ../hw/9pfs/codir.c:101
#2 v9fs_co_readdir_many (pdu=pdu@entry=0x557bb67d2eb0,
fidp=fidp@entry=0x557bb67955b0, entries=entries@entry=0x762afe9fff58,
offset=0, maxsize=131072, dostat=false) at ../hw/9pfs/codir.c:226
#3 0x0000557b7625c1f9 in v9fs_do_readdir (pdu=0x557bb67d2eb0,
fidp=0x557bb67955b0, offset=<optimized out>,
max_count=<optimized out>) at ../hw/9pfs/9p.c:2488
qemu#4 v9fs_readdir (opaque=0x557bb67d2eb0) at ../hw/9pfs/9p.c:2602
That's because V9fsFidOpenState was declared as union type. So the
same memory region is used for either an open POSIX file handle (int),
or a POSIX DIR* pointer, etc., so 9p server incorrectly used the
previously opened (valid) POSIX file handle (0xf) as DIR* pointer,
eventually causing a crash in glibc's rewinddir() function.
Root cause was therefore a missing check in 9p server's 'Treaddir'
request handler, which must ensure that the client supplied FID was
really opened as directory stream before trying to access the
aforementioned union and its DIR* member.
Cc: qemu-stable@nongnu.org
Fixes: d62dbb5 ("virtio-9p: Add fidtype so that we can do type ...")
Reported-by: Akihiro Suda <suda.kyoto@gmail.com>
Tested-by: Akihiro Suda <suda.kyoto@gmail.com>
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Message-Id: <E1t8GnN-002RS8-E2@kylie.crudebyte.com>
(cherry picked from commit 042b4eb)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
osy
pushed a commit
that referenced
this pull request
Jul 7, 2025
While running the new GPU tests it was noted that the proprietary
nVidia driver barfed when run under the sanitiser:
2025-02-20 11:13:08,226: [11:13:07.782] Output 'headless' attempts
EOTF mode SDR and colorimetry mode default.
2025-02-20 11:13:08,227: [11:13:07.784] Output 'headless' using color
profile: stock sRGB color profile
and that's the last thing it outputs.
The sanitizer reports that when the framework sends the SIGTERM
because of the timeout we get a write to a NULL pointer (but
interesting not this time in an atexit callback):
UndefinedBehaviorSanitizer:DEADLYSIGNAL
==471863==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address
0x000000000000 (pc 0x7a18ceaafe80 bp 0x000000000000 sp 0x7ffe8e3ff6d0
T471863)
==471863==The signal is caused by a WRITE memory access.
==471863==Hint: address points to the zero page.
#0 0x7a18ceaafe80
(/lib/x86_64-linux-gnu/libnvidia-eglcore.so.535.183.01+0x16afe80)
(BuildId: 24b0d0b90369112e3de888a93eb8d7e00304a6db)
#1 0x7a18ce9e72c0
(/lib/x86_64-linux-gnu/libnvidia-eglcore.so.535.183.01+0x15e72c0)
(BuildId: 24b0d0b90369112e3de888a93eb8d7e00304a6db)
#2 0x7a18ce9f11bb
(/lib/x86_64-linux-gnu/libnvidia-eglcore.so.535.183.01+0x15f11bb)
(BuildId: 24b0d0b90369112e3de888a93eb8d7e00304a6db)
#3 0x7a18ce6dc9d1
(/lib/x86_64-linux-gnu/libnvidia-eglcore.so.535.183.01+0x12dc9d1)
(BuildId: 24b0d0b90369112e3de888a93eb8d7e00304a6db)
qemu#4 0x7a18e7d15326 in vrend_renderer_create_fence
/usr/src/virglrenderer-1.0.0-1ubuntu2/obj-x86_64-linux-gnu/../src/vrend_renderer.c:10883:26
qemu#5 0x55bfb6621871 in virtio_gpu_virgl_process_cmd
The #dri-devel channel confirmed:
<digetx> stsquad: nv driver is known to not work with venus, don't use
it for testing
So lets skip running the test to avoid known failures. As we now use
vulkaninfo to probe we also need to handle the case where there is no
Vulkan driver configured for the hardware.
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reported-by: Peter Maydell <peter.maydell@linaro.org>
Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com>
[AJB: also skip if vulkaninfo can't find environment]
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20250304222439.2035603-6-alex.bennee@linaro.org>
osy
pushed a commit
that referenced
this pull request
Jul 7, 2025
On the incoming migration side, QEMU uses a coroutine to load all the VM states. Inside, it may reference MigrationState on global states like migration capabilities, parameters, error state, shared mutexes and more. However there's nothing yet to make sure MigrationState won't get destroyed (e.g. after migration_shutdown()). Meanwhile there's also no API available to remove the incoming coroutine in migration_shutdown(), avoiding it to access the freed elements. There's a bug report showing this can happen and crash dest QEMU when migration is cancelled on source. When it happens, the dest main thread is trying to cleanup everything: #0 qemu_aio_coroutine_enter #1 aio_dispatch_handler #2 aio_poll #3 monitor_cleanup qemu#4 qemu_cleanup qemu#5 qemu_default_main Then it found the migration incoming coroutine, schedule it (even after migration_shutdown()), causing crash: #0 __pthread_kill_implementation #1 __pthread_kill_internal #2 __GI_raise #3 __GI_abort qemu#4 __assert_fail_base qemu#5 __assert_fail qemu#6 qemu_mutex_lock_impl qemu#7 qemu_lockable_mutex_lock qemu#8 qemu_lockable_lock qemu#9 qemu_lockable_auto_lock qemu#10 migrate_set_error qemu#11 process_incoming_migration_co qemu#12 coroutine_trampoline To fix it, take a refcount after an incoming setup is properly done when qmp_migrate_incoming() succeeded the 1st time. As it's during a QMP handler which needs BQL, it means the main loop is still alive (without going into cleanups, which also needs BQL). Releasing the refcount now only until the incoming migration coroutine finished or failed. Hence the refcount is valid for both (1) setup phase of incoming ports, mostly IO watches (e.g. qio_channel_add_watch_full()), and (2) the incoming coroutine itself (process_incoming_migration_co()). Note that we can't unref in migration_incoming_state_destroy(), because both qmp_xen_load_devices_state() and load_snapshot() will use it without an incoming migration. Those hold BQL so they're not prone to this issue. PS: I suspect nobody uses Xen's command at all, as it didn't register yank, hence AFAIU the command should crash on master when trying to unregister yank in migration_incoming_state_destroy().. but that's another story. Also note that in some incoming failure cases we may not always unref the MigrationState refcount, which is a trade-off to keep things simple. We could make it accurate, but it can be an overkill. Some examples: - Unlike most of the rest protocols, socket_start_incoming_migration() may create net listener after incoming port setup sucessfully. It means we can't unref in migration_channel_process_incoming() as a generic path because socket protocol might keep using MigrationState. - For either socket or file, multiple IO watches might be created, it means logically each IO watch needs to take one refcount for MigrationState so as to be 100% accurate on ownership of refcount taken. In general, we at least need per-protocol handling to make it accurate, which can be an overkill if we know incoming failed after all. Add a short comment to explain that when taking the refcount in qmp_migrate_incoming(). Bugzilla: https://issues.redhat.com/browse/RHEL-69775 Tested-by: Yan Fu <yafu@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Fabiano Rosas <farosas@suse.de> Message-ID: <20250220132459.512610-1-peterx@redhat.com> Signed-off-by: Fabiano Rosas <farosas@suse.de>
osy
pushed a commit
that referenced
this pull request
Jul 7, 2025
Address a memory leak bug in the usages of timer_del().
The issue arises from the incorrect use of the ambiguous timer API
timer_del(), which does not free the timer object. The LeakSanitizer
report this issue during fuzzing. The correct API timer_free() freed
the timer object instead.
=================================================================
==2586273==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 48 byte(s) in 1 object(s) allocated from:
#0 0x55f2afd89879 in calloc /llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:75:3
#1 0x7f443b93ac50 in g_malloc0 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5ec50)
#2 0x55f2b053962e in timer_new include/qemu/timer.h:542:12
#3 0x55f2b0514771 in timer_new_us include/qemu/timer.h:582:12
qemu#4 0x55f2b0514288 in lsi_scsi_realize hw/scsi/lsi53c895a.c:2350:24
qemu#5 0x55f2b0452d26 in pci_qdev_realize hw/pci/pci.c:2174:9
Signed-off-by: Zheng Huang <hz1624917200@outlook.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <73cd69f9-ff9b-4cd4-b8aa-265f9d6067b9@gmail.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
osy
pushed a commit
that referenced
this pull request
Jul 7, 2025
ASAN spotted a leaking string in machine_set_loadparm():
Direct leak of 9 byte(s) in 1 object(s) allocated from:
#0 0x560ffb5bb379 in malloc ../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:69:3
#1 0x7f1aca926518 in g_malloc ../glib/gmem.c:106
#2 0x7f1aca94113e in g_strdup ../glib/gstrfuncs.c:364
#3 0x560ffc8afbf9 in qobject_input_type_str ../qapi/qobject-input-visitor.c:542:12
qemu#4 0x560ffc8a80ff in visit_type_str ../qapi/qapi-visit-core.c:349:10
qemu#5 0x560ffbe6053a in machine_set_loadparm ../hw/s390x/s390-virtio-ccw.c:802:10
qemu#6 0x560ffc0c5e52 in object_property_set ../qom/object.c:1450:5
qemu#7 0x560ffc0d4175 in object_property_set_qobject ../qom/qom-qobject.c:28:10
qemu#8 0x560ffc0c6004 in object_property_set_str ../qom/object.c:1458:15
qemu#9 0x560ffbe2ae60 in update_machine_ipl_properties ../hw/s390x/ipl.c:569:9
qemu#10 0x560ffbe2aa65 in s390_ipl_update_diag308 ../hw/s390x/ipl.c:594:5
qemu#11 0x560ffbdee132 in handle_diag_308 ../target/s390x/diag.c:147:9
qemu#12 0x560ffbebb956 in helper_diag ../target/s390x/tcg/misc_helper.c:137:9
qemu#13 0x7f1a3c51c730 (/memfd:tcg-jit (deleted)+0x39730)
Cc: qemu-stable@nongnu.org
Signed-off-by: Fabiano Rosas <farosas@suse.de>
Message-ID: <20250509174938.25935-1-farosas@suse.de>
Fixes: 1fd396e ("s390x: Register TYPE_S390_CCW_MACHINE properties as class properties")
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit bdf12f2)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
osy
pushed a commit
that referenced
this pull request
Jul 7, 2025
The hardware stores the instruction code in the lower bits of the FP exception register #1 on FP assist traps. This fixes the FP exception handler on Linux, as the Linux kernel uses the value to decide on the correct signal which should be pushed into userspace (see decode_fpu() in Linux kernel). Signed-off-by: Helge Deller <deller@gmx.de> (cherry picked from commit 923976d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
osy
pushed a commit
that referenced
this pull request
Jul 7, 2025
Improve the linux-user emulation to send the correct si_code depending on overflow (TARGET_FPE_FLTOVF), underflow (TARGET_FPE_FLTUND), ... Note that the hardware stores the relevant flags in FP exception register #1, which is actually the lower 32-bits of the 64-bit fr[0] register in qemu. Signed-off-by: Helge Deller <deller@gmx.de> (cherry picked from commit b4b49cf) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
osy
pushed a commit
that referenced
this pull request
Jul 7, 2025
Implement FP exception register #1 (lower 32-bits of 64-bit fr[0]). A proper implementation is necessary to allow the Linux kernel in system mode and the qemu linux-user to send proper si_code values on SIGFPE signal. Always set the T-bit on taken exception, and merge over- and underflow in system mode to just set overflow bit to mimic the behaviour I tested on a physical machine. The test program below can be used to verify correct behaviour. Note that behaviour on SIGFPE may vary on different platforms. The program should always detect the correct signal, but it may or may not be able to sucessfully continue afterwards. #define _GNU_SOURCE #include <signal.h> #include <stdio.h> #include <fenv.h> #include <float.h> static void fpe_func(int sig, siginfo_t *i, void *v) { sigset_t set; sigemptyset(&set); sigaddset(&set, SIGFPE); sigprocmask(SIG_UNBLOCK, &set, NULL); printf("GOT signal %d with si_code %ld\n", sig, i->si_code); } int main(int argc, char *argv[]) { struct sigaction action = { .sa_sigaction = fpe_func, .sa_flags = SA_RESTART|SA_SIGINFO }; sigaction(SIGFPE, &action, 0); feenableexcept(FE_OVERFLOW | FE_UNDERFLOW); double x = DBL_MIN; return printf("%lf\n", argc > 1 ? 1.7976931348623158E308*1.7976931348623158E308 : x / 10); } Signed-off-by: Helge Deller <deller@gmx.de> (cherry picked from commit ebd3949) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When running on a Mac, QEMU is able to get the host OSK and use it as
the default value for the AppleSMC device. The OSK query operation
doesn't require administrator privileges and can be executed by any user
on the system. This patch is based on open-source code from Apple, just
like the implementation from VirtualBox.
Apple:
https://opensource.apple.com/source/IOKitUser/IOKitUser-647.6.13/pwr_mgt.subproj/IOPMLibPrivate.c
https://opensource.apple.com/source/PowerManagement/PowerManagement-637.60.1/pmconfigd/PrivateLib.c
VirtualBox:
https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Devices/EFI/DevSmc.cpp#L516
Signed-off-by: Pedro Tôrres t0rr3sp3dr0@gmail.com