timer ISR is getting not trigged, SPIFFS not working, Wifi? #10
Comments
|
Hi @peterus, For SPIFFS, have you changed the flash mode to DOUT in your application? https://github.com/espressif/qemu/wiki#build-test-app Regarding Wi-Fi, you are right, it is not emulated in QEMU. You may use "OpenEth" Ethernet MAC driver provided in ESP-IDF: |
|
Hi @igrr, regarding the timer issue: the counter is changing, but it looks like the hw is not triggering an interrupt as the alarm value is staying the same:
regarding the other topics: I am currently using the arduino core which does not have this setting to change the flash mode or network mode. Do you have other suggestions which i could change (localy in the core) to get this working? - changing currently to ESP-IDF is not an option for me as I am using a lot of arduino libraries which are not ported so easily. |
|
i decided to give ESP-IDF a try, but unfortunately SPIFFS is also not working with the settings changed:
edit: sorry for the post, I checked again the config and there was something going wrong with it, now it is working! |
|
after a some days of trying around and getting familiar to ESP-IDF I decided to switch to ESP-IDF. |
igrr
pushed a commit
that referenced
this issue
Feb 20, 2021
Properly free each command resp to avoid memory leak.
ASAN shows memory leak stack:
Indirect leak of 2352520 byte(s) in 571 object(s) allocated from:
#0 0x7f6ca3308d4e in __interceptor_calloc (/lib64/libasan.so.5+0x112d4e)
#1 0x7f6ca3127a50 in g_malloc0 (/lib64/libglib-2.0.so.0+0x55a50)
#2 0x557bf3c71d2b in qdict_new ../qobject/qdict.c:29
#3 0x557bf3c9caba in parse_object ../qobject/json-parser.c:318
#4 0x557bf3c9ce75 in json_parser_parse ../qobject/json-parser.c:580
#5 0x557bf3c8c8cf in json_message_process_token ../qobject/json-streamer.c:92
#6 0x557bf3c9ea59 in json_lexer_feed_char ../qobject/json-lexer.c:313
#7 0x557bf3c9eeb5 in json_lexer_feed ../qobject/json-lexer.c:350
#8 0x557bf3c4793a in qmp_fd_receive ../tests/qtest/libqtest.c:608
#9 0x557bf3c47b58 in qtest_qmp_receive ../tests/qtest/libqtest.c:618
#10 0x557bf3c44245 in wait_command ../tests/qtest/migration-helpers.c:59
#11 0x557bf3c445cb in migrate_query_status ../tests/qtest/migration-helpers.c:108
#12 0x557bf3c44642 in check_migration_status ../tests/qtest/migration-helpers.c:124
#13 0x557bf3c447e7 in wait_for_migration_status ../tests/qtest/migration-helpers.c:148
#14 0x557bf3c43b8f in test_migrate_auto_converge ../tests/qtest/migration-test.c:1243
......
Fix: 5e34005
Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com>
Message-Id: <20201023061218.2080844-2-kuhn.chenqun@huawei.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
igrr
pushed a commit
that referenced
this issue
Feb 20, 2021
mon_get_cpu_env() is indirectly called monitor_parse_arguments() where the current monitor isn't set yet. Instead of using monitor_cur_env(), explicitly pass the Monitor pointer to the function. Without this fix, an HMP command like "x $pc" crashes like this: #0 0x0000555555caa01f in mon_get_cpu_sync (mon=0x0, synchronize=true) at ../monitor/misc.c:270 #1 0x0000555555caa141 in mon_get_cpu (mon=0x0) at ../monitor/misc.c:294 #2 0x0000555555caa158 in mon_get_cpu_env () at ../monitor/misc.c:299 #3 0x0000555555b19739 in monitor_get_pc (mon=0x555556ad2de0, md=0x5555565d2d40 <monitor_defs+1152>, val=0) at ../target/i386/monitor.c:607 #4 0x0000555555cadbec in get_monitor_def (mon=0x555556ad2de0, pval=0x7fffffffc208, name=0x7fffffffc220 "pc") at ../monitor/misc.c:1681 #5 0x000055555582ec4f in expr_unary (mon=0x555556ad2de0) at ../monitor/hmp.c:387 #6 0x000055555582edbb in expr_prod (mon=0x555556ad2de0) at ../monitor/hmp.c:421 #7 0x000055555582ee79 in expr_logic (mon=0x555556ad2de0) at ../monitor/hmp.c:455 #8 0x000055555582eefe in expr_sum (mon=0x555556ad2de0) at ../monitor/hmp.c:484 #9 0x000055555582efe8 in get_expr (mon=0x555556ad2de0, pval=0x7fffffffc418, pp=0x7fffffffc408) at ../monitor/hmp.c:511 #10 0x000055555582fcd4 in monitor_parse_arguments (mon=0x555556ad2de0, endp=0x7fffffffc890, cmd=0x555556675b50 <hmp_cmds+7920>) at ../monitor/hmp.c:876 #11 0x00005555558306a8 in handle_hmp_command (mon=0x555556ad2de0, cmdline=0x555556ada452 "$pc") at ../monitor/hmp.c:1087 #12 0x000055555582df14 in monitor_command_cb (opaque=0x555556ad2de0, cmdline=0x555556ada450 "x $pc", readline_opaque=0x0) at ../monitor/hmp.c:47 After this fix, nothing is left in monitor_parse_arguments() that can indirectly call monitor_cur(), so the fix is complete. Fixes: ff04108 Reported-by: lichun <lichun@ruijie.com.cn> Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20201113114326.97663-4-kwolf@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
igrr
pushed a commit
that referenced
this issue
Feb 20, 2021
In qobject_type(), NULL is returned when the 'QObject' returned from parse_value() is not of QString type,
and this 'QObject' memory will leaked.
So we need to first cache the 'QObject' returned from parse_value(), and finally
free 'QObject' memory at the end of the function.
Also, we add a testcast about invalid dict key.
The memleak stack is as follows:
Direct leak of 32 byte(s) in 1 object(s) allocated from:
#0 0xfffe4b3c34fb in __interceptor_malloc (/lib64/libasan.so.4+0xd34fb)
#1 0xfffe4ae48aa3 in g_malloc (/lib64/libglib-2.0.so.0+0x58aa3)
#2 0xaaab3557d9f7 in qnum_from_int qemu/qobject/qnum.c:25
#3 0xaaab35584d23 in parse_literal qemu/qobject/json-parser.c:511
#4 0xaaab35584d23 in parse_value qemu/qobject/json-parser.c:554
#5 0xaaab35583d77 in parse_pair qemu/qobject/json-parser.c:270
#6 0xaaab355845db in parse_object qemu/qobject/json-parser.c:327
#7 0xaaab355845db in parse_value qemu/qobject/json-parser.c:546
#8 0xaaab35585b1b in json_parser_parse qemu/qobject/json-parser.c:580
#9 0xaaab35583703 in json_message_process_token qemu/qobject/json-streamer.c:92
#10 0xaaab355ddccf in json_lexer_feed_char qemu/qobject/json-lexer.c:313
#11 0xaaab355de0eb in json_lexer_feed qemu/qobject/json-lexer.c:350
#12 0xaaab354aff67 in tcp_chr_read qemu/chardev/char-socket.c:525
#13 0xfffe4ae429db in g_main_context_dispatch (/lib64/libglib-2.0.so.0+0x529db)
#14 0xfffe4ae42d8f (/lib64/libglib-2.0.so.0+0x52d8f)
#15 0xfffe4ae430df in g_main_loop_run (/lib64/libglib-2.0.so.0+0x530df)
#16 0xaaab34d70bff in iothread_run qemu/iothread.c:82
#17 0xaaab3559d71b in qemu_thread_start qemu/util/qemu-thread-posix.c:519
Fixes: 532fb53 ("qapi: Make more of qobject_to()")
Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Alex Chen <alex.chen@huawei.com>
Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201113145525.85151-1-alex.chen@huawei.com>
[Commit message tweaked]
igrr
pushed a commit
that referenced
this issue
Feb 20, 2021
Properly free resp for get_watchdog_action() to avoid memory leak.
ASAN shows memory leak stack:
Indirect leak of 12360 byte(s) in 3 object(s) allocated from:
#0 0x7f41ab6cbd4e in __interceptor_calloc (/lib64/libasan.so.5+0x112d4e)
#1 0x7f41ab4eaa50 in g_malloc0 (/lib64/libglib-2.0.so.0+0x55a50)
#2 0x556487d5374b in qdict_new ../qobject/qdict.c:29
#3 0x556487d65e1a in parse_object ../qobject/json-parser.c:318
#4 0x556487d65cb6 in parse_pair ../qobject/json-parser.c:287
#5 0x556487d65ebd in parse_object ../qobject/json-parser.c:343
#6 0x556487d661d5 in json_parser_parse ../qobject/json-parser.c:580
#7 0x556487d513df in json_message_process_token ../qobject/json-streamer.c:92
#8 0x556487d63919 in json_lexer_feed_char ../qobject/json-lexer.c:313
#9 0x556487d63d75 in json_lexer_feed ../qobject/json-lexer.c:350
#10 0x556487d28b2a in qmp_fd_receive ../tests/qtest/libqtest.c:613
#11 0x556487d2a16f in qtest_qmp_eventwait_ref ../tests/qtest/libqtest.c:827
#12 0x556487d248e2 in get_watchdog_action ../tests/qtest/npcm7xx_watchdog_timer-test.c:94
#13 0x556487d25765 in test_enabling_flags ../tests/qtest/npcm7xx_watchdog_timer-test.c:243
Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com>
Message-Id: <20201118115646.2461726-3-kuhn.chenqun@huawei.com>
Reviewed-by: Havard Skinnemoen <hskinnemoen@google.com>
Reviewed-by: Hao Wu <wuhaotsh@google.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
igrr
pushed a commit
that referenced
this issue
Feb 20, 2021
When 'j = icu->nr_sense – 1', the 'j < icu->nr_sense' condition is true,
then 'j = icu->nr_sense', the'icu->init_sense[j]' has out-of-bounds access.
The asan showed stack:
ERROR: AddressSanitizer: heap-buffer-overflow on address 0x604000004d7d at pc 0x55852cd26a76 bp 0x7ffe39f26200 sp 0x7ffe39f261f0
READ of size 1 at 0x604000004d7d thread T0
#0 0x55852cd26a75 in rxicu_realize ../hw/intc/rx_icu.c:311
#1 0x55852cf075f7 in device_set_realized ../hw/core/qdev.c:886
#2 0x55852cd4a32f in property_set_bool ../qom/object.c:2251
#3 0x55852cd4f9bb in object_property_set ../qom/object.c:1398
#4 0x55852cd54f3f in object_property_set_qobject ../qom/qom-qobject.c:28
#5 0x55852cd4fc3f in object_property_set_bool ../qom/object.c:1465
#6 0x55852cbf0b27 in register_icu ../hw/rx/rx62n.c:156
#7 0x55852cbf12a6 in rx62n_realize ../hw/rx/rx62n.c:261
#8 0x55852cf075f7 in device_set_realized ../hw/core/qdev.c:886
#9 0x55852cd4a32f in property_set_bool ../qom/object.c:2251
#10 0x55852cd4f9bb in object_property_set ../qom/object.c:1398
#11 0x55852cd54f3f in object_property_set_qobject ../qom/qom-qobject.c:28
#12 0x55852cd4fc3f in object_property_set_bool ../qom/object.c:1465
#13 0x55852cbf1a85 in rx_gdbsim_init ../hw/rx/rx-gdbsim.c:109
#14 0x55852cd22de0 in qemu_init ../softmmu/vl.c:4380
#15 0x55852ca57088 in main ../softmmu/main.c:49
#16 0x7feefafa5d42 in __libc_start_main (/lib64/libc.so.6+0x26d42)
Add the 'ice->src[i].sense' initialize to the default value, and then
process init_sense array to identify which irqs should be level-triggered.
Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20201111141733.2358800-1-kuhn.chenqun@huawei.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
igrr
pushed a commit
that referenced
this issue
Aug 2, 2022
In commit 00f05c0 we gave the TYPE_XLNX_CSU_DMA object its own class struct, but forgot to update the TypeInfo::class_size accordingly. This meant that not enough memory was allocated for the class struct, and the initialization of xcdc->read in the class init function wrote off the end of the memory. Add the missing line. Found by running 'check-qtest-aarch64' with a clang address-sanitizer build, which complains: ==2542634==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61000000ab00 at pc 0x559a20aebc29 bp 0x7fff97df74d0 sp 0x7fff97df74c8 WRITE of size 8 at 0x61000000ab00 thread T0 #0 0x559a20aebc28 in xlnx_csu_dma_class_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/san/../../hw/dma/xlnx_csu_dma.c:722:16 #1 0x559a21bf297c in type_initialize /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/san/../../qom/object.c:365:9 #2 0x559a21bf3442 in object_class_foreach_tramp /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/san/../../qom/object.c:1070:5 #3 0x7f09bcb641b7 in g_hash_table_foreach (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x401b7) #4 0x559a21bf3c27 in object_class_foreach /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/san/../../qom/object.c:1092:5 #5 0x559a21bf3c27 in object_class_get_list /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/san/../../qom/object.c:1149:5 #6 0x559a2081a2fd in select_machine /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/san/../../softmmu/vl.c:1661:24 #7 0x559a2081a2fd in qemu_create_machine /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/san/../../softmmu/vl.c:2146:35 #8 0x559a2081a2fd in qemu_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/san/../../softmmu/vl.c:3706:5 #9 0x559a20720ed5 in main /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/san/../../softmmu/main.c:49:5 #10 0x7f09baec00b2 in __libc_start_main /build/glibc-sMfBJT/glibc-2.31/csu/../csu/libc-start.c:308:16 #11 0x559a2067673d in _start (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/san/qemu-system-aarch64+0xf4b73d) 0x61000000ab00 is located 0 bytes to the right of 192-byte region [0x61000000aa40,0x61000000ab00) allocated by thread T0 here: #0 0x559a206eeff2 in calloc (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/san/qemu-system-aarch64+0xfc3ff2) #1 0x7f09bcb7bef0 in g_malloc0 (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x57ef0) #2 0x559a21bf3442 in object_class_foreach_tramp /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/san/../../qom/object.c:1070:5 Fixes: 00f05c0 ("hw/dma/xlnx_csu_dma: Support starting a read transfer through a class method") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Francisco Iglesias <francisco.iglesias@xilinx.com> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20220308150207.2546272-1-peter.maydell@linaro.org
igrr
pushed a commit
that referenced
this issue
Aug 2, 2022
Include the qtest reproducer provided by Alexander Bulekov in https://gitlab.com/qemu-project/qemu/-/issues/542. Without the previous commit, we get: $ make check-qtest-i386 ... Running test tests/qtest/intel-hda-test AddressSanitizer:DEADLYSIGNAL ================================================================= ==1580408==ERROR: AddressSanitizer: stack-overflow on address 0x7ffc3d566fe0 #0 0x63d297cf in address_space_translate_internal softmmu/physmem.c:356 #1 0x63d27260 in flatview_do_translate softmmu/physmem.c:499:15 #2 0x63d27af5 in flatview_translate softmmu/physmem.c:565:15 #3 0x63d4ce84 in flatview_write softmmu/physmem.c:2850:10 #4 0x63d4cb18 in address_space_write softmmu/physmem.c:2950:18 #5 0x63d4d387 in address_space_rw softmmu/physmem.c:2960:16 #6 0x62ae12f2 in dma_memory_rw_relaxed include/sysemu/dma.h:89:12 #7 0x62ae104a in dma_memory_rw include/sysemu/dma.h:132:12 #8 0x62ae6157 in dma_memory_write include/sysemu/dma.h:173:12 #9 0x62ae5ec0 in stl_le_dma include/sysemu/dma.h:275:1 #10 0x62ae5ba2 in stl_le_pci_dma include/hw/pci/pci.h:871:1 #11 0x62ad59a6 in intel_hda_response hw/audio/intel-hda.c:372:12 #12 0x62ad2afb in hda_codec_response hw/audio/intel-hda.c:107:5 #13 0x62aec4e1 in hda_audio_command hw/audio/hda-codec.c:655:5 #14 0x62ae05d9 in intel_hda_send_command hw/audio/intel-hda.c:307:5 #15 0x62adff54 in intel_hda_corb_run hw/audio/intel-hda.c:342:9 #16 0x62adc13b in intel_hda_set_corb_wp hw/audio/intel-hda.c:548:5 #17 0x62ae5942 in intel_hda_reg_write hw/audio/intel-hda.c:977:9 #18 0x62ada10a in intel_hda_mmio_write hw/audio/intel-hda.c:1054:5 #19 0x63d8f383 in memory_region_write_accessor softmmu/memory.c:492:5 #20 0x63d8ecc1 in access_with_adjusted_size softmmu/memory.c:554:18 #21 0x63d8d5d6 in memory_region_dispatch_write softmmu/memory.c:1504:16 #22 0x63d5e85e in flatview_write_continue softmmu/physmem.c:2812:23 #23 0x63d4d05b in flatview_write softmmu/physmem.c:2854:12 #24 0x63d4cb18 in address_space_write softmmu/physmem.c:2950:18 #25 0x63d4d387 in address_space_rw softmmu/physmem.c:2960:16 #26 0x62ae12f2 in dma_memory_rw_relaxed include/sysemu/dma.h:89:12 #27 0x62ae104a in dma_memory_rw include/sysemu/dma.h:132:12 #28 0x62ae6157 in dma_memory_write include/sysemu/dma.h:173:12 #29 0x62ae5ec0 in stl_le_dma include/sysemu/dma.h:275:1 #30 0x62ae5ba2 in stl_le_pci_dma include/hw/pci/pci.h:871:1 #31 0x62ad59a6 in intel_hda_response hw/audio/intel-hda.c:372:12 #32 0x62ad2afb in hda_codec_response hw/audio/intel-hda.c:107:5 #33 0x62aec4e1 in hda_audio_command hw/audio/hda-codec.c:655:5 #34 0x62ae05d9 in intel_hda_send_command hw/audio/intel-hda.c:307:5 #35 0x62adff54 in intel_hda_corb_run hw/audio/intel-hda.c:342:9 #36 0x62adc13b in intel_hda_set_corb_wp hw/audio/intel-hda.c:548:5 #37 0x62ae5942 in intel_hda_reg_write hw/audio/intel-hda.c:977:9 #38 0x62ada10a in intel_hda_mmio_write hw/audio/intel-hda.c:1054:5 #39 0x63d8f383 in memory_region_write_accessor softmmu/memory.c:492:5 #40 0x63d8ecc1 in access_with_adjusted_size softmmu/memory.c:554:18 #41 0x63d8d5d6 in memory_region_dispatch_write softmmu/memory.c:1504:16 #42 0x63d5e85e in flatview_write_continue softmmu/physmem.c:2812:23 #43 0x63d4d05b in flatview_write softmmu/physmem.c:2854:12 #44 0x63d4cb18 in address_space_write softmmu/physmem.c:2950:18 #45 0x63d4d387 in address_space_rw softmmu/physmem.c:2960:16 #46 0x62ae12f2 in dma_memory_rw_relaxed include/sysemu/dma.h:89:12 qemu#47 0x62ae104a in dma_memory_rw include/sysemu/dma.h:132:12 #48 0x62ae6157 in dma_memory_write include/sysemu/dma.h:173:12 ... SUMMARY: AddressSanitizer: stack-overflow softmmu/physmem.c:356 in address_space_translate_internal ==1580408==ABORTING Broken pipe Aborted (core dumped) Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: Thomas Huth <thuth@redhat.com> Message-Id: <20211218160912.1591633-4-philmd@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
igrr
pushed a commit
that referenced
this issue
Aug 2, 2022
The issue reported by OSS-Fuzz produces the following backtrace:
==447470==ERROR: AddressSanitizer: heap-buffer-overflow
READ of size 1 at 0x61500002a080 thread T0
#0 0x71766d47 in sdhci_read_dataport hw/sd/sdhci.c:474:18
#1 0x7175f139 in sdhci_read hw/sd/sdhci.c:1022:19
#2 0x721b937b in memory_region_read_accessor softmmu/memory.c:440:11
#3 0x72171e51 in access_with_adjusted_size softmmu/memory.c:554:18
#4 0x7216f47c in memory_region_dispatch_read1 softmmu/memory.c:1424:16
#5 0x7216ebb9 in memory_region_dispatch_read softmmu/memory.c:1452:9
#6 0x7212db5d in flatview_read_continue softmmu/physmem.c:2879:23
#7 0x7212f958 in flatview_read softmmu/physmem.c:2921:12
#8 0x7212f418 in address_space_read_full softmmu/physmem.c:2934:18
#9 0x721305a9 in address_space_rw softmmu/physmem.c:2962:16
#10 0x7175a392 in dma_memory_rw_relaxed include/sysemu/dma.h:89:12
#11 0x7175a0ea in dma_memory_rw include/sysemu/dma.h:132:12
#12 0x71759684 in dma_memory_read include/sysemu/dma.h:152:12
#13 0x7175518c in sdhci_do_adma hw/sd/sdhci.c:823:27
#14 0x7174bf69 in sdhci_data_transfer hw/sd/sdhci.c:935:13
#15 0x7176aaa7 in sdhci_send_command hw/sd/sdhci.c:376:9
#16 0x717629ee in sdhci_write hw/sd/sdhci.c:1212:9
#17 0x72172513 in memory_region_write_accessor softmmu/memory.c:492:5
#18 0x72171e51 in access_with_adjusted_size softmmu/memory.c:554:18
#19 0x72170766 in memory_region_dispatch_write softmmu/memory.c:1504:16
#20 0x721419ee in flatview_write_continue softmmu/physmem.c:2812:23
#21 0x721301eb in flatview_write softmmu/physmem.c:2854:12
#22 0x7212fca8 in address_space_write softmmu/physmem.c:2950:18
#23 0x721d9a53 in qtest_process_command softmmu/qtest.c:727:9
A DMA descriptor is previously filled in RAM. An I/O access to the
device (frames #22 to #16) start the DMA engine (frame #13). The
engine fetch the descriptor and execute the request, which itself
accesses the SDHCI I/O registers (frame #1 and #0), triggering a
re-entrancy issue.
Fix by prohibit transactions from the DMA to devices. The DMA engine
is thus restricted to memories.
Reported-by: OSS-Fuzz (Issue 36391)
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/451
Message-Id: <20211215205656.488940-3-philmd@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
igrr
pushed a commit
that referenced
this issue
Aug 2, 2022
Include the qtest reproducer provided by Alexander Bulekov in https://gitlab.com/qemu-project/qemu/-/issues/451. Without the previous commit, we get: $ make check-qtest-i386 ... Running test qtest-i386/fuzz-sdcard-test ==447470==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61500002a080 at pc 0x564c71766d48 bp 0x7ffc126c62b0 sp 0x7ffc126c62a8 READ of size 1 at 0x61500002a080 thread T0 #0 0x564c71766d47 in sdhci_read_dataport hw/sd/sdhci.c:474:18 #1 0x564c7175f139 in sdhci_read hw/sd/sdhci.c:1022:19 #2 0x564c721b937b in memory_region_read_accessor softmmu/memory.c:440:11 #3 0x564c72171e51 in access_with_adjusted_size softmmu/memory.c:554:18 #4 0x564c7216f47c in memory_region_dispatch_read1 softmmu/memory.c:1424:16 #5 0x564c7216ebb9 in memory_region_dispatch_read softmmu/memory.c:1452:9 #6 0x564c7212db5d in flatview_read_continue softmmu/physmem.c:2879:23 #7 0x564c7212f958 in flatview_read softmmu/physmem.c:2921:12 #8 0x564c7212f418 in address_space_read_full softmmu/physmem.c:2934:18 #9 0x564c721305a9 in address_space_rw softmmu/physmem.c:2962:16 #10 0x564c7175a392 in dma_memory_rw_relaxed include/sysemu/dma.h:89:12 #11 0x564c7175a0ea in dma_memory_rw include/sysemu/dma.h:132:12 #12 0x564c71759684 in dma_memory_read include/sysemu/dma.h:152:12 #13 0x564c7175518c in sdhci_do_adma hw/sd/sdhci.c:823:27 #14 0x564c7174bf69 in sdhci_data_transfer hw/sd/sdhci.c:935:13 #15 0x564c7176aaa7 in sdhci_send_command hw/sd/sdhci.c:376:9 #16 0x564c717629ee in sdhci_write hw/sd/sdhci.c:1212:9 #17 0x564c72172513 in memory_region_write_accessor softmmu/memory.c:492:5 #18 0x564c72171e51 in access_with_adjusted_size softmmu/memory.c:554:18 #19 0x564c72170766 in memory_region_dispatch_write softmmu/memory.c:1504:16 #20 0x564c721419ee in flatview_write_continue softmmu/physmem.c:2812:23 #21 0x564c721301eb in flatview_write softmmu/physmem.c:2854:12 #22 0x564c7212fca8 in address_space_write softmmu/physmem.c:2950:18 #23 0x564c721d9a53 in qtest_process_command softmmu/qtest.c:727:9 0x61500002a080 is located 0 bytes to the right of 512-byte region [0x615000029e80,0x61500002a080) allocated by thread T0 here: #0 0x564c708e1737 in __interceptor_calloc (qemu-system-i386+0x1e6a737) #1 0x7ff05567b5e0 in g_malloc0 (/lib64/libglib-2.0.so.0+0x5a5e0) #2 0x564c71774adb in sdhci_pci_realize hw/sd/sdhci-pci.c:36:5 SUMMARY: AddressSanitizer: heap-buffer-overflow hw/sd/sdhci.c:474:18 in sdhci_read_dataport Shadow bytes around the buggy address: 0x0c2a7fffd3c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c2a7fffd3d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c2a7fffd3e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c2a7fffd3f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c2a7fffd400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x0c2a7fffd410:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c2a7fffd420: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c2a7fffd430: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c2a7fffd440: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c2a7fffd450: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c2a7fffd460: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Heap left redzone: fa Freed heap region: fd ==447470==ABORTING Broken pipe ERROR qtest-i386/fuzz-sdcard-test - too few tests run (expected 3, got 2) Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: Thomas Huth <thuth@redhat.com> Message-Id: <20211215205656.488940-4-philmd@redhat.com> [thuth: Replaced "-m 4G" with "-m 512M"] Signed-off-by: Thomas Huth <thuth@redhat.com>
listout
pushed a commit
to listout/qemu
that referenced
this issue
Feb 23, 2023
The DMA engine is started by I/O access and then itself accesses the
I/O registers, triggering a reentrancy bug.
The following log can reveal it:
==5637==ERROR: AddressSanitizer: stack-overflow
#0 0x5595435f6078 in tulip_xmit_list_update qemu/hw/net/tulip.c:673
espressif#1 0x5595435f204a in tulip_write qemu/hw/net/tulip.c:805:13
espressif#2 0x559544637f86 in memory_region_write_accessor qemu/softmmu/memory.c:492:5
espressif#3 0x5595446379fa in access_with_adjusted_size qemu/softmmu/memory.c:554:18
espressif#4 0x5595446372fa in memory_region_dispatch_write qemu/softmmu/memory.c
espressif#5 0x55954468b74c in flatview_write_continue qemu/softmmu/physmem.c:2825:23
espressif#6 0x559544683662 in flatview_write qemu/softmmu/physmem.c:2867:12
espressif#7 0x5595446833f3 in address_space_write qemu/softmmu/physmem.c:2963:18
espressif#8 0x5595435fb082 in dma_memory_rw_relaxed qemu/include/sysemu/dma.h:87:12
espressif#9 0x5595435fb082 in dma_memory_rw qemu/include/sysemu/dma.h:130:12
espressif#10 0x5595435fb082 in dma_memory_write qemu/include/sysemu/dma.h:171:12
espressif#11 0x5595435fb082 in stl_le_dma qemu/include/sysemu/dma.h:272:1
espressif#12 0x5595435fb082 in stl_le_pci_dma qemu/include/hw/pci/pci.h:910:1
espressif#13 0x5595435fb082 in tulip_desc_write qemu/hw/net/tulip.c:101:9
espressif#14 0x5595435f7e3d in tulip_xmit_list_update qemu/hw/net/tulip.c:706:9
espressif#15 0x5595435f204a in tulip_write qemu/hw/net/tulip.c:805:13
Fix this bug by restricting the DMA engine to memories regions.
Signed-off-by: Zheyu Ma <zheyuma97@gmail.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
listout
pushed a commit
to listout/qemu
that referenced
this issue
Feb 23, 2023
Setup an ARM virtual machine of machine virt and execute qmp "query-acpi-ospm-status" causes segmentation fault with following dumpstack: espressif#1 0x0000aaaaab64235c in qmp_query_acpi_ospm_status (errp=errp@entry=0xfffffffff030) at ../monitor/qmp-cmds.c:312 espressif#2 0x0000aaaaabfc4e20 in qmp_marshal_query_acpi_ospm_status (args=<optimized out>, ret=0xffffea4ffe90, errp=0xffffea4ffe88) at qapi/qapi-commands-acpi.c:63 espressif#3 0x0000aaaaabff8ba0 in do_qmp_dispatch_bh (opaque=0xffffea4ffe98) at ../qapi/qmp-dispatch.c:128 espressif#4 0x0000aaaaac02e594 in aio_bh_call (bh=0xffffe0004d80) at ../util/async.c:150 espressif#5 aio_bh_poll (ctx=ctx@entry=0xaaaaad0f6040) at ../util/async.c:178 espressif#6 0x0000aaaaac00bd40 in aio_dispatch (ctx=ctx@entry=0xaaaaad0f6040) at ../util/aio-posix.c:421 espressif#7 0x0000aaaaac02e010 in aio_ctx_dispatch (source=0xaaaaad0f6040, callback=<optimized out>, user_data=<optimized out>) at ../util/async.c:320 espressif#8 0x0000fffff76f6884 in g_main_context_dispatch () at /usr/lib64/libglib-2.0.so.0 espressif#9 0x0000aaaaac0452d4 in glib_pollfds_poll () at ../util/main-loop.c:297 espressif#10 os_host_main_loop_wait (timeout=0) at ../util/main-loop.c:320 espressif#11 main_loop_wait (nonblocking=nonblocking@entry=0) at ../util/main-loop.c:596 espressif#12 0x0000aaaaab5c9e50 in qemu_main_loop () at ../softmmu/runstate.c:734 espressif#13 0x0000aaaaab185370 in qemu_main (argc=argc@entry=47, argv=argv@entry=0xfffffffff518, envp=envp@entry=0x0) at ../softmmu/main.c:38 espressif#14 0x0000aaaaab16f99c in main (argc=47, argv=0xfffffffff518) at ../softmmu/main.c:47 Fixes: ebb6207 ("hw/acpi: Add ACPI Generic Event Device Support") Signed-off-by: Keqian Zhu <zhukeqian1@huawei.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-id: 20220816094957.31700-1-zhukeqian1@huawei.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
mattiantonini
pushed a commit
to mattiantonini/ESP32-QEMU
that referenced
this issue
Feb 23, 2023
This is below memleak detected when to quit the qemu-system-x86_64 (with
vhost-scsi-pci).
(qemu) quit
=================================================================
==15568==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 40 byte(s) in 1 object(s) allocated from:
#0 0x7f00aec57917 in __interceptor_calloc (/lib64/libasan.so.6+0xb4917)
#1 0x7f00ada0d7b5 in g_malloc0 (/lib64/libglib-2.0.so.0+0x517b5)
espressif#2 0x5648ffd38bac in vhost_scsi_start ../hw/scsi/vhost-scsi.c:92
espressif#3 0x5648ffd38d52 in vhost_scsi_set_status ../hw/scsi/vhost-scsi.c:131
espressif#4 0x5648ffda340e in virtio_set_status ../hw/virtio/virtio.c:2036
espressif#5 0x5648ff8de281 in virtio_ioport_write ../hw/virtio/virtio-pci.c:431
espressif#6 0x5648ff8deb29 in virtio_pci_config_write ../hw/virtio/virtio-pci.c:576
espressif#7 0x5648ffe5c0c2 in memory_region_write_accessor ../softmmu/memory.c:493
espressif#8 0x5648ffe5c424 in access_with_adjusted_size ../softmmu/memory.c:555
espressif#9 0x5648ffe6428f in memory_region_dispatch_write ../softmmu/memory.c:1515
espressif#10 0x5648ffe8613d in flatview_write_continue ../softmmu/physmem.c:2825
espressif#11 0x5648ffe86490 in flatview_write ../softmmu/physmem.c:2867
espressif#12 0x5648ffe86d9f in address_space_write ../softmmu/physmem.c:2963
espressif#13 0x5648ffe86e57 in address_space_rw ../softmmu/physmem.c:2973
espressif#14 0x5648fffbfb3d in kvm_handle_io ../accel/kvm/kvm-all.c:2639
espressif#15 0x5648fffc0e0d in kvm_cpu_exec ../accel/kvm/kvm-all.c:2890
espressif#16 0x5648fffc90a7 in kvm_vcpu_thread_fn ../accel/kvm/kvm-accel-ops.c:51
espressif#17 0x56490042400a in qemu_thread_start ../util/qemu-thread-posix.c:505
espressif#18 0x7f00ac3b6ea4 in start_thread (/lib64/libpthread.so.0+0x7ea4)
Free the vsc->inflight at the 'stop' path.
Fixes: b82526c ("vhost-scsi: support inflight io track")
Cc: Joe Jin <joe.jin@oracle.com>
Cc: Li Feng <fengli@smartx.com>
Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
Message-Id: <20230104160433.21353-1-dongli.zhang@oracle.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
mattiantonini
pushed a commit
to mattiantonini/ESP32-QEMU
that referenced
this issue
Feb 23, 2023
Fixes the appended use-after-free. The root cause is that
during tb invalidation we use CPU_FOREACH, and therefore
to safely free a vCPU we must wait for an RCU grace period
to elapse.
$ x86_64-linux-user/qemu-x86_64 tests/tcg/x86_64-linux-user/munmap-pthread
=================================================================
==1800604==ERROR: AddressSanitizer: heap-use-after-free on address 0x62d0005f7418 at pc 0x5593da6704eb bp 0x7f4961a7ac70 sp 0x7f4961a7ac60
READ of size 8 at 0x62d0005f7418 thread T2
#0 0x5593da6704ea in tb_jmp_cache_inval_tb ../accel/tcg/tb-maint.c:244
#1 0x5593da6704ea in do_tb_phys_invalidate ../accel/tcg/tb-maint.c:290
espressif#2 0x5593da670631 in tb_phys_invalidate__locked ../accel/tcg/tb-maint.c:306
espressif#3 0x5593da670631 in tb_invalidate_phys_page_range__locked ../accel/tcg/tb-maint.c:542
espressif#4 0x5593da67106d in tb_invalidate_phys_range ../accel/tcg/tb-maint.c:614
espressif#5 0x5593da6a64d4 in target_munmap ../linux-user/mmap.c:766
espressif#6 0x5593da6dba05 in do_syscall1 ../linux-user/syscall.c:10105
espressif#7 0x5593da6f564c in do_syscall ../linux-user/syscall.c:13329
espressif#8 0x5593da49e80c in cpu_loop ../linux-user/x86_64/../i386/cpu_loop.c:233
espressif#9 0x5593da6be28c in clone_func ../linux-user/syscall.c:6633
espressif#10 0x7f496231cb42 in start_thread nptl/pthread_create.c:442
espressif#11 0x7f49623ae9ff (/lib/x86_64-linux-gnu/libc.so.6+0x1269ff)
0x62d0005f7418 is located 28696 bytes inside of 32768-byte region [0x62d0005f0400,0x62d0005f8400)
freed by thread T148 here:
#0 0x7f49627b6460 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:52
#1 0x5593da5ac057 in cpu_exec_unrealizefn ../cpu.c:180
espressif#2 0x5593da81f851 (/home/cota/src/qemu/build/qemu-x86_64+0x484851)
Signed-off-by: Emilio Cota <cota@braap.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20230111151628.320011-2-cota@braap.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20230124180127.1881110-27-alex.bennee@linaro.org>
mattiantonini
pushed a commit
to mattiantonini/ESP32-QEMU
that referenced
this issue
Feb 23, 2023
Fixes this tsan crash, easy to reproduce with any large enough program:
$ tests/unit/test-qht
1..2
ThreadSanitizer: CHECK failed: sanitizer_deadlock_detector.h:67 "((n_all_locks_)) < (((sizeof(all_locks_with_contexts_)/sizeof((all_locks_with_contexts_)[0]))))" (0x40, 0x40) (tid=1821568)
#0 __tsan::CheckUnwind() ../../../../src/libsanitizer/tsan/tsan_rtl.cpp:353 (libtsan.so.2+0x90034)
#1 __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) ../../../../src/libsanitizer/sanitizer_common/sanitizer_termination.cpp:86 (libtsan.so.2+0xca555)
espressif#2 __sanitizer::DeadlockDetectorTLS<__sanitizer::TwoLevelBitVector<1ul, __sanitizer::BasicBitVector<unsigned long> > >::addLock(unsigned long, unsigned long, unsigned int) ../../../../src/libsanitizer/sanitizer_common/sanitizer_deadlock_detector.h:67 (libtsan.so.2+0xb3616)
espressif#3 __sanitizer::DeadlockDetectorTLS<__sanitizer::TwoLevelBitVector<1ul, __sanitizer::BasicBitVector<unsigned long> > >::addLock(unsigned long, unsigned long, unsigned int) ../../../../src/libsanitizer/sanitizer_common/sanitizer_deadlock_detector.h:59 (libtsan.so.2+0xb3616)
espressif#4 __sanitizer::DeadlockDetector<__sanitizer::TwoLevelBitVector<1ul, __sanitizer::BasicBitVector<unsigned long> > >::onLockAfter(__sanitizer::DeadlockDetectorTLS<__sanitizer::TwoLevelBitVector<1ul, __sanitizer::BasicBitVector<unsigned long> > >*, unsigned long, unsigned int) ../../../../src/libsanitizer/sanitizer_common/sanitizer_deadlock_detector.h:216 (libtsan.so.2+0xb3616)
espressif#5 __sanitizer::DD::MutexAfterLock(__sanitizer::DDCallback*, __sanitizer::DDMutex*, bool, bool) ../../../../src/libsanitizer/sanitizer_common/sanitizer_deadlock_detector1.cpp:169 (libtsan.so.2+0xb3616)
espressif#6 __tsan::MutexPostLock(__tsan::ThreadState*, unsigned long, unsigned long, unsigned int, int) ../../../../src/libsanitizer/tsan/tsan_rtl_mutex.cpp:200 (libtsan.so.2+0xa3382)
espressif#7 __tsan_mutex_post_lock ../../../../src/libsanitizer/tsan/tsan_interface_ann.cpp:384 (libtsan.so.2+0x76bc3)
espressif#8 qemu_spin_lock /home/cota/src/qemu/include/qemu/thread.h:259 (test-qht+0x44a97)
espressif#9 qht_map_lock_buckets ../util/qht.c:253 (test-qht+0x44a97)
espressif#10 do_qht_iter ../util/qht.c:809 (test-qht+0x45f33)
espressif#11 qht_iter ../util/qht.c:821 (test-qht+0x45f33)
espressif#12 iter_check ../tests/unit/test-qht.c:121 (test-qht+0xe473)
espressif#13 qht_do_test ../tests/unit/test-qht.c:202 (test-qht+0xe473)
espressif#14 qht_test ../tests/unit/test-qht.c:240 (test-qht+0xe7c1)
espressif#15 test_default ../tests/unit/test-qht.c:246 (test-qht+0xe828)
espressif#16 <null> <null> (libglib-2.0.so.0+0x7daed)
espressif#17 <null> <null> (libglib-2.0.so.0+0x7d80a)
espressif#18 <null> <null> (libglib-2.0.so.0+0x7d80a)
espressif#19 g_test_run_suite <null> (libglib-2.0.so.0+0x7dfe9)
espressif#20 g_test_run <null> (libglib-2.0.so.0+0x7e055)
espressif#21 main ../tests/unit/test-qht.c:259 (test-qht+0xd2c6)
espressif#22 __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 (libc.so.6+0x29d8f)
espressif#23 __libc_start_main_impl ../csu/libc-start.c:392 (libc.so.6+0x29e3f)
espressif#24 _start <null> (test-qht+0xdb44)
Signed-off-by: Emilio Cota <cota@braap.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20230111151628.320011-5-cota@braap.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20230124180127.1881110-30-alex.bennee@linaro.org>
igrr
pushed a commit
that referenced
this issue
Dec 5, 2023
If there is a pending DMA operation during ide_bus_reset(), the fact
that the IDEState is already reset before the operation is canceled
can be problematic. In particular, ide_dma_cb() might be called and
then use the reset IDEState which contains the signature after the
reset. When used to construct the IO operation this leads to
ide_get_sector() returning 0 and nsector being 1. This is particularly
bad, because a write command will thus destroy the first sector which
often contains a partition table or similar.
Traces showing the unsolicited write happening with IDEState
0x5595af6949d0 being used after reset:
> ahci_port_write ahci(0x5595af6923f0)[0]: port write [reg:PxSCTL] @ 0x2c: 0x00000300
> ahci_reset_port ahci(0x5595af6923f0)[0]: reset port
> ide_reset IDEstate 0x5595af6949d0
> ide_reset IDEstate 0x5595af694da8
> ide_bus_reset_aio aio_cancel
> dma_aio_cancel dbs=0x7f64600089a0
> dma_blk_cb dbs=0x7f64600089a0 ret=0
> dma_complete dbs=0x7f64600089a0 ret=0 cb=0x5595acd40b30
> ahci_populate_sglist ahci(0x5595af6923f0)[0]
> ahci_dma_prepare_buf ahci(0x5595af6923f0)[0]: prepare buf limit=512 prepared=512
> ide_dma_cb IDEState 0x5595af6949d0; sector_num=0 n=1 cmd=DMA WRITE
> dma_blk_io dbs=0x7f6420802010 bs=0x5595ae2c6c30 offset=0 to_dev=1
> dma_blk_cb dbs=0x7f6420802010 ret=0
> (gdb) p *qiov
> $11 = {iov = 0x7f647c76d840, niov = 1, {{nalloc = 1, local_iov = {iov_base = 0x0,
> iov_len = 512}}, {__pad = "\001\000\000\000\000\000\000\000\000\000\000",
> size = 512}}}
> (gdb) bt
> #0 blk_aio_pwritev (blk=0x5595ae2c6c30, offset=0, qiov=0x7f6420802070, flags=0,
> cb=0x5595ace6f0b0 <dma_blk_cb>, opaque=0x7f6420802010)
> at ../block/block-backend.c:1682
> #1 0x00005595ace6f185 in dma_blk_cb (opaque=0x7f6420802010, ret=<optimized out>)
> at ../softmmu/dma-helpers.c:179
> #2 0x00005595ace6f778 in dma_blk_io (ctx=0x5595ae0609f0,
> sg=sg@entry=0x5595af694d00, offset=offset@entry=0, align=align@entry=512,
> io_func=io_func@entry=0x5595ace6ee30 <dma_blk_write_io_func>,
> io_func_opaque=io_func_opaque@entry=0x5595ae2c6c30,
> cb=0x5595acd40b30 <ide_dma_cb>, opaque=0x5595af6949d0,
> dir=DMA_DIRECTION_TO_DEVICE) at ../softmmu/dma-helpers.c:244
> #3 0x00005595ace6f90a in dma_blk_write (blk=0x5595ae2c6c30,
> sg=sg@entry=0x5595af694d00, offset=offset@entry=0, align=align@entry=512,
> cb=cb@entry=0x5595acd40b30 <ide_dma_cb>, opaque=opaque@entry=0x5595af6949d0)
> at ../softmmu/dma-helpers.c:280
> #4 0x00005595acd40e18 in ide_dma_cb (opaque=0x5595af6949d0, ret=<optimized out>)
> at ../hw/ide/core.c:953
> #5 0x00005595ace6f319 in dma_complete (ret=0, dbs=0x7f64600089a0)
> at ../softmmu/dma-helpers.c:107
> #6 dma_blk_cb (opaque=0x7f64600089a0, ret=0) at ../softmmu/dma-helpers.c:127
> #7 0x00005595ad12227d in blk_aio_complete (acb=0x7f6460005b10)
> at ../block/block-backend.c:1527
> #8 blk_aio_complete (acb=0x7f6460005b10) at ../block/block-backend.c:1524
> #9 blk_aio_write_entry (opaque=0x7f6460005b10) at ../block/block-backend.c:1594
> #10 0x00005595ad258cfb in coroutine_trampoline (i0=<optimized out>,
> i1=<optimized out>) at ../util/coroutine-ucontext.c:177
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Tested-by: simon.rowe@nutanix.com
Message-ID: <20230906130922.142845-1-f.ebner@proxmox.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 7d75120)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
antmak
pushed a commit
to antmak/qemu
that referenced
this issue
Jan 25, 2024
There is no architectural requirement that SME implies SVE, but our implementation currently assumes it. (FEAT_SME_FA64 does imply SVE.) So if you try to run a CPU with eg "-cpu max,sve=off" you quickly run into an assert when the guest tries to write to SMCR_EL1: espressif#6 0x00007ffff4b38e96 in __GI___assert_fail (assertion=0x5555566e69cb "sm", file=0x5555566e5b24 "../../target/arm/helper.c", line=6865, function=0x5555566e82f0 <__PRETTY_FUNCTION__.31> "sve_vqm1_for_el_sm") at ./assert/assert.c:101 espressif#7 0x0000555555ee33aa in sve_vqm1_for_el_sm (env=0x555557d291f0, el=2, sm=false) at ../../target/arm/helper.c:6865 espressif#8 0x0000555555ee3407 in sve_vqm1_for_el (env=0x555557d291f0, el=2) at ../../target/arm/helper.c:6871 espressif#9 0x0000555555ee3724 in smcr_write (env=0x555557d291f0, ri=0x555557da23b0, value=2147483663) at ../../target/arm/helper.c:6995 espressif#10 0x0000555555fd1dba in helper_set_cp_reg64 (env=0x555557d291f0, rip=0x555557da23b0, value=2147483663) at ../../target/arm/tcg/op_helper.c:839 espressif#11 0x00007fff60056781 in code_gen_buffer () Avoid this unsupported and slightly odd combination by disabling SME when SVE is not present. Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2005 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20231127173318.674758-1-peter.maydell@linaro.org
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I am trying to start with qemu on an existing project which has already its size. Currently I commented a lot of stuff out to test step by step. I am using the ESP32 Arduino core with PlatformIO (if I have to change some settings, please let me know!).
Currently I am facing different issues:
As i was writing: on the HW it is working, any Ideas how to debug this?
I am using this code:
if(!SPIFFS.begin(true)) {And getting this error message:
So it is trying to format something, but it is not working out.
The text was updated successfully, but these errors were encountered: