diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/108/other/226 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/2261 | 102 | ||||
| -rw-r--r-- | results/classifier/108/other/2262 | 214 | ||||
| -rw-r--r-- | results/classifier/108/other/2263 | 43 | ||||
| -rw-r--r-- | results/classifier/108/other/2265 | 63 | ||||
| -rw-r--r-- | results/classifier/108/other/2266 | 84 | ||||
| -rw-r--r-- | results/classifier/108/other/2269 | 56 |
7 files changed, 578 insertions, 0 deletions
diff --git a/results/classifier/108/other/226 b/results/classifier/108/other/226 new file mode 100644 index 000000000..78a55e41e --- /dev/null +++ b/results/classifier/108/other/226 @@ -0,0 +1,16 @@ +performance: 0.842 +device: 0.792 +network: 0.733 +other: 0.732 +PID: 0.574 +vnc: 0.561 +semantic: 0.493 +debug: 0.479 +boot: 0.459 +permissions: 0.429 +KVM: 0.401 +socket: 0.386 +graphic: 0.326 +files: 0.013 + +host window size does not change when guest video screen size changes while moving host window diff --git a/results/classifier/108/other/2261 b/results/classifier/108/other/2261 new file mode 100644 index 000000000..c2823e26b --- /dev/null +++ b/results/classifier/108/other/2261 @@ -0,0 +1,102 @@ +other: 0.886 +permissions: 0.872 +performance: 0.821 +graphic: 0.805 +network: 0.795 +semantic: 0.788 +device: 0.782 +debug: 0.782 +PID: 0.752 +boot: 0.707 +vnc: 0.690 +KVM: 0.688 +socket: 0.677 +files: 0.565 + +qemu-system-x86_64 crashs in cursor_put functions +Description of problem: +This problem cannot be stably reproduced，but we try enable --enable-sanitizers and catch the following information，why qemu_spice_cursor_refresh_bh be called twice at the same time？ + +==57296==ERROR: AddressSanitizer: heap-use-after-free on address 0x623000738110 at pc 0x55cec2ed06aa bp 0x7ffc54d1fea0 sp 0x7ffc54d1fe90 +READ of size 4 at 0x623000738110 thread T0 + #0 0x55cec2ed06a9 in cursor_put ../qemu-6.0.1/ui/cursor.c:112 + #1 0x55cec2f05d40 in vnc_dpy_cursor_define ../qemu-6.0.1/ui/vnc.c:1041 + #2 0x55cec2ec6352 in dpy_cursor_define ../qemu-6.0.1/ui/console.c:1841 + #3 0x55cec3ab176c in qemu_spice_cursor_refresh_bh ../qemu-6.0.1/ui/spice-display.c:469 + #4 0x55cec4abc6eb in aio_bh_call ../qemu-6.0.1/util/async.c:136 + #5 0x55cec4abce43 in aio_bh_poll ../qemu-6.0.1/util/async.c:164 + #6 0x55cec4a5f457 in aio_dispatch ../qemu-6.0.1/util/aio-posix.c:381 + #7 0x55cec4abe386 in aio_ctx_dispatch ../qemu-6.0.1/util/async.c:306 + #8 0x7fa4fadcdd3a in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x55d3a) + #9 0x55cec4b0b5d6 in glib_pollfds_poll ../qemu-6.0.1/util/main-loop.c:231 + #10 0x55cec4b0b7c0 in os_host_main_loop_wait ../qemu-6.0.1/util/main-loop.c:254 + #11 0x55cec4b0bac5 in main_loop_wait ../qemu-6.0.1/util/main-loop.c:530 + #12 0x55cec3f49e70 in qemu_main_loop ../qemu-6.0.1/softmmu/runstate.c:786 + #13 0x55cec2e7f679 in main ../qemu-6.0.1/softmmu/main.c:50 + #14 0x7fa4f96f4d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 + #15 0x7fa4f96f4e3f in __libc_start_main_impl ../csu/libc-start.c:392 + #16 0x55cec2e7f584 in _start (/usr/bin/qemu-system-x86_64+0x298a584) + +0x623000738110 is located 16 bytes inside of 6416-byte region [0x623000738100,0x623000739a10) +freed by thread T0 here: + #0 0x7fa4fb7d9537 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:127 + #1 0x55cec2ed0769 in cursor_put ../qemu-6.0.1/ui/cursor.c:115 + #2 0x55cec3ab1818 in qemu_spice_cursor_refresh_bh ../qemu-6.0.1/ui/spice-display.c:471 + #3 0x55cec4abc6eb in aio_bh_call ../qemu-6.0.1/util/async.c:136 + #4 0x55cec4abce43 in aio_bh_poll ../qemu-6.0.1/util/async.c:164 + #5 0x55cec4a5f457 in aio_dispatch ../qemu-6.0.1/util/aio-posix.c:381 + #6 0x55cec4abe386 in aio_ctx_dispatch ../qemu-6.0.1/util/async.c:306 + #7 0x7fa4fadcdd3a in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x55d3a) + +previously allocated by thread T14 here: + #0 0x7fa4fb7d9a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 + #1 0x7fa4fadd6c50 in g_malloc0 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5ec50) + #2 0x55cec3b16918 in qxl_cursor ../qemu-6.0.1/hw/display/qxl-render.c:361 + #3 0x55cec3b18698 in qxl_render_cursor ../qemu-6.0.1/hw/display/qxl-render.c:448 + #4 0x55cec3af53a5 in interface_get_cursor_command ../qemu-6.0.1/hw/display/qxl.c:856 + #5 0x7fa4fb39ca1f in red_process_cursor ../../server/red-worker.c:152 + #6 0x7fa4fb39ca1f in red_process_cursor ../../server/red-worker.c:140 + +Thread T14 created by T0 here: + #0 0x7fa4fb77d685 in __interceptor_pthread_create ../../../../src/libsanitizer/asan/asan_interceptors.cpp:216 + #1 0x7fa4fb39ece5 in red_worker_run ../../server/red-worker.c:1588 + #2 0x62100002d94f (<unknown module>) + +SUMMARY: AddressSanitizer: heap-use-after-free ../qemu-6.0.1/ui/cursor.c:112 in cursor_put +Shadow bytes around the buggy address: + 0x0c46800defd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c46800defe0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c46800deff0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c46800df000: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c46800df010: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa +=>0x0c46800df020: fd fd[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c46800df030: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c46800df040: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c46800df050: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c46800df060: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c46800df070: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd +Shadow byte legend (one shadow byte represents 8 application bytes): + Addressable: 00 + Partially addressable: 01 02 03 04 05 06 07 + Heap left redzone: fa + Freed heap region: fd + Stack left redzone: f1 + Stack mid redzone: f2 + Stack right redzone: f3 + Stack after return: f5 + Stack use after scope: f8 + Global redzone: f9 + Global init order: f6 + Poisoned by user: f7 + Container overflow: fc + Array cookie: ac + Intra object redzone: bb + ASan internal: fe + Left alloca redzone: ca + Right alloca redzone: cb + Shadow gap: cc +==57296==ABORTING +Steps to reproduce: +This problem cannot be stably reproduced +Additional information: +/label ~"kind::Bug" diff --git a/results/classifier/108/other/2262 b/results/classifier/108/other/2262 new file mode 100644 index 000000000..0cb4dc71d --- /dev/null +++ b/results/classifier/108/other/2262 @@ -0,0 +1,214 @@ +other: 0.871 +graphic: 0.861 +performance: 0.843 +debug: 0.814 +semantic: 0.788 +vnc: 0.775 +boot: 0.764 +files: 0.757 +device: 0.754 +permissions: 0.753 +KVM: 0.738 +PID: 0.727 +socket: 0.628 +network: 0.622 + +linux-user riscv32: wait4/waitpid returns wrong value +Description of problem: +Background job started by bash shell in riscv32 chroot environment under qemu linux-user emulation hangs indefinitely. + +strace shows repeated waitid flood `waitid(P_ALL, -1, {}, WNOHANG|WEXITED|WSTOPPED|WCONTINUED, NULL) = 0`. +Steps to reproduce: +1. cross compile a riscv32 environment with crossdev on gentoo or other way and chroot into it. +2. run `sleep 1000 &` +3. run `ls` +4. infinite hangs + +I have a small reproducer that I think may uncover the issue, but I am not 100% sure. I also tried running qemu with sanitizers enabled, but it produces no warning. Happy to provide a tar bar of my riscv32 rootfs if needed. + +<details><summary>simple_shell.c</summary> + +``` +#include <stdio.h> +#include <stdlib.h> +#include <unistd.h> +#include <string.h> +#include <sys/wait.h> +#include <signal.h> + +#define MAX_LINE 80 /* The maximum length command */ + +#define BACKGROUND 0 +#define FOREGROUND 1 + +struct Job { + pid_t pid; + char command[MAX_LINE]; + int state; // 0 for background, 1 for foreground +}; + +struct Job jobs[10]; // Maximum 10 background jobs +int num_jobs = 0; + +void handle_signal(int signum) { + // Do nothing for now +} + +int launch_process(char **args, int state) { + pid_t pid; + int status; + + pid = fork(); + if (pid == 0) { + // Child process + if (execvp(args[0], args) == -1) { + perror("Error in execvp"); + exit(EXIT_FAILURE); + } + } else if (pid < 0) { + // Error forking + perror("Error forking"); + } else { + // Parent process + if (state == FOREGROUND) { + // Wait for the child process to finish if it's foreground + do { + wait4(pid, &status, WUNTRACED, NULL); + } while (!WIFEXITED(status) && !WIFSIGNALED(status)); + } else { + // Background process, add to jobs list + jobs[num_jobs].pid = pid; + strcpy(jobs[num_jobs].command, args[0]); + jobs[num_jobs].state = BACKGROUND; + num_jobs++; + } + } + return 1; +} + +void bg_command(int job_number) { + // Send SIGCONT signal to a background job + if (kill(jobs[job_number].pid, SIGCONT) == -1) { + perror("kill"); + } else { + jobs[job_number].state = BACKGROUND; + } +} + +void fg_command(int job_number) { + // Bring a background job to foreground + if (kill(jobs[job_number].pid, SIGCONT) == -1) { + perror("kill"); + } else { + jobs[job_number].state = FOREGROUND; + int status; + wait4(jobs[job_number].pid, &status, WUNTRACED, NULL); + } +} + +int main(void) { + char *args[MAX_LINE/2 + 1]; /* command line arguments */ + int should_run = 1; /* flag to determine when to exit program */ + char command[MAX_LINE]; /* buffer to hold the command */ + char *token; /* token for parsing the command */ + + signal(SIGINT, handle_signal); /* Ignore SIGINT for now */ + signal(SIGTSTP, handle_signal); /* Ignore SIGTSTP for now */ + + while (should_run) { + printf("Shell> "); + fflush(stdout); + fgets(command, MAX_LINE, stdin); /* read command from stdin */ + command[strcspn(command, "\n")] = '\0'; /* remove newline character */ + + if (strcmp(command, "exit") == 0) { + should_run = 0; /* exit the shell */ + continue; + } + + if (strcmp(command, "") == 0) { + continue; /* skip empty commands */ + } + + if (strcmp(command, "cd") == 0) { + char *home = getenv("HOME"); + chdir(home); + continue; + } + + if (strcmp(command, "bg") == 0) { + // Run the most recent background job in the background + bg_command(num_jobs - 1); + continue; + } + + if (strcmp(command, "fg") == 0) { + // Bring the most recent background job to foreground + fg_command(num_jobs - 1); + continue; + } + + token = strtok(command, " "); + int i = 0; + while (token != NULL) { + args[i] = token; + token = strtok(NULL, " "); + i++; + } + args[i] = NULL; + + if (strcmp(args[i-1], "&") == 0) { + args[i-1] = NULL; + launch_process(args, BACKGROUND); + } else { + launch_process(args, FOREGROUND); + } + + pid_t tmp; + // Check if any background jobs have finished + for (int j = 0; j < num_jobs; j++) { + if ((tmp = wait4(jobs[j].pid, NULL, WNOHANG, NULL)) > 0) { + printf("[%d] Done\t%s\n", j, jobs[j].command); + // Remove job from list + for (int k = j; k < num_jobs - 1; k++) { + jobs[k] = jobs[k + 1]; + } + num_jobs--; + } + printf("wait4 ret: %d\n", tmp); + } + } + return 0; +} +``` + +</details> + +<details><summary>loop.c</summary> +int main() {while(1){}} +</details> + +1. compile simple_shell.c, statically for simplicity. `riscv32-unknown-gnu-gcc simple_shell.c --static -o shell_riscv32` +2. compile loop.c to riscv32 or x86_64 (x86_64 is simpler with same result) `gcc loop.c --static -o loop` +3. run shell with qemu user +``` +qemu-user-riscv32 ./shell_riscv32 +shell> ./loop & +[0] Done ./sleep_riscv32 +wait4 ret: 98298 +``` +where it is supposed to return 0 on riscv64 or x86 +Additional information: +More context: +This was found on the side when I was trying to track down a riscv32 infinite loop issue with linux-user emulation that has been blocking riscv32 gentoo bootstrap. I am not certain if my reproducer does reproduced that issue, but feels it is close. strace attached to the process repeats, +``` +waitid(P_ALL, -1, {}, WNOHANG|WEXITED, NULL) = 0 +rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], NULL, 8) = 0 +rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], NULL, 8) = 0 +rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0 +rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], NULL, 8) = 0 +rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], NULL, 8) = 0 +rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0 +waitid(P_ALL, -1, ^Cstrace: Process 237805 detached +``` +It appears to be first mentioned here <https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg05475.html>. diff --git a/results/classifier/108/other/2263 b/results/classifier/108/other/2263 new file mode 100644 index 000000000..7ffc6a170 --- /dev/null +++ b/results/classifier/108/other/2263 @@ -0,0 +1,43 @@ +graphic: 0.883 +performance: 0.797 +debug: 0.796 +device: 0.773 +KVM: 0.764 +semantic: 0.715 +files: 0.677 +boot: 0.647 +socket: 0.637 +other: 0.504 +vnc: 0.494 +PID: 0.480 +network: 0.457 +permissions: 0.449 + +guest panics when attempting to perform loadvm operation on x86_64 platform with kvm_intel ept=0 +Description of problem: +The guest experiences a panic when attempting to perform the `loadvm` operation after it has been running for a while on the x86_64 platform with `kvm_intel ept=0`. I'm unsure if this operation is permitted or not, but it functions properly when using `kvm_intel ept=1`. +Steps to reproduce: +1. Load the `kvm-intel` module with the parameter `ept=0`. +2. savevm +Boot the first guest using the previous command line and switch to the QEMU console to execute the `savevm` operation. After that, proceed to shutting down the guest. +3. loadvm +Boot the second guest using the same command line and switch to the QEMU console to execute the `loadevm` operation. After that, the guest panics. +Additional information: +I have performed some debugging and it seems that the issue lies in the fact that the VMM modifies the guest memory without informing the KVM module. Upon further investigation, I noticed that the `loadvm` operation only restores the memory and does not execute any ioctl to modify the user memory region recorded in the KVM module. + +The KVM module calls `kvm_mmu_reset_context()` to unload the current EPT or SPT page table when guest system registers (CR0/CR3/CR4) are restored. However, for EPT, the EPT page table is released directly and can be reconstructed at a later stage. In contrast, for SPT, the KVM only decreases the reference count and retains the outdated SPT page table in the active list that is maintained by the KVM. As a result, this outdated SPT page table is reused later, leading to incorrect mapping. + +To address this, I attempted to call `kvm_arch_flush_shadow_all()` to zap all the page tables in `kvm_mmu_reset_context()`, which allowed the guest to function properly with SPT after the `loadvm` operation. + +Therefore, I believe that QEMU should notify the KVM to clear all the page tables if the KVM is using shadow paging. However, it appears that there is no appropriate ioctl available for the VMM to achieve this. + +guest panic output: + + +Trace the `kvm_mmu_get_page()` event and observe that only one record indicates that the outdated page table is reused instead of being recreated. + + +```shell +perf record -a -e kvmmmu:kvm_mmu_get_page +``` + diff --git a/results/classifier/108/other/2265 b/results/classifier/108/other/2265 new file mode 100644 index 000000000..f2f789442 --- /dev/null +++ b/results/classifier/108/other/2265 @@ -0,0 +1,63 @@ +permissions: 0.853 +KVM: 0.840 +vnc: 0.831 +other: 0.802 +graphic: 0.798 +performance: 0.755 +debug: 0.750 +files: 0.739 +semantic: 0.729 +device: 0.720 +socket: 0.718 +network: 0.702 +boot: 0.695 +PID: 0.636 + +qemu-system-x86_64 crash creating snapshot +Description of problem: +I'm facing a crash in qemu-system-x86_64.\ +I crash because bs->children.lh_first is null and QLIST_NEXT try dereference the pointer. It triggers a SIGSEGV\ +The manner to reproduce is too complex to give on gitlab and the version is not recent. (I reproduce also with 7.1)\ + +here is the stack: + +(gdb) p bs->children\ +$1 = {lh_first = 0x0}\ +(gdb)\ +(gdb) p child\ +$2 = (BdrvChild *) 0x0\ +(gdb)\ + if (bs->implicit) {\ + /* For implicit nodes, just copy everything from the single child */\ + child = QLIST_FIRST(&bs->children);\ +----->> assert(QLIST_NEXT(child, next) == NULL);\ + pstrcpy(bs->exact_filename, sizeof(bs->exact_filename),\ + + +#0 bdrv_refresh_filename (bs=0x562927927000) at ../qemu-6.2.0/block.c:7525\ +#1 0x000056292527dd97 in bdrv_block_device_info (blk=blk@entry=0x0, bs=bs@entry=0x562927927000, flat=flat@entry=true, errp=errp@entry=0x7ffcef7e8318) at ../qemu-6.2.0/block/qapi.c:58\ +#2 0x00005629252470c0 in bdrv_named_nodes_list (flat=true, errp=errp@entry=0x7ffcef7e8318) at ../qemu-6.2.0/block.c:5863\ +#3 0x000056292523da7e in qmp_query_named_block_nodes (has_flat=<optimized out>, flat=<optimized out>, errp=errp@entry=0x7ffcef7e8318) at ../qemu-6.2.0/blockdev.c:2935\ +#4 0x0000562925301ebd in qmp_marshal_query_named_block_nodes (args=<optimized out>, ret=0x7fc833c83e88, errp=0x7fc833c83e80) at qapi/qapi-commands-block-core.c:423\ +#5 0x0000562925344129 in do_qmp_dispatch_bh (opaque=0x7fc833c83e90) at ../qemu-6.2.0/qapi/qmp-dispatch.c:129 +#6 0x000056292535ecf5 in aio_bh_call (bh=0x5629295ab560) at ../qemu-6.2.0/util/async.c:141\ +#7 aio_bh_poll (ctx=ctx@entry=0x5629276c93e0) at ../qemu-6.2.0/util/async.c:169\ +#8 0x000056292534cf9e in aio_dispatch (ctx=0x5629276c93e0) at ../qemu-6.2.0/util/aio-posix.c:381\ +#9 0x000056292535eb9e in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at ../qemu-6.2.0/util/async.c:311\ +#10 0x00007fc8351cafee in g_match_info_fetch_pos () from /lib/x86_64-linux-gnu/libglib-2.0.so.0\ +#11 0x00007fc800000000 in ?? ()\ +#12 0x000003a05cb8b408 in ?? ()\ +#13 0x0000000000000000 in ?? ()\ + +The case lh_first = 0x0 seems to be common, but never when bs->implicit is true. bs->implicit seems to be switch to true by another thread.\ +Because the qemu version and the system are too old, I'm not expecting a patch, I'm just requesting an opinion.\ + +I fixed the problem by just doing:\ +child = QLIST_FIRST(&bs->children);\ +if (bs->implicit && (child != NULL)) {\ + assert(QLIST_NEXT(child, next) == NULL);\ + ....\ +}\ +I don't have the qemu knowledge to evaluate it and consequences.\ +Is there anyone who have any idea ?\ +Thank you very much.\ diff --git a/results/classifier/108/other/2266 b/results/classifier/108/other/2266 new file mode 100644 index 000000000..27a09a3bd --- /dev/null +++ b/results/classifier/108/other/2266 @@ -0,0 +1,84 @@ +debug: 0.887 +files: 0.829 +PID: 0.792 +permissions: 0.779 +device: 0.758 +graphic: 0.694 +semantic: 0.655 +performance: 0.632 +network: 0.612 +socket: 0.605 +KVM: 0.556 +vnc: 0.519 +boot: 0.470 +other: 0.310 + +qemu-system-x86_64: stuck on watchpoint hit +Description of problem: + +Steps to reproduce: +1. `gcc -O0 -g watch-bug.c -o watch-bug` +2. `gdb watch-bug` +3. gdb commands: +``` +b main +r +watch l1 +next [ correct stop on the next line ] +next [ qemu is stuck as watchpoint should be hit ] +``` +Additional information: +* NOTE: it works correctly, if 'continue' command is used instead of 'next' + + +`watch-bug.c` +```c +int i0; +long l1; + + +int main(int argc, char* argv[]) +{ + i0 = argc; + l1 = i0 * 7; + + return 0; +} + +``` + +Log: +```c +Log: +root@qemux86-64:~# gdb watch-bug +GNU gdb (GDB) 13.2 +Copyright (C) 2023 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. +Type "show copying" and "show warranty" for details. +This GDB was configured as "x86_64-poky-linux". +Type "show configuration" for configuration details. +For bug reporting instructions, please see: +<https://www.gnu.org/software/gdb/bugs/>. +Find the GDB manual and other documentation resources online at: + <http://www.gnu.org/software/gdb/documentation/>. + +For help, type "help". +Type "apropos word" to search for commands related to "word"... +Reading symbols from watch-bug... +(gdb) b main +Breakpoint 1 at 0x1134: file watch-bug.c, line 8. +(gdb) r +Starting program: /home/root/watch-bug +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib/libthread_db.so.1". + +Breakpoint 1, main (argc=1, argv=0x7fffffffecd8) at watch-bug.c:8 +8 i0 = argc; +(gdb) watch l1 +Hardware watchpoint 2: l1 +(gdb) next +9 l1 = i0 * 7; +(gdb) next +``` diff --git a/results/classifier/108/other/2269 b/results/classifier/108/other/2269 new file mode 100644 index 000000000..be1b721d9 --- /dev/null +++ b/results/classifier/108/other/2269 @@ -0,0 +1,56 @@ +other: 0.894 +graphic: 0.886 +performance: 0.801 +device: 0.786 +semantic: 0.671 +PID: 0.608 +debug: 0.599 +permissions: 0.575 +socket: 0.431 +network: 0.420 +files: 0.404 +vnc: 0.380 +KVM: 0.278 +boot: 0.252 + +RISC-V exit via sifive_test does not work in scripts with -serial stdio +Description of problem: + +Steps to reproduce: +1. Create assembly file `hello.s`: +```as +.section .text +.globl _start +_start: csrr t0, mhartid + bnez t0, _start + li t0, 0x100000 + li t1, 0x5555 + sw t1, 0(t0) +halt: j halt +``` +2. Create linker script `link.ld`: +```ld +OUTPUT_ARCH( "riscv" ) +ENTRY(_start) +SECTIONS +{ + . = 0x80000000; +} +``` +3. Create runner script `./run.sh` (don't forget to `chmod +x`) +```sh +#!/usr/bin/env bash +timeout 10 qemu-system-riscv64 -M virt -display none -serial stdio -bios none -kernel hello +``` +4. Compile into executable: +```sh +riscv64-unknown-elf-gcc -c -mcmodel=medany -fvisibility=hidden -nostartfiles -march=rv64g -mabi=lp64 -o hello.o hello.s +riscv64-unknown-elf-ld hello.o -nostdlib -T link.ld -o hello +``` +5. Dot-source the script - it will immediately exit cleanly +6. Execute the script - it will timeout with exit code 124 +7. Execute the script with redirected stdin, e.g. `./run.sh < ./run.sh` or `echo | ./run.sh` - it will immediately exit cleanly +Additional information: +This issue happens only with `-serial stdio`. Using `chardev:file` or `chardev:null` does not reproduce the issue. Process substitution like `<(echo 'test')` does not seem to work. `cat | ./run.sh` will wait until any line is send, then exit cleanly. This is mainly an issue when using helper test scripts which want to interact with user, as proper CI/UT would redirect serial anyways. + +I have noticed similar behavior with other RISC-V UART device - when running from scripts, there is no output, as if QEMU was waiting for something, even if there is only UART TX, not RX. It does not matter if I actually type in anything or not. |