diff options
Diffstat (limited to '')
84 files changed, 13636 insertions, 0 deletions
diff --git a/results/classifier/108/other/188 b/results/classifier/108/other/188 new file mode 100644 index 00000000..4035fb92 --- /dev/null +++ b/results/classifier/108/other/188 @@ -0,0 +1,16 @@ +performance: 0.770 +device: 0.739 +network: 0.521 +semantic: 0.488 +graphic: 0.430 +other: 0.409 +debug: 0.336 +permissions: 0.310 +PID: 0.251 +vnc: 0.242 +boot: 0.193 +files: 0.172 +KVM: 0.103 +socket: 0.023 + +savevm with hax saves wrong register state diff --git a/results/classifier/108/other/1880066 b/results/classifier/108/other/1880066 new file mode 100644 index 00000000..d09591c6 --- /dev/null +++ b/results/classifier/108/other/1880066 @@ -0,0 +1,182 @@ +other: 0.985 +permissions: 0.980 +semantic: 0.974 +graphic: 0.973 +device: 0.972 +debug: 0.972 +performance: 0.966 +socket: 0.956 +PID: 0.955 +files: 0.950 +boot: 0.940 +vnc: 0.934 +KVM: 0.931 +network: 0.886 + +Microphone input dies in guest when switching evdev input + +justin@justin-3900x:~$ lsb_release -a +No LSB modules are available. +Distributor ID: Ubuntu +Description: Ubuntu 20.04 LTS +Release: 20.04 +Codename: focal + + + +justin@justin-3900x:~$ apt list --installed | egrep '*qemu*|*kvm*' + +WARNING: apt does not have a stable CLI interface. Use with caution in scripts. + +ipxe-qemu-256k-compat-efi-roms/focal,focal,now 1.0.0+git-20150424.a25a16d-0ubuntu4 all [installed,automatic] +ipxe-qemu/focal,focal,now 1.0.0+git-20190109.133f4c4-0ubuntu3 all [installed,automatic] +libvirt-daemon-driver-qemu/focal,now 6.0.0-0ubuntu8 amd64 [installed,automatic] +qemu-block-extra/focal-updates,focal-security,now 1:4.2-3ubuntu6.1 amd64 [installed,automatic] +qemu-kvm/focal-updates,focal-security,now 1:4.2-3ubuntu6.1 amd64 [installed] +qemu-system-common/focal-updates,focal-security,now 1:4.2-3ubuntu6.1 amd64 [installed,automatic] +qemu-system-data/focal-updates,focal-updates,focal-security,focal-security,now 1:4.2-3ubuntu6.1 all [installed,automatic] +qemu-system-gui/focal-updates,focal-security,now 1:4.2-3ubuntu6.1 amd64 [installed,automatic] +qemu-system-x86/focal-updates,focal-security,now 1:4.2-3ubuntu6.1 amd64 [installed] +qemu-utils/focal-updates,focal-security,now 1:4.2-3ubuntu6.1 amd64 [installed,automatic] +qemu/focal-updates,focal-security,now 1:4.2-3ubuntu6.1 amd64 [installed] +justin@justin-3900x:~$ + +This did not happen in Eoan (qemu 4.0.0). I was able to switch in/out of a VM with my audio coming through fine. I enabled Eoan in my sources.list, downgraded all my qemu packages, and the issue was resolved. + +This happens on the latest Windows 10 guest when a sound device is listening for the microphone. + +/var/log/libvirt/qemu/<vmname>.log spews this error out when I switch with evdev (which is just the keyboard and mouse, the audio is passed through I assume spice): + + +audio: live=228193 hw->conv_buf->size=1920 +A bug was just triggered in audio_get_avail +Context: +audio: live=228675 sw->hw->conv_buf->size=1920 +A bug was just triggered in audio_pcm_hw_get_live_in +Context: +audio: live=228675 hw->conv_buf->size=1920 +A bug was just triggered in audio_get_avail +Context: +audio: live=229156 sw->hw->conv_buf->size=1920 +A bug was just triggered in audio_pcm_hw_get_live_in +Context: +audio: live=229156 hw->conv_buf->size=1920 +A bug was just triggered in audio_get_avail +Context: +audio: live=229638 sw->hw->conv_buf->size=1920 +A bug was just triggered in audio_pcm_hw_get_live_in +Context: +audio: live=229638 hw->conv_buf->size=1920 +A bug was just triggered in audio_get_avail +Context: +audio: live=230119 sw->hw->conv_buf->size=1920 +A bug was just triggered in audio_pcm_hw_get_live_in +Context: +audio: live=230119 hw->conv_buf->size=1920 +A bug was just triggered in audio_get_avail +Context: +audio: live=230600 sw->hw->conv_buf->size=1920 +A bug was just triggered in audio_pcm_hw_get_live_in +Context: +audio: live=230600 hw->conv_buf->size=1920 +A bug was just triggered in audio_get_avail +Context: +audio: live=231081 sw->hw->conv_buf->size=1920 + +I have this exact issue with any VM using Spice audio redirection. +My setup has Linux (Fedora 32) as host and guest. +The Guest microphone freezes mid way through most video conferences, which is quite a pain. +I see the exact same error messages: + +A bug was just triggered in audio_get_avail +Context: +audio: live=172895567 sw->hw->conv_buf->size=1920 +A bug was just triggered in audio_pcm_hw_get_live_in +Context: +audio: live=172895567 hw->conv_buf->size=1920 + +Closing the spice client (Boxes or Virtmanager) and reconnecting sometimes restores microphone. +I have tried AC97 and HD Audio as virtual hardware and have the same results, AC97 may be proving to be a little less failure prone, but I have not had enough events to be sure. + + +I upgraded to Ubuntu 20.10 (Groovy Gorilla) and the issue was resolved. + +Here's a list of relevant package versions: + +root@justin-3900x:/home/justin# apt list --installed | grep virt (etc...) + +WARNING: apt does not have a stable CLI interface. Use with caution in scripts. + +gir1.2-libvirt-glib-1.0/groovy,now 3.0.0-1 amd64 [installed,automatic] +libgovirt-common/groovy,groovy,now 0.3.7-1 all [installed,automatic] +libgovirt2/groovy,now 0.3.7-1 amd64 [installed,automatic] +libqt5virtualkeyboard5/groovy,now 5.14.2+dfsg-2 amd64 [installed,automatic] +libsys-virt-perl/groovy,now 6.3.0-1 amd64 [installed,automatic] +libvirt-clients/groovy-updates,now 6.6.0-1ubuntu3.1 amd64 [installed,automatic] +libvirt-daemon-driver-qemu/groovy-updates,now 6.6.0-1ubuntu3.1 amd64 [installed,automatic] +libvirt-daemon-driver-storage-zfs/groovy-updates,now 6.6.0-1ubuntu3.1 amd64 [installed] +libvirt-daemon-system-systemd/groovy-updates,now 6.6.0-1ubuntu3.1 amd64 [installed,automatic] +libvirt-daemon-system/groovy-updates,now 6.6.0-1ubuntu3.1 amd64 [installed,automatic] +libvirt-daemon/groovy-updates,now 6.6.0-1ubuntu3.1 amd64 [installed,automatic] +libvirt-glib-1.0-0/groovy,now 3.0.0-1 amd64 [installed,automatic] +libvirt0/groovy-updates,now 6.6.0-1ubuntu3.1 amd64 [installed,automatic] +python3-libvirt/groovy,now 6.1.0-1 amd64 [installed,automatic] +qml-module-qtquick-virtualkeyboard/groovy,now 5.14.2+dfsg-2 amd64 [installed,automatic] +qtvirtualkeyboard-plugin/groovy,now 5.14.2+dfsg-2 amd64 [installed,automatic] +ruby-fog-libvirt/groovy,groovy,now 0.6.0-1 all [installed,automatic] +ruby-libvirt/groovy,now 0.7.1-1build1 amd64 [installed,automatic] +vagrant-libvirt/groovy,groovy,now 0.1.2-1 all [installed,automatic] +virt-manager/groovy,groovy,now 1:2.2.1-4ubuntu2 all [installed] +virt-p2v/groovy,now 1.42.0-2 amd64 [installed,automatic] +virt-viewer/groovy,now 7.0-2build1 amd64 [installed,automatic] +virtinst/groovy,groovy,now 1:2.2.1-4ubuntu2 all [installed,automatic] +qemu-kvm/groovy,now 1:5.0-5ubuntu9 amd64 [installed] +ipxe-qemu-256k-compat-efi-roms/groovy,groovy,now 1.0.0+git-20150424.a25a16d-0ubuntu4 all [installed,automatic] +ipxe-qemu/groovy,groovy,now 1.0.0+git-20190125.36a4c85-5ubuntu3 all [installed,automatic] +libvirt-daemon-driver-qemu/groovy-updates,now 6.6.0-1ubuntu3.1 amd64 [installed,automatic] +qemu-block-extra/groovy,now 1:5.0-5ubuntu9 amd64 [installed,automatic] +qemu-efi-aarch64/groovy,groovy,now 2020.05-5 all [installed,automatic] +qemu-efi-arm/groovy,groovy,now 2020.05-5 all [installed,automatic] +qemu-kvm/groovy,now 1:5.0-5ubuntu9 amd64 [installed] +qemu-system-arm/groovy,now 1:5.0-5ubuntu9 amd64 [installed] +qemu-system-common/groovy,now 1:5.0-5ubuntu9 amd64 [installed,automatic] +qemu-system-data/groovy,groovy,now 1:5.0-5ubuntu9 all [installed,automatic] +qemu-system-gui/groovy,now 1:5.0-5ubuntu9 amd64 [installed,automatic] +qemu-system-x86/groovy,now 1:5.0-5ubuntu9 amd64 [installed] +qemu-user-static/groovy,now 1:5.0-5ubuntu9 amd64 [installed] +qemu-utils/groovy,now 1:5.0-5ubuntu9 amd64 [installed,automatic] +qemu/groovy,now 1:5.0-5ubuntu9 amd64 [installed] + + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting older bugs to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system. + +Thank you and sorry for the inconvenience. + + +Was fixed when moving to QEMU 5.x in Ubuntu 20.10. + +Was fixed when moving to QEMU 5.x in Ubuntu 20.10. + diff --git a/results/classifier/108/other/1880189 b/results/classifier/108/other/1880189 new file mode 100644 index 00000000..5be1335a --- /dev/null +++ b/results/classifier/108/other/1880189 @@ -0,0 +1,127 @@ +other: 0.939 +permissions: 0.922 +files: 0.922 +debug: 0.922 +vnc: 0.921 +device: 0.920 +KVM: 0.917 +performance: 0.913 +semantic: 0.912 +boot: 0.911 +graphic: 0.909 +network: 0.904 +socket: 0.895 +PID: 0.889 + +I/O writes make cirrus_invalidate_region() crash + +As of commit d19f1ab0, LLVM libFuzzer found: + +qemu-fuzz-i386: hw/display/cirrus_vga.c:646: void cirrus_invalidate_region(CirrusVGAState *, int, int, int, int): Assertion `off_cur_end >= off_cur' failed. +==1336555== ERROR: libFuzzer: deadly signal + #0 0xaaaaaf943ce4 in __sanitizer_print_stack_trace + #1 0xaaaaaf899474 in fuzzer::PrintStackTrace() + #2 0xaaaaaf884c80 in fuzzer::Fuzzer::CrashCallback() + #3 0xffff9b4e8568 (linux-vdso.so.1+0x568) + #4 0xffff99ac406c in __libc_signal_restore_set /build/glibc-w4ZToO/glibc-2.31/signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3 + #5 0xffff99ac406c in raise /build/glibc-w4ZToO/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:48:3 + #6 0xffff99ab0d64 in abort /build/glibc-w4ZToO/glibc-2.31/stdlib/abort.c:79:7 + #7 0xffff99abd5d8 in __assert_fail_base /build/glibc-w4ZToO/glibc-2.31/assert/assert.c:92:3 + #8 0xffff99abd640 in __assert_fail /build/glibc-w4ZToO/glibc-2.31/assert/assert.c:101:3 + #9 0xaaaab040768c in cirrus_invalidate_region + #10 0xaaaab0405404 in cirrus_bitblt_solidfill + #11 0xaaaab0402a88 in cirrus_bitblt_start + #12 0xaaaab04046a8 in cirrus_write_bitblt + #13 0xaaaab0400db4 in cirrus_vga_write_gr + #14 0xaaaab03fd33c in cirrus_vga_ioport_write + #15 0xaaaaafb41674 in memory_region_write_accessor + #16 0xaaaaafb411ec in access_with_adjusted_size + #17 0xaaaaafb40180 in memory_region_dispatch_write + #18 0xaaaaaf995dfc in flatview_write_continue + #19 0xaaaaaf985bd8 in flatview_write + #20 0xaaaaaf98574c in address_space_write + #21 0xaaaab110510c in ioport_fuzz_qtest + #22 0xaaaab1103a48 in i440fx_fuzz_qtest + #23 0xaaaab11010d8 in LLVMFuzzerTestOneInput + +Reproducer: + +qemu-system-i386 -M isapc,accel=qtest -vga cirrus -qtest stdio << 'EOF' +outl 0x03b1 0x2fdc1001 +outb 0x03cc 0xe +outb 0x03cc 0xe +outb 0x03cc 0x2f +outb 0x03cc 0xe +outb 0x03cc 0x2f +outb 0x03cc 0xe +outl 0x03cc 0xedc100e +outb 0x03cc 0x2f +outl 0x03cc 0xe24f40e +outl 0x03cc 0x2f23dc12 +outl 0x03cc 0xe23f40e +outl 0x03cc 0xe31dc12 +outb 0x03cc 0x2f +outl 0x03cc 0xe2af40e +outl 0x03cc 0x2f235612 +outl 0x03cc 0xe23f40e +outl 0x03cc 0xe31dc12 +outb 0x03cc 0x2f +outl 0x03cc 0x2fdcf40e +outb 0x03cc 0xe +outl 0x03cc 0xedc100e +outb 0x03cc 0x2f +outl 0x03cc 0xe24f40e +outl 0x03cc 0xe23dc12 +outb 0x03cc 0x2f +outl 0x03cc 0xedc100e +outl 0x03cc 0x2fdc400e +outb 0x03cc 0xe +outl 0x03cc 0xe130100e +outb 0x03cc 0x2f +outl 0x03cc 0xe23f40e +outl 0x03cc 0xe31dc12 +outb 0x03cc 0x2f +outl 0x03cc 0xe33f40e +outl 0x03cc 0xdc235612 +outb 0x03cc 0xe +outl 0x03cc 0x2fdc400e +outb 0x03cc 0xe +outl 0x03cc 0xfb24100e +outb 0x03cc 0x2f +outl 0x03cc 0xdc10dc0e +outl 0x03cc 0x2f31dc12 +outl 0x03cc 0xe23f40e +outl 0x03cc 0xe31dc12 +outb 0x03cc 0x2f +outl 0x03cc 0xe23f40e +outl 0x03cc 0xe31dc12 +outb 0x03cc 0x2f +outl 0x03cc 0x1021f40e +EOF +qemu-system-i386: hw/display/cirrus_vga.c:645: cirrus_invalidate_region: Assertion `off_cur_end >= off_cur' failed. +Aborted (core dumped) + +(gdb) bt +#0 0x00007f1d019fee35 in raise () at /lib64/libc.so.6 +#1 0x00007f1d019e9895 in abort () at /lib64/libc.so.6 +#2 0x00007f1d019e9769 in _nl_load_domain.cold () at /lib64/libc.so.6 +#3 0x00007f1d019f7566 in annobin_assert.c_end () at /lib64/libc.so.6 +#4 0x00005645cb447a37 in cirrus_invalidate_region (s=0x5645cd237540, off_begin=2097204, off_pitch=251, bytesperline=1, lines=7169) at hw/display/cirrus_vga.c:645 +#5 0x00005645cb447cc8 in cirrus_bitblt_solidfill (s=0x5645cd237540, blt_rop=0) at hw/display/cirrus_vga.c:704 +#6 0x00005645cb448886 in cirrus_bitblt_start (s=0x5645cd237540) at hw/display/cirrus_vga.c:1005 +#7 0x00005645cb448dd1 in cirrus_write_bitblt (s=0x5645cd237540, reg_value=47) at hw/display/cirrus_vga.c:1090 +#8 0x00005645cb449b02 in cirrus_vga_write_gr (s=0x5645cd237540, reg_index=49, reg_value=47) at hw/display/cirrus_vga.c:1593 +#9 0x00005645cb44bb2f in cirrus_vga_ioport_write (opaque=0x5645cd237540, addr=975, val=47, size=1) at hw/display/cirrus_vga.c:2686 +#10 0x00005645cb1e0d6e in memory_region_write_accessor (mr=0x5645cd247f10, addr=31, value=0x7fff178d6c18, size=1, shift=24, mask=255, attrs=...) at memory.c:483 +#11 0x00005645cb1e0f7f in access_with_adjusted_size (addr=28, value=0x7fff178d6c18, size=4, access_size_min=1, access_size_max=1, access_fn= + 0x5645cb1e0c8b <memory_region_write_accessor>, mr=0x5645cd247f10, attrs=...) at memory.c:544 +#12 0x00005645cb1e3e9d in memory_region_dispatch_write (mr=0x5645cd247f10, addr=28, data=791796754, op=MO_32, attrs=...) at memory.c:1476 +#13 0x00005645cb1845e5 in flatview_write_continue (fv=0x5645cd65e510, addr=972, attrs=..., ptr=0x7fff178d6da4, len=4, addr1=28, l=4, mr=0x5645cd247f10) at exec.c:3137 +#14 0x00005645cb18472a in flatview_write (fv=0x5645cd65e510, addr=972, attrs=..., buf=0x7fff178d6da4, len=4) at exec.c:3177 +#15 0x00005645cb184a7d in address_space_write (as=0x5645cbd7bb20 <address_space_io>, addr=972, attrs=..., buf=0x7fff178d6da4, len=4) at exec.c:3268 +#16 0x00005645cb1db385 in cpu_outl (addr=972, val=791796754) at ioport.c:80 + +Making this bug public as secalert@ said "if an unprivileged guest user can not trigger it, it can be treated as a normal bug". + +Fixed in commit 5fcf787582dd911df3a971718010bfca5a20e61d + diff --git a/results/classifier/108/other/1880225 b/results/classifier/108/other/1880225 new file mode 100644 index 00000000..6aa6b6a1 --- /dev/null +++ b/results/classifier/108/other/1880225 @@ -0,0 +1,1122 @@ +other: 0.953 +debug: 0.944 +graphic: 0.940 +semantic: 0.936 +permissions: 0.927 +performance: 0.925 +device: 0.924 +PID: 0.921 +vnc: 0.915 +socket: 0.909 +network: 0.899 +files: 0.889 +boot: 0.857 +KVM: 0.841 + +Emulation of some arm programs fail with "Assertion `have_guest_base' failed." + +This issue is observer with QEMU ToT, checked out around May 15th (but I believe it is present in current master too), and wasn't present in QEMU v5.0.0. + +I am using 32-bit Intel(R) Pentium(R) M processor 1.73GHz host. + +Arm cross-compiler is a standard cross-compiler that comes with Debian-based distributions, and gcc version is: + +$ arm-linux-gnueabi-gcc --version +arm-linux-gnueabi-gcc (Debian 8.3.0-2) 8.3.0 + +Compile this program with cross compiler: + +$ arm-linux-gnueabi-gcc -O2 -static toupper_string.c -o toupper_string-arm + +Emulation with QEMU v5.0.0 is correct, and gives expected output: + +$ ~/Build/qemu-5.0.0/build-gcc/arm-linux-user/qemu-arm ./toupper_string-arm +CONTROL RESULT: (toupper_string) + nwlrbbmqbhcdarz owkkyhiddqscdxr jmowfrxsjybldbe fsarcbynecdyggx xpklorellnmpapq + NWLRBBMQBHCDARZ OWKKYHIDDQSCDXR JMOWFRXSJYBLDBE FSARCBYNECDYGGX XPKLORELLNMPAPQ + +While, in case of QEMU master it fails: + +$ ~/Build/qemu-master/build-gcc/arm-linux-user/qemu-arm ./toupper_string-arm +qemu-arm: /home/rtrk/Build/qemu-master/linux-user/elfload.c:2294: probe_guest_base: Assertion `have_guest_base' failed. +Aborted + +There are many other programs that exibit the same behavior. The failure is arm-sprecific. + + +----------------------------------------------------- + +source code: (let's call this file toupper_string.c) (similar file is also in attachment) + + +#include <stdlib.h> +#include <string.h> +#include <stdio.h> +#include <unistd.h> + + +#define MAX_STRING_LENGHT 15 +#define NUMBER_OF_RANDOM_STRINGS 100 +#define DEFAULT_NUMBER_OF_REPETITIONS 30000 +#define MAX_NUMBER_OF_REPETITIONS 1000000000 +#define NUMBER_OF_CONTROL_PRINT_ITEMS 5 + +/* Structure for keeping an array of strings */ +struct StringStruct { + char chars[MAX_STRING_LENGHT + 1]; +}; + +/** + * Sets characters of the given string to random small letters a-z. + * @param s String to get random characters. + * @len Length of the input string. + */ +static void gen_random_string(char *chars, const int len) +{ + static const char letters[] = "abcdefghijklmnopqrstuvwxyz"; + + for (size_t i = 0; i < len; i++) { + chars[i] = letters[rand() % (sizeof(letters) - 1)]; + } + chars[len] = 0; +} + +void main (int argc, char* argv[]) +{ + struct StringStruct random_strings[NUMBER_OF_RANDOM_STRINGS]; + struct StringStruct strings_to_be_uppercased[NUMBER_OF_RANDOM_STRINGS]; + int32_t number_of_repetitions = DEFAULT_NUMBER_OF_REPETITIONS; + int32_t option; + + /* Parse command line options */ + while ((option = getopt(argc, argv, "n:")) != -1) { + if (option == 'n') { + int32_t user_number_of_repetitions = atoi(optarg); + /* Check if the value is a negative number */ + if (user_number_of_repetitions < 1) { + fprintf(stderr, "Error ... Value for option '-n' cannot be a " + "negative number.\n"); + exit(EXIT_FAILURE); + } + /* Check if the value is a string or zero */ + if (user_number_of_repetitions == 0) { + fprintf(stderr, "Error ... Invalid value for option '-n'.\n"); + exit(EXIT_FAILURE); + } + /* Check if the value is too large */ + if (user_number_of_repetitions > MAX_NUMBER_OF_REPETITIONS) { + fprintf(stderr, "Error ... Value for option '-n' cannot be " + "more than %d.\n", MAX_NUMBER_OF_REPETITIONS); + exit(EXIT_FAILURE); + } + number_of_repetitions = user_number_of_repetitions; + } else { + exit(EXIT_FAILURE); + } + } + + /* Create an array of strings with random content */ + srand(1); + for (size_t i = 0; i < NUMBER_OF_RANDOM_STRINGS; i++) { + gen_random_string(random_strings[i].chars, MAX_STRING_LENGHT); + } + + /* Perform uppercasing of a set of random strings multiple times */ + for (size_t j = 0; j < number_of_repetitions; j++) { + /* Copy initial set of random strings to the set to be uppercased */ + memcpy(strings_to_be_uppercased, random_strings, + NUMBER_OF_RANDOM_STRINGS * (MAX_STRING_LENGHT + 1)); + /* Do actual changing case to uppercase */ + for (size_t i = 0; i < NUMBER_OF_RANDOM_STRINGS; i++) { + int k = 0; + + while (strings_to_be_uppercased[i].chars[k]) { + char ch = strings_to_be_uppercased[i].chars[k] - 32; + memcpy((void *)strings_to_be_uppercased[i].chars + k, + &ch, 1); + k++; + } + } + } + + /* Control printing */ + printf("CONTROL RESULT: (toupper_string)\n"); + for (size_t i = 0; i < NUMBER_OF_CONTROL_PRINT_ITEMS; i++) { + printf(" %s", random_strings[i].chars); + } + printf("\n"); + for (size_t i = 0; i < NUMBER_OF_CONTROL_PRINT_ITEMS; i++) { + printf(" %s", strings_to_be_uppercased[i].chars); + } + printf("\n"); +} + + + + +Aleksandar Markovic <email address hidden> writes: + +> Public bug reported: +> +> This issue is observer with QEMU ToT, checked out around May 15th (but I +> believe it is present in current master too), and wasn't present in QEMU +> v5.0.0. +> +> I am using 32-bit Intel(R) Pentium(R) M processor 1.73GHz host. +> +> Arm cross-compiler is a standard cross-compiler that comes with Debian- +> based distributions, and gcc version is: +> +> $ arm-linux-gnueabi-gcc --version +> arm-linux-gnueabi-gcc (Debian 8.3.0-2) 8.3.0 +> +> Compile this program with cross compiler: +> +> $ arm-linux-gnueabi-gcc -O2 -static toupper_string.c -o toupper_string- +> arm +> +> Emulation with QEMU v5.0.0 is correct, and gives expected output: +> +> $ ~/Build/qemu-5.0.0/build-gcc/arm-linux-user/qemu-arm ./toupper_string-arm +> CONTROL RESULT: (toupper_string) +> nwlrbbmqbhcdarz owkkyhiddqscdxr jmowfrxsjybldbe fsarcbynecdyggx xpklorellnmpapq +> NWLRBBMQBHCDARZ OWKKYHIDDQSCDXR JMOWFRXSJYBLDBE FSARCBYNECDYGGX XPKLORELLNMPAPQ +> +> While, in case of QEMU master it fails: +> +> $ ~/Build/qemu-master/build-gcc/arm-linux-user/qemu-arm ./toupper_string-arm +> qemu-arm: /home/rtrk/Build/qemu-master/linux-user/elfload.c:2294: probe_guest_base: Assertion `have_guest_base' failed. +> Aborted +<snip> + +Works for me in our TCG tests on master: + +20:15:43 [alex@zen:~/l/q/b/user.static] review/aarch64-vms-v7|… + ./arm-linux-user/qemu-arm ./tests/tcg/arm-linux-user/toupper +CONTROL RESULT: (toupper_string) + nwlrbbmqbhcdarz owkkyhiddqscdxr jmowfrxsjybldbe fsarcbynecdyggx xpklorellnmpapq + NWLRBBMQBHCDARZ OWKKYHIDDQSCDXR JMOWFRXSJYBLDBE FSARCBYNECDYGGX XPKLORELLNMPAPQ + +I have submitted a fix to the list that affected programs that couldn't +see /proc/self/maps but I guess that isn't the case here. + +-- +Alex Bennée + + +Using bisection, it can be deduced that this behavior appears to be caused by this commit: + + +commit ee94743034bfb443cf246eda4971bdc15d8ee066 (HEAD) +Author: Alex Bennée <email address hidden> +Date: Wed May 13 18:51:28 2020 +0100 + + linux-user: completely re-write init_guest_space + + First we ensure all guest space initialisation logic comes through + probe_guest_base once we understand the nature of the binary we are + loading. The convoluted init_guest_space routine is removed and + replaced with a number of pgb_* helpers which are called depending on + what requirements we have when loading the binary. + + We first try to do what is requested by the host. Failing that we try + and satisfy the guest requested base address. If all those options + fail we fall back to finding a space in the memory map using our + recently written read_self_maps() helper. + + There are some additional complications we try and take into account + when looking for holes in the address space. We try not to go directly + after the system brk() space so there is space for a little growth. We + also don't want to have to use negative offsets which would result in + slightly less efficient code on x86 when it's unable to use the + segment offset register. + + Less mind-binding gotos and hopefully clearer logic throughout. + + Signed-off-by: Alex Bennée <email address hidden> + Acked-by: Laurent Vivier <email address hidden> + + Message-Id: <email address hidden> + +I just want to stress once again that the test was performed on a 32-bit Intel host. + +It appear that there is no problem on Intel 64-bit hosts. + +Perhaps the problem is manifested on all 32-bit hosts. I currently don't have access to any other 320bit host due to remote work. + +The arm is the only target were I noticed this happens. I checked hppa, mips, mipsel, m68k, ppc, and sh4, they ae all fine, with the same program/example, on the same 32-bit Intel host. I did not checked other target except those I just mentioned. + + +Aleksandar Markovic <email address hidden> writes: + +> I just want to stress once again that the test was performed on a 32-bit +> Intel host. + +Ahh - OK that makes sense. I'll see if I can replicate. + + +-- +Alex Bennée + + +The problem may be in int_guest_commpage() - it returns false. + +From gdb debugging session: + +(gdb) p addr +$1 = (void *) 0xb7ffd000 +(gdb) p want +$2 = (void *) 0xffff0000 +(gdb) n +398 if (addr != want) { +(gdb) p qemu_host_page_size +$3 = 4096 +(gdb) l +393 +394 if (addr == MAP_FAILED) { +395 perror("Allocating guest commpage"); +396 exit(EXIT_FAILURE); +397 } +398 if (addr != want) { +399 return false; +400 } +401 +402 /* Set kernel helper versions; rest of page is 0. */ +(gdb) + + +Aleksandar Markovic <email address hidden> writes: + +> The problem may be in int_guest_commpage() - it returns false. +> +>>From gdb debugging session: +> +> (gdb) p addr +> $1 = (void *) 0xb7ffd000 +> (gdb) p want +> $2 = (void *) 0xffff0000 +> (gdb) n +> 398 if (addr != want) { +> (gdb) p qemu_host_page_size +> $3 = 4096 +> (gdb) l +> 393 +> 394 if (addr == MAP_FAILED) { +> 395 perror("Allocating guest commpage"); +> 396 exit(EXIT_FAILURE); +> 397 } +> 398 if (addr != want) { +> 399 return false; +> 400 } +> 401 +> 402 /* Set kernel helper versions; rest of page is 0. */ +> (gdb) + +I'm not totally convinced the calculation that we do to work out the +extended size of the guest space in 32 bit: + + 11:10 alex@debian-buster-i386/i686 [arm/bugs/add-mmap-fallback@github] >./arm-linux-user/qemu-arm tests/tcg/arm-linux-user/sha1 + pgb_static: loaddr: 10000 + pgb_static: loaddr: ffff0000 + pgb_find_hole: ffff0000:10809a8 (1000) + pgb_find_hole: 0:10809a8 + init_guest_commpage: 0xffff0000 -> 0xb7f48000 (4096) + qemu-arm: /home/alex/lsrc/qemu.git/linux-user/elfload.c:2350: probe_guest_base: Assertion `have_guest_base' failed. + Aborted (core dumped) + +Or in fact why we don't do a MAP_FIXED ass we should have ensured we +have enough space allocated for the guest. Richard any ideas? + +-- +Alex Bennée + + +We rely on the pointer to wrap when accessing the high address of the +COMMPAGE so it lands somewhere reasonable. However on 32 bit hosts we +cannot afford just to map the entire 4gb address range. The old mmap +trial and error code handled this by just checking we could map both +the guest_base and the computed COMMPAGE address. + +We can't just manipulate loadaddr to get what we want so we introduce +an offset which pgb_find_hole can apply when looking for a gap for +guest_base that ensures there is space left to map the COMMPAGE +afterwards. + +This is arguably a little inefficient for the one 32 bit +value (kuser_helper_version) we need to keep there given all the +actual code entries are picked up during the translation phase. + +Fixes: ee94743034b +Bug: https://bugs.launchpad.net/qemu/+bug/1880225 +Cc: Bug 1880225 <email address hidden> +Signed-off-by: Alex Bennée <email address hidden> +Cc: Richard Henderson <email address hidden> +Cc: Peter Maydell <email address hidden> +--- + linux-user/elfload.c | 18 ++++++++++-------- + 1 file changed, 10 insertions(+), 8 deletions(-) + +diff --git a/linux-user/elfload.c b/linux-user/elfload.c +index d6027867a1a..31defce95b5 100644 +--- a/linux-user/elfload.c ++++ b/linux-user/elfload.c +@@ -2145,7 +2145,7 @@ static uintptr_t pgd_find_hole_fallback(uintptr_t guest_size, uintptr_t brk, lon + + /* Return value for guest_base, or -1 if no hole found. */ + static uintptr_t pgb_find_hole(uintptr_t guest_loaddr, uintptr_t guest_size, +- long align) ++ long align, uintptr_t offset) + { + GSList *maps, *iter; + uintptr_t this_start, this_end, next_start, brk; +@@ -2171,7 +2171,7 @@ static uintptr_t pgb_find_hole(uintptr_t guest_loaddr, uintptr_t guest_size, + + this_end = ((MapInfo *)iter->data)->start; + next_start = ((MapInfo *)iter->data)->end; +- align_start = ROUND_UP(this_start, align); ++ align_start = ROUND_UP(this_start + offset, align); + + /* Skip holes that are too small. */ + if (align_start >= this_end) { +@@ -2221,6 +2221,7 @@ static void pgb_static(const char *image_name, abi_ulong orig_loaddr, + { + uintptr_t loaddr = orig_loaddr; + uintptr_t hiaddr = orig_hiaddr; ++ uintptr_t offset = 0; + uintptr_t addr; + + if (hiaddr != orig_hiaddr) { +@@ -2234,18 +2235,19 @@ static void pgb_static(const char *image_name, abi_ulong orig_loaddr, + if (ARM_COMMPAGE) { + /* + * Extend the allocation to include the commpage. +- * For a 64-bit host, this is just 4GiB; for a 32-bit host, +- * the address arithmetic will wrap around, but the difference +- * will produce the correct allocation size. ++ * For a 64-bit host, this is just 4GiB; for a 32-bit host we ++ * need to ensure there is space bellow the guest_base so we ++ * can map the commpage in the place needed when the address ++ * arithmetic wraps around. + */ + if (sizeof(uintptr_t) == 8 || loaddr >= 0x80000000u) { + hiaddr = (uintptr_t)4 << 30; + } else { +- loaddr = ARM_COMMPAGE & -align; ++ offset = (128 * KiB); + } + } + +- addr = pgb_find_hole(loaddr, hiaddr - loaddr, align); ++ addr = pgb_find_hole(loaddr, hiaddr - loaddr, align, offset); + if (addr == -1) { + /* + * If ARM_COMMPAGE, there *might* be a non-consecutive allocation +@@ -2280,7 +2282,7 @@ static void pgb_dynamic(const char *image_name, long align) + * just above that, and maximises the positive guest addresses. + */ + commpage = ARM_COMMPAGE & -align; +- addr = pgb_find_hole(commpage, -commpage, align); ++ addr = pgb_find_hole(commpage, -commpage, align, 0); + assert(addr != -1); + guest_base = addr; + } +-- +2.20.1 + + + +сре, 27. мај 2020. у 12:07 Alex Bennée <email address hidden> је написао/ла: +> +> We rely on the pointer to wrap when accessing the high address of the +> COMMPAGE so it lands somewhere reasonable. However on 32 bit hosts we +> cannot afford just to map the entire 4gb address range. The old mmap +> trial and error code handled this by just checking we could map both +> the guest_base and the computed COMMPAGE address. +> +> We can't just manipulate loadaddr to get what we want so we introduce +> an offset which pgb_find_hole can apply when looking for a gap for +> guest_base that ensures there is space left to map the COMMPAGE +> afterwards. +> +> This is arguably a little inefficient for the one 32 bit +> value (kuser_helper_version) we need to keep there given all the +> actual code entries are picked up during the translation phase. +> +> Fixes: ee94743034b +> Bug: https://bugs.launchpad.net/qemu/+bug/1880225 + +For the scenario in this bug report, for today's master, before and after +applying this patch: + +BEFORE: + +$ ~/Build/qemu-master/build-gcc/arm-linux-user/qemu-arm ./toupper_string-arm +qemu-arm: /home/rtrk/Build/qemu-master/linux-user/elfload.c:2294: +probe_guest_base: Assertion `have_guest_base' failed. +Aborted + +AFTER: + +$ ~/Build/qemu-master/build-gcc/arm-linux-user/qemu-arm ./toupper_string-arm +CONTROL RESULT: (toupper_string) + nwlrbbmqbhcdarz owkkyhiddqscdxr jmowfrxsjybldbe fsarcbynecdyggx xpklorellnmpapq + NWLRBBMQBHCDARZ OWKKYHIDDQSCDXR JMOWFRXSJYBLDBE FSARCBYNECDYGGX XPKLORELLNMPAPQ + +So, it works in my test bed. + +Tested-by: Aleksandar Markovic <email address hidden> + +> Cc: Bug 1880225 <email address hidden> +> Signed-off-by: Alex Bennée <email address hidden> +> Cc: Richard Henderson <email address hidden> +> Cc: Peter Maydell <email address hidden> +> --- +> linux-user/elfload.c | 18 ++++++++++-------- +> 1 file changed, 10 insertions(+), 8 deletions(-) +> +> diff --git a/linux-user/elfload.c b/linux-user/elfload.c +> index d6027867a1a..31defce95b5 100644 +> --- a/linux-user/elfload.c +> +++ b/linux-user/elfload.c +> @@ -2145,7 +2145,7 @@ static uintptr_t pgd_find_hole_fallback(uintptr_t guest_size, uintptr_t brk, lon +> +> /* Return value for guest_base, or -1 if no hole found. */ +> static uintptr_t pgb_find_hole(uintptr_t guest_loaddr, uintptr_t guest_size, +> - long align) +> + long align, uintptr_t offset) +> { +> GSList *maps, *iter; +> uintptr_t this_start, this_end, next_start, brk; +> @@ -2171,7 +2171,7 @@ static uintptr_t pgb_find_hole(uintptr_t guest_loaddr, uintptr_t guest_size, +> +> this_end = ((MapInfo *)iter->data)->start; +> next_start = ((MapInfo *)iter->data)->end; +> - align_start = ROUND_UP(this_start, align); +> + align_start = ROUND_UP(this_start + offset, align); +> +> /* Skip holes that are too small. */ +> if (align_start >= this_end) { +> @@ -2221,6 +2221,7 @@ static void pgb_static(const char *image_name, abi_ulong orig_loaddr, +> { +> uintptr_t loaddr = orig_loaddr; +> uintptr_t hiaddr = orig_hiaddr; +> + uintptr_t offset = 0; +> uintptr_t addr; +> +> if (hiaddr != orig_hiaddr) { +> @@ -2234,18 +2235,19 @@ static void pgb_static(const char *image_name, abi_ulong orig_loaddr, +> if (ARM_COMMPAGE) { +> /* +> * Extend the allocation to include the commpage. +> - * For a 64-bit host, this is just 4GiB; for a 32-bit host, +> - * the address arithmetic will wrap around, but the difference +> - * will produce the correct allocation size. +> + * For a 64-bit host, this is just 4GiB; for a 32-bit host we +> + * need to ensure there is space bellow the guest_base so we +> + * can map the commpage in the place needed when the address +> + * arithmetic wraps around. +> */ +> if (sizeof(uintptr_t) == 8 || loaddr >= 0x80000000u) { +> hiaddr = (uintptr_t)4 << 30; +> } else { +> - loaddr = ARM_COMMPAGE & -align; +> + offset = (128 * KiB); +> } +> } +> +> - addr = pgb_find_hole(loaddr, hiaddr - loaddr, align); +> + addr = pgb_find_hole(loaddr, hiaddr - loaddr, align, offset); +> if (addr == -1) { +> /* +> * If ARM_COMMPAGE, there *might* be a non-consecutive allocation +> @@ -2280,7 +2282,7 @@ static void pgb_dynamic(const char *image_name, long align) +> * just above that, and maximises the positive guest addresses. +> */ +> commpage = ARM_COMMPAGE & -align; +> - addr = pgb_find_hole(commpage, -commpage, align); +> + addr = pgb_find_hole(commpage, -commpage, align, 0); +> assert(addr != -1); +> guest_base = addr; +> } +> -- +> 2.20.1 +> +> + + +сре, 27. мај 2020. у 14:05 Aleksandar Markovic +<email address hidden> је написао/ла: +> +> сре, 27. мај 2020. у 12:07 Alex Bennée <email address hidden> је написао/ла: +> > +> > We rely on the pointer to wrap when accessing the high address of the +> > COMMPAGE so it lands somewhere reasonable. However on 32 bit hosts we +> > cannot afford just to map the entire 4gb address range. The old mmap +> > trial and error code handled this by just checking we could map both +> > the guest_base and the computed COMMPAGE address. +> > +> > We can't just manipulate loadaddr to get what we want so we introduce +> > an offset which pgb_find_hole can apply when looking for a gap for +> > guest_base that ensures there is space left to map the COMMPAGE +> > afterwards. +> > +> > This is arguably a little inefficient for the one 32 bit +> > value (kuser_helper_version) we need to keep there given all the +> > actual code entries are picked up during the translation phase. +> > +> > Fixes: ee94743034b +> > Bug: https://bugs.launchpad.net/qemu/+bug/1880225 +> +> For the scenario in this bug report, for today's master, before and after +> applying this patch: +> + +I am not sure how significant is this info, but I executed the test +without applying patch 1/3, so only 2/3 was applied in the case +"AFTER". + +Aleksandar + +> BEFORE: +> +> $ ~/Build/qemu-master/build-gcc/arm-linux-user/qemu-arm ./toupper_string-arm +> qemu-arm: /home/rtrk/Build/qemu-master/linux-user/elfload.c:2294: +> probe_guest_base: Assertion `have_guest_base' failed. +> Aborted +> +> AFTER: +> +> $ ~/Build/qemu-master/build-gcc/arm-linux-user/qemu-arm ./toupper_string-arm +> CONTROL RESULT: (toupper_string) +> nwlrbbmqbhcdarz owkkyhiddqscdxr jmowfrxsjybldbe fsarcbynecdyggx xpklorellnmpapq +> NWLRBBMQBHCDARZ OWKKYHIDDQSCDXR JMOWFRXSJYBLDBE FSARCBYNECDYGGX XPKLORELLNMPAPQ +> +> So, it works in my test bed. +> +> Tested-by: Aleksandar Markovic <email address hidden> +> +> > Cc: Bug 1880225 <email address hidden> +> > Signed-off-by: Alex Bennée <email address hidden> +> > Cc: Richard Henderson <email address hidden> +> > Cc: Peter Maydell <email address hidden> +> > --- +> > linux-user/elfload.c | 18 ++++++++++-------- +> > 1 file changed, 10 insertions(+), 8 deletions(-) +> > +> > diff --git a/linux-user/elfload.c b/linux-user/elfload.c +> > index d6027867a1a..31defce95b5 100644 +> > --- a/linux-user/elfload.c +> > +++ b/linux-user/elfload.c +> > @@ -2145,7 +2145,7 @@ static uintptr_t pgd_find_hole_fallback(uintptr_t guest_size, uintptr_t brk, lon +> > +> > /* Return value for guest_base, or -1 if no hole found. */ +> > static uintptr_t pgb_find_hole(uintptr_t guest_loaddr, uintptr_t guest_size, +> > - long align) +> > + long align, uintptr_t offset) +> > { +> > GSList *maps, *iter; +> > uintptr_t this_start, this_end, next_start, brk; +> > @@ -2171,7 +2171,7 @@ static uintptr_t pgb_find_hole(uintptr_t guest_loaddr, uintptr_t guest_size, +> > +> > this_end = ((MapInfo *)iter->data)->start; +> > next_start = ((MapInfo *)iter->data)->end; +> > - align_start = ROUND_UP(this_start, align); +> > + align_start = ROUND_UP(this_start + offset, align); +> > +> > /* Skip holes that are too small. */ +> > if (align_start >= this_end) { +> > @@ -2221,6 +2221,7 @@ static void pgb_static(const char *image_name, abi_ulong orig_loaddr, +> > { +> > uintptr_t loaddr = orig_loaddr; +> > uintptr_t hiaddr = orig_hiaddr; +> > + uintptr_t offset = 0; +> > uintptr_t addr; +> > +> > if (hiaddr != orig_hiaddr) { +> > @@ -2234,18 +2235,19 @@ static void pgb_static(const char *image_name, abi_ulong orig_loaddr, +> > if (ARM_COMMPAGE) { +> > /* +> > * Extend the allocation to include the commpage. +> > - * For a 64-bit host, this is just 4GiB; for a 32-bit host, +> > - * the address arithmetic will wrap around, but the difference +> > - * will produce the correct allocation size. +> > + * For a 64-bit host, this is just 4GiB; for a 32-bit host we +> > + * need to ensure there is space bellow the guest_base so we +> > + * can map the commpage in the place needed when the address +> > + * arithmetic wraps around. +> > */ +> > if (sizeof(uintptr_t) == 8 || loaddr >= 0x80000000u) { +> > hiaddr = (uintptr_t)4 << 30; +> > } else { +> > - loaddr = ARM_COMMPAGE & -align; +> > + offset = (128 * KiB); +> > } +> > } +> > +> > - addr = pgb_find_hole(loaddr, hiaddr - loaddr, align); +> > + addr = pgb_find_hole(loaddr, hiaddr - loaddr, align, offset); +> > if (addr == -1) { +> > /* +> > * If ARM_COMMPAGE, there *might* be a non-consecutive allocation +> > @@ -2280,7 +2282,7 @@ static void pgb_dynamic(const char *image_name, long align) +> > * just above that, and maximises the positive guest addresses. +> > */ +> > commpage = ARM_COMMPAGE & -align; +> > - addr = pgb_find_hole(commpage, -commpage, align); +> > + addr = pgb_find_hole(commpage, -commpage, align, 0); +> > assert(addr != -1); +> > guest_base = addr; +> > } +> > -- +> > 2.20.1 +> > +> > + + + +Aleksandar Markovic <email address hidden> writes: + +> сре, 27. мај 2020. у 14:05 Aleksandar Markovic +> <email address hidden> је написао/ла: +>> +>> сре, 27. мај 2020. у 12:07 Alex Bennée <email address hidden> је написао/ла: +>> > +>> > We rely on the pointer to wrap when accessing the high address of the +>> > COMMPAGE so it lands somewhere reasonable. However on 32 bit hosts we +>> > cannot afford just to map the entire 4gb address range. The old mmap +>> > trial and error code handled this by just checking we could map both +>> > the guest_base and the computed COMMPAGE address. +>> > +>> > We can't just manipulate loadaddr to get what we want so we introduce +>> > an offset which pgb_find_hole can apply when looking for a gap for +>> > guest_base that ensures there is space left to map the COMMPAGE +>> > afterwards. +>> > +>> > This is arguably a little inefficient for the one 32 bit +>> > value (kuser_helper_version) we need to keep there given all the +>> > actual code entries are picked up during the translation phase. +>> > +>> > Fixes: ee94743034b +>> > Bug: https://bugs.launchpad.net/qemu/+bug/1880225 +>> +>> For the scenario in this bug report, for today's master, before and after +>> applying this patch: +>> +> +> I am not sure how significant is this info, but I executed the test +> without applying patch 1/3, so only 2/3 was applied in the case +> "AFTER". + +That is expected. The other fix only affects binaries run inside a +/proc-less chroot and the final patch is a test case for COMMPAGE +support. + +-- +Alex Bennée + + + +Richard Henderson <email address hidden> writes: + +> On 5/27/20 3:05 AM, Alex Bennée wrote: +>> @@ -2145,7 +2145,7 @@ static uintptr_t pgd_find_hole_fallback(uintptr_t guest_size, uintptr_t brk, lon +>> +>> /* Return value for guest_base, or -1 if no hole found. */ +>> static uintptr_t pgb_find_hole(uintptr_t guest_loaddr, uintptr_t guest_size, +>> - long align) +>> + long align, uintptr_t offset) +>> { +>> GSList *maps, *iter; +>> uintptr_t this_start, this_end, next_start, brk; +>> @@ -2171,7 +2171,7 @@ static uintptr_t pgb_find_hole(uintptr_t guest_loaddr, uintptr_t guest_size, +>> +>> this_end = ((MapInfo *)iter->data)->start; +>> next_start = ((MapInfo *)iter->data)->end; +>> - align_start = ROUND_UP(this_start, align); +>> + align_start = ROUND_UP(this_start + offset, align); +>> +>> /* Skip holes that are too small. */ +> +> I suppose offset is supposed to mean we start from -offset? + +Well guest_base will start higher meaning we have space for the +commpage beneath it. + +> You didn't update +> pgb_find_hole_fallback. + +Fixed. + +> +>> - loaddr = ARM_COMMPAGE & -align; +>> + offset = (128 * KiB); +> +> Why 128K? Surely this should be an expression against ARM_COMMPAGE. + +In theory: + + offset = -(ARM_COMMPAGE & -align); + +should do the trick but I found it failed every now and again. +Frustratingly putting printfs in made it go away so in frustration I +just upped the offset until it stopped happening. + +I do kinda wish rr worked on i386 :-/ + + +> +> +> r~ + + +-- +Alex Bennée + + + +Alex Bennée <email address hidden> writes: + +> Richard Henderson <email address hidden> writes: +> +>> On 5/27/20 3:05 AM, Alex Bennée wrote: +>>> @@ -2145,7 +2145,7 @@ static uintptr_t pgd_find_hole_fallback(uintptr_t guest_size, uintptr_t brk, lon +>>> +>>> /* Return value for guest_base, or -1 if no hole found. */ +>>> static uintptr_t pgb_find_hole(uintptr_t guest_loaddr, uintptr_t guest_size, +>>> - long align) +>>> + long align, uintptr_t offset) +>>> { +>>> GSList *maps, *iter; +>>> uintptr_t this_start, this_end, next_start, brk; +>>> @@ -2171,7 +2171,7 @@ static uintptr_t pgb_find_hole(uintptr_t guest_loaddr, uintptr_t guest_size, +>>> +>>> this_end = ((MapInfo *)iter->data)->start; +>>> next_start = ((MapInfo *)iter->data)->end; +>>> - align_start = ROUND_UP(this_start, align); +>>> + align_start = ROUND_UP(this_start + offset, align); +>>> +>>> /* Skip holes that are too small. */ +>> +>> I suppose offset is supposed to mean we start from -offset? +> +> Well guest_base will start higher meaning we have space for the +> commpage beneath it. +> +>> You didn't update +>> pgb_find_hole_fallback. +> +> Fixed. +> +>> +>>> - loaddr = ARM_COMMPAGE & -align; +>>> + offset = (128 * KiB); +>> +>> Why 128K? Surely this should be an expression against ARM_COMMPAGE. +> +> In theory: +> +> offset = -(ARM_COMMPAGE & -align); +> +> should do the trick but I found it failed every now and again. +> Frustratingly putting printfs in made it go away so in frustration I +> just upped the offset until it stopped happening. +> +> I do kinda wish rr worked on i386 :-/ + +Ahh all I needed was a MAP_FIXED for init_commpage + +-- +Alex Bennée + + +We rely on the pointer to wrap when accessing the high address of the +COMMPAGE so it lands somewhere reasonable. However on 32 bit hosts we +cannot afford just to map the entire 4gb address range. The old mmap +trial and error code handled this by just checking we could map both +the guest_base and the computed COMMPAGE address. + +We can't just manipulate loadaddr to get what we want so we introduce +an offset which pgb_find_hole can apply when looking for a gap for +guest_base that ensures there is space left to map the COMMPAGE +afterwards. + +This is arguably a little inefficient for the one 32 bit +value (kuser_helper_version) we need to keep there given all the +actual code entries are picked up during the translation phase. + +Fixes: ee94743034b +Bug: https://bugs.launchpad.net/qemu/+bug/1880225 +Cc: Bug 1880225 <email address hidden> +Signed-off-by: Alex Bennée <email address hidden> +Tested-by: Aleksandar Markovic <email address hidden> +Cc: Richard Henderson <email address hidden> +Cc: Peter Maydell <email address hidden> +Message-Id: <email address hidden> + +--- +v3 + - base offset on ARM_COMMPAGE + - ensure we MAP_FIXED the commpage + - support offset in pgd_find_hole_fallback +--- + linux-user/elfload.c | 31 +++++++++++++++++-------------- + 1 file changed, 17 insertions(+), 14 deletions(-) + +diff --git a/linux-user/elfload.c b/linux-user/elfload.c +index 475d243f3bd..b5cb21384a1 100644 +--- a/linux-user/elfload.c ++++ b/linux-user/elfload.c +@@ -389,7 +389,7 @@ static bool init_guest_commpage(void) + { + void *want = g2h(ARM_COMMPAGE & -qemu_host_page_size); + void *addr = mmap(want, qemu_host_page_size, PROT_READ | PROT_WRITE, +- MAP_ANONYMOUS | MAP_PRIVATE, -1, 0); ++ MAP_ANONYMOUS | MAP_PRIVATE | MAP_FIXED, -1, 0); + + if (addr == MAP_FAILED) { + perror("Allocating guest commpage"); +@@ -2113,7 +2113,8 @@ static void pgb_have_guest_base(const char *image_name, abi_ulong guest_loaddr, + * only dumbly iterate up the host address space seeing if the + * allocation would work. + */ +-static uintptr_t pgd_find_hole_fallback(uintptr_t guest_size, uintptr_t brk, long align) ++static uintptr_t pgd_find_hole_fallback(uintptr_t guest_size, uintptr_t brk, ++ long align, uintptr_t offset) + { + uintptr_t base; + +@@ -2123,7 +2124,7 @@ static uintptr_t pgd_find_hole_fallback(uintptr_t guest_size, uintptr_t brk, lon + while (true) { + uintptr_t align_start, end; + align_start = ROUND_UP(base, align); +- end = align_start + guest_size; ++ end = align_start + guest_size + offset; + + /* if brk is anywhere in the range give ourselves some room to grow. */ + if (align_start <= brk && brk < end) { +@@ -2138,7 +2139,7 @@ static uintptr_t pgd_find_hole_fallback(uintptr_t guest_size, uintptr_t brk, lon + PROT_NONE, flags, -1, 0); + if (mmap_start != MAP_FAILED) { + munmap((void *) align_start, guest_size); +- return (uintptr_t) mmap_start; ++ return (uintptr_t) mmap_start + offset; + } + base += qemu_host_page_size; + } +@@ -2147,7 +2148,7 @@ static uintptr_t pgd_find_hole_fallback(uintptr_t guest_size, uintptr_t brk, lon + + /* Return value for guest_base, or -1 if no hole found. */ + static uintptr_t pgb_find_hole(uintptr_t guest_loaddr, uintptr_t guest_size, +- long align) ++ long align, uintptr_t offset) + { + GSList *maps, *iter; + uintptr_t this_start, this_end, next_start, brk; +@@ -2161,7 +2162,7 @@ static uintptr_t pgb_find_hole(uintptr_t guest_loaddr, uintptr_t guest_size, + brk = (uintptr_t)sbrk(0); + + if (!maps) { +- return pgd_find_hole_fallback(guest_size, brk, align); ++ return pgd_find_hole_fallback(guest_size, brk, align, offset); + } + + /* The first hole is before the first map entry. */ +@@ -2173,7 +2174,7 @@ static uintptr_t pgb_find_hole(uintptr_t guest_loaddr, uintptr_t guest_size, + + this_end = ((MapInfo *)iter->data)->start; + next_start = ((MapInfo *)iter->data)->end; +- align_start = ROUND_UP(this_start, align); ++ align_start = ROUND_UP(this_start + offset, align); + + /* Skip holes that are too small. */ + if (align_start >= this_end) { +@@ -2223,6 +2224,7 @@ static void pgb_static(const char *image_name, abi_ulong orig_loaddr, + { + uintptr_t loaddr = orig_loaddr; + uintptr_t hiaddr = orig_hiaddr; ++ uintptr_t offset = 0; + uintptr_t addr; + + if (hiaddr != orig_hiaddr) { +@@ -2236,18 +2238,19 @@ static void pgb_static(const char *image_name, abi_ulong orig_loaddr, + if (ARM_COMMPAGE) { + /* + * Extend the allocation to include the commpage. +- * For a 64-bit host, this is just 4GiB; for a 32-bit host, +- * the address arithmetic will wrap around, but the difference +- * will produce the correct allocation size. ++ * For a 64-bit host, this is just 4GiB; for a 32-bit host we ++ * need to ensure there is space bellow the guest_base so we ++ * can map the commpage in the place needed when the address ++ * arithmetic wraps around. + */ + if (sizeof(uintptr_t) == 8 || loaddr >= 0x80000000u) { +- hiaddr = (uintptr_t)4 << 30; ++ hiaddr = (uintptr_t) 4 << 30; + } else { +- loaddr = ARM_COMMPAGE & -align; ++ offset = -(ARM_COMMPAGE & -align); + } + } + +- addr = pgb_find_hole(loaddr, hiaddr - loaddr, align); ++ addr = pgb_find_hole(loaddr, hiaddr - loaddr, align, offset); + if (addr == -1) { + /* + * If ARM_COMMPAGE, there *might* be a non-consecutive allocation +@@ -2282,7 +2285,7 @@ static void pgb_dynamic(const char *image_name, long align) + * just above that, and maximises the positive guest addresses. + */ + commpage = ARM_COMMPAGE & -align; +- addr = pgb_find_hole(commpage, -commpage, align); ++ addr = pgb_find_hole(commpage, -commpage, align, 0); + assert(addr != -1); + guest_base = addr; + } +-- +2.20.1 + + + +We rely on the pointer to wrap when accessing the high address of the +COMMPAGE so it lands somewhere reasonable. However on 32 bit hosts we +cannot afford just to map the entire 4gb address range. The old mmap +trial and error code handled this by just checking we could map both +the guest_base and the computed COMMPAGE address. + +We can't just manipulate loadaddr to get what we want so we introduce +an offset which pgb_find_hole can apply when looking for a gap for +guest_base that ensures there is space left to map the COMMPAGE +afterwards. + +This is arguably a little inefficient for the one 32 bit +value (kuser_helper_version) we need to keep there given all the +actual code entries are picked up during the translation phase. + +Fixes: ee94743034b +Bug: https://bugs.launchpad.net/qemu/+bug/1880225 +Cc: Bug 1880225 <email address hidden> +Signed-off-by: Alex Bennée <email address hidden> +Tested-by: Aleksandar Markovic <email address hidden> +Cc: Richard Henderson <email address hidden> +Cc: Peter Maydell <email address hidden> +Message-Id: <email address hidden> + +diff --git a/linux-user/elfload.c b/linux-user/elfload.c +index 475d243f3bd..b5cb21384a1 100644 +--- a/linux-user/elfload.c ++++ b/linux-user/elfload.c +@@ -389,7 +389,7 @@ static bool init_guest_commpage(void) + { + void *want = g2h(ARM_COMMPAGE & -qemu_host_page_size); + void *addr = mmap(want, qemu_host_page_size, PROT_READ | PROT_WRITE, +- MAP_ANONYMOUS | MAP_PRIVATE, -1, 0); ++ MAP_ANONYMOUS | MAP_PRIVATE | MAP_FIXED, -1, 0); + + if (addr == MAP_FAILED) { + perror("Allocating guest commpage"); +@@ -2113,7 +2113,8 @@ static void pgb_have_guest_base(const char *image_name, abi_ulong guest_loaddr, + * only dumbly iterate up the host address space seeing if the + * allocation would work. + */ +-static uintptr_t pgd_find_hole_fallback(uintptr_t guest_size, uintptr_t brk, long align) ++static uintptr_t pgd_find_hole_fallback(uintptr_t guest_size, uintptr_t brk, ++ long align, uintptr_t offset) + { + uintptr_t base; + +@@ -2123,7 +2124,7 @@ static uintptr_t pgd_find_hole_fallback(uintptr_t guest_size, uintptr_t brk, lon + while (true) { + uintptr_t align_start, end; + align_start = ROUND_UP(base, align); +- end = align_start + guest_size; ++ end = align_start + guest_size + offset; + + /* if brk is anywhere in the range give ourselves some room to grow. */ + if (align_start <= brk && brk < end) { +@@ -2138,7 +2139,7 @@ static uintptr_t pgd_find_hole_fallback(uintptr_t guest_size, uintptr_t brk, lon + PROT_NONE, flags, -1, 0); + if (mmap_start != MAP_FAILED) { + munmap((void *) align_start, guest_size); +- return (uintptr_t) mmap_start; ++ return (uintptr_t) mmap_start + offset; + } + base += qemu_host_page_size; + } +@@ -2147,7 +2148,7 @@ static uintptr_t pgd_find_hole_fallback(uintptr_t guest_size, uintptr_t brk, lon + + /* Return value for guest_base, or -1 if no hole found. */ + static uintptr_t pgb_find_hole(uintptr_t guest_loaddr, uintptr_t guest_size, +- long align) ++ long align, uintptr_t offset) + { + GSList *maps, *iter; + uintptr_t this_start, this_end, next_start, brk; +@@ -2161,7 +2162,7 @@ static uintptr_t pgb_find_hole(uintptr_t guest_loaddr, uintptr_t guest_size, + brk = (uintptr_t)sbrk(0); + + if (!maps) { +- return pgd_find_hole_fallback(guest_size, brk, align); ++ return pgd_find_hole_fallback(guest_size, brk, align, offset); + } + + /* The first hole is before the first map entry. */ +@@ -2173,7 +2174,7 @@ static uintptr_t pgb_find_hole(uintptr_t guest_loaddr, uintptr_t guest_size, + + this_end = ((MapInfo *)iter->data)->start; + next_start = ((MapInfo *)iter->data)->end; +- align_start = ROUND_UP(this_start, align); ++ align_start = ROUND_UP(this_start + offset, align); + + /* Skip holes that are too small. */ + if (align_start >= this_end) { +@@ -2223,6 +2224,7 @@ static void pgb_static(const char *image_name, abi_ulong orig_loaddr, + { + uintptr_t loaddr = orig_loaddr; + uintptr_t hiaddr = orig_hiaddr; ++ uintptr_t offset = 0; + uintptr_t addr; + + if (hiaddr != orig_hiaddr) { +@@ -2236,18 +2238,19 @@ static void pgb_static(const char *image_name, abi_ulong orig_loaddr, + if (ARM_COMMPAGE) { + /* + * Extend the allocation to include the commpage. +- * For a 64-bit host, this is just 4GiB; for a 32-bit host, +- * the address arithmetic will wrap around, but the difference +- * will produce the correct allocation size. ++ * For a 64-bit host, this is just 4GiB; for a 32-bit host we ++ * need to ensure there is space bellow the guest_base so we ++ * can map the commpage in the place needed when the address ++ * arithmetic wraps around. + */ + if (sizeof(uintptr_t) == 8 || loaddr >= 0x80000000u) { +- hiaddr = (uintptr_t)4 << 30; ++ hiaddr = (uintptr_t) 4 << 30; + } else { +- loaddr = ARM_COMMPAGE & -align; ++ offset = -(ARM_COMMPAGE & -align); + } + } + +- addr = pgb_find_hole(loaddr, hiaddr - loaddr, align); ++ addr = pgb_find_hole(loaddr, hiaddr - loaddr, align, offset); + if (addr == -1) { + /* + * If ARM_COMMPAGE, there *might* be a non-consecutive allocation +@@ -2282,7 +2285,7 @@ static void pgb_dynamic(const char *image_name, long align) + * just above that, and maximises the positive guest addresses. + */ + commpage = ARM_COMMPAGE & -align; +- addr = pgb_find_hole(commpage, -commpage, align); ++ addr = pgb_find_hole(commpage, -commpage, align, 0); + assert(addr != -1); + guest_base = addr; + } +-- +2.20.1 + + + +Fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=5c3e87f345ac93de9260f + diff --git a/results/classifier/108/other/1880326 b/results/classifier/108/other/1880326 new file mode 100644 index 00000000..35ee5154 --- /dev/null +++ b/results/classifier/108/other/1880326 @@ -0,0 +1,720 @@ +other: 0.950 +permissions: 0.931 +graphic: 0.929 +semantic: 0.913 +performance: 0.910 +device: 0.896 +PID: 0.895 +debug: 0.888 +boot: 0.876 +files: 0.837 +KVM: 0.831 +vnc: 0.804 +socket: 0.726 +network: 0.716 + +memory writes make artist_rop8() crash + +As of commit d19f1ab0, LLVM libFuzzer found: + +================================================================= +==6814==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7fd89f97bd5a at pc 0x55dc44594db5 bp 0x7ffd6f461b40 sp 0x7ffd6f461b38 +READ of size 1 at 0x7fd89f97bd5a thread T0 + #0 0x55dc44594db4 in artist_rop8 + #1 0x55dc44595fd9 in draw_line + #2 0x55dc445937e4 in draw_line_size + #3 0x55dc4458ee9d in artist_reg_write + #4 0x55dc43f77ba7 in memory_region_write_accessor + #5 0x55dc43f775b8 in access_with_adjusted_size + #6 0x55dc43f762b3 in memory_region_dispatch_write + #7 0x55dc43dbb322 in flatview_write_continue + #8 0x55dc43dab2e2 in flatview_write + #9 0x55dc43daae14 in address_space_write + +0x7fd89f97bd5a is located 1122 bytes to the right of 16777464-byte region [0x7fd89e97b800,0x7fd89f97b8f8) +allocated by thread T0 here: + #0 0x55dc43d87abf in operator new(unsigned long) + #1 0x55dc43c4274d in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) + #2 0x55dc43c3a526 in main (qemu-fuzz-hppa+0x982526) + #3 0x7fd8d05edf42 in __libc_start_main (/lib64/libc.so.6+0x23f42) + +SUMMARY: AddressSanitizer: heap-buffer-overflow (qemu-fuzz-hppa+0x12dcdb4) in artist_rop8 +Shadow bytes around the buggy address: + 0x0ffb93f27750: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0ffb93f27760: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0ffb93f27770: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0ffb93f27780: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0ffb93f27790: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa +=>0x0ffb93f277a0: fa fa fa fa fa fa fa fa fa fa fa[fa]fa fa fa fa + 0x0ffb93f277b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0ffb93f277c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0ffb93f277d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0ffb93f277e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0ffb93f277f0: 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 + 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 +==6814==ABORTING + +How to reproduce: + +qemu-system-hppa -S -qtest stdio -accel qtest -display none < EOF +writeb 0xf8100081 0x40 +writeb 0xf81000c5 0x40 +writeb 0xf8100e44 0x2b +writeb 0xf8100e44 0x56 +writeb 0xf8100e44 0x10 +writeb 0xf8100600 0x0 +writeb 0xf8100821 0x21 +writeb 0xf8100b01 0x14 +writew 0xf8100044 0x1245 +writeb 0xf8100a0e 0x50 +writeb 0xf8100a02 0x49 +writeb 0xf8100821 0x0 +writew 0xf8100014 0x0 +writeb 0xf8100e46 0x46 +writeb 0xf8100052 0xe +writeb 0xf8100621 0x14 +writeb 0xf8100b01 0x14 +writew 0xf8100044 0x1241 +writeb 0xf8100b02 0x25 +writeb 0xf8100b01 0x4 +writeb 0xf8100e46 0xb0 +writeb 0xf8100b02 0x0 +writel 0xf81000c4 0x49494949 +writeb 0xf8100b02 0x10 +writew 0xf8100010 0x11 +writew 0xf8100044 0x1212 +writew 0xf8100044 0x1245 +writew 0xf8100050 0xe2a +writeb 0xf8100002 0x11 +writeb 0xf8100081 0xec +writeb 0xf8100081 0xec +writeb 0xf810030e 0xe +writeb 0xf810000e 0x44 +writeb 0xf8100000 0xe +writeb 0xf8100044 0xe +writeb 0xf8100000 0xe +writeb 0xf810030e 0x13 +writeb 0xf8100b44 0x2a +writeb 0xf8100bf8 0x4 +writeb 0xf8100007 0x45 +writeb 0xf81000ff 0xff +writew 0xf8100044 0xf042 +writew 0xf8100000 0x45 +writew 0xf8100044 0xf042 +writeb 0xf8100000 0xc5 +writeb 0xf81000ff 0xff +writel 0xf8100044 0x101364ff +writel 0xf81000c4 0xfba0a0a0 +writeb 0xf8100000 0x2a +writeb 0xf81000c5 0x40 +writeb 0xf81000ff 0xdf +writew 0xf8100000 0x4144 +writeb 0xf81000df 0x0 +writew 0xf8100044 0x4400 +writel 0xf8100044 0x101364ff +writel 0xf81000c4 0xfb490045 +writeb 0xf8100000 0x2a +writeb 0xf81000c5 0x40 +writel 0xf8100044 0x101364ff +writel 0xf8100bc4 0x49004545 +writeb 0xf8100000 0x2a +writeb 0xf81000c5 0x40 +writeb 0xf810000e 0x21 +writeb 0xf8100000 0x2a +writeb 0xf81000c3 0x40 +writeb 0xf81000ff 0xdf +writew 0xf8100044 0x1210 +writew 0xf8100044 0x1210 +writew 0xf8100010 0x4412 +writew 0xf8100010 0x4412 +writew 0xf8100044 0x1210 +writew 0xf8100044 0x1210 +writew 0xf8100044 0x1210 +writew 0xf8100000 0x4144 +writew 0xf8100044 0x4400 +writew 0xf8100000 0x4144 +writew 0xf81000bc 0xc100 +writew 0xf8100000 0x4144 +writew 0xf81000bc 0xc100 +writew 0xf8100044 0x1210 +writel 0xf8100044 0xfb53000a +writew 0xf8100044 0x1210 +writel 0xf8100044 0xfb53000a +writew 0xf8100044 0x1210 +writel 0xf8100044 0xfba7000a +writew 0xf8100044 0x1210 +writew 0xf8100044 0x1210 +writew 0xf8100000 0x4144 +writew 0xf8100000 0x4144 +writew 0xf8100000 0x4144 +writew 0xf8100044 0x4400 +writew 0xf8100044 0x4411 +writew 0xf8100044 0x1210 +writew 0xf8100044 0x1210 +writew 0xf8100044 0x1210 +writew 0xf8100044 0x1212 +writew 0xf8100044 0x4445 +writeb 0xf81000ff 0xff +writeb 0xf8100121 0x14 +writeb 0xf8100121 0x14 +writeb 0xf8100421 0x0 +writeb 0xf8100421 0x28 +writeb 0xf8100000 0x2a +writeb 0xf81000c5 0x40 +writeb 0xf8100040 0x0 +writeb 0xf8100007 0x45 +writeb 0xf8100007 0x45 +writeb 0xf8100bf8 0x4 +writeb 0xf8100bf8 0x4 +writeb 0xf8100bf8 0x4 +writeb 0xf8100bf8 0x4 +writeb 0xf8100bf8 0x4 +writew 0xf8100060 0x11 +writew 0xf8100060 0x11 +writew 0xf8100060 0x17 +writeb 0xf8100446 0x46 +writeb 0xf8100604 0x50 +writeb 0xf8100821 0x21 +writeb 0xf8100108 0x21 +writeb 0xf810010c 0x21 +writeb 0xf8100081 0xec +writeb 0xf8100041 0xec +writel 0xf8100044 0x101364ff +writel 0xf81000c4 0xfba0a0a0 +writel 0xf8100044 0x101364ff +writel 0xf81000c4 0xfba0a0a0 +writel 0xf8100044 0x101364ff +writel 0xf81000c4 0xfba0a0a0 +writeb 0xf8100052 0x24 +writew 0xf8100000 0x4144 +writeb 0xf81000df 0x0 +writew 0xf8100044 0x4400 +writew 0xf8100000 0x4144 +writeb 0xf81000df 0x41 +writeb 0xf8100504 0x50 +writew 0xf8100010 0x4412 +writew 0xf8100010 0x4412 +writew 0xf8100094 0x4145 +writel 0xf8100044 0x10424410 +writel 0xf81000a0 0xa0a0492a +writel 0xf8100044 0x10040000 +writeb 0xf8100007 0x44 +writeb 0xf81000ff 0xff +writeb 0xf8100007 0x44 +writeb 0xf81000ff 0x4 +writel 0xf8100044 0x10134900 +writeb 0xf8100000 0x2a +writeb 0xf81000c5 0x40 +writeb 0xf8100000 0x2a +writeb 0xf81000c5 0x40 +writew 0xf8100040 0x1212 +writew 0xf8100044 0x1245 +writew 0xf8100040 0x1212 +writew 0xf8100040 0x5002 +writew 0xf8100040 0x5002 +writew 0xf8100040 0x502a +writeb 0xf8100081 0x40 +writeb 0xf810005d 0x40 +writeb 0xf8100030 0x5d +writeb 0xf8100e44 0x44 +writeb 0xf8100044 0x3 +writeb 0xf8100044 0x3 +writeb 0xf8100044 0x13 +writew 0xf8100044 0x1210 +writew 0xf8100044 0x1210 +writew 0xf8100044 0x1210 +writew 0xf8100044 0x6d10 +writeb 0xf8100044 0x6d +writeb 0xf8100000 0x2a +writeb 0xf8100044 0x40 +writeb 0xf8100045 0xec +writew 0xf8100044 0x1210 +writew 0xf8100044 0x1245 +writel 0xf8100044 0x101364ff +writel 0xf81000c4 0xfba0a0a0 +writel 0xf8100044 0x101364ff +writel 0xf8100044 0x101364ff +writel 0xf8100044 0x101364ff +writel 0xf8100008 0xfba0a0a0 +writel 0xf8100044 0x4208fba0 +writew 0xf8100010 0x4412 +writew 0xf8100010 0x4412 +writew 0xf8100010 0x4412 +writew 0xf8100010 0x4412 +writew 0xf8100010 0x4412 +writew 0xf8100000 0x4144 +writeb 0xf810030e 0xe +writeb 0xf810030e 0xe +writeb 0xf810032b 0xe +writeb 0xf810032b 0xe +writew 0xf8100010 0x4412 +writew 0xf81000ca 0x4441 +writew 0xf8100010 0x4412 +writew 0xf8100010 0x4412 +writew 0xf8100010 0x4412 +writew 0xf8100010 0x4412 +writeb 0xf8100080 0xe +writeb 0xf8100080 0xd8 +writeb 0xf8100080 0x26 +writeb 0xf8100040 0x80 +writeb 0xf8100040 0x26 +writeb 0xf81000c3 0x40 +writeb 0xf81000ff 0xdf +writeb 0xf81000c3 0x40 +writeb 0xf81000ff 0xdf +writew 0xf8100014 0x4000 +writeb 0xf8100000 0xe +writeb 0xf8100000 0x9e +writeb 0xf8100000 0x3c +writeb 0xf8100000 0x3c +writeb 0xf8100000 0x3c +writew 0xf8100000 0x4144 +writeb 0xf81000df 0x41 +writeb 0xf8100007 0x45 +writeb 0xf81000ff 0xff +writeb 0xf8100007 0xb4 +writeb 0xf81000ff 0xff +writeb 0xf8100007 0xb4 +writeb 0xf8100007 0xb4 +writel 0xf8100044 0x10139c05 +writel 0xf81000c4 0xfba0a0a0 +writeb 0xf8100604 0x50 +writeb 0xf8100021 0xe +writeb 0xf8100021 0xe +writeb 0xf8100021 0xe +writeb 0xf8100021 0x90 +writew 0xf8100010 0x11 +writew 0xf8100010 0x11 +writew 0xf8100010 0x11 +writeb 0xf8100021 0xe +writeb 0xf8100021 0xe +writeb 0xf8100021 0xe +writeb 0xf8100021 0xe +writeb 0xf8100021 0xe +writew 0xf8100010 0x4412 +writew 0xf8100010 0x4412 +writew 0xf8100010 0x4412 +writew 0xf8100010 0x4412 +writew 0xf8100010 0x4412 +writeb 0xf8100021 0xe +writeb 0xf8100021 0xe +writeb 0xf8100021 0x21 +writeb 0xf8100021 0x21 +writeb 0xf8100000 0x0 +writeb 0xf8100e04 0x46 +EOF + +Program terminated with signal SIGSEGV, Segmentation fault. +#0 0x000056367b2085c0 in artist_rop8 (s=0x56367d38b510, dst=0x7f9f972fffff <error: Cannot access memory at address 0x7f9f972fffff>, val=0 '\000') at hw/display/artist.c:284 +284 *dst &= ~plane_mask; +(gdb) bt +#0 0x000056367b2085c0 in artist_rop8 (s=0x56367d38b510, dst=0x7f9f972fffff <error: Cannot access memory at address 0x7f9f972fffff>, val=0 '\000') at hw/display/artist.c:284 +#1 0x000056367b209325 in draw_line (s=0x56367d38b510, x1=-20480, y1=-1, x2=0, y2=17920, update_start=true, skip_pix=-1, max_pix=-1) at hw/display/artist.c:646 +#2 0x000056367b2095a0 in draw_line_size (s=0x56367d38b510, update_start=true) at hw/display/artist.c:696 +#3 0x000056367b20a214 in artist_reg_write (opaque=0x56367d38b510, addr=1052164, val=70, size=1) at hw/display/artist.c:932 +#4 0x000056367b06ea7c in memory_region_write_accessor (mr=0x56367d38ba10, addr=1052164, value=0x7fff112132d8, size=1, shift=0, mask=255, attrs=...) at memory.c:483 +#5 0x000056367b06ec33 in access_with_adjusted_size (addr=1052164, value=0x7fff112132d8, size=1, access_size_min=1, access_size_max=4, access_fn= + 0x56367b06e999 <memory_region_write_accessor>, mr=0x56367d38ba10, attrs=...) at memory.c:540 +#6 0x000056367b071bb4 in memory_region_dispatch_write (mr=0x56367d38ba10, addr=1052164, data=70, op=MO_8, attrs=...) at memory.c:1477 +#7 0x000056367b00fe33 in flatview_write_continue (fv=0x56367d6f9fa0, addr=4161801732, attrs=..., ptr=0x7fff112134e0, len=1, addr1=1052164, l=1, mr=0x56367d38ba10) at exec.c:3147 +#8 0x000056367b00ff81 in flatview_write (fv=0x56367d6f9fa0, addr=4161801732, attrs=..., buf=0x7fff112134e0, len=1) at exec.c:3190 +#9 0x000056367b0102eb in address_space_write (as=0x56367cff99c0, addr=4161801732, attrs=..., buf=0x7fff112134e0, len=1) at exec.c:3289 + +On 5/23/20 8:03 PM, Philippe Mathieu-Daudé wrote: +> Public bug reported: +> +> As of commit d19f1ab0, LLVM libFuzzer found: +> +> ================================================================= +> ==6814==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7fd89f97bd5a at pc 0x55dc44594db5 bp 0x7ffd6f461b40 sp 0x7ffd6f461b38 +> READ of size 1 at 0x7fd89f97bd5a thread T0 +> #0 0x55dc44594db4 in artist_rop8 +> #1 0x55dc44595fd9 in draw_line +> #2 0x55dc445937e4 in draw_line_size +> #3 0x55dc4458ee9d in artist_reg_write +> #4 0x55dc43f77ba7 in memory_region_write_accessor +> #5 0x55dc43f775b8 in access_with_adjusted_size +> #6 0x55dc43f762b3 in memory_region_dispatch_write +> #7 0x55dc43dbb322 in flatview_write_continue +> #8 0x55dc43dab2e2 in flatview_write +> #9 0x55dc43daae14 in address_space_write +> +> 0x7fd89f97bd5a is located 1122 bytes to the right of 16777464-byte region [0x7fd89e97b800,0x7fd89f97b8f8) +> allocated by thread T0 here: +> #0 0x55dc43d87abf in operator new(unsigned long) +> #1 0x55dc43c4274d in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) +> #2 0x55dc43c3a526 in main (qemu-fuzz-hppa+0x982526) +> #3 0x7fd8d05edf42 in __libc_start_main (/lib64/libc.so.6+0x23f42) +> +> SUMMARY: AddressSanitizer: heap-buffer-overflow (qemu-fuzz-hppa+0x12dcdb4) in artist_rop8 +> Shadow bytes around the buggy address: +> 0x0ffb93f27750: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa +> 0x0ffb93f27760: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa +> 0x0ffb93f27770: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa +> 0x0ffb93f27780: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa +> 0x0ffb93f27790: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa +> =>0x0ffb93f277a0: fa fa fa fa fa fa fa fa fa fa fa[fa]fa fa fa fa +> 0x0ffb93f277b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa +> 0x0ffb93f277c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa +> 0x0ffb93f277d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa +> 0x0ffb93f277e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa +> 0x0ffb93f277f0: 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 +> 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 +> ==6814==ABORTING +> +> How to reproduce: +> +> qemu-system-hppa -S -qtest stdio -accel qtest -display none < EOF +> writeb 0xf8100081 0x40 +> writeb 0xf81000c5 0x40 +> writeb 0xf8100e44 0x2b +> writeb 0xf8100e44 0x56 +> writeb 0xf8100e44 0x10 +> writeb 0xf8100600 0x0 +> writeb 0xf8100821 0x21 +> writeb 0xf8100b01 0x14 +> writew 0xf8100044 0x1245 +> writeb 0xf8100a0e 0x50 +> writeb 0xf8100a02 0x49 +> writeb 0xf8100821 0x0 +> writew 0xf8100014 0x0 +> writeb 0xf8100e46 0x46 +> writeb 0xf8100052 0xe +> writeb 0xf8100621 0x14 +> writeb 0xf8100b01 0x14 +> writew 0xf8100044 0x1241 +> writeb 0xf8100b02 0x25 +> writeb 0xf8100b01 0x4 +> writeb 0xf8100e46 0xb0 +> writeb 0xf8100b02 0x0 +> writel 0xf81000c4 0x49494949 +> writeb 0xf8100b02 0x10 +> writew 0xf8100010 0x11 +> writew 0xf8100044 0x1212 +> writew 0xf8100044 0x1245 +> writew 0xf8100050 0xe2a +> writeb 0xf8100002 0x11 +> writeb 0xf8100081 0xec +> writeb 0xf8100081 0xec +> writeb 0xf810030e 0xe +> writeb 0xf810000e 0x44 +> writeb 0xf8100000 0xe +> writeb 0xf8100044 0xe +> writeb 0xf8100000 0xe +> writeb 0xf810030e 0x13 +> writeb 0xf8100b44 0x2a +> writeb 0xf8100bf8 0x4 +> writeb 0xf8100007 0x45 +> writeb 0xf81000ff 0xff +> writew 0xf8100044 0xf042 +> writew 0xf8100000 0x45 +> writew 0xf8100044 0xf042 +> writeb 0xf8100000 0xc5 +> writeb 0xf81000ff 0xff +> writel 0xf8100044 0x101364ff +> writel 0xf81000c4 0xfba0a0a0 +> writeb 0xf8100000 0x2a +> writeb 0xf81000c5 0x40 +> writeb 0xf81000ff 0xdf +> writew 0xf8100000 0x4144 +> writeb 0xf81000df 0x0 +> writew 0xf8100044 0x4400 +> writel 0xf8100044 0x101364ff +> writel 0xf81000c4 0xfb490045 +> writeb 0xf8100000 0x2a +> writeb 0xf81000c5 0x40 +> writel 0xf8100044 0x101364ff +> writel 0xf8100bc4 0x49004545 +> writeb 0xf8100000 0x2a +> writeb 0xf81000c5 0x40 +> writeb 0xf810000e 0x21 +> writeb 0xf8100000 0x2a +> writeb 0xf81000c3 0x40 +> writeb 0xf81000ff 0xdf +> writew 0xf8100044 0x1210 +> writew 0xf8100044 0x1210 +> writew 0xf8100010 0x4412 +> writew 0xf8100010 0x4412 +> writew 0xf8100044 0x1210 +> writew 0xf8100044 0x1210 +> writew 0xf8100044 0x1210 +> writew 0xf8100000 0x4144 +> writew 0xf8100044 0x4400 +> writew 0xf8100000 0x4144 +> writew 0xf81000bc 0xc100 +> writew 0xf8100000 0x4144 +> writew 0xf81000bc 0xc100 +> writew 0xf8100044 0x1210 +> writel 0xf8100044 0xfb53000a +> writew 0xf8100044 0x1210 +> writel 0xf8100044 0xfb53000a +> writew 0xf8100044 0x1210 +> writel 0xf8100044 0xfba7000a +> writew 0xf8100044 0x1210 +> writew 0xf8100044 0x1210 +> writew 0xf8100000 0x4144 +> writew 0xf8100000 0x4144 +> writew 0xf8100000 0x4144 +> writew 0xf8100044 0x4400 +> writew 0xf8100044 0x4411 +> writew 0xf8100044 0x1210 +> writew 0xf8100044 0x1210 +> writew 0xf8100044 0x1210 +> writew 0xf8100044 0x1212 +> writew 0xf8100044 0x4445 +> writeb 0xf81000ff 0xff +> writeb 0xf8100121 0x14 +> writeb 0xf8100121 0x14 +> writeb 0xf8100421 0x0 +> writeb 0xf8100421 0x28 +> writeb 0xf8100000 0x2a +> writeb 0xf81000c5 0x40 +> writeb 0xf8100040 0x0 +> writeb 0xf8100007 0x45 +> writeb 0xf8100007 0x45 +> writeb 0xf8100bf8 0x4 +> writeb 0xf8100bf8 0x4 +> writeb 0xf8100bf8 0x4 +> writeb 0xf8100bf8 0x4 +> writeb 0xf8100bf8 0x4 +> writew 0xf8100060 0x11 +> writew 0xf8100060 0x11 +> writew 0xf8100060 0x17 +> writeb 0xf8100446 0x46 +> writeb 0xf8100604 0x50 +> writeb 0xf8100821 0x21 +> writeb 0xf8100108 0x21 +> writeb 0xf810010c 0x21 +> writeb 0xf8100081 0xec +> writeb 0xf8100041 0xec +> writel 0xf8100044 0x101364ff +> writel 0xf81000c4 0xfba0a0a0 +> writel 0xf8100044 0x101364ff +> writel 0xf81000c4 0xfba0a0a0 +> writel 0xf8100044 0x101364ff +> writel 0xf81000c4 0xfba0a0a0 +> writeb 0xf8100052 0x24 +> writew 0xf8100000 0x4144 +> writeb 0xf81000df 0x0 +> writew 0xf8100044 0x4400 +> writew 0xf8100000 0x4144 +> writeb 0xf81000df 0x41 +> writeb 0xf8100504 0x50 +> writew 0xf8100010 0x4412 +> writew 0xf8100010 0x4412 +> writew 0xf8100094 0x4145 +> writel 0xf8100044 0x10424410 +> writel 0xf81000a0 0xa0a0492a +> writel 0xf8100044 0x10040000 +> writeb 0xf8100007 0x44 +> writeb 0xf81000ff 0xff +> writeb 0xf8100007 0x44 +> writeb 0xf81000ff 0x4 +> writel 0xf8100044 0x10134900 +> writeb 0xf8100000 0x2a +> writeb 0xf81000c5 0x40 +> writeb 0xf8100000 0x2a +> writeb 0xf81000c5 0x40 +> writew 0xf8100040 0x1212 +> writew 0xf8100044 0x1245 +> writew 0xf8100040 0x1212 +> writew 0xf8100040 0x5002 +> writew 0xf8100040 0x5002 +> writew 0xf8100040 0x502a +> writeb 0xf8100081 0x40 +> writeb 0xf810005d 0x40 +> writeb 0xf8100030 0x5d +> writeb 0xf8100e44 0x44 +> writeb 0xf8100044 0x3 +> writeb 0xf8100044 0x3 +> writeb 0xf8100044 0x13 +> writew 0xf8100044 0x1210 +> writew 0xf8100044 0x1210 +> writew 0xf8100044 0x1210 +> writew 0xf8100044 0x6d10 +> writeb 0xf8100044 0x6d +> writeb 0xf8100000 0x2a +> writeb 0xf8100044 0x40 +> writeb 0xf8100045 0xec +> writew 0xf8100044 0x1210 +> writew 0xf8100044 0x1245 +> writel 0xf8100044 0x101364ff +> writel 0xf81000c4 0xfba0a0a0 +> writel 0xf8100044 0x101364ff +> writel 0xf8100044 0x101364ff +> writel 0xf8100044 0x101364ff +> writel 0xf8100008 0xfba0a0a0 +> writel 0xf8100044 0x4208fba0 +> writew 0xf8100010 0x4412 +> writew 0xf8100010 0x4412 +> writew 0xf8100010 0x4412 +> writew 0xf8100010 0x4412 +> writew 0xf8100010 0x4412 +> writew 0xf8100000 0x4144 +> writeb 0xf810030e 0xe +> writeb 0xf810030e 0xe +> writeb 0xf810032b 0xe +> writeb 0xf810032b 0xe +> writew 0xf8100010 0x4412 +> writew 0xf81000ca 0x4441 +> writew 0xf8100010 0x4412 +> writew 0xf8100010 0x4412 +> writew 0xf8100010 0x4412 +> writew 0xf8100010 0x4412 +> writeb 0xf8100080 0xe +> writeb 0xf8100080 0xd8 +> writeb 0xf8100080 0x26 +> writeb 0xf8100040 0x80 +> writeb 0xf8100040 0x26 +> writeb 0xf81000c3 0x40 +> writeb 0xf81000ff 0xdf +> writeb 0xf81000c3 0x40 +> writeb 0xf81000ff 0xdf +> writew 0xf8100014 0x4000 +> writeb 0xf8100000 0xe +> writeb 0xf8100000 0x9e +> writeb 0xf8100000 0x3c +> writeb 0xf8100000 0x3c +> writeb 0xf8100000 0x3c +> writew 0xf8100000 0x4144 +> writeb 0xf81000df 0x41 +> writeb 0xf8100007 0x45 +> writeb 0xf81000ff 0xff +> writeb 0xf8100007 0xb4 +> writeb 0xf81000ff 0xff +> writeb 0xf8100007 0xb4 +> writeb 0xf8100007 0xb4 +> writel 0xf8100044 0x10139c05 +> writel 0xf81000c4 0xfba0a0a0 +> writeb 0xf8100604 0x50 +> writeb 0xf8100021 0xe +> writeb 0xf8100021 0xe +> writeb 0xf8100021 0xe +> writeb 0xf8100021 0x90 +> writew 0xf8100010 0x11 +> writew 0xf8100010 0x11 +> writew 0xf8100010 0x11 +> writeb 0xf8100021 0xe +> writeb 0xf8100021 0xe +> writeb 0xf8100021 0xe +> writeb 0xf8100021 0xe +> writeb 0xf8100021 0xe +> writew 0xf8100010 0x4412 +> writew 0xf8100010 0x4412 +> writew 0xf8100010 0x4412 +> writew 0xf8100010 0x4412 +> writew 0xf8100010 0x4412 +> writeb 0xf8100021 0xe +> writeb 0xf8100021 0xe +> writeb 0xf8100021 0x21 +> writeb 0xf8100021 0x21 +> writeb 0xf8100000 0x0 +> writeb 0xf8100e04 0x46 +> EOF +> +> Program terminated with signal SIGSEGV, Segmentation fault. +> #0 0x000056367b2085c0 in artist_rop8 (s=0x56367d38b510, dst=0x7f9f972fffff <error: Cannot access memory at address 0x7f9f972fffff>, val=0 '\000') at hw/display/artist.c:284 +> 284 *dst &= ~plane_mask; +> (gdb) bt +> #0 0x000056367b2085c0 in artist_rop8 (s=0x56367d38b510, dst=0x7f9f972fffff <error: Cannot access memory at address 0x7f9f972fffff>, val=0 '\000') at hw/display/artist.c:284 +> #1 0x000056367b209325 in draw_line (s=0x56367d38b510, x1=-20480, y1=-1, x2=0, y2=17920, update_start=true, skip_pix=-1, max_pix=-1) at hw/display/artist.c:646 +> #2 0x000056367b2095a0 in draw_line_size (s=0x56367d38b510, update_start=true) at hw/display/artist.c:696 +> #3 0x000056367b20a214 in artist_reg_write (opaque=0x56367d38b510, addr=1052164, val=70, size=1) at hw/display/artist.c:932 +> #4 0x000056367b06ea7c in memory_region_write_accessor (mr=0x56367d38ba10, addr=1052164, value=0x7fff112132d8, size=1, shift=0, mask=255, attrs=...) at memory.c:483 +> #5 0x000056367b06ec33 in access_with_adjusted_size (addr=1052164, value=0x7fff112132d8, size=1, access_size_min=1, access_size_max=4, access_fn= +> 0x56367b06e999 <memory_region_write_accessor>, mr=0x56367d38ba10, attrs=...) at memory.c:540 +> #6 0x000056367b071bb4 in memory_region_dispatch_write (mr=0x56367d38ba10, addr=1052164, data=70, op=MO_8, attrs=...) at memory.c:1477 +> #7 0x000056367b00fe33 in flatview_write_continue (fv=0x56367d6f9fa0, addr=4161801732, attrs=..., ptr=0x7fff112134e0, len=1, addr1=1052164, l=1, mr=0x56367d38ba10) at exec.c:3147 +> #8 0x000056367b00ff81 in flatview_write (fv=0x56367d6f9fa0, addr=4161801732, attrs=..., buf=0x7fff112134e0, len=1) at exec.c:3190 +> #9 0x000056367b0102eb in address_space_write (as=0x56367cff99c0, addr=4161801732, attrs=..., buf=0x7fff112134e0, len=1) at exec.c:3289 +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> + +The crash is avoided using this patch: +-- >8 -- +diff --git a/hw/display/artist.c b/hw/display/artist.c +index 6e17c43f13..fcfd67da47 100644 +--- a/hw/display/artist.c ++++ b/hw/display/artist.c +@@ -563,7 +563,7 @@ static void fill_window(ARTISTState *s, int startx, +int starty, + static void draw_line(ARTISTState *s, int x1, int y1, int x2, int y2, + bool update_start, int skip_pix, int max_pix) + { +- struct vram_buffer *buf; ++ struct vram_buffer *buf = &s->vram_buffer[ARTIST_BUFFER_AP]; + uint8_t color; + int dx, dy, t, e, x, y, incy, diago, horiz; + bool c1; +@@ -571,6 +571,12 @@ static void draw_line(ARTISTState *s, int x1, int +y1, int x2, int y2, + + trace_artist_draw_line(x1, y1, x2, y2); + ++ if (x1 * y1 >= buf->size || x2 * y2 >= buf->size) { ++ qemu_log_mask(LOG_GUEST_ERROR, ++ "draw line (%d,%d) (%d,%d)\n", x1, y1, x2, y2); ++ return; ++ } ++ + if (update_start) { + s->vram_start = (x2 << 16) | y2; + } +@@ -628,7 +634,6 @@ static void draw_line(ARTISTState *s, int x1, int +y1, int x2, int y2, + x = x1; + y = y1; + color = artist_get_color(s); +- buf = &s->vram_buffer[ARTIST_BUFFER_AP]; + + do { + if (c1) { +--- + +I am not sure this is the best fix, IMO the invalid value should be +reported earlier. + + +Fixed in commits 84a7b7741a62ede8ff01ae151e59b2a16bda629b and a501bfc91763d4642390090dd4e6039d67b63702 + diff --git a/results/classifier/108/other/1880332 b/results/classifier/108/other/1880332 new file mode 100644 index 00000000..5e2cabd9 --- /dev/null +++ b/results/classifier/108/other/1880332 @@ -0,0 +1,52 @@ +other: 0.855 +graphic: 0.843 +permissions: 0.714 +device: 0.705 +performance: 0.667 +socket: 0.667 +network: 0.662 +PID: 0.660 +debug: 0.617 +files: 0.563 +vnc: 0.516 +semantic: 0.508 +boot: 0.465 +KVM: 0.401 + +Possible regression in QEMU 5.0.0 after CVE-2020-10702 (segmentation fault) + +I've come across a very specific situation, but I'm sure it could be replicated in other cases. + +In QEMU 5.0.0 when I use user emulation with a cURL binary for aarch64 and connect to a server using TLS 1.2 and ECDHE-ECDSA-CHACHA20-POLY1305 cypher a segmentation fault occurs. + +I attach a Dockerfile that reproduces this crash and the strace output with and without the de0b1bae6461f67243282555475f88b2384a1eb9 commit reverted. + + + +This is a compiler bug affecting (at least) libcrypto.so.1.1: + + 179d90: d503233f paciasp + 179d94: a9bb7bfd stp x29, x30, [sp, #-80]! +... + 17a400: d50323bf autiasp + 17a404: f84507fd ldr x29, [sp], #80 + 17a408: d65f03c0 ret + +The PAC happens with the initial sp: + + X30=0000005501de55fc SP=00000055018477a0 + +while the AUTH happens with the decremented sp: + + X30=0011005501de55fc SP=0000005501847750 + +Since the salt (sp) is different for the two operations, the +authorization should and does fail: + + X30=0020005501de55fc + +Note bit 53 is now set in x30, which is the error indication. + +The compiler must move the authiasp down below the ldr pop. + + diff --git a/results/classifier/108/other/1880355 b/results/classifier/108/other/1880355 new file mode 100644 index 00000000..49abb473 --- /dev/null +++ b/results/classifier/108/other/1880355 @@ -0,0 +1,150 @@ +KVM: 0.651 +other: 0.633 +vnc: 0.627 +permissions: 0.607 +graphic: 0.595 +device: 0.566 +semantic: 0.565 +performance: 0.563 +debug: 0.557 +files: 0.549 +PID: 0.546 +socket: 0.533 +boot: 0.530 +network: 0.515 + +Length restrictions for fw_cfg_dma_transfer? + +For me, this takes close to 3 minutes at 100% CPU: +echo "outl 0x518 0x9596ffff" | ./i386-softmmu/qemu-system-i386 -M q35 -m 32 -nographic -accel qtest -monitor none -serial none -qtest stdio + +#0 phys_page_find (d=0x606000035d80, addr=136728041144404) at /exec.c:338 +#1 address_space_lookup_region (d=0x606000035d80, addr=136728041144404, resolve_subpage=true) at /exec.c:363 +#2 address_space_translate_internal (d=0x606000035d80, addr=136728041144404, xlat=0x7fff1fc0d070, plen=0x7fff1fc0d090, resolve_subpage=true) at /exec.c:382 +#3 flatview_do_translate (fv=0x606000035d20, addr=136728041144404, xlat=0x7fff1fc0d070, plen_out=0x7fff1fc0d090, page_mask_out=0x0, is_write=true, is_mmio=true, target_as=0x7fff1fc0ce10, attrs=...) + pment/qemu/exec.c:520 +#4 flatview_translate (fv=0x606000035d20, addr=136728041144404, xlat=0x7fff1fc0d070, plen=0x7fff1fc0d090, is_write=true, attrs=...) at /exec.c:586 +#5 flatview_write_continue (fv=0x606000035d20, addr=136728041144404, attrs=..., ptr=0x7fff1fc0d660, len=172, addr1=136728041144400, l=172, mr=0x557fd54e77e0 <io_mem_unassigned>) + pment/qemu/exec.c:3160 +#6 flatview_write (fv=0x606000035d20, addr=136728041144064, attrs=..., buf=0x7fff1fc0d660, len=512) at /exec.c:3177 +#7 address_space_write (as=0x557fd54e7a00 <address_space_memory>, addr=136728041144064, attrs=..., buf=0x7fff1fc0d660, len=512) at /exec.c:3271 +#8 dma_memory_set (as=0x557fd54e7a00 <address_space_memory>, addr=136728041144064, c=0 '\000', len=1378422272) at /dma-helpers.c:31 +#9 fw_cfg_dma_transfer (s=0x61a000001e80) at /hw/nvram/fw_cfg.c:400 +#10 fw_cfg_dma_mem_write (opaque=0x61a000001e80, addr=4, value=4294940309, size=4) at /hw/nvram/fw_cfg.c:467 +#11 memory_region_write_accessor (mr=0x61a000002200, addr=4, value=0x7fff1fc0e3d0, size=4, shift=0, mask=4294967295, attrs=...) at /memory.c:483 +#12 access_with_adjusted_size (addr=4, value=0x7fff1fc0e3d0, size=4, access_size_min=1, access_size_max=8, access_fn=0x557fd2288c80 <memory_region_write_accessor>, mr=0x61a000002200, attrs=...) + pment/qemu/memory.c:539 +#13 memory_region_dispatch_write (mr=0x61a000002200, addr=4, data=4294940309, op=MO_32, attrs=...) at /memory.c:1476 +#14 flatview_write_continue (fv=0x606000035f00, addr=1304, attrs=..., ptr=0x7fff1fc0ec40, len=4, addr1=4, l=4, mr=0x61a000002200) at /exec.c:3137 +#15 flatview_write (fv=0x606000035f00, addr=1304, attrs=..., buf=0x7fff1fc0ec40, len=4) at /exec.c:3177 +#16 address_space_write (as=0x557fd54e7bc0 <address_space_io>, addr=1304, attrs=..., buf=0x7fff1fc0ec40, len=4) at /exec.c:3271 + + +It looks like fw_cfg_dma_transfer gets the address(136728041144064) and length(1378422272) for the read from the value provided as input 4294940309 (0xFFFF9695) which lands in pcbios. Should there be any limits on the length of guest-memory that fw_cfg should populate? +Found by libfuzzer + +On 5/24/20 6:12 AM, Alexander Bulekov wrote: +> Public bug reported: +> +> For me, this takes close to 3 minutes at 100% CPU: +> echo "outl 0x518 0x9596ffff" | ./i386-softmmu/qemu-system-i386 -M q35 -m 32 -nographic -accel qtest -monitor none -serial none -qtest stdio +> +> #0 phys_page_find (d=0x606000035d80, addr=136728041144404) at /exec.c:338 +> #1 address_space_lookup_region (d=0x606000035d80, addr=136728041144404, resolve_subpage=true) at /exec.c:363 +> #2 address_space_translate_internal (d=0x606000035d80, addr=136728041144404, xlat=0x7fff1fc0d070, plen=0x7fff1fc0d090, resolve_subpage=true) at /exec.c:382 +> #3 flatview_do_translate (fv=0x606000035d20, addr=136728041144404, xlat=0x7fff1fc0d070, plen_out=0x7fff1fc0d090, page_mask_out=0x0, is_write=true, is_mmio=true, target_as=0x7fff1fc0ce10, attrs=...) +> pment/qemu/exec.c:520 +> #4 flatview_translate (fv=0x606000035d20, addr=136728041144404, xlat=0x7fff1fc0d070, plen=0x7fff1fc0d090, is_write=true, attrs=...) at /exec.c:586 +> #5 flatview_write_continue (fv=0x606000035d20, addr=136728041144404, attrs=..., ptr=0x7fff1fc0d660, len=172, addr1=136728041144400, l=172, mr=0x557fd54e77e0 <io_mem_unassigned>) +> pment/qemu/exec.c:3160 +> #6 flatview_write (fv=0x606000035d20, addr=136728041144064, attrs=..., buf=0x7fff1fc0d660, len=512) at /exec.c:3177 +> #7 address_space_write (as=0x557fd54e7a00 <address_space_memory>, addr=136728041144064, attrs=..., buf=0x7fff1fc0d660, len=512) at /exec.c:3271 +> #8 dma_memory_set (as=0x557fd54e7a00 <address_space_memory>, addr=136728041144064, c=0 '\000', len=1378422272) at /dma-helpers.c:31 +> #9 fw_cfg_dma_transfer (s=0x61a000001e80) at /hw/nvram/fw_cfg.c:400 +> #10 fw_cfg_dma_mem_write (opaque=0x61a000001e80, addr=4, value=4294940309, size=4) at /hw/nvram/fw_cfg.c:467 +> #11 memory_region_write_accessor (mr=0x61a000002200, addr=4, value=0x7fff1fc0e3d0, size=4, shift=0, mask=4294967295, attrs=...) at /memory.c:483 +> #12 access_with_adjusted_size (addr=4, value=0x7fff1fc0e3d0, size=4, access_size_min=1, access_size_max=8, access_fn=0x557fd2288c80 <memory_region_write_accessor>, mr=0x61a000002200, attrs=...) +> pment/qemu/memory.c:539 +> #13 memory_region_dispatch_write (mr=0x61a000002200, addr=4, data=4294940309, op=MO_32, attrs=...) at /memory.c:1476 +> #14 flatview_write_continue (fv=0x606000035f00, addr=1304, attrs=..., ptr=0x7fff1fc0ec40, len=4, addr1=4, l=4, mr=0x61a000002200) at /exec.c:3137 +> #15 flatview_write (fv=0x606000035f00, addr=1304, attrs=..., buf=0x7fff1fc0ec40, len=4) at /exec.c:3177 +> #16 address_space_write (as=0x557fd54e7bc0 <address_space_io>, addr=1304, attrs=..., buf=0x7fff1fc0ec40, len=4) at /exec.c:3271 +> +> +> It looks like fw_cfg_dma_transfer gets the address(136728041144064) and length(1378422272) for the read from the value provided as input 4294940309 (0xFFFF9695) which lands in pcbios. Should there be any limits on the length of guest-memory that fw_cfg should populate? + +It looks to me a normal behavior for a DMA device. DMA devices have a +different address space view than the CPUs. +Also note the fw_cfg is a generic device, not restricted to the x86 arch. + +Maybe this function could use dma_memory_valid() to skip unassigned regions? + + + +On Sun, 24 May 2020 at 11:30, Philippe Mathieu-Daudé <email address hidden> wrote: +> It looks to me a normal behavior for a DMA device. DMA devices have a +> different address space view than the CPUs. +> Also note the fw_cfg is a generic device, not restricted to the x86 arch. + +In an ideal world all our DMA devices would use some kind of common +framework or design pattern so they didn't hog all the CPU +and/or spend minutes with the BQL held if the guest requests +an enormous-sized DMA. In practice many of them just have +a simple "loop until the DMA transfer is complete" implementation... + +thanks +-- PMM + + +On 5/24/20 3:40 PM, Peter Maydell wrote: +> On Sun, 24 May 2020 at 11:30, Philippe Mathieu-Daudé <email address hidden> wrote: +>> It looks to me a normal behavior for a DMA device. DMA devices have a +>> different address space view than the CPUs. +>> Also note the fw_cfg is a generic device, not restricted to the x86 arch. +> +> In an ideal world all our DMA devices would use some kind of common +> framework or design pattern so they didn't hog all the CPU +> and/or spend minutes with the BQL held if the guest requests +> an enormous-sized DMA. In practice many of them just have +> a simple "loop until the DMA transfer is complete" implementation... + +Is this framework already implemented in the hidden dma-helpers.c? + +Apparently this file was written for BlockBackend, but the code seems +rather generic. + + + +On 24/05/2020 14:40, Peter Maydell wrote: + +> On Sun, 24 May 2020 at 11:30, Philippe Mathieu-Daudé <email address hidden> wrote: +>> It looks to me a normal behavior for a DMA device. DMA devices have a +>> different address space view than the CPUs. +>> Also note the fw_cfg is a generic device, not restricted to the x86 arch. +> +> In an ideal world all our DMA devices would use some kind of common +> framework or design pattern so they didn't hog all the CPU +> and/or spend minutes with the BQL held if the guest requests +> an enormous-sized DMA. In practice many of them just have +> a simple "loop until the DMA transfer is complete" implementation... + +One of the problems with the PPC Mac DBDMA emulation is that the controller is +effectively a mini-CPU that runs its own programs for transferring data to/from memory. + +Currently this is done as a QEMU BH which means for larger transfers the emulated CPU +can be paused for a not insignificant amount of time until the program performing the +transfer finishes. I've always wondered if this should be running in a separate +thread to reduce its impact. + + +ATB, + +Mark. + + +Can you still reproduce this problem with the current git version of QEMU? ... for me, the command now returns immediately. + +This no longer causes timeout/excessive CPU usage for me. Probably fixed + +Ok, thanks for checking! Closing now. + diff --git a/results/classifier/108/other/1880424 b/results/classifier/108/other/1880424 new file mode 100644 index 00000000..65357919 --- /dev/null +++ b/results/classifier/108/other/1880424 @@ -0,0 +1,61 @@ +permissions: 0.918 +other: 0.899 +graphic: 0.894 +performance: 0.891 +device: 0.889 +vnc: 0.885 +files: 0.883 +semantic: 0.880 +KVM: 0.876 +socket: 0.873 +debug: 0.872 +boot: 0.858 +network: 0.852 +PID: 0.842 + +I/O write make imx_epit_reset() crash + +libFuzzer found: + +qemu-fuzz-arm: hw/core/ptimer.c:377: void ptimer_transaction_begin(ptimer_state *): Assertion `!s->in_transaction' failed. +==6041== ERROR: libFuzzer: deadly signal + #8 0x7fcaba320565 in __GI___assert_fail (/lib64/libc.so.6+0x30565) + #9 0x563b46f91637 in ptimer_transaction_begin (qemu-fuzz-arm+0x1af1637) + #10 0x563b476cc4c6 in imx_epit_reset (qemu-fuzz-arm+0x222c4c6) + #11 0x563b476cd004 in imx_epit_write (qemu-fuzz-arm+0x222d004) + #12 0x563b46582377 in memory_region_write_accessor (qemu-fuzz-arm+0x10e2377) + #13 0x563b46581ee3 in access_with_adjusted_size (qemu-fuzz-arm+0x10e1ee3) + #14 0x563b46580a83 in memory_region_dispatch_write (qemu-fuzz-arm+0x10e0a83) + #15 0x563b463c5022 in flatview_write_continue (qemu-fuzz-arm+0xf25022) + #16 0x563b463b4ea2 in flatview_write (qemu-fuzz-arm+0xf14ea2) + #17 0x563b463b49d4 in address_space_write (qemu-fuzz-arm+0xf149d4) + +Reproducer: + +qemu-system-arm -M kzm -display none -S -qtest stdio << 'EOF' +writel 0x53f94000 0x110000 +EOF + +qemu-system-arm: hw/core/ptimer.c:377: ptimer_transaction_begin: Assertion `!s->in_transaction' failed. +Aborted (core dumped) + +(gdb) bt +#1 0x00007f4aa4daa895 in abort () at /lib64/libc.so.6 +#2 0x00007f4aa4daa769 in _nl_load_domain.cold () at /lib64/libc.so.6 +#3 0x00007f4aa4db8566 in annobin_assert.c_end () at /lib64/libc.so.6 +#4 0x000055ee85400164 in ptimer_transaction_begin (s=0x55ee873bc4c0) at hw/core/ptimer.c:377 +#5 0x000055ee855c7936 in imx_epit_reset (dev=0x55ee871725c0) at hw/timer/imx_epit.c:111 +#6 0x000055ee855c7d1b in imx_epit_write (opaque=0x55ee871725c0, offset=0, value=1114112, size=4) at hw/timer/imx_epit.c:209 +#7 0x000055ee8513db85 in memory_region_write_accessor (mr=0x55ee871728f0, addr=0, value=0x7fff3012d6f8, size=4, shift=0, mask=4294967295, attrs=...) at memory.c:483 +#8 0x000055ee8513dd96 in access_with_adjusted_size (addr=0, value=0x7fff3012d6f8, size=4, access_size_min=1, access_size_max=4, access_fn= + 0x55ee8513daa2 <memory_region_write_accessor>, mr=0x55ee871728f0, attrs=...) at memory.c:545 +#9 0x000055ee85140cbd in memory_region_dispatch_write (mr=0x55ee871728f0, addr=0, data=1114112, op=MO_32, attrs=...) at memory.c:1477 +#10 0x000055ee850deba5 in flatview_write_continue (fv=0x55ee87181bd0, addr=1408843776, attrs=..., ptr=0x7fff3012d900, len=4, addr1=0, l=4, mr=0x55ee871728f0) at exec.c:3147 +#11 0x000055ee850decf3 in flatview_write (fv=0x55ee87181bd0, addr=1408843776, attrs=..., buf=0x7fff3012d900, len=4) at exec.c:3190 +#12 0x000055ee850df05d in address_space_write (as=0x55ee8730a560, addr=1408843776, attrs=..., buf=0x7fff3012d900, len=4) at exec.c:3289 + +Patch on list: https://<email address hidden>/ + +Patch has been included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=13557fd392890cbd985 + diff --git a/results/classifier/108/other/1880518 b/results/classifier/108/other/1880518 new file mode 100644 index 00000000..a2b904f9 --- /dev/null +++ b/results/classifier/108/other/1880518 @@ -0,0 +1,98 @@ +other: 0.876 +permissions: 0.864 +vnc: 0.813 +graphic: 0.812 +files: 0.795 +semantic: 0.792 +debug: 0.777 +performance: 0.774 +PID: 0.774 +KVM: 0.772 +device: 0.772 +socket: 0.764 +boot: 0.741 +network: 0.721 + +issue while installing docker inside s390x container + +This is in reference to https://github.com/multiarch/qemu-user-static/issues/108. +I am facing issue while installing docker inside s390x container under qemu on Ubuntu 18.04 host running on amd64. +Following are the contents of /proc/sys/fs/binfmt_misc/qemu-s390x on Intel host after running +docker run --rm --privileged multiarch/qemu-user-static --reset -p yes +enabled +interpreter /usr/bin/qemu-s390x-static +flags: F +offset 0 +magic 7f454c4602020100000000000000000000020016 +mask ffffffffffffff00fffffffffffffffffffeffff +I could get docker service up with the following trick. +printf '{"iptables": false,"ip-masq": false,"bridge": "none" }' > /etc/docker/daemon.json +But even though docker service comes up, images are not getting pulled, docker pull fails with the following error. +failed to register layer: Error processing tar file(exit status 1): + +Without a more detailled error message we can'know what happens. + +What I see is you don't have the 'OC' flags that should help to execute binaries with (s) bit. + +You should also report the version of qemu. + +The error message that I posted above is all that I see when I go to pull and image. +Following is the log from docker daemon + +time="2020-05-26T07:34:31.385796553Z" level=info msg="API listen on /var/run/docker.sock" +time="2020-05-26T07:34:34.607431981Z" level=debug msg="Calling GET /_ping" +time="2020-05-26T07:34:34.635096021Z" level=debug msg="Calling GET /v1.38/containers/json" +time="2020-05-26T07:34:43.919894850Z" level=debug msg="Calling GET /_ping" +time="2020-05-26T07:34:43.963634642Z" level=debug msg="Calling GET /v1.38/info" +time="2020-05-26T07:34:44.702451808Z" level=debug msg="Calling POST /v1.38/images/create?fromImage=hello-world&tag=latest" +time="2020-05-26T07:34:44.715857621Z" level=debug msg="Trying to pull hello-world from https://registry-1.docker.io v2" +time="2020-05-26T07:34:46.805807639Z" level=debug msg="Pulling ref from V2 registry: hello-world:latest" +time="2020-05-26T07:34:46.806872106Z" level=debug msg="docker.io/library/hello-world:latest resolved to a manifestList object with 9 entries; looking for a unknown/s390x match" +time="2020-05-26T07:34:46.808815074Z" level=debug msg="found match for linux/s390x with media type application/vnd.docker.distribution.manifest.v2+json, digest sha256:e49abad529e5d9bd6787f3abeab94e09ba274fe34731349556a850b9aebbf7bf" +time="2020-05-26T07:34:47.233545931Z" level=debug msg="pulling blob \"sha256:3c80930bfdd5b53b7ca2a6b8116ed9a273af43a6b2dd13e81e82aae7521be469\"" +time="2020-05-26T07:34:47.864739182Z" level=debug msg="Downloaded 3c80930bfdd5 to tempfile /var/lib/docker/tmp/GetImageBlob114078888" +time="2020-05-26T07:34:48.038875327Z" level=debug msg="Cleaning up layer b3da5d545c61d65059a2190feb19ae13797338ee999542b615e93e9708b88507: Error processing tar file(exit status 1): " +time="2020-05-26T07:34:48.049928529Z" level=info msg="Attempting next endpoint for pull after error: failed to register layer: Error processing tar file(exit status 1): " + +Since I am using multiarch/qemu-user-static with the latest tag, qemu version is 4.2.0-6. + +docker in docker works flawlessly on native s390x host. I am facing this issue only with qemu. Are there any other steps to follow to make docker in docker work under qemu? + +Any pointers about this issue? Any other steps needs to be followed to resolve the issue? + +Also same issue observed with docker version 19.03. docker pull command failing with an error "failed to register layer: Error processing tar file(exit status 1):" + + + +QEMU 4.2 is quite old already, can you also reproduce the issue with the latest version of QEMU (v5.2 ... or maybe even with the 6.0-rc1 that should get released next week)? + +Yes we have observed the issue with multiarch/qemu-user-static image v5.2.0-1 and 5.2.0-2 + + +docker not starting inside s390x container. Log shows: + +Error starting daemon: Error initializing network controller: error obtaining controller instance: failed to create NAT chain DOCKER: iptables failed: iptables -t nat -N DOCKER: iptables v1.6.1: can't initialize iptables table `nat': iptables who? (do you need to insmod?) +Perhaps iptables or your kernel needs to be upgraded. + (exit status 3) + + +As we are facing issue with service docker start ( for docker in docker s390x container under qemu) + +time="2021-03-23T07:29:07.645278866Z" level=warning msg="Running modprobe nf_nat failed with message: ``, error: exec: \"modprobe\": executable file not found in $PATH" +time="2021-03-23T07:29:07.645535879Z" level=warning msg="Running modprobe xt_conntrack failed with message: ``, error: exec: \"modprobe\": executable file not found in $PATH" +Error starting daemon: Error initializing network controller: error obtaining controller instance: failed to create NAT chain DOCKER: iptables failed: iptables -t nat -N DOCKER: iptables v1.6.1: can't initialize iptables table `nat': iptables who? (do you need to insmod?) +Perhaps iptables or your kernel needs to be upgraded. + (exit status 3) + +Does it mean that qemu doesn't support/have enabled related modules? modprobe? + + +Could you please let me know if my understanding is correct? Qemu doesn't support/have enabled related modules? modprobe? + +insmod/modprobe inside the container cannot load the modules because they are the one for the target architecture while the kernel is the one of the host. If you need functionalities in the container provided by some modules you need to load these modules using modprobe/insmod on the host. + +Looks like for docker in docker in cross architectures is not yet supported. if we use -v /var/run/docker.sock:/var/run/docker.sock , docker will always run as client in s390x container and server from amd64. + +Looks like docker in docker for cross architectures is not yet supported in qemu. +can be closed + diff --git a/results/classifier/108/other/1880722 b/results/classifier/108/other/1880722 new file mode 100644 index 00000000..6b66a312 --- /dev/null +++ b/results/classifier/108/other/1880722 @@ -0,0 +1,60 @@ +performance: 0.864 +graphic: 0.686 +other: 0.662 +device: 0.511 +permissions: 0.458 +files: 0.450 +semantic: 0.449 +debug: 0.436 +PID: 0.416 +network: 0.405 +vnc: 0.359 +socket: 0.329 +KVM: 0.307 +boot: 0.253 + +Problems related to checking page crossing in use_goto_tb() + +The discussion that led to this bug discovery can be found in this +mailing list thread: +https://lists.nongnu.org/archive/html/qemu-devel/2020-05/msg05426.html + +A workaround for this problem would be to check for page crossings for +both the user and system modes in the use_goto_tb() function across +targets. Some targets like "hppa" already implement this fix but others +don't. + +To solve the root cause of this problem, the linux-user/mmap.c should +be fixed to do all the invalidations required. By doing so, up to 6.93% +performance improvements will be achieved. + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting older bugs to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1881231 b/results/classifier/108/other/1881231 new file mode 100644 index 00000000..f4f46db0 --- /dev/null +++ b/results/classifier/108/other/1881231 @@ -0,0 +1,88 @@ +other: 0.936 +permissions: 0.933 +semantic: 0.932 +debug: 0.931 +performance: 0.922 +graphic: 0.920 +device: 0.908 +network: 0.901 +vnc: 0.900 +PID: 0.900 +files: 0.899 +boot: 0.890 +socket: 0.889 +KVM: 0.873 + +colo: Can not recover colo after svm failover twice + +Hi Expert, +x-blockdev-change met some error, during testing colo + +Host os: +CentOS Linux release 7.6.1810 (Core) + +Reproduce steps: +1. create colo vm following https://github.com/qemu/qemu/blob/master/docs/COLO-FT.txt +2. kill secondary vm and remove the nbd child from the quorum to wait for recover + type those commands on primary vm console: + { 'execute': 'x-blockdev-change', 'arguments': {'parent': 'colo-disk0', 'child': 'children.1'}} + { 'execute': 'human-monitor-command','arguments': {'command-line': 'drive_del replication0'}} + { 'execute': 'x-colo-lost-heartbeat'} +3. recover colo +4. kill secondary vm again after recover colo and type same commands as step 2: + { 'execute': 'x-blockdev-change', 'arguments': {'parent': 'colo-disk0', 'child': 'children.1'}} + { 'execute': 'human-monitor-command','arguments': {'command-line': 'drive_del replication0'}} + { 'execute': 'x-colo-lost-heartbeat'} + but the first command got error + { 'execute': 'x-blockdev-change', 'arguments': {'parent': 'colo-disk0', 'child': 'children.1'}} +{"error": {"class": "GenericError", "desc": "Node 'colo-disk0' does not have child 'children.1'"}} + +according to https://www.qemu.org/docs/master/qemu-qmp-ref.html +Command: x-blockdev-change +Dynamically reconfigure the block driver state graph. It can be used to add, remove, insert or replace a graph node. Currently only the Quorum driver implements this feature to add or remove its child. This is useful to fix a broken quorum child. + +It seems x-blockdev-change not worked as expected. + +Thanks. + + + +In step 3 I used following commands: +on primary vm console: +{"execute": "drive-mirror", "arguments":{ "device": "colo-disk0", "job-id": "resync", "target": "nbd://169.254.66.10:9999/parent0", "mode": "existing","format":"raw","sync":"full"} } + +// till the job ready +{ "execute": "query-block-jobs" } + +{"execute": "stop"} +{"execute": "block-job-cancel", "arguments":{ "device": "resync"} } + +{'execute': 'human-monitor-command', 'arguments': {'command-line': 'drive_add -n buddy driver=replication,mode=primary,file.driver=nbd,file.host=169.254.66.10,file.port=9999,file.export=parent0,node-name=replication0'}} +{'execute': 'x-blockdev-change', 'arguments':{'parent': 'colo-disk0', 'node': 'replication0' } } +{'execute': 'migrate-set-capabilities', 'arguments': {'capabilities': [ {'capability': 'x-colo', 'state': true } ] } } +{'execute': 'migrate', 'arguments': {'uri': 'tcp:169.254.66.10:9998' } } +{ "execute": "migrate-set-parameters" , "arguments":{ "x-checkpoint-delay": 10000 } } + + +primary vm command: +./qemu-system-x86_64 -L /usr/share/qemu-kvm/ -enable-kvm -cpu qemu64,+kvmclock -m 2048 -smp 2 -qmp stdio -vnc :0 -device piix3-usb-uhci -device usb-tablet -name primary -netdev tap,id=hn0,vhost=off,br=br_bond1,helper=/usr/libexec/qemu-bridge-helper -device rtl8139,id=e0,netdev=hn0,romfile="" -chardev socket,id=mirror0,host=169.254.66.11,port=9003,server,nowait -chardev socket,id=compare1,host=169.254.66.11,port=9004,server,wait -chardev socket,id=compare0,host=169.254.66.11,port=9001,server,nowait -chardev socket,id=compare0-0,host=169.254.66.11,port=9001 -chardev socket,id=compare_out,host=169.254.66.11,port=9005,server,nowait -chardev socket,id=compare_out0,host=169.254.66.11,port=9005 -object filter-mirror,id=m0,netdev=hn0,queue=tx,outdev=mirror0 -object filter-redirector,netdev=hn0,id=redire0,queue=rx,indev=compare_out -object filter-redirector,netdev=hn0,id=redire1,queue=rx,outdev=compare0 -object iothread,id=iothread1 -object colo-compare,id=comp0,primary_in=compare0-0,secondary_in=compare1,outdev=compare_out0,iothread=iothread1 -drive if=ide,id=colo-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,children.0.file.filename=/root/Centos7.4.qcow2,children.0.driver=qcow2 -S + +secondary vm: +./qemu-system-x86_64 -L /usr/share/qemu-kvm/ -enable-kvm -cpu qemu64,+kvmclock -m 2048 -smp 2 -qmp stdio -vnc :1 -device piix3-usb-uhci -device usb-tablet -name secondary -netdev tap,id=hn0,vhost=off,br=br_bond1,helper=/usr/libexec/qemu-bridge-helper -device rtl8139,id=e0,netdev=hn0,romfile="" -chardev socket,id=red0,host=169.254.66.11,port=9003,reconnect=1 -chardev socket,id=red1,host=169.254.66.11,port=9004,reconnect=1 -object filter-redirector,id=f1,netdev=hn0,queue=tx,indev=red0 -object filter-redirector,id=f2,netdev=hn0,queue=rx,outdev=red1 -object filter-rewriter,id=rew0,netdev=hn0,queue=all -drive if=none,id=parent0,file.filename=/root/Centos7.4.qcow2,driver=qcow2 -drive if=none,id=childs0,driver=replication,mode=secondary,file.driver=qcow2,top-id=childs0,file.file.filename=/root/active.qcow2,file.backing.driver=qcow2,file.backing.file.filename=/root/hidden.qcow2,file.backing.backing=parent0 -drive if=none,id=colo-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,children.0=childs0 -incoming tcp:0:9998 + + +Please try this patch: +https://lists.nongnu.org/archive/html/qemu-devel/2020-06/msg00016.html + +Thanks +Zhang Chen + +I think Lukas's fix: + block/quorum.c: stable children names + +was merged a few days ago as 5eb9a3c7b0571562c0289747690e25e6855bc96f + +Can someone confirm that helped? + +QEMU v5.2 has been released now and should contain the fix + diff --git a/results/classifier/108/other/1881249 b/results/classifier/108/other/1881249 new file mode 100644 index 00000000..a93b1f69 --- /dev/null +++ b/results/classifier/108/other/1881249 @@ -0,0 +1,81 @@ +device: 0.798 +performance: 0.731 +other: 0.640 +files: 0.606 +permissions: 0.580 +graphic: 0.506 +vnc: 0.475 +boot: 0.461 +network: 0.418 +semantic: 0.418 +PID: 0.406 +socket: 0.398 +debug: 0.393 +KVM: 0.238 + +CPU fetch from unpopulated ROM on reset + +Some architectures fetch the $PC/$SP register as vectors in memory, usually ROM. +The CPU reset() handler is called before the ROM code is populated, resulting in fetching incorrect PC/SP. + +Architectures affected: +- M68K +- RX +- ARM M-profile + +Different comments from Peter Maydell regarding this issue: + +- https://<email address hidden>/msg683768.html + +"We should be able to do this with the new 3-phase +reset API : the rom loader reset should happen in phase 2, +and the Arm CPU should only load the new PC and SP in +phase 3." + +- https://<email address hidden>/msg686480.html + +"The expectation at the moment is that the board code should +register a reset function with qemu_register_reset() which +calls cpu_reset(). Relying on doing a reset in realize won't +work for the case where there's a QEMU system reset, because +we don't re-init/realize everything, we just call all the +reset hooks. + +If m68k reads pc/sp from memory on reset you'll probably run +into the same reset-ordering vs hw/cpu/loader.c that Arm M-profile +has; we currently work around that in the arm reset function." + +- https://<email address hidden>/msg683856.html + +Related (invalidated thus rejected) series: + +- https://<email address hidden>/msg683763.html + +"Support device reset handler priority configuration" + +This series adds support for configuring device reset handler priority, and +uses it to ensure that the ARMv7-M CPU reset handler is invoked after the ROM +reset handler. + +- https://<email address hidden>/msg686413.html + +"Avoid latent bug calling cpu_reset() on uninitialized vCPU" + +cpu_reset() might modify architecture-specific fields allocated +by qemu_init_vcpu(). To avoid bugs similar to the one fixed in +commit 00d0f7cb66 when introducing new architectures, move the +cpu_reset() calls after qemu_init_vcpu(). + +I had an initial look at fixing this for arm via 3-phase reset, but ran into the problem that currently CPU reset is triggered via a qemu_register_reset() hook, and qemu_register_reset() itself does not have a 3-phase reset API, so the reset hook for resetting the CPUs will end up doing all 3 phases of reset for the CPU before the reset hook for reset-from-sysbus-root does all 3 phases for other devices. (I forget whether rom-data-copy happens via sysbus reset or is its own qemu_register_reset hook, but either way the same issue applies.) + +One approach to this would be to add 3-phase support to qemu_register_reset(), I guess. + + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'invalid' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/236 + + diff --git a/results/classifier/108/other/1881506 b/results/classifier/108/other/1881506 new file mode 100644 index 00000000..725822e5 --- /dev/null +++ b/results/classifier/108/other/1881506 @@ -0,0 +1,51 @@ +graphic: 0.873 +debug: 0.844 +other: 0.840 +boot: 0.826 +semantic: 0.773 +device: 0.763 +performance: 0.753 +permissions: 0.720 +files: 0.691 +network: 0.602 +socket: 0.593 +vnc: 0.571 +PID: 0.515 +KVM: 0.363 + +TCG doesn't support a lot of features that should be supported + +This is quite odd, and I'm not sure about how to get around it. I'm writing an OS in Rust and require APIC support. When I boot my kernel with qemu-system-x86_64, however, it dumps out a [lot] of warnings; it claims that TCG doesn't support FMA, X2APIC, AVX, F16C, AVX2, RDSEED, SHA-NI, FXSR-OPT, misalignsse, 3dnowprefetch, osvw, topoext, perfctr-core, clzero, xsaveerptr, ibpb, nrip-save, xsavec, and xsaves, but prints these warnings over 80 times before finally doing what I told it to do. Running QEMU 5.0.0 (unknown commit hash), as follows: +qemu-system-x86_64 -drive format=raw,file=target\x86_64-kernel-none\debug\bootimage-kernel.bin -serial stdio -no-reboot -hdb disk.img -s -m 4G -usb -rtc base=utc,clock=host -cpu EPYC-v3,+acpi,+apic,+rdrand,+rdseed,+sse,+sse2,+sse4.1,+sse4.2,+sse4a,+ssse3,+syscall,+x2apic -smp cpus=8 -soundhw all +I would run using HAXM, but my kernel requires RDRAND, and QEMU does not, to my knowledge, automatically support RDRAND (and I don't know how to enable it). + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting older bugs to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1881552 b/results/classifier/108/other/1881552 new file mode 100644 index 00000000..72d69242 --- /dev/null +++ b/results/classifier/108/other/1881552 @@ -0,0 +1,72 @@ +permissions: 0.917 +graphic: 0.904 +other: 0.885 +debug: 0.881 +performance: 0.865 +device: 0.865 +semantic: 0.859 +PID: 0.837 +boot: 0.818 +files: 0.816 +vnc: 0.792 +KVM: 0.781 +socket: 0.779 +network: 0.770 + +potential AArch64 ABI bug wrt handling of 128-bit bit-fields + +After upgrading to Ubuntu 20.04 LTS, GCC 9.3 displays a lot of notes: + +hw/block/pflash_cfi01.c: In function ‘pflash_mem_read_with_attrs’: +hw/block/pflash_cfi01.c:663:20: note: parameter passing for argument of type ‘MemTxAttrs’ {aka ‘struct MemTxAttrs’} changed in GCC 9.1 + 663 | static MemTxResult pflash_mem_read_with_attrs(void *opaque, hwaddr addr, uint64_t *value, + | ^~~~~~~~~~~~~~~~~~~~~~~~~~ +hw/block/pflash_cfi01.c: In function ‘pflash_mem_write_with_attrs’: +hw/block/pflash_cfi01.c:677:20: note: parameter passing for argument of type ‘MemTxAttrs’ {aka ‘struct MemTxAttrs’} changed in GCC 9.1 + 677 | static MemTxResult pflash_mem_write_with_attrs(void *opaque, hwaddr addr, uint64_t value, + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ +hw/nvram/fw_cfg.c: In function ‘fw_cfg_dma_mem_valid’: +hw/nvram/fw_cfg.c:475:13: note: parameter passing for argument of type ‘MemTxAttrs’ {aka ‘struct MemTxAttrs’} changed in GCC 9.1 + 475 | static bool fw_cfg_dma_mem_valid(void *opaque, hwaddr addr, + | ^~~~~~~~~~~~~~~~~~~~ +hw/nvram/fw_cfg.c: In function ‘fw_cfg_data_mem_valid’: +hw/nvram/fw_cfg.c:483:13: note: parameter passing for argument of type ‘MemTxAttrs’ {aka ‘struct MemTxAttrs’} changed in GCC 9.1 + 483 | static bool fw_cfg_data_mem_valid(void *opaque, hwaddr addr, + | ^~~~~~~~~~~~~~~~~~~~~ +hw/nvram/fw_cfg.c: In function ‘fw_cfg_ctl_mem_valid’: +hw/nvram/fw_cfg.c:501:13: note: parameter passing for argument of type ‘MemTxAttrs’ {aka ‘struct MemTxAttrs’} changed in GCC 9.1 + 501 | static bool fw_cfg_ctl_mem_valid(void *opaque, hwaddr addr, + | ^~~~~~~~~~~~~~~~~~~~ +hw/nvram/fw_cfg.c: In function ‘fw_cfg_comb_valid’: +hw/nvram/fw_cfg.c:521:13: note: parameter passing for argument of type ‘MemTxAttrs’ {aka ‘struct MemTxAttrs’} changed in GCC 9.1 + 521 | static bool fw_cfg_comb_valid(void *opaque, hwaddr addr, + | ^~~~~~~~~~~~~~~~~ +hw/intc/arm_gic.c: In function ‘gic_do_hyp_read’: +hw/intc/arm_gic.c:1996:20: note: parameter passing for argument of type ‘MemTxAttrs’ {aka ‘struct MemTxAttrs’} changed in GCC 9.1 + 1996 | static MemTxResult gic_do_hyp_read(void *opaque, hwaddr addr, uint64_t *data, + | ^~~~~~~~~~~~~~~ +hw/intc/arm_gic.c: In function ‘gic_thiscpu_hyp_read’: +hw/intc/arm_gic.c:1979:20: note: parameter passing for argument of type ‘MemTxAttrs’ {aka ‘struct MemTxAttrs’} changed in GCC 9.1 + 1979 | static MemTxResult gic_thiscpu_hyp_read(void *opaque, hwaddr addr, uint64_t *data, + | ^~~~~~~~~~~~~~~~~~~~ +hw/intc/arm_gic.c: In function ‘gic_get_current_pending_irq’: +hw/intc/arm_gic.c:419:17: note: parameter passing for argument of type ‘MemTxAttrs’ {aka ‘struct MemTxAttrs’} changed in GCC 9.1 + 419 | static uint16_t gic_get_current_pending_irq(GICState *s, int cpu, + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ + +This seems related to: +https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469 +https://gcc.gnu.org/git/?p=gcc.git&a=commit;h=c590597c45 + + This is pretty unlikely in real code, but similar to Arm, the AArch64 + ABI has a bug with the handling of 128-bit bit-fields, where if the + bit-field dominates the overall alignment the back-end code may end up + passing the argument correctly. This is a regression that started in + gcc-6 when the ABI support code was updated to support overaligned + types. The fix is very similar in concept to the Arm fix. 128-bit + bit-fields are fortunately extremely rare, so I'd be very surprised if + anyone has been bitten by this. + +The warnings aren't a problem for QEMU because we don't expose these functions as public ABI, so the whole compile will be consistently built with the same compiler version. So we added -Wno-psabi in commit bac8d222a19f4a30d to silence the compiler here. + + diff --git a/results/classifier/108/other/1881645 b/results/classifier/108/other/1881645 new file mode 100644 index 00000000..dbe48843 --- /dev/null +++ b/results/classifier/108/other/1881645 @@ -0,0 +1,24 @@ +device: 0.808 +graphic: 0.775 +other: 0.704 +semantic: 0.502 +network: 0.491 +performance: 0.434 +debug: 0.302 +boot: 0.289 +KVM: 0.173 +PID: 0.171 +vnc: 0.164 +socket: 0.144 +files: 0.087 +permissions: 0.057 + +qemu-system-x86_64 --help (or --version) gives no output + +I have Arch Linux with qemu 5.0.0-6 (seen with pacman). Running VMs work just fine, but when I run qemu-system-x86_64 --version or qemu-system-x86_64 --help, there is no feedback on the screen. This behavior messes up other applications (GNS3 in my case that cannot recognize qemu as correctly installed because there is no feedback. +My kernel is 5.6.11. + +Can you reproduce this problem with the latest upstream version of QEMU, too (currently v6.0)? Otherwise it might be a bug in the version from your distribution, in that case please report it in the bug tracker of your distro instead. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1881648 b/results/classifier/108/other/1881648 new file mode 100644 index 00000000..7e8b212b --- /dev/null +++ b/results/classifier/108/other/1881648 @@ -0,0 +1,46 @@ +semantic: 0.819 +graphic: 0.816 +device: 0.767 +PID: 0.733 +network: 0.688 +other: 0.660 +performance: 0.653 +files: 0.642 +socket: 0.593 +boot: 0.544 +vnc: 0.519 +permissions: 0.456 +KVM: 0.414 +debug: 0.350 + +`qemu-img info` reports an incorrect actual-size when the underlying posix filesystem has transparent compression + +qemu-img info reports the same thing as `du`*1024: + +$ qemu-img info --output json ./my.qcow2 | jq '."actual-size"' +558619648 + +$ du ./my.qcow2 +545527 ./my.qcow2 + +$ echo $((558619648 / 545527)) +1024 + +and this is correct in terms of bytes on disk, but due to transparent compression implemented by the filesystem, it is not the actual byte count: + +$ du -h --apparent-size ./my.qcow2 +1346568192 my.qcow2 + +But that’s the point of that field, to show the amount of space used by the image on the host. + +The man page documents it as: “disk size: How much space the image file occupies on the host file system (may be shown as 0 if this information is unavailable, e.g. because there is no file system)”, and the QAPI definition of ImageInfo documents the actual-size field as “actual size on disk in bytes of the image”. + +So it is documented as and intended to be the number of bytes used, not the length of the file. + +Max + +This bug has been reported on the Ubuntu ISO testing tracker. + +A list of all reports related to this bug can be found here: +http://iso.qa.ubuntu.com/qatracker/reports/bugs/1881648 + diff --git a/results/classifier/108/other/1881729 b/results/classifier/108/other/1881729 new file mode 100644 index 00000000..94e27ac4 --- /dev/null +++ b/results/classifier/108/other/1881729 @@ -0,0 +1,50 @@ +other: 0.758 +graphic: 0.749 +device: 0.660 +performance: 0.659 +files: 0.628 +semantic: 0.623 +permissions: 0.620 +PID: 0.611 +debug: 0.598 +network: 0.533 +socket: 0.481 +vnc: 0.444 +KVM: 0.382 +boot: 0.339 + +target_read_memory in disas.c ignores possible errors + +`target_read_memory` in `disas.c` ignores (possible) errors. This leads to disassembler possibly disassembling garbage. + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting older bugs to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system (but you won't be the reporter of the bug +in the new system and thus won't get notified on changes anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1882065 b/results/classifier/108/other/1882065 new file mode 100644 index 00000000..38b69194 --- /dev/null +++ b/results/classifier/108/other/1882065 @@ -0,0 +1,52 @@ +graphic: 0.749 +performance: 0.722 +network: 0.716 +device: 0.712 +semantic: 0.692 +vnc: 0.659 +socket: 0.636 +other: 0.589 +files: 0.558 +PID: 0.547 +permissions: 0.525 +debug: 0.519 +boot: 0.487 +KVM: 0.422 + +Could this cause OOB bug ? + +In function megasas_handle_scsi(hw/scsi/megasas.c): + +```c +static int megasas_handle_scsi(MegasasState *s, MegasasCmd *cmd, + int frame_cmd) +{ + ............................................................................ + cdb = cmd->frame->pass.cdb; + target_id = cmd->frame->header.target_id; + lun_id = cmd->frame->header.lun_id; + cdb_len = cmd->frame->header.cdb_len; + ............................................................................ + if (cdb_len > 16) { + trace_megasas_scsi_invalid_cdb_len( + mfi_frame_desc[frame_cmd], is_logical, + target_id, lun_id, cdb_len); + megasas_write_sense(cmd, SENSE_CODE(INVALID_OPCODE)); + cmd->frame->header.scsi_status = CHECK_CONDITION; + s->event_count++; + return MFI_STAT_SCSI_DONE_WITH_ERROR; + } +} +``` + +Two variables, frame_cmd and cdb_len, can be controlled by guest os. So can mfi_frame_desc[frame_cmd] cause OOB bug ? + +QEMU emulator version 5.0.50 (v5.0.0-533-gdebe78ce14-dirty) + +You must start the trace function of QEMU to trigger this BUG! + +I think we should fix this anyway, even if it can only be triggered when trace functions are enabled + +Fix has been included: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=ee760ac80ac1f1 + diff --git a/results/classifier/108/other/1882241 b/results/classifier/108/other/1882241 new file mode 100644 index 00000000..d1dd0f70 --- /dev/null +++ b/results/classifier/108/other/1882241 @@ -0,0 +1,130 @@ +files: 0.829 +device: 0.798 +performance: 0.794 +boot: 0.786 +vnc: 0.721 +permissions: 0.715 +semantic: 0.713 +PID: 0.710 +network: 0.701 +graphic: 0.694 +other: 0.654 +debug: 0.644 +KVM: 0.626 +socket: 0.605 + +file transfer over cifs to 64bit guest corrupts large files + +qemu 4.0 compiled fom source. +vm called by +qemu-system-x86_64 -cpu qemu64 -smp 4 -m 4G -drive file=/data/images/slack14.2_64bit_test.qcow2,format=qcow2 -cdrom /mnt/smb1/slackware/iso/slackware64-14.2-install-dvd.iso -boot c -net nic,macaddr=02:00:00:11:11:17,model=i82551 -net bridge,br=br0 -enable-kvm -k en-gb -display vnc=:3 -monitor telnet:localhost:7103,server,nowait,nodelay + +copying large files eg 2.4gb or reading them on a cifs mount in the guest causes corruption every time. For smaller files 40-60mb corruption is more than 50% of the time. tested by md5sum on cifs server, or on host machine vs. on guest vm. +corruption is seen only with 64bit guest using cifs with i82551 emulated network device +ie. 32bit guest using cifs with i82551 emulated network device gives no corruption. + +changing the emulated device to vmxnet3 removes the data corruption (see below) + +qemu-system-x86_64 -cpu qemu64 -smp 4 -m 4G -drive file=/data/images/slack14.2_64bit_test.qcow2,format=qcow2 -cdrom /mnt/smb1/slackware/iso/slackware64-14.2-install-dvd.iso -boot c -net nic,macaddr=02:00:00:11:11:17,model=vmxnet3 -net bridge,br=br0 -enable-kvm -k en-gb -display vnc=:3 -monitor telnet:localhost:7103,server,nowait,nodelay + +this corruption is repeatable. ie. I created new vm, call using top example, installed 64bit linux, mounted cifs share and copied 2.4gb file to /tmp then run md5sum "filecopied" +the md5sum is different every time. copy same file to the host, or to a 32bit guest with the same virtual network device and bridge and md5sums are correct. The host pysical network adapter is +lspci|grep Ether +1e:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 11) + +physically connected via gigabit ethernet to cifs server (via gigabit switch) + +On Fri, Jun 05, 2020 at 12:30:39PM -0000, timsoft wrote: +> Public bug reported: +> +> qemu 4.0 compiled fom source. +> vm called by +> qemu-system-x86_64 -cpu qemu64 -smp 4 -m 4G -drive file=/data/images/slack14.2_64bit_test.qcow2,format=qcow2 -cdrom /mnt/smb1/slackware/iso/slackware64-14.2-install-dvd.iso -boot c -net nic,macaddr=02:00:00:11:11:17,model=i82551 -net bridge,br=br0 -enable-kvm -k en-gb -display vnc=:3 -monitor telnet:localhost:7103,server,nowait,nodelay +> +> copying large files eg 2.4gb or reading them on a cifs mount in the guest causes corruption every time. For smaller files 40-60mb corruption is more than 50% of the time. tested by md5sum on cifs server, or on host machine vs. on guest vm. +> corruption is seen only with 64bit guest using cifs with i82551 emulated network device +> ie. 32bit guest using cifs with i82551 emulated network device gives no corruption. +> +> changing the emulated device to vmxnet3 removes the data corruption (see +> below) +> +> qemu-system-x86_64 -cpu qemu64 -smp 4 -m 4G -drive +> file=/data/images/slack14.2_64bit_test.qcow2,format=qcow2 -cdrom +> /mnt/smb1/slackware/iso/slackware64-14.2-install-dvd.iso -boot c -net +> nic,macaddr=02:00:00:11:11:17,model=vmxnet3 -net bridge,br=br0 -enable- +> kvm -k en-gb -display vnc=:3 -monitor +> telnet:localhost:7103,server,nowait,nodelay +> +> this corruption is repeatable. ie. I created new vm, call using top example, installed 64bit linux, mounted cifs share and copied 2.4gb file to /tmp then run md5sum "filecopied" +> the md5sum is different every time. copy same file to the host, or to a 32bit guest with the same virtual network device and bridge and md5sums are correct. The host pysical network adapter is +> lspci|grep Ether +> 1e:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 11) +> +> physically connected via gigabit ethernet to cifs server (via gigabit +> switch) + +Not a solution but some comments: + +1. As a sanity-check you could try "nc <guest-ip> 1234 </path/to/file" on + the host and "nc -l -p 1234 >/tmp/file" in the guest. Netcat simply + sends/receives data over a TCP connection (it's a much simpler test + than CIFS). Is the checksum okay? + +2. I don't know the CIFS network protocol, but if Wireshark can dissect + it then you could compare the flows between the vmxnet3 and the + i82551. This is only feasible if Wireshark can produce an unencrypted + conversation and the CIFS protocol doesn't have many protocol header + fields that differ between two otherwise identical sessions. + +3. virtio-net is the most widely used and high-performance NIC model. + Other emulated NIC models are mainly there for very old guests that + lack virtio guest drivers. + + +thanks for the suggestion. I tried using netcat (nc) to transfer a large file from host to guest, and also from fileserver to guest with the problematic i82551 emulated network adapter on the host and the files transfered reliably. (correct md5sum 3 out of 3 attempts) +I also tried md5sum of the same file mounted on the guest fs as before and it still corrupts the data. +this seems to imply there is something in the cifs implementation which reacts adversly with this particular combination of virtual network hardware, the fact it works with the vmxnet3 emulated card, would support that conclusion. + +On Wed, Jun 17, 2020 at 02:55:55PM -0000, timsoft wrote: +> thanks for the suggestion. I tried using netcat (nc) to transfer a large file from host to guest, and also from fileserver to guest with the problematic i82551 emulated network adapter on the host and the files transfered reliably. (correct md5sum 3 out of 3 attempts) +> I also tried md5sum of the same file mounted on the guest fs as before and it still corrupts the data. +> this seems to imply there is something in the cifs implementation which reacts adversly with this particular combination of virtual network hardware, the fact it works with the vmxnet3 emulated card, would support that conclusion. + +I'm not sure if someone will look into it because the eepro100 +(i82551) NIC device is old an not used much nowadays. + +However, if someone does decide to investigate and wants to brainstorm +debugging ideas or needs help, feel free to contact me. + + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting older bugs to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system (but you won't be the reporter of the bug +in the new system and thus won't get notified on changes anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1882350 b/results/classifier/108/other/1882350 new file mode 100644 index 00000000..46b7b2f6 --- /dev/null +++ b/results/classifier/108/other/1882350 @@ -0,0 +1,110 @@ +device: 0.873 +other: 0.858 +KVM: 0.846 +semantic: 0.843 +PID: 0.829 +performance: 0.815 +permissions: 0.805 +files: 0.764 +boot: 0.754 +debug: 0.743 +graphic: 0.719 +vnc: 0.675 +network: 0.674 +socket: 0.598 + +it always create sdx device when I configure ide device with hdx name + +I have configured 2 ide disks with name starting with hd, but when the vm boots up, it shows disks whose name starting with sd. + +1. ide disks in vm xml: + + <disk type='file' device='disk'> + <driver name='qemu' type='raw'/> + <source file='/data3_raw.qcow2'/> + <target dev='hdc' bus='ide'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/data2.qcow2'/> + <target dev='hdb' bus='ide'/> + </disk> + + +2. in VM: + +sda 8:0 0 2G 0 disk +sdb 8:16 0 1G 0 disk + + +3. from vm.log: + +le=/data2.qcow2,format=qcow2,if=none,id=drive-ide0-0-1 -device ide-hd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 -drive file=/data3_raw.qcow2,format=raw,if=none,id=drive-ide0-1-0 -device ide-hd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev t + + +4. rpm info: (I got the same issue on 2 diff envs) +(1) env1 +qemu-kvm-1.5.3-105 +libvirt-3.2.0-14.el7 +(2) env2 +libvirt-5.9.0-1.el8 +qemu-4.1.0-1.el8 + +On 6/6/20 5:50 AM, marshell wrote: +> Public bug reported: +> +> I have configured 2 ide disks with name starting with hd, but when the +> vm boots up, it shows disks whose name starting with sd. + +This looks more like a libvirt question than a qemu one. + +> +> 1. ide disks in vm xml: +> +> <disk type='file' device='disk'> +> <driver name='qemu' type='raw'/> +> <source file='/data3_raw.qcow2'/> +> <target dev='hdc' bus='ide'/> +> </disk> +> <disk type='file' device='disk'> +> <driver name='qemu' type='qcow2'/> +> <source file='/data2.qcow2'/> +> <target dev='hdb' bus='ide'/> +> </disk> + +The name that libvirt chooses to identify disks from the host +perspective is independent... + +> +> +> 2. in VM: +> +> sda 8:0 0 2G 0 disk +> sdb 8:16 0 1G 0 disk + +...from what the guest OS chooses to use. Although there are many +situations where a Linux guest will pick the same names as libvirt chose +on the host side based on the transport (such as SCSI or virtio), there +is no guarantee that this is always the case, nor that your guest is +always running Linux as its OS. + +-- +Eric Blake, Principal Software Engineer +Red Hat, Inc. +1-919-301-3226 +Virtualization: qemu.org | libvirt.org + + + +Thanks a lot for the reply. + + +But from the cmdline of qemu, we can see as following, libvirt passed "-device" option with "ide-hd, bus=ide.0" to qemu. I am wondering why qemu received this option, but it is still dealing it as scsi bus device instead of ide bus device, since with "lssci" cmd, we can see the ide disk we configured in xml. + +>3. from vm.log: + +>le=/data2.qcow2,format=qcow2,if=none,id=drive-ide0-0-1 -device ide-hd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 >-drive file=/data3_raw.qcow2,format=raw,if=none,id=drive-ide0-1-0 -device ide-hd,bus=ide.1,unit=0,drive=drive-ide0-1->0,id=ide0-1-0 -netdev t + +Which kernel / linux distro are you using in the guest? Can you spot something related in the output of "dmesg" in the guest? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1882497 b/results/classifier/108/other/1882497 new file mode 100644 index 00000000..2286a9c2 --- /dev/null +++ b/results/classifier/108/other/1882497 @@ -0,0 +1,51 @@ +performance: 0.911 +other: 0.581 +graphic: 0.535 +files: 0.533 +device: 0.527 +vnc: 0.503 +PID: 0.503 +semantic: 0.469 +network: 0.461 +socket: 0.444 +permissions: 0.411 +debug: 0.380 +boot: 0.281 +KVM: 0.235 + +Missing 'cmp' utility makes build take 10 times as long + +I have been doing some work cross compiling qemu for Windows using a minimal Fedora container. Recently I started hitting some timeouts on the CI service and noticed a build of all targets was going over 1 hour. + +It seems like the 'cmp' utility from diffutils is used somewhere in the process and if it's missing, either a configure or a make gets run way too many times - I'll try to pull logs from the CI system at some stage soon. + +Could a warning or error be added if cmp is missing? + +cmp is used in the makefiles. + +And there is some kind of warning during build if it is missing: + +/bin/sh: cmp: command not found + +But perhaps it should abort the build in this case. + +Something like that helps: + +diff --git a/Makefile b/Makefile +index 40e4f7677bde..05e029bd99db 100644 +--- a/Makefile ++++ b/Makefile +@@ -482,6 +482,7 @@ include $(SRC_PATH)/tests/Makefile.include + all: $(DOCS) $(if $(BUILD_DOCS),sphinxdocs) $(TOOLS) $(HELPERS-y) recurse-all modules $(vhost-user-json-y) + + qemu-version.h: FORCE ++ @type cmp + $(call quiet-command, \ + (printf '#define QEMU_PKGVERSION "$(QEMU_PKGVERSION)"\n'; \ + printf '#define QEMU_FULL_VERSION "$(FULL_VERSION)"\n'; \ + + +Does this problem still persist with the latest version of QEMU (since we switched the build system mostly to meson now)? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1882671 b/results/classifier/108/other/1882671 new file mode 100644 index 00000000..5a9a5900 --- /dev/null +++ b/results/classifier/108/other/1882671 @@ -0,0 +1,799 @@ +permissions: 0.767 +debug: 0.708 +semantic: 0.672 +performance: 0.633 +graphic: 0.619 +device: 0.601 +socket: 0.599 +boot: 0.574 +other: 0.549 +PID: 0.538 +network: 0.536 +files: 0.493 +vnc: 0.471 +KVM: 0.453 + +unbalanced UEFI TPL manipulations in iPXE with DOWNLOAD_PROTO_HTTPS enabled + +The version of QEMU (4.2.0) packaged for Ubuntu 20.04 hangs indefinitely at boot if an OVMF bios is used. This happens ONLY with qemu-system-x86_64. qemu-system-i386 works fine with the latest ia32 OVMF bios. + +NOTE[1]: the same identical OVMF bios works fine on QEMU 2.x packaged with Ubuntu 18.04. +NOTE[2]: reproducing the fatal bug requires *no* operating system: + + qemu-system-x86_64 -bios OVMF-pure-efi.fd + +On its window QEMU gets stuck at the very first stage: + "Guest has not initialized the display (yet)." + +NOTE[3]: QEMU gets stuck no matter if KVM is used or not. + +NOTE[4]: By adding the `-d int` option it is possible to observe that QEMU is, apparently, stuck in an endless loop of interrupts. For the first few seconds, registers' values vary quickly, but at some point they reach a final value, while the interrupt counter increments: + + 2568: v=68 e=0000 i=0 cpl=0 IP=0038:0000000007f1d225 pc=0000000007f1d225 SP=0030:0000000007f0c8d0 env->regs[R_EAX]=0000000000000000 +RAX=0000000000000000 RBX=0000000007f0c920 RCX=0000000000000000 RDX=0000000000000001 +RSI=0000000006d18798 RDI=0000000000008664 RBP=0000000000000000 RSP=0000000007f0c8d0 +R8 =0000000000000001 R9 =0000000000000089 R10=0000000000000000 R11=0000000007f2c987 +R12=0000000000000000 R13=0000000000000000 R14=0000000007087901 R15=0000000000000000 +RIP=0000000007f1d225 RFL=00000246 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0030 0000000000000000 ffffffff 00cf9300 DPL=0 DS [-WA] +CS =0038 0000000000000000 ffffffff 00af9a00 DPL=0 CS64 [-R-] +SS =0030 0000000000000000 ffffffff 00cf9300 DPL=0 DS [-WA] +DS =0030 0000000000000000 ffffffff 00cf9300 DPL=0 DS [-WA] +FS =0030 0000000000000000 ffffffff 00cf9300 DPL=0 DS [-WA] +GS =0030 0000000000000000 ffffffff 00cf9300 DPL=0 DS [-WA] +LDT=0000 0000000000000000 0000ffff 00008200 DPL=0 LDT +TR =0000 0000000000000000 0000ffff 00008b00 DPL=0 TSS64-busy +GDT= 00000000079eea98 00000047 +IDT= 000000000758f018 00000fff +CR0=80010033 CR2=0000000000000000 CR3=0000000007c01000 CR4=00000668 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +CCS=0000000000000044 CCD=0000000000000000 CCO=EFLAGS +EFER=0000000000000d00 + + +NOTE[5]: Just to better help the investigation of the bug, I'd like to remark that the issue is NOT caused by an endless loop of triple-faults. I tried with -d cpu_reset and there is NO such loop. No triple fault whatsoever. + +NOTE[6]: The OVMF version used for the test has been downloaded from: +https://www.kraxel.org/repos/jenkins/edk2/edk2.git-ovmf-x64-0-20200515.1398.g6ff7c838d0.noarch.rpm + +but the issue is the same with older OVMF versions as well. + + +Please take a look at it, as the bug is NOT a corner case. QEMU 4.2.0 cannot boot with an UEFI firmware (OVMF) while virtualizing a x86_64 machine AT ALL. + +Thank you very much, +Vladislav K. Valtchev + +Please add + + -debugcon file:debug.log -global isa-debugcon.iobase=0x402 + +to the QEMU cmdline, and attach "debug.log". Thanks. + +Thanks for the quick response, I'm attaching the debug.log file. + + +Status changed to 'Confirmed' because the bug affects multiple users. + +Vladislav, + +The OVMF debug log ends like this (with UEFI protocol GUIDs decoded as +their textual identifiers in edk2): + +> [Security] 3rd party image[6D19D18] can be loaded after EndOfDxe: PciRoot(0x0)/Pci(0x3,0x0)/Offset(0x16400,0x4B1FF). +> InstallProtocolInterface: [EfiLoadedImageProtocol] 6D187C0 +> Loading driver at 0x00006B1F000 EntryPoint=0x00006B25497 82540em.efi +> InstallProtocolInterface: [EfiLoadedImageDevicePathProtocol] 6D18498 +> ProtectUefiImageCommon - 0x6D187C0 +> - 0x0000000006B1F000 - 0x00000000000B6E60 +> InstallProtocolInterface: [EfiDriverBindingProtocol] 6B50C00 +> InstallProtocolInterface: [EfiComponentName2Protocol] 6B50BD0 +> ASSERT /home/jenkins/workspace/edk2/rpms/build/edk2-g6ff7c838d0/MdeModulePkg/Core/Dxe/Image/Image.c(1676): Image->Tpl == gEfiCurrentTpl + +This final log snippet confirms that a UEFI device driver called +"82540em.efi" is being loaded and started from the option ROM BAR of the +PCI device that is at slot 3, function 0, of the root bridge. + +When this UEFI device driver is started, it trips an assert in the +platform firmware. Namely, in the CoreStartImage() function in the +"MdeModulePkg/Core/Dxe/Image/Image.c" source file of edk2: + + // + // Image has completed. Verify the tpl is the same + // + ASSERT (Image->Tpl == gEfiCurrentTpl); + +This suggests that the "82540em.efi" driver exits its entry point +function after having raised, but not having restored, the TPL (Task +Priority Level). In other words, the symptom indicates a bug in the UEFI +driver. + +I *suspect* (but am not sure) that you are using an e1000 emulated NIC, +and the "82540em.efi" driver exposed in its oprom comes from the iPXE +project: + +src/drivers/net/intel.c: PCI_ROM ( 0x8086, 0x100e, "82540em", "82540EM", 0 ), + +Therefore I suspect a bug in the iPXE version that the Ubuntu 20.04 +upgrade brought to you. + +(I can see a number of TPL-related patches in the iPXE git history, +around Feb-Mar 2018. And QEMU loads the iPXE oprom into the emulated +NICs ROM BAR.) + +Please try installing different versions of the iPXE package on your +Ubuntu host, and re-run your test (without changing any other elements +of your setup). + +Thanks. + + +(From the UEFI executable name "82540em.efi" in the log, I initially suspected an assigned physical NIC with a buggy flashed-on oprom. But grepping the iPXE tree for "82540em" yields a match, and QEMU loads the iPXE oproms by default into the emulated NICs' ROM BARs.) + +Hi Laszlo, +thanks for investigating the problem so rapidly. + +So, I downgraded the ipxe-qemu package from 1.0.0+git-20190109.133f4c4-0ubuntu3 (focal) to 1.0.0+git-20180124.fbe8c52d-0ubuntu2 (bionic) and the problem completely disappeared. Your theory looks absolutely correct to me. + +For what it's worth, I just discovered that, even with the buggy ipxe-qemu in Focal, the OVMF distributed with QEMU itself (/usr/share/qemu/OVMF.fd) worked, but ONLY with it. I tried with multiple other versions of OVMF and all of them caused QEMU to stuck at boot, probably because of that ASSERT in the 82540em.efi driver. + +Vlad + +Hi Vlad, + +the ipxe-qemu package in Ubuntu (1.0.0+git-20190109.133f4c4-0ubuntu3) is +built with DOWNLOAD_PROTO_HTTPS enabled (in "src/config/general.h"). +According to the Ubuntu changelog, this is a new feature added in +"1.0.0+git-20190109.133f4c4-0ubuntu1". + +With DOWNLOAD_PROTO_HTTPS enabled, I can reproduce the issue locally, +with iPXE built from source at git commit 133f4c4 (which you report the +issue for), and also at current iPXE master (9ee70fb95bc2). + +The issue does not reproduce (with DOWNLOAD_PROTO_HTTPS enabled) at +commit fbe8c52d. This suggests the problem should be bisectable. + +If I disable DOWNLOAD_PROTO_HTTPS, then the problem goes away even at +133f4c4 (i.e., the issue is masked). + +I've used current edk2 master to test with (14c7ed8b51f6). + +Viewed at 133f4c4: + +The DOWNLOAD_PROTO_HTTPS feature test macro seems to result in iPXE +attempting to gather entropy. (Likely for setting up TLS connections.) +For entropy gathering, iPXE seems to use an EFI timer, and to measure +jitter across one timer tick. In this, iPXE plays some tricks with the +UEFI TPL (Task Priority Level). + +In general, iPXE seems to want to run at TPL_CALLBACK most of the time, +to mask the timer interrupt in most code locations, and drops down to +TPL_APPLICATION only when it actively wants a timer callback (for the +jitter collection, see above). + +When the iPXE driver is launched, the StartImage() UEFI boot service +takes a note of the current TPL. It is TPL_APPLICATION (value 4). Then +iPXE seems to perform the above trickery with TPL_CALLBACK & entropy +collection. Finally, after installing EfiDriverBindingProtocol and +EfiComponentName2Protocol, the iPXE driver exits (as expected from a +UEFI driver model driver -- the entry point function is only supposed to +perform some setup steps & install some protocol interfaces). At this +point, StartImage() verifies whether the TPL has been restored to the +same as it was before launching the driver. + +Unfortunately, something about the TPL manipulations in iPXE is +unbalanced, because I see the following TPL changes: + +- raise: APPLICATION (4) -> CALLBACK (8) +- raise: CALLBACK (8) -> NOTIFY (16) +- raise: NOTIFY (16) -> NOTIFY (16) +- restore: NOTIFY (16) -> NOTIFY (16) +- restore: NOTIFY (16) -> CALLBACK (8) + +Note that the final "restore: CALLBACK (8) -> APPLICATION (4)" +transition is missing, before iPXE exits. This is what StartImage() +catches and reports with the failed ASSERT(). + +So, as I mentioned, the problem is bisectable. Here's the bisection log: + +> git bisect start +> # bad: [9ee70fb95bc266885ff88be228b044a2bb226eeb] [efi] Attempt to +> # connect our driver directly if ConnectController fails +> git bisect bad 9ee70fb95bc266885ff88be228b044a2bb226eeb +> # bad: [133f4c47baef6002b2ccb4904a035cda2303c6e5] [build] Handle +> # R_X86_64_PLT32 from binutils 2.31 +> git bisect bad 133f4c47baef6002b2ccb4904a035cda2303c6e5 +> # good: [fbe8c52d0d9cdb3d6f5fe8be8edab54618becc1f] [ena] Fix spurious +> # uninitialised variable warning on older versions of gcc +> git bisect good fbe8c52d0d9cdb3d6f5fe8be8edab54618becc1f +> # bad: [bc85368cdd311fe68ffcf251e7e8e90c14f8a9dc] [librm] Ensure that +> # inline code symbols are unique +> git bisect bad bc85368cdd311fe68ffcf251e7e8e90c14f8a9dc +> # bad: [0778418e29ea16fc897fc5b6e497054f5ba86ebd] [golan] Do not +> # assume all devices are identical +> git bisect bad 0778418e29ea16fc897fc5b6e497054f5ba86ebd +> # good: [f672a27b34220865b403df519593f382859559e0] [efi] Raise TPL +> # within EFI_USB_IO_PROTOCOL entry points +> git bisect good f672a27b34220865b403df519593f382859559e0 +> # bad: [d8c500b7945e57023dde5bd0be2b0e40963315d9] [efi] Drop to +> # TPL_APPLICATION when gathering entropy +> git bisect bad d8c500b7945e57023dde5bd0be2b0e40963315d9 +> # good: [c84f9d67272beaed98f98bf308471df16340a3be] [iscsi] Parse IPv6 +> # address in root path +> git bisect good c84f9d67272beaed98f98bf308471df16340a3be +> # first bad commit: [d8c500b7945e57023dde5bd0be2b0e40963315d9] [efi] +> # Drop to TPL_APPLICATION when gathering entropy + +The bisection fingers d8c500b7945e ("[efi] Drop to TPL_APPLICATION when + gathering entropy", 2018-03-12) as first bad commit. + +Feel free to report this problem on the upstream iPXE mailing list. + +Regarding Ubuntu downstream, you should be able to work around this +issue by #undef-ing DOWNLOAD_PROTO_HTTPS again, in +"src/config/general.h" -- *minimally* in the CONFIG=qemu build(s). That +is, in the ipxe-qemu subpackage. + +That's because in a CONFIG=qemu build, you totally don't need (or even +*use*) the iPXE HTTPS infrastructure (the entropy gathering that trips +the ASSERT seems spurious to me, with CONFIG=qemu). With CONFIG=qemu, +iPXE provides the UEFI SNP (Simple Network Protocol) interface on top of +the e1000 NIC, and the crypto stuff (if any) is done by the platform +firmware (edk2 / OVMF). + + + + +Thanks for the whole investigation, Laszlo. +I sent an e-mail to <email address hidden> forwarding your analysis with +a quick summary of mine on the top, indicating the probable first bad commit. + +Vlad + +Awesome debugging Lazlo and also a really well doen bug report Vladislav - thanks! + +As Ubutnu background DOWNLOAD_PROTO_HTTPS is enabled since quite a long time in Ubuntu since bug 1025239. + +I don't know if there are better ways nowadays that might allow to disable it in future versions of Ubuntu, but for the already released versions I can't just disable it anyway. +Therefore @Vladislav if the thread you started at <email address hidden> comes to a conclusion/patch please let us know here so that I can consider backporting whatever the final solution will be. + +I was happy to contribute, Christian :-) + +I just wanted to add that after sending the e-mail to <email address hidden>, I received an automatic response explaining that my e-mail will have to be approved by a moderator because I'm not a member of that mailing list. I just hope that my e-mail won't rot there indefinitely. + + +Vlad, + +you could subscribe to ipxe-devel at <https://lists.ipxe.org/mailman/listinfo/ipxe-devel>, wait until it's confirmed (I think it's automatic, so no moderator approval is needed for subscribing), and then resend your message. You can even stay subscribed -- if you don't want to get the ipxe-devel list traffic, you can click "unsubscribe or edit options", and then "disable mail delivery" (which is *different* from unsubscribing). That way you'd remain a subscriber (so you could post at any time), but you wouldn't get the general list traffic. + +hth +Laszlo + +Christian, + +you can enable DOWNLOAD_PROTO_HTTPS in the traditional BIOS image built from iPXE, and disable it in the UEFI driver built from iPXE. You can still combine both drivers into a combined option ROM. For SeaBIOS guests, there's not going to be any change. + +For UEFI guests, see my comment#7 -- you don't need the iPXE HTTPS implementation, because OVMF already contains the edk2 HTTPS BOOT feature (assuming you build OVMF with "-D NETWORK_HTTP_BOOT_ENABLE -D NETWORK_TLS_ENABLE"). The whole point of CONFIG=qemu is to strip the UEFI build of iPXE to a mere Simple Network Protocol driver. Such a build provides only the lowest level hardware abstraction for UEFI, and the rest (IPv[46], TCP/UDP, DHCP, PXE, TFTP, HTTP(S)) are provided on top by the edk2 implementations of various standard UEFI interfaces. + +If you want to run a full-featured iPXE build on a UEFI machine (including: in an OVMF guest), you still can, of course; lots of people do that, for good reasons. But that use case is best served by the *standalone UEFI application* build of iPXE (produced at "bin-x86_64-efi/ipxe.efi" by "make"). The UEFI *driver* build of iPXE should be as minimal as possible, in comparison -- just provide SNP for the desired NIC models. + +@Lazlo thanks a lot for that awesome experience and guidance! + +Config is a bit odd in this package anyway from too many people touching it with different mindset and a lot of history. + +There is this from upstream source: src/config/general.h +Which is patched to enable DOWNLOAD_PROTO_HTTPS via debian/patches/enable-https.patch + +But there also is $ cat debian/config/general.h: +#define ROM_BANNER_TIMEOUT 0 +#define NET_PROTO_IPV6 +#define DOWNLOAD_PROTO_NFS +This goes into ./config/local/general.h at the override_dh_auto_configure stage. + +I think I should merge with the latest version from Debian, then see how I can configure HTTPS with some but not the other builds and then run everything through a bigger regression check. +I'll start a merge of the latest version in bug 1884758 and then check out disabling DOWNLOAD_PROTO_HTTPS for EFI. + +The recent edk2 builds have -DNETWORK_HTTP_BOOT_ENABLE=TRUE -DNETWORK_TLS_ENABLE +Recent as in 2020.05-2 which means >=groovy. + +For the eventual SRU to Focal things are more complex as there -DNETWORK_TLS_ENABLE was missing. + +The above was an FYI, but is should be fine as outlined by Lazlo this isn't needed as since ipxe 1.0.0+git-20180124.fbe8c52d-0ubuntu4 we use CONFIG=qemu and in comment #7 he explained that in this case "totally don't need (or even *use*) the iPXE HTTPS infrastructure (the entropy gathering that trips the ASSERT seems spurious to me, with CONFIG=qemu). With CONFIG=qemu, iPXE provides the UEFI SNP (Simple Network Protocol) interface on top of the e1000 NIC, and the crypto stuff (if any) is done by the platform firmware (edk2 / OVMF)" + +Note: the bisection result of d8c500b7945e ("[efi] Drop to TPL_APPLICATION when gathering entropy" is in <=133f4c4 but > fbe8c52d which means for Ubuntu releases that would be affected >=Disco. + +@Lazlo - are combined roms breaking your suggestion to "just disable https in efi roms"? +In the build for the efi roms it uses this at some point: + src/util/catrom.pl src/bin-i386-pcbios/82540em.rom src/bin-x86_64-efi/82540em.efirom > src/bin-combined/82540em.efirom + +So the *efi* file in ipxe-qemu will be a combined rom (since 2013). +Of these the legacy one will have HTTPS enabled and the EFI part won't. +Would you expect that this is a problem for the suggested workaround (I don't but would be glad if you would let me know what you think about it)? + +Christian, + +what you describe seems to be exactly what I propose. Namely: +- build "82540em.rom" with HTTPS enabled, +- build "82540em.efirom" with CONFIG=qemu, and HTTPS disabled, +- create a combined option ROM image from the above two, using "catrom.pl". + +Thanks +Laszlo + +Thank you Lazlo, going forward that is the process that I have it execute then. +On the SRU I'll "only" disable HTTPS on EFI roms and we can take a look if nothing else stops working but this case here would be fixed. + +-- + +One question thou - asking for help to be able to make this an SRU at soem point. + +Vladislav initially reported the test could just be "qemu -bios ovmf". +I tried this in various Ubuntu releases like: + qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd +But without any other setup that properly gives the edk tianocore logo followed by some PXE tries and failing to boot. After the timeouts all passed it eventually gives me the UEFI shell. + +I'd have hoped this behaves differently in Bionic (working) and Focal (failing) per the initial report - but it seems to be the same. + +My point is that I fail to recreate the bug in the existing releases, which is a requirement (to be able to verify the fix) for the SRU. + +@Vladislav (or @Lazlo since you said you can reproduce it) - is there now a better way known how to trigger this. + + +I used + +qemu-system-x86_64 \ + -enable-kvm \ + -monitor stdio \ + -drive if=pflash,snapshot=on,format=raw,file=OVMF.fd \ + -global e1000.romfile=82540em.combined.rom \ + -debugcon file:debug.log \ + -global isa-debugcon.iobase=0x402 + +where "OVMF.fd" was built from edk2 at then-master (14c7ed8b51f6 -- see comment 7), and "82540em.combined.rom" is the combined oprom (with HTTPS enabled in the EFI driver too) built from the problematic iPXE version(s). + +OVMF was built with "-b DEBUG". ("-b RELEASE" would remove the ASSERT()s from the firmware modules.) + +"debug.log" captures the firmware debug output. That's the file that ends with the ASSERT failure seen in comment 4. + +Following [1] I was building my test OVMF as guided by Lazlo. +That way I was able to use the combined e1000 EFI of the Ubuntu packages vs the debug OVMF build. + +Using that I can confirm the behavior (Bionic working, Focal failing). + +$ qemu-system-x86_64 -enable-kvm -monitor stdio -drive if=pflash,snapshot=on,format=raw,file=/root/edk2/Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd -global e1000.romfile=/usr/lib/ipxe/qemu/efi-e1000.rom -debugcon file:debug.log -global isa-debugcon.iobase=0x402 + +#/usr/lib/ipxe/qemu/efi-e1000.rom is from package ipxe-qemu +#/root/edk2/Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd is the debug build, I'll attach that file here to eas repo in other places + +Symptoms when failing: +- UI never leaves the "initializing" state +- in the debug.log the bad case asserts with + ASSERT /root/edk2/MdeModulePkg/Core/Dxe/Image/Image.c(1676): Image->Tpl == gEfiCurrentTpl + +That it seems to work fine with the ovmf build that is in Focal 0~20191122.bd85bf54-2ubuntu3 makes the SRU of this less urgent IMHO. And also resolves some of my remaining confusion since I've known that EFI boots in general work - and it seems (at least in this test POV) - that only a newer or different built OVMF triggers the issue. + +[1]: https://wiki.ubuntu.com/UEFI/EDK2#Set_up_build_environment + +I beg your pardon Lazlo, but one more question on CONFIG=qemu. +Since it was introduced config=QEMU was exported for efi and legacy roms. +But it seems for legacy roms like 82540em.rom CONFIG=qemu being set or not doesn't make a difference. + +I I just look at src/config/qemu/* vs src/config/ there is a massive difference and I see it showing up in the build log, so the export has "some" effect. + +Grepping for qemu.*82540em I see + +Old: +/tmp/buildlog_ubuntu-focal-amd64.ipxe_1.0.0+git-20190109.133f4c4-0ubuntu3_BUILDING.txt:35050:gcc -DARCH=i386 -DPLATFORM=pcbios -DSECUREBOOT=0 -march=i386 -fomit-frame-pointer -fstrength-reduce -falign-jumps=1 -falign-loops=1 -falign-functions=1 -mpreferred-stack-boundary=2 -mregparm=3 -mrtd -freg-struct-return -m32 -fshort-wchar -Ui386 -Ulinux -DNVALGRIND -Iinclude -I. -Iarch/x86/include -Iarch/i386/include -Iarch/i386/include/pcbios -Os -g -ffreestanding -Wall -W -Wformat-nonliteral -fno-stack-protector -fno-dwarf2-cfi-asm -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables -Wno-address -Wno-stringop-truncation -fno-PIE -no-pie -ffunction-sections -fdata-sections -include include/compiler.h -DASM_TCHAR='@' -DASM_TCHAR_OPS='@' -DCONFIG=qemu -DLOCAL_CONFIG=qemu -DOBJECT=version -DBUILD_NAME="\"82540em.rom\"" \ +/tmp/buildlog_ubuntu-focal-amd64.ipxe_1.0.0+git-20190109.133f4c4-0ubuntu3_BUILDING.txt:47807:gcc -DARCH=x86_64 -DPLATFORM=efi -DSECUREBOOT=0 -fstrength-reduce -fomit-frame-pointer -falign-jumps=1 -falign-loops=1 -falign-functions=1 -m64 -mno-mmx -mno-sse -fshort-wchar -Ui386 -Ulinux -DNVALGRIND -fpie -mno-red-zone -Iinclude -I. -Iarch/x86/include -Iarch/x86_64/include -Iarch/x86_64/include/efi -Os -g -ffreestanding -Wall -W -Wformat-nonliteral -fno-stack-protector -fno-dwarf2-cfi-asm -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables -Wno-address -Wno-stringop-truncation -ffunction-sections -fdata-sections -include include/compiler.h -DASM_TCHAR='@' -DASM_TCHAR_OPS='@' -DCONFIG=qemu -DLOCAL_CONFIG=qemu -DOBJECT=version -DBUILD_NAME="\"82540em.efidrv\"" \ + +New: +ipxe_1.0.0+git-20190125.36a4c85-5ubuntu1~ppa1_amd64.build:43490:gcc -DARCH=x86_64 -DPLATFORM=efi -DSECUREBOOT=0 -fstrength-reduce -fomit-frame-pointer -falign-jumps=1 -falign-loops=1 -falign-functions=1 -m64 -mno-mmx -mno-sse -fshort-wchar -Ui386 -Ulinux -DNVALGRIND -fpie -mno-red-zone -Iinclude -I. -Iarch/x86/include -Iarch/x86_64/include -Iarch/x86_64/include/efi -Os -g -ffreestanding -Wall -W -Wformat-nonliteral -fno-stack-protector -fno-dwarf2-cfi-asm -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables -Wno-address -Wno-stringop-truncation -ffunction-sections -fdata-sections -include include/compiler.h -DASM_TCHAR='@' -DASM_TCHAR_OPS='@' -DCONFIG=qemu -DLOCAL_CONFIG=qemu -DOBJECT=version -DBUILD_NAME="\"82540em.efidrv\"" \ + +But at least on the output size of 82540em.rom I see no difference. +Hence my question - does CONFIG=qemu have no effect on the legacy roms? +If it has an effect what is the recommended config for them - setting it or not? +(Right now I have no more set CONFIG=qemu for legacy roms, but since it would be a change I want to be sure it really is a no-op or at least what is recommended). + +Christian, + +> But it seems for legacy roms like 82540em.rom CONFIG=qemu being set or not doesn't make a +> difference. + +(1) That's my understanding as well; from the following original iPXE commits anyway: + +- a15c0d7e868a ("[efi] Allow user experience to be downgraded", 2015-07-22), +- a200ad462e69 ("[build] Add named configuration for qemu", 2015-07-22). + +(I played a part in those commits existing.) + +(2) However, just to be 100% sure, I recommend *not* changing the CONFIG=<whatever> setting for the traditional BIOS build. If you have had CONFIG=qemu there, then keep it. If you haven't, then don't add it now. + +What matters is that the EFI build be performed with CONFIG=qemu. + +(FWIW, last time I looked, in RHEL downstream we used to build iPXE with CONFIG=qemu covering *both* the traditional BIOS image and the EFI image. But, I don't think that's enough reason for you to diverge now from your previous BIOS image settings in Ubuntu. I don't think you should risk regressions with that. Really, what matters is that the EFI image be built with CONFIG=qemu.) + +Thanks +Laszlo + +Thanks Lazlo, I'll keep the legacy roms as CONFIG=qemu then. +I didn't plan to change this on an SRU anyway, but going forward I wanted to adapt this to be correct. Hearing that in RH you also used CONFIG=qemu covering *both* is kind of re-assuring to keep it like that for now. + +This bug was fixed in the package ipxe - 1.0.0+git-20190125.36a4c85-5ubuntu1 + +--------------- +ipxe (1.0.0+git-20190125.36a4c85-5ubuntu1) groovy; urgency=medium + + * Merge with Debian unstable (LP: #1884758). Remaining changes: + - Split grub integration from ipxe->grub-ipxe. + - d/control: add package and adapt dependencies + - d/[grub-]ipxe.install: move some files to grub-ipxe + - rename d/ipxe.post* to d/grub-ipxe-post* + [updated to match 1.0.0+git-20190125.36a4c85-5] + - d/util/check-rom-sizes, d/rules: check sizes of generated roms to avoid + accidentally breaking KVM live migration on updates/fixes. + [updated for new and dropped rom file names] + - debian/copyright: update copyright information to satisfy lintian + dep5 checks (LP: 1747071) + - Build ROMs for QEMU with CONFIG=qemu (LP: 1789319) + [updated to match 1.0.0+git-20190125.36a4c85-5 and be more verbose] + - debian/patches/handle-dhcp-nack.patch: Handle DHCP NAK and send a + re-discover. (LP 1707999) + - d/p/0005-strip-802.1Q-VLAN-0-priority-tags.patch: Strip 802.1Q VLAN 0 + priority tags; Fixes PXE when VLAN tag is 0. (LP: 1805920) + - d/tree/ipxe/etc/grub.d/20_ipxe: Make grub-ipxe work under UEFI + (LP: 1811496) + - Use ipxe.efi under UEFI + - Save default entry when iPXE is selected + - d/tree/ipxe/etc/grub.d/20_ipxe: Identify ipxe grub menu entry in + an easier way (LP: 1858374) + * Dropped changes + - new upstream release 20190109.133f4c4 [superseded by new upstream] + - new upstream release 20180124.fbe8c52d [superseded by new upstream] + - Revert to the former git snapshot 20150424.a25a16d + [superseded by new upstream] + - This brings back debian/patches/0002-Don-t-use-libiberty.patch as needed + on the older source. + - Adapt d/p/0001-rom-change-banner-timeout.diff.patch to former state to + match old source. + - drop d/p/util-elf2efi-GNU_SOURCE.patch as it was not needed on old + source + - Fix FTBFS with newer perl versions [upstream] + - d/p/0004-fix_no-pie_option.patch: correct -no-pie option + to build without pie + [ still carried before ] + - Install ne.rom as pxe-ne2k_isa.rom + - d/ipxe-qemu.install: Install ne.rom as pxe-ne2k_isa.rom. + - d/ipxe-qemu.links: compat link for ne.rom + [ no more needed, was an old xen hvmloader bug ] + - d/ipxe-qemu.links: Add compat links from /usr/share/qemu + to /usr/lib/ipxe/qemu. + [ no more needed, transition from trusty ] + - add new rom for vmxnet3 (LP 1737211) [in Debian now] + - Add e1000e firmware for qemu. (closes 884240) [in Debian now] + - d/control: ipxe-qemu breaks qemu-system-x86 <2.11 [no more needed] + - d/p/enable-https.patch: Enable HTTPS support. + [resolved per rom type in d/rules now] + * Added changes + - d/rules: only enable https on non EFI roms. This lets EFI handle https + itself and avoids breakage in TPL manipulations (LP: #1882671) + - d/util/check-rom-sizes: fix if size does exactly match + +ipxe (1.0.0+git-20190125.36a4c85-5) unstable; urgency=medium + + * Cleanup src/bin correctly. (closes: #952275) + +ipxe (1.0.0+git-20190125.36a4c85-4) unstable; urgency=medium + + * Use new source format instead of own rules. + * Use debhelper 12. + * Move ipxe.efi into /boot. (closes: #947267) + +ipxe (1.0.0+git-20190125.36a4c85-3) unstable; urgency=medium + + * Combine legacy and EFI rom again. (closes: #947024) + +ipxe (1.0.0+git-20190125.36a4c85-2) unstable; urgency=medium + + * Add Vcs information. + * Include snponly.efi. (closes: #944321) + +ipxe (1.0.0+git-20190125.36a4c85-1) unstable; urgency=medium + + * New snapshot. (closes: #832765, #906365) + * Add e1000e and vmxnet3 firmware for qemu. (closes: #884240, #868124) + + -- Christian Ehrhardt <email address hidden> Tue, 23 Jun 2020 16:23:52 +0200 + +I have prepared a merge proposals and PPA test builds for Focal/Eoan +E-MP => https://code.launchpad.net/~paelzer/ubuntu/+source/ipxe/+git/ipxe/+merge/386647 +E-PPA => https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4126/+packages +F-MP => https://code.launchpad.net/~paelzer/ubuntu/+source/ipxe/+git/ipxe/+merge/386648 +F-PPA => https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4127/+packages + +For Eoan/Focal we need to be sure that the OVMF builds from edk2 can really take over the HTTPS functionality. Because edk2 itself for Debian/Ubuntu only got enabled later in >=Groovy: + + edk2 (2020.05-2) unstable; urgency=medium + * Enable https boot support, thanks to Dimitri John Ledkov. LP: #1883114. + +This comes down to: +-COMMON_FLAGS = -DNETWORK_HTTP_BOOT_ENABLE=TRUE -DSECURE_BOOT_ENABLE=TRUE ++COMMON_FLAGS = -DNETWORK_HTTP_BOOT_ENABLE=TRUE -DNETWORK_TLS_ENABLE -DSECURE_BOOT_ENABLE=TRUE + +Therefore once we drop HTTPS from the ipxe-qemu combined efi roms expecting that OVMF will take over this we need to ensure this can work without above enabling being available in Eoan/Focal as well. + +/me looks for a good way to verify that as I'm unsure if the test mentioned in bug 1883114 will really proved what we need in regard to dropping https here. Maybe an actual OVMF boot via HTTPS should be set up. If there are suggestions for a good way to test that this OVMF-HTTPS-takeover works as expected I'm open to them. + +If it turns out that we need to enable it in edk2/ovmf before we can go on in ipxe/ipxe-qemu we we can upload ipxe-qemu with a versioned BREAKS to the older ovmf package (to avoid https is dropped in 'ipxe-qemu', but not yet enabled in the 'ovmf'). But if needed backporting bug 1883114 becomes a pre-req to SRU this bug here. + +We will need quite some time to ensure this isn't breaking things. +The merge proposal was reviewed and I'll upload to Focal-unapproved now. +The intention is to not have me testing in advance and then having a short time in -proposed. Instead I think for this case it will be helpful to have it in proposed early, but longer to increase the amount of 3rd-party/people testing it. + +Therefore I have added block-proposed tags right away. + +Hello Vladislav, or anyone else affected, + +Accepted ipxe into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/ipxe/1.0.0+git-20190109.133f4c4-0ubuntu3.1 in a few hours, and then in the -proposed repository. + +Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. + +If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed. + +Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! + +N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. + +Test #1: + + * Test the attached OVMF that triggers the bug: +qemu-system-x86_64 -enable-kvm -monitor stdio -drive if=pflash,snapshot=on,format=raw,file=OVMF-14c7ed8b51f6-DEBUG-enabled.fd -global e1000.romfile=/usr/lib/ipxe/qemu/efi-e1000.rom -debugcon file:debug.log -global isa-debugcon.iobase=0x402 + +Focal as-is with ipxe-qemu 1.0.0+git-20190109.133f4c4-0ubuntu3 fails: + +ASSERT /root/edk2/MdeModulePkg/Core/Dxe/Image/Image.c(1676): Image->Tpl == gEfiCurrentTpl + +Upgrading to proposed: +root@f-ipxe:~# apt install ipxe-qemu=1.0.0+git-20190109.133f4c4-0ubuntu3.1 +Reading package lists... Done +Building dependency tree +Reading state information... Done +The following packages will be upgraded: + ipxe-qemu +1 upgraded, 0 newly installed, 0 to remove and 28 not upgraded. +Need to get 903 kB of archives. +After this operation, 1749 kB of additional disk space will be used. +Get:1 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 ipxe-qemu all 1.0.0+git-20190109.133f4c4-0ubuntu3.1 [903 kB] +Fetched 903 kB in 0s (1963 kB/s) +(Reading database ... 47652 files and directories currently installed.) +Preparing to unpack .../ipxe-qemu_1.0.0+git-20190109.133f4c4-0ubuntu3.1_all.deb ... +Unpacking ipxe-qemu (1.0.0+git-20190109.133f4c4-0ubuntu3.1) over (1.0.0+git-20190109.133f4c4-0ubuntu3) ... +Setting up ipxe-qemu (1.0.0+git-20190109.133f4c4-0ubuntu3.1) ... + +With the version from proposed the crash/assert no more happens. + +Test #2 + * We pad the rom sizes to be sure, but never the less double check + migrations between Bionic <-> Focal (known to break on size changes) + +Manual size check (can be seen in build log): +OK: efi-e1000e.rom is exactly 524288 bytes as expected +... + +Seems ok, a regression test doing cross release migrations with proposed enabled is running + + +Test #3: + + * Extra Test: HTTPS boot a uEFI guest with the efi roms from ipxe-qemu + with old/new ipxe-qmeu code. This shall ensure that OVMF can really take + over as-is or if we need bug 1883114 before we can do so. + Details TBD when I'm doing these tests + +I created a q35 guest in libvirt without a disk and set it to run in uEFI mode via OVMF. +Starting that without further setup runs into an EFI loader that can't find anything to boot. + +Start PXE over IPv4 +... +Not Found +Start HTTP Boot over IPv4 +... +Not Found +-> into interactive boot-failed menu + +As I mentioned before in comment #26 Focals EDK2 didn't have HTTPS enabled yet, only in Groovy. + + +Therefure using the OVMF of groovy and the ipxe-qemu package from Focal-proposed I set up a test. + +$ cp ovmf-groovy/usr/share/OVMF/OVMF_VARS.fd test-vars.fd +$ qemu-system-x86_64 -enable-kvm -drive if=pflash,format=raw,readonly,file=/home/ubuntu/ovmf-groovy/usr/share/OVMF/OVMF_CODE.fd -drive if=pflash,format=raw,file=test-vars.fd -monitor stdio + +We can see that in this OVMF build the OVMF device manager has the option to enroll TLScerts. But TBH I haven't ever used this setup to then HTTPS boot through EFI/OVMF. + + +I found [1] but before going through all the lengths to set this up I wonder for further regression testing I wonder if there at all was a way to get HTTPS boot working in EFI mode with: +a) https enabled /usr/lib/ipxe/qemu/efi-e1000e.rom +b) not https enabled /usr/share/OVMF/OVMF_CODE.fd + + +I'm a bit lost in all the rom/boot/https/loader options. +I beg your pardon but @Lazlo do you know if above mentioned way existed and might - now that we take https away from (a) - be regressing? +If so which way would this need to be set up to be tested? +Is [1][2] a proper way to exercise this in Focal "using the https in e1000e" or would that only work with the HTTPS enabled OVMF of groovy? + +[1]: https://en.opensuse.org/UEFI_HTTPBoot_Server_Setup +[2]: https://edk2-docs.gitbook.io/getting-started-with-uefi-https-boot-on-edk-ii/introduction + +P.S. cross release migration tests still running + + +The TPL manipulation issue in iPXE is fixed as of commit http://github.com/ipxe/ipxe/commit/2ae5d4338 + +Building an iPXE ROM with HTTPS enabled will now initialise with no problems in qemu. + +Michael + + +Hello Christian, + +For *some* form of UEFI HTTPS boot, you have to enable *at least one* of +the {edk2, iPXE} HTTPS stacks. I'm unfamiliar with the Ubuntu releases, +but my understanding is the following: + +Ubuntu release edk2 HTTPS enabled iPXE HTTPS enabled iPXE TPL regression +-------------- ------------------ ------------------ ------------------- +Bionic no <don't know> no +Focal no yes yes +Groovy yes (bug 1883114) no (this bug) masked (this bug) + +In Groovy, you can work around the iPXE TPL regression by disabling the +iPXE HTTPS stack (i.e., in the efi-e1000e option ROM). Because, you can +effectively "replace" it with the edk2 HTTPS stack in the platform +firmware (in the OVMF binary), per bug 1883114. + +In Focal, if you do the same to iPXE, you can't fall back to the edk2 +HTTPS stack in OVMF -- because bug 1883114 is out of scope for Focal, +AIUI. + +However, disabling the iPXE HTTPS stack in Focal would not cause a +regression, in my opinion. That's because in Focal you can't boot the +"OVMF + efi-e1000e" combination *at all* -- you don't get far enough in +the boot process to even *attempt* HTTPS boot (or a boot from another +kind of media, for that matter). + +Thus in Focal, no form of *UEFI boot* (HTTPS or otherwise) has ever +worked, so there's nothing to regress by disabling the iPXE HTTPS stack +in "efi-e1000e.rom". + + +Sorry about the malformed table in comment 33 -- that's not my doing. I laid it out correctly; Launchpad messed it up by squeezing whitespace. Here it is again, using dots rather than spaces. + +Ubuntu.release..edk2.HTTPS.enabled..iPXE.HTTPS.enabled..iPXE.TPL.regression +--------------..------------------..------------------..------------------- +Bionic..........no..................<don't.know>........no................. +Focal...........no..................yes.................yes................ +Groovy..........yes.(bug.1883114)...no.(this.bug).......masked.(this.bug).. + + +Regression tests completed, no issues migrating in/out of updates nor between releases due to changing sizes (That mostly covers the non EFI roms thou). + +I want to also do some more manual tests with EFI guests in that regard. + +Hi Michael, thank you for the fix, and for mentioning it here. I didn't ignore your comment 32 when I was writing what would become comments 33 and 34 -- I think we must have been writing our comments in parallel, and I simply didn't see yours. + +Christian, now you should be able to resolve this LP ticket without modifying anything on the packaging side, by backporting upstream iPXE commit 2ae5d4338. + +Thanks! + + + <loader readonly='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.fd</loader> + <nvram template='/usr/share/OVMF/OVMF_VARS.fd'>/var/lib/uvtool/libvirt/images/bionic.VARS.fd</nvram> + +makes it run eif ovmf EFI like +-drive file=/usr/share/OVMF/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on -drive file=/var/lib/uvtool/libvirt/images/bionic.VARS.fd,if=pflash,format=raw,unit=1 + +Still mgriates well from Bionic -> Focal and Back +B +$ virsh migrate --unsafe --live bionic qemu+ssh://10.225.185.44/system +F +$ virsh migrate --unsafe --live bionic qemu+ssh://10.225.185.35/system +B +$ virsh console bionic +Connected to domain bionic +Escape character is ^] +Ubuntu 18.04.4 LTS bionic ttyS0 +bionic login: + +So that also works well. +The only possible option missing to be tested is the real https boot via Focals OVMF (which didn't have https enabled), but unless someone comes back explaining that there is an odd combination that could have got that going we should be good. + +Let is sit a bit more time in proposed to be sure and wait for feedback. +Then we can declare it fully verified. + +I saw your update on refresh - yeah despite feeling sort of safe on the change as-is this fix seems even better for an SRU. + +Let me get that into groovy (there the packaging change made sense, no need to turn that back). +And from there SRU it to Focal. + + +Thank you Michael and Lazlo for the work and discussion on this. + +fix as URL => https://github.com/ipxe/ipxe/commit/2ae5d4338661b65c63eb5cb1a96e5b803fe7d620 + +This bug was fixed in the package ipxe - 1.0.0+git-20190125.36a4c85-5ubuntu2 + +--------------- +ipxe (1.0.0+git-20190125.36a4c85-5ubuntu2) groovy; urgency=medium + + * d/p/lp-1882671-efi-Raise-TPL-during-driver-entry-point.patch: fix the + formerly avoided efi TPL issues (LP: #1882671) + + -- Christian Ehrhardt <email address hidden> Thu, 16 Jul 2020 14:36:54 +0200 + +Fix uploaded for SRU to focal-unapproved. + +Hello Vladislav, or anyone else affected, + +Accepted ipxe into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/ipxe/1.0.0+git-20190109.133f4c4-0ubuntu3.2 in a few hours, and then in the -proposed repository. + +Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. + +If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed. + +Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! + +N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. + +Testing the actual case: +$ dpkg -S /usr/lib/ipxe/qemu/efi-e1000.rom +ipxe-qemu: /usr/lib/ipxe/qemu/efi-e1000.rom + +root@f-ipxe:~# apt-cache policy ipxe-qemu +ipxe-qemu: + Installed: 1.0.0+git-20190109.133f4c4-0ubuntu3.2 + Candidate: 1.0.0+git-20190109.133f4c4-0ubuntu3.2 + Version table: + *** 1.0.0+git-20190109.133f4c4-0ubuntu3.2 500 + 500 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 Packages + 100 /var/lib/dpkg/status + 1.0.0+git-20190109.133f4c4-0ubuntu3.2 500 + 500 http://ppa.launchpad.net/ci-train-ppa-service/4156/ubuntu focal/main amd64 Packages + 1.0.0+git-20190109.133f4c4-0ubuntu3 500 + 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages + +$ qemu-system-x86_64 -enable-kvm -monitor stdio -drive if=pflash,snapshot=on,format=raw,file=OVMF-14c7ed8b51f6-DEBUG-enabled.fd -global e1000.romfile=/usr/lib/ipxe/qemu/efi-e1000.rom -debugcon file:debug.log -global isa-debugcon.iobase=0x402 + +With the fix this now boots through to the actual EFI prompt and tries to initialize boot options. The log file no more lists the assertion. + +Testing the sizes went well, they are int he right size buckets as they were before (no major change by the patch). + +Note: We have not touched the HTTPs capability in the SRU which makes this much saver in this try#2. Therefore also the re-testing of these isn't needed this time. + +This overall LGTM and was in proposed for an extra-while without negative feedback, setting verification-done. + +This bug was fixed in the package ipxe - 1.0.0+git-20190109.133f4c4-0ubuntu3.2 + +--------------- +ipxe (1.0.0+git-20190109.133f4c4-0ubuntu3.2) focal; urgency=medium + + * Revert the changes of the non released version + 1.0.0+git-20190109.133f4c4-0ubuntu3.1 as there is a less impactful + fix more suited for an SRU. + * d/p/lp-1882671-efi-Raise-TPL-during-driver-entry-point.patch: fix the + formerly avoided efi TPL issues (LP: #1882671) + +ipxe (1.0.0+git-20190109.133f4c4-0ubuntu3.1) focal; urgency=medium + + * only enable https on non EFI roms. This lets EFI/OVMF handle https + itself and avoids breakage in TPL manipulations (LP: 1882671) + - d/p/enable-https.patch: drop old global way to Enable HTTPS support + - d/rules: enable https on non EFI roms. + - d/util/check-rom-sizes: fix if size does exactly match + + -- Christian Ehrhardt <email address hidden> Thu, 16 Jul 2020 16:51:30 +0200 + +The verification of the Stable Release Update for ipxe has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. + +Per comment #32, fixed in upstream iPXE commit 2ae5d4338, setting ticket status for iPXE to "Fix Committed". + diff --git a/results/classifier/108/other/1882784 b/results/classifier/108/other/1882784 new file mode 100644 index 00000000..1a2e53f6 --- /dev/null +++ b/results/classifier/108/other/1882784 @@ -0,0 +1,80 @@ +socket: 0.820 +network: 0.799 +permissions: 0.797 +files: 0.774 +device: 0.762 +graphic: 0.751 +vnc: 0.741 +PID: 0.739 +boot: 0.735 +other: 0.703 +debug: 0.687 +performance: 0.683 +KVM: 0.671 +semantic: 0.630 + +Legacy IGD passthrough in QEMU 5 disabled + +Bug with tag v5.0.0, or commit fdd76fecdde1ad444ff4deb7f1c4f7e4a1ef97d6 + +As of QEMU 5 Legacy IGD PT is no longer working. + +Host is a Xeon E3-1226 v3 and my method to test is to run the following: + +./qemu-system-x86_64 \ + -device 'pci-bridge,id=pci.1,chassis_nr=1,bus=pci.0,addr=0x1f' \ + -device 'vfio-pci,host=00:02.0,addr=02.0' \ + -L '/usr/share/kvm' \ + -nographic \ + -vga none \ + -nodefaults + +in the hope of seeing a "IGD device 0000:00:02.0 cannot support legacy mode due to existing devices at address 1f.0" error. + +The culprit appears to be this commit: + +https://github.com/qemu/qemu/commit/29d62771c81d8fd244a67c14a1d968c268d3fb19 + +Specifically the following block in pci-quirks.c: + +#ifdef CONFIG_VFIO_IGD + vfio_probe_igd_bar4_quirk(vdev, nr); +#endif + +as the kconfig variable CONFIG_VFIO_IGD doesn't appear to be available outside of makefiles as described here: https://qemu.weilnetz.de/doc/devel/kconfig.html. I can confirm that the igd code is being pulled in as removing this check, as would defining the variable I presume, makes Legacy IGD PT work again (ie I see the expected "existing devices" error). + +I first spotted this in Proxmox, but have confirmed the bug by building QEMU sources. + +Hi! That info in kconfig.html is not up to date anymore, we are generating now #defines for the Kconfig switches. And in my build tree, I can see: + +$ grep CONFIG_VFIO_IGD *-softmmu/*.h +x86_64-softmmu/config-devices.h:#define CONFIG_VFIO_IGD 1 + +... what's missing in that file is simply a "#include "config-devices.h" ... sorry, that fell somehow through the cracks. I'll prepare a patch for that. + +Looks similar to https://bugs.launchpad.net/qemu/+bug/1879175 + +Looks the same, although the title was misleading so I missed it. + +@Thomas, I used the same patch and verified that it works (I know you don't pick up patches here but I presume you have your own): + +diff --git a/hw/vfio/pci-quirks.c b/hw/vfio/pci-quirks.c +index 2d348f8237..a633df965e 100644 +--- a/hw/vfio/pci-quirks.c ++++ b/hw/vfio/pci-quirks.c +@@ -25,6 +25,7 @@ + #include "hw/qdev-properties.h" + #include "pci.h" + #include "trace.h" ++#include "config-devices.h" + + /* + * List of device ids/vendor ids for which to disable + + +Patch is on the list now: +https://lists.gnu.org/archive/html/qemu-devel/2020-06/msg02567.html + +Patch has been included: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=643a4eacef87a318c + diff --git a/results/classifier/108/other/1883083 b/results/classifier/108/other/1883083 new file mode 100644 index 00000000..642e75f9 --- /dev/null +++ b/results/classifier/108/other/1883083 @@ -0,0 +1,67 @@ +graphic: 0.816 +performance: 0.767 +files: 0.745 +device: 0.706 +permissions: 0.674 +KVM: 0.613 +PID: 0.605 +socket: 0.600 +network: 0.593 +vnc: 0.575 +semantic: 0.537 +boot: 0.474 +other: 0.420 +debug: 0.372 + +QEMU: block/vvfat driver issues + +Nathan Huckleberry <email address hidden> has reported following issues in the block/vvfat driver for the virtual VFAT file system image, used to share a host system directory with a guest VM. + +Please note: + -> https://www.qemu.org/docs/master/system/images.html#virtual-fat-disk-images + +Virtual VFAT read/write support is available only for (beta) testing purposes. + +Following issues are reproducible with: + + host)$ ./bin/qemu-system-x86_64 -nographic -enable-kvm \ + -drive file=fat:rw:/tmp/var/run/,index=2 -m 2048 /var/lib/libvirt/images/f27vm.qcow2 + + guest)# mount -t vfat /dev/sdb1 /mnt/ + +The attached reproducers (run inside a guest) include: + +1. dir.sh: - directory traversal on the host + - It creates a file under /mnt/yyyy + - Then edits the VFAT directory entry to make it -> /mnt/../y + - The handle_renames_and_mkdirs() routine does not check this new file name + and creates a file outside of the shared directory on the host + +2. dos.sh: hits an assertion failure in vvfat driver + - Creates a deep directory tree like - /mnt/0/1/2/3/4/5/6/../29/30/ + - While updating vvfat commits, driver hits an assertion in + handle_renames_and_mkdirs + ... + } else if (commit->action == ACTION_MKDIR) { + ... + assert(j < s->mapping.next); <== it fails + +3. read.sh: reads past vvfat directory entries + - Creates a file with: echo "x" > /mnt/a + - Reads past VVFAT directory entry structure with + + # head -c 1000000 $MNTDEV | xxd | grep x -A 512 + + - It may disclose some heap addresses. + +4. write.sh: heap buffer overflow + - Creates large number of files as /mnt/file[1..35] + - while syncing directory tree with the host, driver hits an overflow + while doing memmove(3) in array_roll() routine + + + +This ticket has been transferred to QEMU's new bug tracker here: +https://gitlab.com/qemu-project/qemu/-/issues/272 +... thus closing the issue on Launchpad now. + diff --git a/results/classifier/108/other/1883268 b/results/classifier/108/other/1883268 new file mode 100644 index 00000000..01bdb1d4 --- /dev/null +++ b/results/classifier/108/other/1883268 @@ -0,0 +1,114 @@ +permissions: 0.893 +semantic: 0.890 +graphic: 0.883 +other: 0.871 +device: 0.868 +performance: 0.865 +socket: 0.841 +debug: 0.837 +PID: 0.829 +boot: 0.810 +network: 0.808 +vnc: 0.787 +files: 0.773 +KVM: 0.694 + +random errors on aarch64 when executing __aarch64_cas8_acq_rel + +Hello, + +Since I upgraded to qemu-5.0 when executing the GCC testsuite, +I've noticed random failures of g++.dg/ext/sync-4.C. + +I'm attaching the source of the testcase, the binary executable and the qemu traces (huge, 111MB!) starting at main (with qemu-aarch64 -cpu cortex-a57 -R 0 -d in_asm,int,exec,cpu,unimp,guest_errors,nochain) + +The traces where generated by a CI build, I built the executable manually but I expect it to be the same as the one executed by CI. + +In seems the problem occurs in f13, which leads to a call to abort() + +The preprocessed version of f13/t13 are as follows: +static bool f13 (void *p) __attribute__ ((noinline)); +static bool f13 (void *p) +{ + return (__sync_bool_compare_and_swap((ditype*)p, 1, 2)); +} +static void t13 () +{ + try { + f13(0); + } + catch (...) { + return; + } + abort(); +} + + +When looking at the execution traces at address 0x00400c9c, main calls f13, which in turn calls __aarch64_cas8_acq_rel (at 0x00401084) +__aarch64_cas8_acq_rel returns to f13 (address 0x0040113c), then f13 returns to main (0x0040108c) which then calls abort (0x00400ca0) + +I'm not quite sure what's wrong :-( + +I've not noticed such random problems with native aarch64 hardware. + + + + + + + +FWIW, I cannot reproduce the problem with x86_64 host, +but I can reproduce it on a 32-bit i686 host. + +There's nothing wrong with the atomic operation, which +makes sense since it's against a NULL pointer. The +problem that I see is in the unwinding -- the catch +never happens and std::terminate gets called. + +There must be some sort of 32-bit TCG error though, +because the same binary works on x86_64 host. + +The most confusing thing about this test case is that +12 previous throws work correctly, but the 13th fails. + +Hi Richard, + +Thanks for taking a look and confirming that you managed to reproduce the problem. +I forgot to mention that I'm using x86_64 hosts, not i686. I hope there are not two unrelated issues... + + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +Opened ticket on gitlab: https://gitlab.com/qemu-project/qemu/-/issues/333 + + +Thanks for moving the ticket to gitlab! ... so I'm closing this on Launchpad now. + diff --git a/results/classifier/108/other/1883560 b/results/classifier/108/other/1883560 new file mode 100644 index 00000000..92e4f402 --- /dev/null +++ b/results/classifier/108/other/1883560 @@ -0,0 +1,315 @@ +other: 0.961 +performance: 0.957 +debug: 0.954 +semantic: 0.949 +graphic: 0.947 +permissions: 0.946 +device: 0.944 +PID: 0.938 +vnc: 0.938 +network: 0.935 +files: 0.933 +KVM: 0.928 +socket: 0.925 +boot: 0.894 + +mips linux-user builds occasionly crash randomly only to be fixed by a full clean re-build + +From time to time I find check-tcg crashes with a one of the MIPS binaries. The last time it crashed was running the test: + + ./mips64el-linux-user/qemu-mips64el ./tests/tcg/mips64el-linux-user/threadcount + +Inevitably after some time noodling around wondering what could be causing this weird behaviour I wonder if it is a build issue. I wipe all the mips* build directories, re-run configure and re-build and voila problem goes away. + +It seems there must be some sort of build artefact which isn't being properly re-generated on a build update which causes weird problems. Additional data point if I: + + rm -rf mips64el-linux-user + ../../configure + make + +then I see failures in mip32 builds - eg: + + GEN mipsn32el-linux-user/config-target.h + In file included from /home/alex/lsrc/qemu.git/linux-user/syscall_defs.h:10, + from /home/alex/lsrc/qemu.git/linux-user/qemu.h:16, + from /home/alex/lsrc/qemu.git/linux-user/linuxload.c:5: + /home/alex/lsrc/qemu.git/linux-user/mips64/syscall_nr.h:1: error: unterminated #ifndef + #ifndef LINUX_USER_MIPS64_SYSCALL_NR_H + + make[1]: *** [/home/alex/lsrc/qemu.git/rules.mak:69: linux-user/linuxload.o] Error 1 + make[1]: *** Waiting for unfinished jobs.... + +which implies there is a cross dependency between different targets somewhere. If I executed: + + rm -rf mips* + +before re-configuring and re-building then everything works again. + +syscall_nr.h is generated from syscall_n32.tbl and syscall_n64.tbl, so it should be under your build directory, not the source directory. + +But if you did a build before the change, the dependency file .d will store a path in the src dir and the new file will not be generated in the build dir but in the previous place. + +linux-user/mips64/Makefile.objs: + +ifeq ($(TARGET_SYSTBL_ABI),n32) +%/syscall_nr.h: $(SRC_PATH)/linux-user/$(TARGET_ABI_DIR)/syscall_n32.tbl $(syshdr) + $(call quiet-command, sh $(syshdr) $< $@ n32 "" 6000,"GEN","$@") +endif +ifeq ($(TARGET_SYSTBL_ABI),n64) +%/syscall_nr.h: $(SRC_PATH)/linux-user/$(TARGET_ABI_DIR)/syscall_n64.tbl $(syshdr) + $(call quiet-command, sh $(syshdr) $< $@ n64 "" 5000,"GEN","$@") +endif + +Normally this is cleaned up by the configure with: + +for arch in alpha hppa m68k xtensa sh4 microblaze arm ppc s390x sparc sparc64 \ + i386 x86_64 mips mips64 ; do + # remove the file if it has been generated in the source directory + rm -f "${source_path}/linux-user/${arch}/syscall_nr.h" + # remove the dependency files + for target in ${arch}*-linux-user ; do + test -d "${target}" && find "${target}" -type f -name "*.d" \ + -exec grep -q "${source_path}/linux-user/${arch}/syscall_nr.h" {} \; \ + -print | while read file ; do rm "${file}" "${file%.d}.o" ; done + done +don + + +OK the syscall_nr failure is a red hearing - that was affected by a stray generated file in my source tree (maybe I accidentally ran make in the top directory?). + +However I've just run into the mips64le-linux-user crash again which didn't go away until I deleted all mips* directories and rebuilt. + +четвртак, 18. јун 2020., Cornelia Huck <email address hidden> је написао/ла: + +> On Mon, 15 Jun 2020 15:18:48 -0000 +> Alex Bennée <email address hidden> wrote: +> +> > Public bug reported: +> > +> > >From time to time I find check-tcg crashes with a one of the MIPS +> > binaries. The last time it crashed was running the test: +> > +> > ./mips64el-linux-user/qemu-mips64el ./tests/tcg/mips64el-linux- +> > user/threadcount +> > +> > Inevitably after some time noodling around wondering what could be +> > causing this weird behaviour I wonder if it is a build issue. I wipe all +> > the mips* build directories, re-run configure and re-build and voila +> > problem goes away. +> > +> > It seems there must be some sort of build artefact which isn't being +> > properly re-generated on a build update which causes weird problems. +> > Additional data point if I: +> > +> > rm -rf mips64el-linux-user +> > ../../configure +> > make +> > +> > then I see failures in mip32 builds - eg: +> > +> > GEN mipsn32el-linux-user/config-target.h +> > In file included from /home/alex/lsrc/qemu.git/ +> linux-user/syscall_defs.h:10, +> > from /home/alex/lsrc/qemu.git/linux-user/qemu.h:16, +> > from /home/alex/lsrc/qemu.git/ +> linux-user/linuxload.c:5: +> > /home/alex/lsrc/qemu.git/linux-user/mips64/syscall_nr.h:1: error: +> unterminated #ifndef +> > #ifndef LINUX_USER_MIPS64_SYSCALL_NR_H +> > +> > make[1]: *** [/home/alex/lsrc/qemu.git/rules.mak:69: +> linux-user/linuxload.o] Error 1 +> > make[1]: *** Waiting for unfinished jobs.... +> > +> > which implies there is a cross dependency between different targets +> > somewhere. If I executed: +> > +> > rm -rf mips* +> > +> > before re-configuring and re-building then everything works again. +> > +> > ** Affects: qemu +> > Importance: Undecided +> > Status: New +> > +> > +> > ** Tags: build linux-user mips +> > +> +> FWIW, this does not seem to be a mips-only issue: I'm seeing the +> threadcount test fail with s390x-linux-user as well, and it also goes +> away (only) if I purge the build directory, re-configure, and re-build. +> +> +Valuable info! + + +четвртак, 18. јун 2020., Cornelia Huck <email address hidden> је написао/ла: + +> On Mon, 15 Jun 2020 15:18:48 -0000 +> Alex Bennée <email address hidden> wrote: +> +> > Public bug reported: +> > +> > >From time to time I find check-tcg crashes with a one of the MIPS +> > binaries. The last time it crashed was running the test: +> > +> > ./mips64el-linux-user/qemu-mips64el ./tests/tcg/mips64el-linux- +> > user/threadcount +> > +> > Inevitably after some time noodling around wondering what could be +> > causing this weird behaviour I wonder if it is a build issue. I wipe all +> > the mips* build directories, re-run configure and re-build and voila +> > problem goes away. +> > +> > It seems there must be some sort of build artefact which isn't being +> > properly re-generated on a build update which causes weird problems. +> > Additional data point if I: +> > +> > rm -rf mips64el-linux-user +> > ../../configure +> > make +> > +> > then I see failures in mip32 builds - eg: +> > +> > GEN mipsn32el-linux-user/config-target.h +> > In file included from /home/alex/lsrc/qemu.git/ +> linux-user/syscall_defs.h:10, +> > from /home/alex/lsrc/qemu.git/linux-user/qemu.h:16, +> > from /home/alex/lsrc/qemu.git/ +> linux-user/linuxload.c:5: +> > /home/alex/lsrc/qemu.git/linux-user/mips64/syscall_nr.h:1: error: +> unterminated #ifndef +> > #ifndef LINUX_USER_MIPS64_SYSCALL_NR_H +> > +> > make[1]: *** [/home/alex/lsrc/qemu.git/rules.mak:69: +> linux-user/linuxload.o] Error 1 +> > make[1]: *** Waiting for unfinished jobs.... +> > +> > which implies there is a cross dependency between different targets +> > somewhere. If I executed: +> > +> > rm -rf mips* +> > +> > before re-configuring and re-building then everything works again. +> > +> > ** Affects: qemu +> > Importance: Undecided +> > Status: New +> > +> > +> > ** Tags: build linux-user mips +> > +> +> FWIW, this does not seem to be a mips-only issue: I'm seeing the +> threadcount test fail with s390x-linux-user as well, and it also goes +> away (only) if I purge the build directory, re-configure, and re-build. +> +> +> +Alex, Cornelia, + +Do you perhaps recall how did you obtain the original binaries (those with +the problem)? What would be your typical workflow? Perhaps "git-pull + +make" on existing, but not latest source tree? + +Thanks, +Aleksandar + + +Aleksandar, Alex, see comment #1. + +I think the problem happens because I moved the syscall_nr.h from source directory to build directory. If source directory is not cleaned up correctly, the build will not generate the new header in the build directory but in source directory and some targets that need 32bit, 64bit or a new API will only use the first one generated (as in this case they are all at the same place). + +See the following PR: https://<email address hidden>/ + + +Cornelia Huck <email address hidden> writes: + +> On Thu, 18 Jun 2020 19:00:34 +0200 +> Aleksandar Markovic <email address hidden> wrote: +> +>> четвртак, 18. јун 2020., Cornelia Huck <email address hidden> је написао/ла: +>> +>> > On Mon, 15 Jun 2020 15:18:48 -0000 +>> > Alex Bennée <email address hidden> wrote: +>> > +>> > > Public bug reported: +>> > > +>> > > >From time to time I find check-tcg crashes with a one of the MIPS +>> > > binaries. The last time it crashed was running the test: +>> > > +>> > > ./mips64el-linux-user/qemu-mips64el ./tests/tcg/mips64el-linux- +>> > > user/threadcount +>> > > +>> > > Inevitably after some time noodling around wondering what could be +>> > > causing this weird behaviour I wonder if it is a build issue. I wipe all +>> > > the mips* build directories, re-run configure and re-build and voila +>> > > problem goes away. +>> > > +>> > > It seems there must be some sort of build artefact which isn't being +>> > > properly re-generated on a build update which causes weird problems. +>> > > Additional data point if I: +>> > > +>> > > rm -rf mips64el-linux-user +>> > > ../../configure +>> > > make +>> > > +>> > > then I see failures in mip32 builds - eg: +>> > > +>> > > GEN mipsn32el-linux-user/config-target.h +>> > > In file included from /home/alex/lsrc/qemu.git/ +>> > linux-user/syscall_defs.h:10, +>> > > from /home/alex/lsrc/qemu.git/linux-user/qemu.h:16, +>> > > from /home/alex/lsrc/qemu.git/ +>> > linux-user/linuxload.c:5: +>> > > /home/alex/lsrc/qemu.git/linux-user/mips64/syscall_nr.h:1: error: +>> > unterminated #ifndef +>> > > #ifndef LINUX_USER_MIPS64_SYSCALL_NR_H +>> > > +>> > > make[1]: *** [/home/alex/lsrc/qemu.git/rules.mak:69: +>> > linux-user/linuxload.o] Error 1 +>> > > make[1]: *** Waiting for unfinished jobs.... +>> > > +>> > > which implies there is a cross dependency between different targets +>> > > somewhere. If I executed: +>> > > +>> > > rm -rf mips* +>> > > +>> > > before re-configuring and re-building then everything works again. +>> > > +>> > > ** Affects: qemu +>> > > Importance: Undecided +>> > > Status: New +>> > > +>> > > +>> > > ** Tags: build linux-user mips +>> > > +>> > +>> > FWIW, this does not seem to be a mips-only issue: I'm seeing the +>> > threadcount test fail with s390x-linux-user as well, and it also goes +>> > away (only) if I purge the build directory, re-configure, and re-build. +>> > +>> > +>> > +>> Alex, Cornelia, +>> +>> Do you perhaps recall how did you obtain the original binaries (those with +>> the problem)? What would be your typical workflow? Perhaps "git-pull + +>> make" on existing, but not latest source tree? +> +> Just a bog-standard "pull some stuff, do make, create a branch and put +> some patches on it, do make, switch to another branch, do make, etc". No +> advanced fiddling with git history, doing make on a subtree, etc. + +Same here. As I say the syscall_nr breakage was a different one. I'll +regularly just advance my tree and find this sort of breakage. + +-- +Alex Bennée + + +Does this problem still persist after we've switched the build system to meson? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1883593 b/results/classifier/108/other/1883593 new file mode 100644 index 00000000..10c0e21c --- /dev/null +++ b/results/classifier/108/other/1883593 @@ -0,0 +1,69 @@ +performance: 0.819 +boot: 0.695 +other: 0.618 +semantic: 0.611 +device: 0.601 +vnc: 0.549 +PID: 0.541 +graphic: 0.527 +permissions: 0.508 +socket: 0.475 +files: 0.462 +network: 0.460 +debug: 0.456 +KVM: 0.080 + +Windows XP takes much longer to boot in TCG mode since 5.0 + +Since upgrading from 4.2 to 5.0, a Windows XP VM takes much longer to boot. + +It hangs about three minutes on "welcome" screen with the blue background, while previously the total boot time was less than a minute. + +The issue only happens in TCG mode (not with KVM) and also happens with the current master which includes the uring patches (7d3660e7). + +I can reproduce this issue with a clean XP install with no flags other than `-m 2G`. After booting, the performance seems to be normal. + +Are you able to bisect between 4.2 and 5.0 and identify what introduces the slow down? + +Bisecting showed that this is the bad commit: + + b55f54bc965607c45b5010a107a792ba333ba654 exec: flush CPU TB cache in breakpoint_invalidate + +And I can indeed confirm that this commit is much slower than the previous one, e18e5501d8ac692d32657a3e1ef545b14e72b730. + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting older bugs to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system. + +Thank you and sorry for the inconvenience. + + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/404 + + diff --git a/results/classifier/108/other/1883728 b/results/classifier/108/other/1883728 new file mode 100644 index 00000000..1a56be08 --- /dev/null +++ b/results/classifier/108/other/1883728 @@ -0,0 +1,178 @@ +other: 0.973 +vnc: 0.969 +KVM: 0.949 +permissions: 0.938 +debug: 0.937 +semantic: 0.933 +device: 0.931 +PID: 0.928 +socket: 0.923 +graphic: 0.923 +performance: 0.918 +network: 0.900 +boot: 0.897 +files: 0.884 + +address_space_unmap: Assertion `mr != NULL' failed. + +To reproduce run the QEMU with the following command line: +``` +qemu-system-x86_64 -cdrom hypertrash_os_bios_crash.iso -nographic -m 100 -enable-kvm -device virtio-gpu-pci -device nec-usb-xhci -device usb-audio +``` + +QEMU Version: +``` +# qemu-5.0.0 +$ ./configure --target-list=x86_64-softmmu --enable-sanitizers; make +$ x86_64-softmmu/qemu-system-x86_64 --version +QEMU emulator version 5.0.0 +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers +``` + + + +Here's a qtest reproducer: + +cat << EOF | ./i386-softmmu/qemu-system-i386 \ +-device nec-usb-xhci -trace usb\* \ +-device usb-audio -device usb-storage,drive=mydrive \ +-drive id=mydrive,file=null-co://,size=2M,format=raw,if=none \ +-nodefaults -nographic -qtest stdio +outl 0xcf8 0x80001016 +outl 0xcfc 0x3c319f0d +outl 0xcf8 0x80001004 +outl 0xcfc 0xc77695e +writel 0x9f0d000000000040 0xffffd855 +write 0x1d 0x1 0x27 +write 0x2d 0x1 0x2e +write 0x17232 0x1 0x03 +write 0x17254 0x1 0x05 +write 0x17276 0x1 0x72 +write 0x17278 0x1 0x02 +write 0x3d 0x1 0x27 +write 0x40 0x1 0x2e +write 0x41 0x1 0x72 +write 0x42 0x1 0x01 +write 0x4d 0x1 0x2e +write 0x4f 0x1 0x01 +writeq 0x9f0d000000002000 0x5c05140100000000 +writeq 0x9f0d000000002000 0x5c05140100000000 +write 0x2008d 0x1 0x13 +writeq 0x9f0d000000002000 0x100ef0100000009 +write 0x200ad 0x1 0x27 +write 0x200bd 0x1 0x5c +write 0x200cd 0x1 0x2e +write 0x200dd 0x1 0x2f +write 0x200e8 0x1 0x08 +write 0x200ec 0x1 0xfe +write 0x200ed 0x1 0x08 +write 0x200fd 0x1 0x05 +write 0x2010d 0x1 0x2e +write 0x2011d 0x1 0x2f +write 0x2012d 0x1 0x08 +write 0x20137 0x1 0x5e +write 0x2013a 0x1 0x2f +write 0x2013d 0x1 0x05 +write 0x2014d 0x1 0x13 +writeq 0x9f0d000000002000 0x100ef0100000009 +EOF + +... +[S +0.017146] OK +[R +0.017149] writeq 0x9f0d000000002000 0x5c05140100000000 +30899@1597183147.299108:usb_xhci_doorbell_write off 0x0000, val 0x00000000 +30899@1597183147.299112:usb_xhci_fetch_trb addr 0x0000000000000000, TRB_RESERVED, p 0x0000000000000000, s 0x00000000, c 0x00000000 +30899@1597183147.299115:usb_xhci_doorbell_write off 0x0004, val 0x5c051401 +OK +[S +0.017162] OK +[R +0.017166] writeq 0x9f0d000000002000 0x5c05140100000000 +30899@1597183147.299124:usb_xhci_doorbell_write off 0x0000, val 0x00000000 +30899@1597183147.299126:usb_xhci_fetch_trb addr 0x0000000000000010, CR_ENABLE_SLOT, p 0x0000000000000000, s 0x00000000, c 0x00002700 +30899@1597183147.299129:usb_xhci_slot_enable slotid 1 +30899@1597183147.299132:usb_xhci_fetch_trb addr 0x0000000000000020, CR_ADDRESS_DEVICE, p 0x0000000000000000, s 0x00000000, c 0x00002e00 +30899@1597183147.299134:usb_xhci_fetch_trb addr 0x0000000000000030, CR_ENABLE_SLOT, p 0x0000000000000000, s 0x00000000, c 0x00002700 +30899@1597183147.299137:usb_xhci_slot_enable slotid 2 +30899@1597183147.299139:usb_xhci_fetch_trb addr 0x0000000000000040, CR_ADDRESS_DEVICE, p 0x000000000001722e, s 0x00000000, c 0x01002e00 +30899@1597183147.299144:usb_xhci_slot_address slotid 1, port 1 +30899@1597183147.299148:usb_xhci_ep_enable slotid 1, epid 1 +30899@1597183147.299151:usb_xhci_fetch_trb addr 0x0000000000000050, TRB_RESERVED, p 0x0000000000000000, s 0x00000000, c 0x00000000 +30899@1597183147.299154:usb_xhci_doorbell_write off 0x0004, val 0x5c051401 +30899@1597183147.299157:usb_xhci_ep_kick slotid 1, epid 1, streamid 23557 +30899@1597183147.299161:usb_xhci_fetch_trb addr 0x0000000000020070, TRB_RESERVED, p 0x0000000000000000, s 0x00000000, c 0x00000000 +OK +[S +0.017210] OK +[R +0.017214] write 0x2008d 0x1 0x13 +OK +[S +0.017219] OK +[R +0.017223] writeq 0x9f0d000000002000 0x100ef0100000009 +30899@1597183147.299181:usb_xhci_doorbell_write off 0x0000, val 0x00000009 +30899@1597183147.299183:usb_xhci_doorbell_write off 0x0004, val 0x0100ef01 +30899@1597183147.299185:usb_xhci_ep_kick slotid 1, epid 1, streamid 256 +30899@1597183147.299189:usb_xhci_fetch_trb addr 0x0000000000020080, TR_STATUS, p 0x0000000000000000, s 0x00000000, c 0x00001300 +30899@1597183147.299191:usb_xhci_xfer_start 0x5622548f9760: slotid 1, epid 1, streamid 0 +TRB_SETUP 1300 1300 1300 0 +30899@1597183147.299196:usb_xhci_fetch_trb addr 0x0000000000020090, TRB_RESERVED, p 0x0000000000000000, s 0x00000000, c 0x00000000 +OK +[S +0.017244] OK +[R +0.017248] write 0x200ad 0x1 0x27 +OK +[S +0.017338] OK +[R +0.017342] writeq 0x9f0d000000002000 0x100ef0100000009 +30899@1597183147.299300:usb_xhci_doorbell_write off 0x0000, val 0x00000009 +30899@1597183147.299302:usb_xhci_doorbell_write off 0x0004, val 0x0100ef01 +30899@1597183147.299304:usb_xhci_ep_kick slotid 1, epid 1, streamid 256 +30899@1597183147.299308:usb_xhci_fetch_trb addr 0x00000000000200a0, CR_ENABLE_SLOT, p 0x0000000000000000, s 0x00000000, c 0x00002700 +30899@1597183147.299310:usb_xhci_xfer_start 0x5622548f9890: slotid 1, epid 1, streamid 0 +TRB_SETUP 2700 2700 2700 0 +30899@1597183147.299315:usb_xhci_fetch_trb addr 0x00000000000200b0, CR_NOOP, p 0x0000000000000000, s 0x00000000, c 0x00005c00 +30899@1597183147.299318:usb_xhci_xfer_start 0x5622548f99a0: slotid 1, epid 1, streamid 0 +TRB_SETUP 5c00 5c00 5c00 0 +30899@1597183147.299322:usb_xhci_fetch_trb addr 0x00000000000200c0, CR_ADDRESS_DEVICE, p 0x0000000000000000, s 0x00000000, c 0x00002e00 +30899@1597183147.299325:usb_xhci_xfer_start 0x5622548f9ab0: slotid 1, epid 1, streamid 0 +TRB_SETUP 2e00 2e00 2e00 0 +30899@1597183147.299329:usb_xhci_fetch_trb addr 0x00000000000200d0, CR_ADDRESS_DEVICE, p 0x0000000000000000, s 0x00000000, c 0x00002f00 +30899@1597183147.299331:usb_xhci_xfer_start 0x5622548f9c10: slotid 1, epid 1, streamid 0 +TRB_SETUP 2f00 2f00 2f00 0 +30899@1597183147.299337:usb_xhci_fetch_trb addr 0x00000000000200e0, TR_SETUP, p 0x0000000000000000, s 0x00000008, c 0x000008fe +30899@1597183147.299340:usb_xhci_fetch_trb addr 0x00000000000200f0, TR_NORMAL, p 0x0000000000000000, s 0x00000000, c 0x00000500 +30899@1597183147.299342:usb_xhci_fetch_trb addr 0x0000000000020100, CR_ADDRESS_DEVICE, p 0x0000000000000000, s 0x00000000, c 0x00002e00 +30899@1597183147.299345:usb_xhci_fetch_trb addr 0x0000000000020110, CR_ADDRESS_DEVICE, p 0x0000000000000000, s 0x00000000, c 0x00002f00 +30899@1597183147.299348:usb_xhci_fetch_trb addr 0x0000000000020120, TR_SETUP, p 0x0000000000000000, s 0x00000000, c 0x00000800 +30899@1597183147.299351:usb_xhci_fetch_trb addr 0x0000000000020130, TR_NORMAL, p 0x5e00000000000000, s 0x002f0000, c 0x00000500 +30899@1597183147.299353:usb_xhci_fetch_trb addr 0x0000000000020140, TR_STATUS, p 0x0000000000000000, s 0x00000000, c 0x00001300 +30899@1597183147.299356:usb_xhci_xfer_start 0x5622548f9d70: slotid 1, epid 1, streamid 0 +TRB_SETUP 8fe 1300 8fe 8 +30899@1597183147.299361:usb_packet_state_change bus 0, port 1, ep 0, packet 0x5622548f9d78, state undef -> setup +30899@1597183147.299466:usb_packet_state_change bus 0, port 1, ep 0, packet 0x5622548f9d78, state setup -> complete +qemu-system-i386: /home/alxndr/Development/qemu/general-fuzz/exec.c:3623: void address_space_unmap(AddressSpace *, void *, hwaddr, _Bool, hwaddr): Assertion `mr != NULL' failed. + + + + + +#8 0x7f8f9e7e6091 in __assert_fail /build/glibc-GwnBeO/glibc-2.30/assert/assert.c:101:3 +#9 0x55f7507b374a in address_space_unmap exec.c:3623:9 +#10 0x55f750baeab8 in dma_memory_unmap include/sysemu/dma.h:145:5 +#11 0x55f750baea1b in usb_packet_unmap hw/usb/libhw.c:65:9 +#12 0x55f750bcbb73 in xhci_xfer_unmap hw/usb/hcd-xhci.c:1487:5 +#13 0x55f750bcba3d in xhci_try_complete_packet hw/usb/hcd-xhci.c:1642:9 +#14 0x55f750bcc888 in xhci_fire_ctl_transfer hw/usb/hcd-xhci.c:1728:5 +#15 0x55f750bcb306 in xhci_kick_epctx hw/usb/hcd-xhci.c:1991:13 +#16 0x55f750bd04e9 in xhci_kick_ep hw/usb/hcd-xhci.c:1861:5 +#17 0x55f750bd253c in xhci_doorbell_write hw/usb/hcd-xhci.c:3162:13 +#18 0x55f75091def1 in memory_region_write_accessor softmmu/memory.c:483:5 +#19 0x55f75091ddf3 in access_with_adjusted_size softmmu/memory.c:544:18 +#20 0x55f75091dac5 in memory_region_dispatch_write softmmu/memory.c +#21 0x55f7507b51e2 in flatview_write_continue exec.c:3176:23 +#22 0x55f7507b2a30 in flatview_write exec.c:3216:14 +#23 0x55f7507b2968 in address_space_write exec.c:3308:18 +#24 0x55f750929e3b in qtest_process_command softmmu/qtest.c + + +Can you still reproduce this assert with QEMU v6.0 ? For me, it does not seem to run into the assert() anymore, so I assume this has been fixed within the last months? + +OSS-Fuzz never picked up on this one, so I'm guessing it was fixed sometime between 5.1 and 5.2. +Not a fun section to bisect, but looks like it was fixed by 21bc31524e ("hw: xhci: check return value of 'usb_packet_map'") + +Ok, thanks for checking! So seems like this has been fixed, thus I'm closing the bug. If it happens again, please open a new ticket in our new gitlab issue tracker. + diff --git a/results/classifier/108/other/1883729 b/results/classifier/108/other/1883729 new file mode 100644 index 00000000..0bdf393c --- /dev/null +++ b/results/classifier/108/other/1883729 @@ -0,0 +1,413 @@ +graphic: 0.726 +other: 0.705 +vnc: 0.687 +KVM: 0.632 +device: 0.581 +performance: 0.536 +semantic: 0.524 +debug: 0.513 +permissions: 0.482 +network: 0.465 +files: 0.463 +boot: 0.461 +PID: 0.455 +socket: 0.452 + +xhci_find_stream: Assertion `streamid != 0' failed. + +To reproduce run the QEMU with the following command line: +``` +qemu-system-x86_64 -cdrom hypertrash_os_bios_crash.iso -nographic -m 100 -enable-kvm -device virtio-gpu-pci -device nec-usb-xhci -device usb-audio +``` + +QEMU Version: +``` +# qemu-5.0.0 +$ ./configure --target-list=x86_64-softmmu --enable-sanitizers; make +$ x86_64-softmmu/qemu-system-x86_64 --version +QEMU emulator version 5.0.0 +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers +``` + + + +Attaching a QTest reproducer. +./i386-softmmu/qemu-system-i386 -device nec-usb-xhci -trace usb\* \ +-device usb-audio -device usb-storage,drive=mydrive \ +-drive id=mydrive,file=null-co://,size=2M,format=raw,if=none \ +-nodefaults -nographic -qtest stdio < repro + + +Close to the crash: +21000@1597111713.503068:usb_xhci_slot_configure slotid 58 +21000@1597111713.503074:usb_xhci_ep_disable slotid 58, epid 2 +21000@1597111713.503077:usb_xhci_ep_enable slotid 58, epid 2 +21000@1597111713.503085:usb_xhci_ep_disable slotid 58, epid 6 +21000@1597111713.503088:usb_xhci_ep_enable slotid 58, epid 6 +21000@1597111713.503092:usb_xhci_ep_disable slotid 58, epid 24 +21000@1597111713.503095:usb_xhci_ep_enable slotid 58, epid 24 +21000@1597111713.503099:usb_xhci_ep_disable slotid 58, epid 25 +21000@1597111713.503102:usb_xhci_ep_enable slotid 58, epid 25 +21000@1597111713.503106:usb_xhci_ep_disable slotid 58, epid 29 +21000@1597111713.503109:usb_xhci_ep_enable slotid 58, epid 29 +21000@1597111713.503113:usb_xhci_ep_disable slotid 58, epid 30 +21000@1597111713.503116:usb_xhci_ep_enable slotid 58, epid 30 +21000@1597111713.503121:usb_xhci_fetch_trb addr 0x0000000000000b20, CR_ENABLE_SLOT, p 0x0000000000000000, s 0x00000000, c 0x00002700 +21000@1597111713.503127:usb_xhci_slot_enable slotid 59 +21000@1597111713.503130:usb_xhci_fetch_trb addr 0x0000000000000b30, CR_SET_TR_DEQUEUE, p 0x0000000000000000, s 0x00000000, c 0x00004300 +21000@1597111713.503135:usb_xhci_fetch_trb addr 0x0000000000000b40, CR_ENABLE_SLOT, p 0x0000000000000000, s 0x00000000, c 0x00002700 +21000@1597111713.503140:usb_xhci_slot_enable slotid 60 +21000@1597111713.503143:usb_xhci_fetch_trb addr 0x0000000000000b50, CR_EVALUATE_CONTEXT, p 0x0000000000000000, s 0x00000000, c 0x00003600 +21000@1597111713.503149:usb_xhci_fetch_trb addr 0x0000000000000b60, CR_STOP_ENDPOINT, p 0x0000000000000000, s 0x00000000, c 0x3afd3c00 +21000@1597111713.503154:usb_xhci_ep_stop slotid 58, epid 29 +21000@1597111713.503159:usb_xhci_ep_state slotid 58, epid 29, running -> stopped +21000@1597111713.503163:usb_xhci_fetch_trb addr 0x0000000000000b70, CR_ENABLE_SLOT, p 0x0000000000000000, s 0x00000000, c 0x00002700 +21000@1597111713.503168:usb_xhci_slot_enable slotid 61 +21000@1597111713.503171:usb_xhci_fetch_trb addr 0x0000000000000b80, CR_SET_TR_DEQUEUE, p 0x0000000000000000, s 0x00000000, c 0x3afd4300 +21000@1597111713.503177:usb_xhci_ep_set_dequeue slotid 58, epid 29, streamid 0, ptr 0x0000000000000000 +qemu-system-i386: hw/usb/hcd-xhci.c:1016: XHCIStreamContext *xhci_find_stream(XHCIEPContext *, unsigned int, uint32_t *): Assertion `streamid != 0' failed. +Aborted + + +Can you still reproduce this assertion with the latest version 6.0 of QEMU? ... I cannot trigger it here, so I assume this issue has been fixed? + +I don't think it is fixed yet.. This is https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28571#c4 + +Bash Reproducer: +./qemu-system-i386 -display none -machine accel=qtest, -m 512M \ +-machine q35 -nodefaults -drive \ +file=null-co://,if=none,format=raw,id=disk0 -device qemu-xhci,id=xhci \ +-device usb-tablet,bus=xhci.0 -device usb-bot -device \ +usb-storage,drive=disk0 -chardev null,id=cd0 -chardev null,id=cd1 \ +-device usb-braille,chardev=cd0 -device usb-ccid -device usb-ccid \ +-device usb-kbd -device usb-mouse -device usb-serial,chardev=cd1 -device\ + usb-tablet -device usb-wacom-tablet -device usb-audio -qtest /dev/null \ +-qtest stdio < attachment + +Testcase: +/* + * Autogenerated Fuzzer Test Case + * + * Copyright (c) 2021 <name of author> + * + * This work is licensed under the terms of the GNU GPL, version 2 or later. + * See the COPYING file in the top-level directory. + */ + +#include "qemu/osdep.h" + +#include "libqos/libqtest.h" + +static void test_fuzz(void) +{ + QTestState *s = qtest_init( + "-display none , -m 512M -machine q35 -nodefaults -drive " + "file=null-co://,if=none,format=raw,id=disk0 -device qemu-xhci,id=xhci -device " + "usb-tablet,bus=xhci.0 -device usb-bot -device usb-storage,drive=disk0 -chardev " + "null,id=cd0 -chardev null,id=cd1 -device usb-braille,chardev=cd0 -device " + "usb-ccid -device usb-ccid -device usb-kbd -device usb-mouse -device " + "usb-serial,chardev=cd1 -device usb-tablet -device usb-wacom-tablet -device " + "usb-audio -qtest /dev/null"); + qtest_outl(s, 0xcf8, 0x80000816); + qtest_outl(s, 0xcfc, 0xffff); + qtest_outl(s, 0xcf8, 0x80000803); + qtest_outl(s, 0xcfc, 0x0600); + qtest_outl(s, 0xcf8, 0x80000810); + qtest_outl(s, 0xcfc, 0x2e654000); + qtest_writel(s, 0xffff00002e654040, 0xffffff05); + qtest_bufwrite(s, 0x4d, "\x04", 0x1); + qtest_bufwrite(s, 0x5d, "\x04", 0x1); + qtest_bufwrite(s, 0x6d, "\x04", 0x1); + qtest_bufwrite(s, 0x7d, "\x04", 0x1); + qtest_bufwrite(s, 0x8d, "\x04", 0x1); + qtest_bufwrite(s, 0x9d, "\x04", 0x1); + qtest_bufwrite(s, 0xad, "\x04", 0x1); + qtest_bufwrite(s, 0xbd, "\x04", 0x1); + qtest_bufwrite(s, 0xcd, "\x04", 0x1); + qtest_bufwrite(s, 0xdd, "\x04", 0x1); + qtest_bufwrite(s, 0xed, "\x04", 0x1); + qtest_bufwrite(s, 0xfd, "\x04", 0x1); + qtest_bufwrite(s, 0x10d, "\x04", 0x1); + qtest_bufwrite(s, 0x11d, "\x04", 0x1); + qtest_bufwrite(s, 0x12d, "\x04", 0x1); + qtest_bufwrite(s, 0x13d, "\x04", 0x1); + qtest_bufwrite(s, 0x14d, "\x04", 0x1); + qtest_bufwrite(s, 0x15d, "\x04", 0x1); + qtest_bufwrite(s, 0x16d, "\x04", 0x1); + qtest_bufwrite(s, 0x17d, "\x04", 0x1); + qtest_bufwrite(s, 0x18d, "\x04", 0x1); + qtest_bufwrite(s, 0x19d, "\x04", 0x1); + qtest_bufwrite(s, 0x1ad, "\x04", 0x1); + qtest_bufwrite(s, 0x1bd, "\x04", 0x1); + qtest_bufwrite(s, 0x1cd, "\x04", 0x1); + qtest_bufwrite(s, 0x1dd, "\x04", 0x1); + qtest_bufwrite(s, 0x1ed, "\x04", 0x1); + qtest_bufwrite(s, 0x1fd, "\x04", 0x1); + qtest_bufwrite(s, 0x20d, "\x04", 0x1); + qtest_bufwrite(s, 0x21d, "\x04", 0x1); + qtest_bufwrite(s, 0x22d, "\x04", 0x1); + qtest_bufwrite(s, 0x23d, "\x04", 0x1); + qtest_bufwrite(s, 0x24d, "\x04", 0x1); + qtest_bufwrite(s, 0x25d, "\x04", 0x1); + qtest_bufwrite(s, 0x26d, "\x04", 0x1); + qtest_bufwrite(s, 0x27d, "\x04", 0x1); + qtest_bufwrite(s, 0x28d, "\x04", 0x1); + qtest_bufwrite(s, 0x29d, "\x04", 0x1); + qtest_bufwrite(s, 0x2ad, "\x04", 0x1); + qtest_bufwrite(s, 0x2bd, "\x04", 0x1); + qtest_bufwrite(s, 0x2cd, "\x04", 0x1); + qtest_bufwrite(s, 0x2dd, "\x04", 0x1); + qtest_bufwrite(s, 0x2ed, "\x04", 0x1); + qtest_bufwrite(s, 0x2fd, "\x04", 0x1); + qtest_bufwrite(s, 0x30d, "\x04", 0x1); + qtest_bufwrite(s, 0x31d, "\x04", 0x1); + qtest_bufwrite(s, 0x32d, "\x04", 0x1); + qtest_bufwrite(s, 0x33d, "\x04", 0x1); + qtest_bufwrite(s, 0x34d, "\x04", 0x1); + qtest_bufwrite(s, 0x35d, "\x04", 0x1); + qtest_bufwrite(s, 0x36d, "\x04", 0x1); + qtest_bufwrite(s, 0x37d, "\x04", 0x1); + qtest_bufwrite(s, 0x38d, "\x04", 0x1); + qtest_bufwrite(s, 0x39d, "\x04", 0x1); + qtest_bufwrite(s, 0x3ad, "\x04", 0x1); + qtest_bufwrite(s, 0x3bd, "\x04", 0x1); + qtest_bufwrite(s, 0x3cd, "\x04", 0x1); + qtest_bufwrite(s, 0x3dd, "\x04", 0x1); + qtest_bufwrite(s, 0x3ed, "\x04", 0x1); + qtest_bufwrite(s, 0x3fd, "\x04", 0x1); + qtest_bufwrite(s, 0x40d, "\x04", 0x1); + qtest_bufwrite(s, 0x41d, "\x04", 0x1); + qtest_bufwrite(s, 0x42d, "\x04", 0x1); + qtest_bufwrite(s, 0x43d, "\x04", 0x1); + qtest_bufwrite(s, 0x44d, "\x04", 0x1); + qtest_bufwrite(s, 0x45d, "\x04", 0x1); + qtest_bufwrite(s, 0x46d, "\x04", 0x1); + qtest_bufwrite(s, 0x47d, "\x04", 0x1); + qtest_bufwrite(s, 0x48d, "\x04", 0x1); + qtest_bufwrite(s, 0x49d, "\x04", 0x1); + qtest_bufwrite(s, 0x4ad, "\x04", 0x1); + qtest_bufwrite(s, 0x4bd, "\x04", 0x1); + qtest_bufwrite(s, 0x4cd, "\x04", 0x1); + qtest_bufwrite(s, 0x4dd, "\x04", 0x1); + qtest_bufwrite(s, 0x4ed, "\x04", 0x1); + qtest_bufwrite(s, 0x4fd, "\x04", 0x1); + qtest_bufwrite(s, 0x50d, "\x04", 0x1); + qtest_bufwrite(s, 0x51d, "\x04", 0x1); + qtest_bufwrite(s, 0x52d, "\x04", 0x1); + qtest_bufwrite(s, 0x53d, "\x04", 0x1); + qtest_bufwrite(s, 0x54d, "\x04", 0x1); + qtest_bufwrite(s, 0x55d, "\x04", 0x1); + qtest_bufwrite(s, 0x56d, "\x04", 0x1); + qtest_bufwrite(s, 0x57d, "\x04", 0x1); + qtest_bufwrite(s, 0x58d, "\x04", 0x1); + qtest_bufwrite(s, 0x59d, "\x04", 0x1); + qtest_bufwrite(s, 0x5ad, "\x04", 0x1); + qtest_bufwrite(s, 0x5bd, "\x04", 0x1); + qtest_bufwrite(s, 0x5cd, "\x04", 0x1); + qtest_bufwrite(s, 0x5dd, "\x04", 0x1); + qtest_bufwrite(s, 0x5ed, "\x04", 0x1); + qtest_bufwrite(s, 0x5fd, "\x04", 0x1); + qtest_bufwrite(s, 0x60d, "\x04", 0x1); + qtest_bufwrite(s, 0x61d, "\x04", 0x1); + qtest_bufwrite(s, 0x62d, "\x04", 0x1); + qtest_bufwrite(s, 0x63d, "\x04", 0x1); + qtest_bufwrite(s, 0x64d, "\x04", 0x1); + qtest_bufwrite(s, 0x65d, "\x04", 0x1); + qtest_bufwrite(s, 0x66d, "\x04", 0x1); + qtest_bufwrite(s, 0x67d, "\x04", 0x1); + qtest_bufwrite(s, 0x68d, "\x04", 0x1); + qtest_bufwrite(s, 0x69d, "\x04", 0x1); + qtest_bufwrite(s, 0x6ad, "\x04", 0x1); + qtest_bufwrite(s, 0x6bd, "\x04", 0x1); + qtest_bufwrite(s, 0x6cd, "\x04", 0x1); + qtest_bufwrite(s, 0x6dd, "\x04", 0x1); + qtest_bufwrite(s, 0x6ed, "\x04", 0x1); + qtest_bufwrite(s, 0x6fd, "\x04", 0x1); + qtest_bufwrite(s, 0x70d, "\x04", 0x1); + qtest_bufwrite(s, 0x71d, "\x04", 0x1); + qtest_bufwrite(s, 0x72d, "\x04", 0x1); + qtest_bufwrite(s, 0x73d, "\x04", 0x1); + qtest_bufwrite(s, 0x74d, "\x04", 0x1); + qtest_bufwrite(s, 0x75d, "\x04", 0x1); + qtest_bufwrite(s, 0x76d, "\x04", 0x1); + qtest_bufwrite(s, 0x77d, "\x04", 0x1); + qtest_bufwrite(s, 0x78d, "\x04", 0x1); + qtest_bufwrite(s, 0x79d, "\x04", 0x1); + qtest_bufwrite(s, 0x7ad, "\x04", 0x1); + qtest_bufwrite(s, 0x7bd, "\x04", 0x1); + qtest_bufwrite(s, 0x7cd, "\x04", 0x1); + qtest_bufwrite(s, 0x7dd, "\x04", 0x1); + qtest_bufwrite(s, 0x7ed, "\x04", 0x1); + qtest_bufwrite(s, 0x7fd, "\x04", 0x1); + qtest_bufwrite(s, 0x80d, "\x04", 0x1); + qtest_bufwrite(s, 0x81d, "\x04", 0x1); + qtest_bufwrite(s, 0x82d, "\x04", 0x1); + qtest_bufwrite(s, 0x83d, "\x04", 0x1); + qtest_bufwrite(s, 0x84d, "\x04", 0x1); + qtest_bufwrite(s, 0x85d, "\x04", 0x1); + qtest_bufwrite(s, 0x86d, "\x04", 0x1); + qtest_bufwrite(s, 0x87d, "\x04", 0x1); + qtest_bufwrite(s, 0x88d, "\x04", 0x1); + qtest_bufwrite(s, 0x89d, "\x04", 0x1); + qtest_bufwrite(s, 0x8ad, "\x04", 0x1); + qtest_bufwrite(s, 0x8bd, "\x04", 0x1); + qtest_bufwrite(s, 0x8cd, "\x04", 0x1); + qtest_bufwrite(s, 0x8dd, "\x04", 0x1); + qtest_bufwrite(s, 0x8ed, "\x04", 0x1); + qtest_bufwrite(s, 0x8fd, "\x04", 0x1); + qtest_bufwrite(s, 0x90d, "\x04", 0x1); + qtest_bufwrite(s, 0x91d, "\x04", 0x1); + qtest_bufwrite(s, 0x92d, "\x04", 0x1); + qtest_bufwrite(s, 0x93d, "\x04", 0x1); + qtest_bufwrite(s, 0x94d, "\x04", 0x1); + qtest_bufwrite(s, 0x95d, "\x04", 0x1); + qtest_bufwrite(s, 0x96d, "\x04", 0x1); + qtest_bufwrite(s, 0x97d, "\x04", 0x1); + qtest_bufwrite(s, 0x98d, "\x04", 0x1); + qtest_bufwrite(s, 0x99d, "\x04", 0x1); + qtest_bufwrite(s, 0x9ad, "\x04", 0x1); + qtest_bufwrite(s, 0x9bd, "\x04", 0x1); + qtest_bufwrite(s, 0x9cd, "\x04", 0x1); + qtest_bufwrite(s, 0x9dd, "\x04", 0x1); + qtest_bufwrite(s, 0x9ed, "\x04", 0x1); + qtest_bufwrite(s, 0x9fd, "\x04", 0x1); + qtest_bufwrite(s, 0xa0d, "\x04", 0x1); + qtest_bufwrite(s, 0xa1d, "\x04", 0x1); + qtest_bufwrite(s, 0xa2d, "\x04", 0x1); + qtest_bufwrite(s, 0xa3d, "\x04", 0x1); + qtest_bufwrite(s, 0xa4d, "\x04", 0x1); + qtest_bufwrite(s, 0xa5d, "\x04", 0x1); + qtest_bufwrite(s, 0xa6d, "\x04", 0x1); + qtest_bufwrite(s, 0xa7d, "\x04", 0x1); + qtest_bufwrite(s, 0xa8d, "\x04", 0x1); + qtest_bufwrite(s, 0xa9d, "\x04", 0x1); + qtest_bufwrite(s, 0xaad, "\x04", 0x1); + qtest_bufwrite(s, 0xabd, "\x04", 0x1); + qtest_bufwrite(s, 0xacd, "\x04", 0x1); + qtest_bufwrite(s, 0xadd, "\x04", 0x1); + qtest_bufwrite(s, 0xaed, "\x04", 0x1); + qtest_bufwrite(s, 0xafd, "\x04", 0x1); + qtest_bufwrite(s, 0xb0d, "\x04", 0x1); + qtest_bufwrite(s, 0xb1d, "\x04", 0x1); + qtest_bufwrite(s, 0xb2d, "\x04", 0x1); + qtest_bufwrite(s, 0xb3d, "\x04", 0x1); + qtest_bufwrite(s, 0xb4d, "\x04", 0x1); + qtest_bufwrite(s, 0xb5d, "\x04", 0x1); + qtest_bufwrite(s, 0xb6d, "\x04", 0x1); + qtest_bufwrite(s, 0xb7d, "\x04", 0x1); + qtest_bufwrite(s, 0xb8d, "\x04", 0x1); + qtest_bufwrite(s, 0xb9d, "\x04", 0x1); + qtest_bufwrite(s, 0xbad, "\x04", 0x1); + qtest_bufwrite(s, 0xbbd, "\x04", 0x1); + qtest_bufwrite(s, 0xbcd, "\x04", 0x1); + qtest_bufwrite(s, 0xbdd, "\x04", 0x1); + qtest_bufwrite(s, 0xbed, "\x04", 0x1); + qtest_bufwrite(s, 0xbfd, "\x04", 0x1); + qtest_bufwrite(s, 0xc0d, "\x04", 0x1); + qtest_bufwrite(s, 0xc1d, "\x04", 0x1); + qtest_bufwrite(s, 0xc2d, "\x04", 0x1); + qtest_bufwrite(s, 0xc3d, "\x04", 0x1); + qtest_bufwrite(s, 0xc4d, "\x04", 0x1); + qtest_bufwrite(s, 0xc5d, "\x04", 0x1); + qtest_bufwrite(s, 0xc6d, "\x04", 0x1); + qtest_bufwrite(s, 0xc7d, "\x04", 0x1); + qtest_bufwrite(s, 0xc8d, "\x04", 0x1); + qtest_bufwrite(s, 0xc9d, "\x04", 0x1); + qtest_bufwrite(s, 0xcad, "\x04", 0x1); + qtest_bufwrite(s, 0xcbd, "\x04", 0x1); + qtest_bufwrite(s, 0xccd, "\x04", 0x1); + qtest_bufwrite(s, 0xcdd, "\x04", 0x1); + qtest_bufwrite(s, 0xced, "\x04", 0x1); + qtest_bufwrite(s, 0xcfd, "\x04", 0x1); + qtest_bufwrite(s, 0xd0d, "\x04", 0x1); + qtest_bufwrite(s, 0xd1d, "\x04", 0x1); + qtest_bufwrite(s, 0xd2d, "\x04", 0x1); + qtest_bufwrite(s, 0xd3d, "\x04", 0x1); + qtest_bufwrite(s, 0xd4d, "\x04", 0x1); + qtest_bufwrite(s, 0xd5d, "\x04", 0x1); + qtest_bufwrite(s, 0xd6d, "\x04", 0x1); + qtest_bufwrite(s, 0xd7d, "\x04", 0x1); + qtest_bufwrite(s, 0xd8d, "\x04", 0x1); + qtest_bufwrite(s, 0xd9d, "\x04", 0x1); + qtest_bufwrite(s, 0xdad, "\x04", 0x1); + qtest_bufwrite(s, 0xdbd, "\x04", 0x1); + qtest_bufwrite(s, 0xdcd, "\x04", 0x1); + qtest_bufwrite(s, 0xddd, "\x04", 0x1); + qtest_bufwrite(s, 0xded, "\x04", 0x1); + qtest_bufwrite(s, 0xdfd, "\x04", 0x1); + qtest_bufwrite(s, 0xe0d, "\x04", 0x1); + qtest_bufwrite(s, 0xe1d, "\x04", 0x1); + qtest_bufwrite(s, 0xe2d, "\x04", 0x1); + qtest_bufwrite(s, 0xe3d, "\x04", 0x1); + qtest_bufwrite(s, 0xe4d, "\x04", 0x1); + qtest_bufwrite(s, 0xe5d, "\x04", 0x1); + qtest_bufwrite(s, 0xe6d, "\x04", 0x1); + qtest_bufwrite(s, 0xe7d, "\x04", 0x1); + qtest_bufwrite(s, 0xe8d, "\x04", 0x1); + qtest_bufwrite(s, 0xe9d, "\x04", 0x1); + qtest_bufwrite(s, 0xead, "\x04", 0x1); + qtest_bufwrite(s, 0xebd, "\x04", 0x1); + qtest_bufwrite(s, 0xecd, "\x04", 0x1); + qtest_bufwrite(s, 0xedd, "\x04", 0x1); + qtest_bufwrite(s, 0xeed, "\x04", 0x1); + qtest_bufwrite(s, 0xefd, "\x04", 0x1); + qtest_bufwrite(s, 0xf0d, "\x04", 0x1); + qtest_bufwrite(s, 0xf1d, "\x04", 0x1); + qtest_bufwrite(s, 0xf2d, "\x04", 0x1); + qtest_bufwrite(s, 0xf3d, "\x04", 0x1); + qtest_bufwrite(s, 0xf4d, "\x04", 0x1); + qtest_bufwrite(s, 0xf5d, "\x04", 0x1); + qtest_bufwrite(s, 0xf6d, "\x04", 0x1); + qtest_bufwrite(s, 0xf7d, "\x04", 0x1); + qtest_bufwrite(s, 0xf8d, "\x04", 0x1); + qtest_bufwrite(s, 0xf9d, "\x04", 0x1); + qtest_bufwrite(s, 0xfad, "\x04", 0x1); + qtest_bufwrite(s, 0xfbd, "\x04", 0x1); + qtest_bufwrite(s, 0xfcd, "\x04", 0x1); + qtest_bufwrite(s, 0xfdd, "\x04", 0x1); + qtest_bufwrite(s, 0xfed, "\x24", 0x1); + qtest_bufwrite(s, 0xffd, "\x24", 0x1); + qtest_bufwrite(s, 0x100d, "\x24", 0x1); + qtest_bufwrite(s, 0x101d, "\x24", 0x1); + qtest_bufwrite(s, 0x102d, "\x24", 0x1); + qtest_bufwrite(s, 0x1041, "\x6d", 0x1); + qtest_bufwrite(s, 0x104d, "\x2c", 0x1); + qtest_bufwrite(s, 0x104f, "\x05", 0x1); + qtest_writel(s, 0xffff00002e656000, 0x0); + qtest_writel(s, 0xffff00002e656000, 0x0); + qtest_writel(s, 0xffff00002e656000, 0x0); + qtest_writel(s, 0xffff00002e656000, 0x0); + qtest_bufwrite(s, 0x6d04, "\x03", 0x1); + qtest_bufwrite(s, 0x6d26, "\x04", 0x1); + qtest_bufwrite(s, 0x6d41, "\x04", 0x1); + qtest_writel(s, 0xffff00002e656000, 0x0); + qtest_writel(s, 0xffff00002e656000, 0x0); + qtest_bufwrite(s, 0xffff00002e656014, "\x01\x00\x00\x00", 0x4); + qtest_quit(s); +} +int main(int argc, char **argv) +{ + const char *arch = qtest_get_arch(); + + g_test_init(&argc, &argv, NULL); + + if (strcmp(arch, "i386") == 0) { + qtest_add_func("fuzz/test_fuzz", test_fuzz); + } + + return g_test_run(); +} + + + + +Ok, with the new attachment from comment #5, I can also reporoduce the bug again. It does not reproduce with the attachments from comment #1 or #2 anymore, so this now seems to be a different way to run into this assert. Anyway, setting the status back to Confirmed since it is reproducible again. + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/273 + + diff --git a/results/classifier/108/other/1883739 b/results/classifier/108/other/1883739 new file mode 100644 index 00000000..db9804a6 --- /dev/null +++ b/results/classifier/108/other/1883739 @@ -0,0 +1,54 @@ +graphic: 0.826 +files: 0.809 +other: 0.808 +performance: 0.804 +KVM: 0.786 +device: 0.749 +permissions: 0.733 +network: 0.709 +PID: 0.659 +socket: 0.652 +boot: 0.626 +debug: 0.609 +semantic: 0.601 +vnc: 0.586 + +ide_dma_cb: Assertion `prep_size >= 0 && prep_size <= n * 512' failed. + +To reproduce run the QEMU with the following command line: +``` +qemu-system-x86_64 -cdrom hypertrash.iso -nographic -m 100 -enable-kvm -net none -drive id=disk,file=hda.img,if=none -device ahci,id=ahci -device ide-hd,drive=disk,bus=ahci.0 +``` + +QEMU Version: +``` +# qemu-5.0.0 +$ ./configure --target-list=x86_64-softmmu --enable-sanitizers; make +$ x86_64-softmmu/qemu-system-x86_64 --version +QEMU emulator version 5.0.0 +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers +``` + +To create disk image run: +``` +dd if=/dev/zero of=hda.img bs=1024 count=1024 +``` + + + +ACK. I do not have time to fix this bug at the moment under the belief that it's likely low-priority and only "misbehaving guests" can trigger it. Some advice: + +1. Do not use IDE in production deployments after initial installation, if you can help it. Use a performant virtio solution. + +2. If anyone would like to fix this problem, I will be more than happy to point you to the exact lines of code that cause the problem. I think the fix will be easy, but testing will be time-consuming as it involves understanding error behavior of real hardware that I don't personally have the setup to quickly test or verify. + +From memory: the problem is that ide_dma_cb expects that it was able to prepare at least one sector's worth of scatter-gather list to begin DMA, but it's possible to give malformed SG lists where IDE is unable to process the remainder of a sector in a list. + +It was not clear to me at the time when I first investigated this what a real controller would do if it got an incomplete sector and how it should signal that. + +It was also not clear to me if the sg_prepare function for the pci bmdma controller would ever encounter a situation where further entries in the list might be received "later" and we should "wait" for them. + +If this bug is more dangerous than a self-inflicted DOS, please let me know and I'll re-prioritize. Patches, email and IRC chats welcome. + +--js + diff --git a/results/classifier/108/other/1883784 b/results/classifier/108/other/1883784 new file mode 100644 index 00000000..69a753cb --- /dev/null +++ b/results/classifier/108/other/1883784 @@ -0,0 +1,63 @@ +performance: 0.917 +other: 0.911 +graphic: 0.881 +semantic: 0.818 +files: 0.736 +permissions: 0.724 +device: 0.696 +PID: 0.654 +network: 0.625 +KVM: 0.570 +debug: 0.566 +vnc: 0.551 +boot: 0.516 +socket: 0.469 + +[ppc64le] qemu behavior differs from ppc64le hardware + +I have some code which passes my test suite on PPC64LE hardware when compiled with GCC 10, but the saem binary fails with both qemu-ppc64le 4.2 (on Fedora 32) and qemu-ppc64le-static 5.0.0 (Debian testing). + +I'm not getting any errors about illegal instructions or anything, like that; the results are just silently different on qemu. + +I've generated a reduced test case, which is attached along with the binaries (both are the same code, one is just statically linked). They should execute successufully on PPC64LE hardware, but on qemu they hit a __builtin_abort (because the computed value doesn't match the expected value). + +Without being familiar with PPC assembly I'm not sure what else I can do, but if there is anything please let me know. + + + +Did you try to run it in a qemu-system-ppc64 guest? +It would help to know if it is a tcg or a linux-user bug. + +I just ran the provided binaries on a qemu-system-ppc64 version 5.0-5 from Debian Bullseye and they also aborted there + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting older bugs to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system (but you won't be the reporter of the bug +in the new system and thus won't get notified on changes anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1884169 b/results/classifier/108/other/1884169 new file mode 100644 index 00000000..0c977c6b --- /dev/null +++ b/results/classifier/108/other/1884169 @@ -0,0 +1,33 @@ +network: 0.838 +device: 0.636 +semantic: 0.506 +graphic: 0.370 +performance: 0.361 +other: 0.356 +permissions: 0.288 +KVM: 0.259 +debug: 0.157 +files: 0.148 +PID: 0.133 +vnc: 0.096 +boot: 0.063 +socket: 0.061 + +There is no option group 'fsdev' for OSX + +When I try to use -fsoption on OSX I receive this error: + +-fsdev local,security_model=mapped,id=fsdev0,path=devel/dmos-example: There is no option group 'fsdev' + +That's the behaviour on macOS that I would expect ATM. So it's not a bug. + +Your macOS version was compiled without virtfs support, that's why qemu does not even offer you these options. + +Even though 9P is a network protocol, you still need support by host OS and guest OS for some kind of communication channel between host and guest. Currently 9pfs in qemu supports either virtio (Linux KVM host <-> Linux guest) or Xen as communication channel. For macOS so far nobody bothered to implement a communication driver for qemu 9pfs yet. + +But actually OS X (macOS) supports 9pfs and it does have its own AppleVirtIO9PVFS which makes things a bit strange, would not that be a good workaround, to use the AppleVirtIO9PVFS? + +All my best, + +Waheed + diff --git a/results/classifier/108/other/1884302 b/results/classifier/108/other/1884302 new file mode 100644 index 00000000..e6acb8a2 --- /dev/null +++ b/results/classifier/108/other/1884302 @@ -0,0 +1,49 @@ +device: 0.792 +graphic: 0.782 +files: 0.747 +socket: 0.708 +performance: 0.681 +network: 0.655 +other: 0.595 +semantic: 0.578 +KVM: 0.574 +PID: 0.568 +vnc: 0.547 +permissions: 0.544 +debug: 0.482 +boot: 0.445 + +disable automatic mouse grabbing + +I'm using QEMU 5.0.0 on a Gentoo Linux host system. Guest is an Arch Linux system. + +I'd like to disable automatic mouse grabbing when the QEMU window is focused. +I would prefer for QEMU to grab the mouse only after a click. + +I use the i3 window manager on my host system. +Suppose I'm in workspace 1, while the QEMU window is in workspace 2. +In order to switch to workspace 2, I need to press the "Win+2" key combination ("Win" is the Windows key). +The problem is that the character "2" (from "Win+2") will get transferred to the guest system. +For example, if I have a text editor opened under the guest system, the character "2" will be pasted inside the document I'm working on, which is pretty annoying. + +I would like instead to press the "Win+2" key combination and then explicitely click on the QEMU window with the mouse before grabbing it. + +Command line: + +qemu-system-x86_64 -drive file=/home/fturco/qemu/arch.img,media=disk,index=0,if=virtio,format=raw,cache=none -cpu host -m 2G -k it -enable-kvm -net nic,model=virtio -net user -vga virtio -display sdl -usb -rtc base=utc -soundhw ac97 -monitor stdio -no-quit + +Possibly similar bug: https://bugs.launchpad.net/qemu/+bug/906864 + +FYI: The gtk ui has support for that. Try "-display gtk,grab-on-hover=off". You can also toggle it in the "view" menu. + +Thanks for the info, but I prefer to continue using the SDL interface, if possible. +Is there a plan to add the grab-on-hover=off option to the SDL interface? + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/75 + + diff --git a/results/classifier/108/other/1884507 b/results/classifier/108/other/1884507 new file mode 100644 index 00000000..458d1a9a --- /dev/null +++ b/results/classifier/108/other/1884507 @@ -0,0 +1,51 @@ +other: 0.885 +semantic: 0.875 +device: 0.636 +performance: 0.478 +graphic: 0.469 +PID: 0.343 +boot: 0.282 +vnc: 0.258 +permissions: 0.230 +debug: 0.207 +network: 0.202 +socket: 0.196 +KVM: 0.139 +files: 0.092 + +'none' machine should use 'none' display option + +As the 'none' machine doesn't have any peripheral (except CPU cores) +it is pointless to start a display. + +'-M none' should imply '-display none'. + +Could be as simple as setting MachineClass->default_display = "none" ... have you tried whether that's working as expected? + +Actually, thinking about this twice, I think you made a wrong assumption here. "-display" is about the GUI backend that should be used. "-M" is about the emulated hardware. The emulated hardware options should never influence the host backend options. And it is e.g. perfectly valid to use the "none" machine as CPU instruction simulator in a GTK window, so it does not make sense to force the disablement the GUI in that case. + +> I think you made a wrong assumption here. "-display" is +> about the GUI backend that should be used. "-M" is about +> the emulated hardware. The emulated hardware options +> should never influence the host backend options. + +Aright. What confuses me is having serial0/parallel0 chardevs +initialized when using the none-machine. I realized when +looking at your suggestion in comment #1 that the chardevs +(among other hardware related things) are initialized in +qemu_init(). + +I started testing using: + + bool is_none_machine = !strcmp(machine_class->name, + MACHINE_TYPE_NAME("none")); + +and disabling blocks of code with: + + if (!is_none_machine) { + ... + } + +then planned to update this ticket description but you beat +me. I'll open a different issue. + diff --git a/results/classifier/108/other/1884684 b/results/classifier/108/other/1884684 new file mode 100644 index 00000000..60d22b4c --- /dev/null +++ b/results/classifier/108/other/1884684 @@ -0,0 +1,253 @@ +permissions: 0.893 +performance: 0.881 +other: 0.871 +vnc: 0.867 +device: 0.839 +KVM: 0.838 +graphic: 0.831 +debug: 0.828 +semantic: 0.824 +network: 0.816 +files: 0.785 +socket: 0.763 +PID: 0.747 +boot: 0.704 + +QEMU 5.0: Guest VM hangs/freeze when unplugging USB device + +Setup: + +Host: Debian/SID, Kernel 5.6, QEMU 5.0 +Guest: Windows 10 VM with PCI and USB device passthrough. + +Problem: Guest VM suddenly hangs when pulling USB device out from the Host. + +Observations: + - Issue appears to be related to QEMU 5.0 + - It started after an upgrade to QEMU 5.0. + - Downgrading only QEMU on multiple systems fixes the issue. + + - Issue is very reproducible. + - Most of the time within a few attempts of pulling/reconnecting the device. + - Issue happens with multiple devices (I did try standard HID devices, a webcam and an x-ray sensor). + + - Guest just hangs. + - Display output remains on last frame shown. + - Ping to Guest immediately stops working. + - Logs in the Guest stop logging immediately. + + - Host is fine and thinks the Guest is fine. + - Guest continues to show as running in "virsh list". + - No suspicious entries in the QEMU logs. + - No suspicious entries in Host syslogs/messages. + - Host can can kill guest "virsh destroy" and respawn fine. + + - Issue seems widespread. + - Multiple similar reports from ProxMox users after upgrade to ProxMox 6.2 for both Windows and Linux guests (First version that uses QEMU 5.0) + +https://forum.proxmox.com/threads/vm-freezes-when-disconnecting-usb-keyboard-and-mouse.70287/ +https://forum.proxmox.com/threads/usb-drive-crashes-vm.70214/ +https://forum.proxmox.com/threads/latest-proxmox-usb-disconnects-freeze-kvm.70398/ +https://forum.proxmox.com/threads/vm-with-gpu-passthrough-freezes-when-turning-off-monitor-after-proxmox-6-2-upgrade.69821/ +https://forum.proxmox.com/threads/vm-with-gpu-passthrough-freezes-when-turning-off-monitor-after-proxmox-6-2-upgrade.69824/ + +I'd be more than happy any debugs that might be helpful. + +Following reports on Proxmox forums, this is still very much seen by multiple users with no known workaround. + +I was able to run QEMU 5.0.13 (Debian) with all traces turned on and capture the following: + +- Behavior is reproducible by unbinding usb device on the host (ex. "echo '1-8' > /sys/bus/usb/drivers/usb/unbind") +- qemu trace logs stops at exactly the same time when VM freezes +- Last few lines of the qemu trace: + +1592303@1596123157.254134:virtio_notify vdev 0x56193d04d820 vq 0x7fcd5c48a010 +1592320@1596123158.822309:usb_xhci_oper_read off 0x0004, ret 0x00000008 +1592320@1596123158.822397:usb_xhci_port_read port 1, off 0x0000, ret 0x0e0002a0 +1592320@1596123158.822459:usb_xhci_port_read port 2, off 0x0000, ret 0x0e0002a0 +1592320@1596123158.822513:usb_xhci_port_read port 3, off 0x0000, ret 0x0e0002a0 +1592320@1596123158.822565:usb_xhci_port_read port 4, off 0x0000, ret 0x0e0002a0 +1592303@1596123159.858372:virtqueue_alloc_element elem 0x56193c8c8990 size 56 in_num 2 out_num 0 +1592303@1596123159.858435:virtqueue_pop vq 0x7fcd5c48a010 elem 0x56193c8c8990 in_num 2 out_num 0 +1592303@1596123159.858482:virtqueue_fill vq 0x7fcd5c48a010 elem 0x56193c8c8990 len 72 idx 0 +1592303@1596123159.858533:virtqueue_flush vq 0x7fcd5c48a010 count 1 +1592303@1596123159.858565:virtio_notify vdev 0x56193d04d820 vq 0x7fcd5c48a010 +1592303@1596123160.272641:virtqueue_alloc_element elem 0x56193c8c8990 size 56 in_num 2 out_num 0 +1592303@1596123160.272702:virtqueue_pop vq 0x7fcd5c48a010 elem 0x56193c8c8990 in_num 2 out_num 0 +1592303@1596123160.272751:virtqueue_fill vq 0x7fcd5c48a010 elem 0x56193c8c8990 len 104 idx 0 +1592303@1596123160.272802:virtqueue_flush vq 0x7fcd5c48a010 count 1 +1592303@1596123160.272833:virtio_notify vdev 0x56193d04d820 vq 0x7fcd5c48a010 +1592303@1596123160.845694:lockcnt_unlock_attempt lockcnt 0x56193bea6514 unlock 5->4 +1592303@1596123160.846821:lockcnt_unlock_success lockcnt 0x56193bea6514 unlock 5->4 succeeded +1592303@1596123160.847923:usb_host_req_complete dev 1:4, packet 0x7fcb84000ea8, status 0, length 0 +1592303@1596123160.849369:usb_packet_state_change bus 0, port 1, ep 2, packet 0x7fcb84000ea8, state async -> complete +1592303@1596123160.851157:usb_xhci_xfer_success 0x7fcb84000ea0: len 0 +1592303@1596123160.851214:usb_xhci_queue_event v 3, idx 5, ER_TRANSFER, CC_SHORT_PACKET, p 0xffffac0c62444ae3, s 0x0d000000, c 0x02058005 +1592303@1596123160.851285:usb_xhci_irq_msix nr 3 +1592303@1596123160.851331:usb_xhci_ep_kick slotid 2, epid 5, streamid 0 +1592303@1596123160.851374:usb_host_req_data dev 1:4, packet 0x56193cce8da8, in 1, ep 2, size 4 +1592303@1596123160.851434:usb_host_req_complete dev 1:4, packet 0x56193cce8da8, status -1, length 0 +1592303@1596123160.851485:usb_packet_state_change bus 0, port 1, ep 2, packet 0x56193cce8da8, state queued -> complete +1592303@1596123160.851541:usb_xhci_xfer_error 0x56193cce8da0: ret -1 +1592303@1596123160.851577:usb_xhci_queue_event v 3, idx 6, ER_TRANSFER, CC_USB_TRANSACTION_ERROR, p 0x00000001c18a4e20, s 0x04000004, c 0x02058001 +1592303@1596123160.851647:usb_xhci_ep_state slotid 2, epid 5, running -> halted +1592303@1596123160.852700:usb_xhci_ep_kick slotid 2, epid 5, streamid 0 +1592303@1596123160.852744:usb_host_req_complete dev 1:4, packet 0x7fcb84000b98, status 0, length 0 +1592303@1596123160.852788:usb_packet_state_change bus 0, port 1, ep 1, packet 0x7fcb84000b98, state async -> complete +1592303@1596123160.852845:usb_xhci_xfer_success 0x7fcb84000b90: len 0 +1592303@1596123160.852879:usb_xhci_queue_event v 3, idx 7, ER_TRANSFER, CC_SHORT_PACKET, p 0xffffac0c6229aae3, s 0x0d000000, c 0x02038005 +1592303@1596123160.852945:usb_xhci_ep_kick slotid 2, epid 3, streamid 0 +1592303@1596123160.852977:usb_host_req_data dev 1:4, packet 0x56193c9da348, in 1, ep 1, size 8 +1592303@1596123160.853031:usb_host_req_complete dev 1:4, packet 0x56193c9da348, status -1, length 0 +1592303@1596123160.853080:usb_packet_state_change bus 0, port 1, ep 1, packet 0x56193c9da348, state queued -> complete +1592303@1596123160.853136:usb_xhci_xfer_error 0x56193c9da340: ret -1 +1592303@1596123160.853170:usb_xhci_queue_event v 3, idx 8, ER_TRANSFER, CC_USB_TRANSACTION_ERROR, p 0x00000001c18a4c20, s 0x04000008, c 0x02038001 +1592303@1596123160.853240:usb_xhci_ep_state slotid 2, epid 3, running -> halted +1592303@1596123160.853280:usb_xhci_ep_kick slotid 2, epid 3, streamid 0 +1592303@1596123160.853316:lockcnt_unlock_attempt lockcnt 0x56193bea6514 unlock 1->4 +1592303@1596123160.853352:lockcnt_unlock_success lockcnt 0x56193bea6514 unlock 1->4 succeeded +1592303@1596123160.853564:usb_host_close dev 1:4 +libusb: error [udev_hotplug_event] ignoring udev action unbind + + +Link to bug on the proxmox side: + +https://bugzilla.proxmox.com/show_bug.cgi?id=2781 + +I do get get the same backtrace in gdb every time every time when we reproduce the hang: + +(gdb) thread apply all bt + +Thread 9 (Thread 0x7fd1415ff700 (LWP 3202)): +#0 0x00007fd323d154bf in __GI___poll (fds=0x7fd1415fe6c0, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 +#1 0x00007fd324978bb2 in ?? () from target:/lib/x86_64-linux-gnu/libusb-1.0.so.0 +#2 0x00007fd323defea7 in start_thread (arg=<optimized out>) at pthread_create.c:477 +#3 0x00007fd323d1feaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Thread 8 (Thread 0x7fd1437fe700 (LWP 3171)): +#0 0x00007fd323d16d87 in ioctl () at ../sysdeps/unix/syscall-template.S:120 +#1 0x000055a5daef74f7 in kvm_vcpu_ioctl () +#2 0x000055a5daef7631 in kvm_cpu_exec () +#3 0x000055a5daedaede in ?? () +#4 0x000055a5db32194b in ?? () +#5 0x00007fd323defea7 in start_thread (arg=<optimized out>) at pthread_create.c:477 +#6 0x00007fd323d1feaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Thread 7 (Thread 0x7fd143fff700 (LWP 3170)): +#0 0x00007fd323d16d87 in ioctl () at ../sysdeps/unix/syscall-template.S:120 +#1 0x000055a5daef74f7 in kvm_vcpu_ioctl () +#2 0x000055a5daef7631 in kvm_cpu_exec () +#3 0x000055a5daedaede in ?? () +#4 0x000055a5db32194b in ?? () +#5 0x00007fd323defea7 in start_thread (arg=<optimized out>) at pthread_create.c:477 +#6 0x00007fd323d1feaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Thread 6 (Thread 0x7fd150dfd700 (LWP 3169)): +#0 __lll_lock_wait (futex=futex@entry=0x55a5db80a540, private=0) at lowlevellock.c:52 +#1 0x00007fd323df2843 in __GI___pthread_mutex_lock (mutex=0x55a5db80a540) at ../nptl/pthread_mutex_lock.c:80 +#2 0x000055a5db321b43 in qemu_mutex_lock_impl () +#3 0x000055a5daedac8e in qemu_mutex_lock_iothread_impl () +#4 0x000055a5dae92ac9 in ?? () +#5 0x000055a5dae97de7 in flatview_read_continue () +#6 0x000055a5dae98023 in ?? () +#7 0x000055a5dae9813b in address_space_read_full () +#8 0x000055a5daef78cf in kvm_cpu_exec () +#9 0x000055a5daedaede in ?? () +#10 0x000055a5db32194b in ?? () +#11 0x00007fd323defea7 in start_thread (arg=<optimized out>) at pthread_create.c:477 +#12 0x00007fd323d1feaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Thread 5 (Thread 0x7fd1515fe700 (LWP 3168)): +#0 __lll_lock_wait (futex=futex@entry=0x55a5db80a540, private=0) at lowlevellock.c:52 +#1 0x00007fd323df2843 in __GI___pthread_mutex_lock (mutex=0x55a5db80a540) at ../nptl/pthread_mutex_lock.c:80 +#2 0x000055a5db321b43 in qemu_mutex_lock_impl () +#3 0x000055a5daedac8e in qemu_mutex_lock_iothread_impl () +#4 0x000055a5dae92ac9 in ?? () +#5 0x000055a5dae97de7 in flatview_read_continue () +#6 0x000055a5dae98023 in ?? () +#7 0x000055a5dae9813b in address_space_read_full () +#8 0x000055a5daef78cf in kvm_cpu_exec () +#9 0x000055a5daedaede in ?? () +#10 0x000055a5db32194b in ?? () +#11 0x00007fd323defea7 in start_thread (arg=<optimized out>) at pthread_create.c:477 +#12 0x00007fd323d1feaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Thread 4 (Thread 0x7fd151dff700 (LWP 3167)): +#0 __lll_lock_wait (futex=futex@entry=0x55a5db80a540, private=0) at lowlevellock.c:52 +#1 0x00007fd323df2843 in __GI___pthread_mutex_lock (mutex=0x55a5db80a540) at ../nptl/pthread_mutex_lock.c:80 +--Type <RET> for more, q to quit, c to continue without paging-- +#2 0x000055a5db321b43 in qemu_mutex_lock_impl () +#3 0x000055a5daedac8e in qemu_mutex_lock_iothread_impl () +#4 0x000055a5dae92ac9 in ?? () +#5 0x000055a5dae97de7 in flatview_read_continue () +#6 0x000055a5dae98023 in ?? () +#7 0x000055a5dae9813b in address_space_read_full () +#8 0x000055a5daef78cf in kvm_cpu_exec () +#9 0x000055a5daedaede in ?? () +#10 0x000055a5db32194b in ?? () +#11 0x00007fd323defea7 in start_thread (arg=<optimized out>) at pthread_create.c:477 +#12 0x00007fd323d1feaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Thread 3 (Thread 0x7fd320d97700 (LWP 3166)): +#0 0x00007fd323d154bf in __GI___poll (fds=0x7fd318003180, nfds=3, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 +#1 0x00007fd324a097ee in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0 +#2 0x00007fd324a09b53 in g_main_loop_run () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0 +#3 0x000055a5db016c71 in ?? () +#4 0x000055a5db32194b in ?? () +#5 0x00007fd323defea7 in start_thread (arg=<optimized out>) at pthread_create.c:477 +#6 0x00007fd323d1feaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Thread 2 (Thread 0x7fd3224de700 (LWP 3156)): +#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 +#1 0x000055a5db3226fa in qemu_event_wait () +#2 0x000055a5db33466a in ?? () +#3 0x000055a5db32194b in ?? () +#4 0x00007fd323defea7 in start_thread (arg=<optimized out>) at pthread_create.c:477 +#5 0x00007fd323d1feaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Thread 1 (Thread 0x7fd3224dff40 (LWP 3148)): +#0 0x00007fd323d154bf in __GI___poll (fds=0x55a5dca30150, nfds=3, timeout=3) at ../sysdeps/unix/sysv/linux/poll.c:29 +#1 0x00007fd324971f4d in ?? () from target:/lib/x86_64-linux-gnu/libusb-1.0.so.0 +#2 0x00007fd32497316c in libusb_handle_events_timeout_completed () from target:/lib/x86_64-linux-gnu/libusb-1.0.so.0 +#3 0x000055a5db18edc7 in ?? () +#4 0x000055a5db18efab in ?? () +#5 0x000055a5db31abf7 in aio_bh_poll () +#6 0x000055a5db31e3fe in aio_dispatch () +#7 0x000055a5db31aace in ?? () +#8 0x00007fd324a095fd in g_main_context_dispatch () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0 +#9 0x000055a5db31d638 in main_loop_wait () +#10 0x000055a5dafad309 in qemu_main_loop () +#11 0x000055a5dae9125e in main () +(gdb) + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting older bugs to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system (but you won't be the reporter of the bug +in the new system and thus won't get notified on changes anymore). + +Thank you and sorry for the inconvenience. + + +Issue does not occur in latest version of QEMU anymore. + diff --git a/results/classifier/108/other/1884693 b/results/classifier/108/other/1884693 new file mode 100644 index 00000000..949f7dc9 --- /dev/null +++ b/results/classifier/108/other/1884693 @@ -0,0 +1,78 @@ +other: 0.981 +graphic: 0.975 +permissions: 0.972 +performance: 0.967 +files: 0.964 +semantic: 0.957 +PID: 0.952 +device: 0.946 +debug: 0.943 +socket: 0.924 +KVM: 0.909 +boot: 0.906 +vnc: 0.899 +network: 0.871 + +Assertion failure in address_space_unmap through ahci_map_clb_address + +Hello, +Reproducer: +cat << EOF | ./i386-softmmu/qemu-system-i386 -qtest stdio -monitor none -serial none -M pc-q35-5.0 -nographic +outl 0xcf8 0x8000fa24 +outl 0xcfc 0xe1068000 +outl 0xcf8 0x8000fa04 +outw 0xcfc 0x7 +outl 0xcf8 0x8000fb20 +write 0xe1068304 0x1 0x21 +write 0xe1068318 0x1 0x21 +write 0xe1068384 0x1 0x21 +write 0xe1068398 0x2 0x21 +EOF + +Stack trace: +#0 0x55bfabfe9ea0 in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 +#1 0x55bfabfc8ef9 in __sanitizer_print_stack_trace (build/i386-softmmu/qemu-fuzz-i386+0x7b7ef9) +#2 0x55bfabfaf933 in fuzzer::PrintStackTrace() FuzzerUtil.cpp:210:5 +#3 0x7f88df76110f (/lib/x86_64-linux-gnu/libpthread.so.0+0x1410f) +#4 0x7f88df5a4760 in __libc_signal_restore_set /build/glibc-GwnBeO/glibc-2.30/signal/../sysdeps/unix/sysv/linux/internal-signals.h:84:10 +#5 0x7f88df5a4760 in raise /build/glibc-GwnBeO/glibc-2.30/signal/../sysdeps/unix/sysv/linux/raise.c:48:3 +#6 0x7f88df58e55a in abort /build/glibc-GwnBeO/glibc-2.30/stdlib/abort.c:79:7 +#7 0x7f88df58e42e in __assert_fail_base /build/glibc-GwnBeO/glibc-2.30/assert/assert.c:92:3 +#8 0x7f88df59d091 in __assert_fail /build/glibc-GwnBeO/glibc-2.30/assert/assert.c:101:3 +#9 0x55bfabff7182 in address_space_unmap exec.c:3602:9 +#10 0x55bfac4a452f in dma_memory_unmap include/sysemu/dma.h:148:5 +#11 0x55bfac4a452f in map_page hw/ide/ahci.c:254:9 +#12 0x55bfac4a1f98 in ahci_map_clb_address hw/ide/ahci.c:748:5 +#13 0x55bfac4a1f98 in ahci_cond_start_engines hw/ide/ahci.c:276:14 +#14 0x55bfac4a074e in ahci_port_write hw/ide/ahci.c:339:9 +#15 0x55bfac4a074e in ahci_mem_write hw/ide/ahci.c:513:9 +#16 0x55bfac0e0dc2 in memory_region_write_accessor memory.c:483:5 +#17 0x55bfac0e0bde in access_with_adjusted_size memory.c:544:18 +#18 0x55bfac0e0917 in memory_region_dispatch_write memory.c +#19 0x55bfabffa4fd in flatview_write_continue exec.c:3146:23 +#20 0x55bfabff569b in flatview_write exec.c:3186:14 +#21 0x55bfabff569b in address_space_write exec.c:3280:18 +#22 0x55bfac8982a9 in op_write_pattern tests/qtest/fuzz/general_fuzz.c:407:5 +#23 0x55bfac897749 in general_fuzz tests/qtest/fuzz/general_fuzz.c:481:17 +#24 0x55bfac8930a2 in LLVMFuzzerTestOneInput tests/qtest/fuzz/fuzz.c:136:5 +#25 0x55bfabfb0e68 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) FuzzerLoop.cpp:558:15 +#26 0x55bfabfb0485 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) FuzzerLoop.cpp:470:3 +#27 0x55bfabfb18a1 in fuzzer::Fuzzer::MutateAndTestOne() FuzzerLoop.cpp:701:19 +#28 0x55bfabfb2305 in fuzzer::Fuzzer::Loop(std::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) FuzzerLoop.cpp:837:5 +#29 0x55bfabfa2018 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) FuzzerDriver.cpp:846:6 +#30 0x55bfabfb8722 in main FuzzerMain.cpp:19:10 +#31 0x7f88df58fe0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 +#32 0x55bfabf97869 in _start (build/i386-softmmu/qemu-fuzz-i386+0x786869) + +The same error can be triggered through ahci_map_fis_address @ hw/ide/ahci.c:721:5 +Found with generic device fuzzer: https://<email address hidden>/ + +Please let me know if I can provide any further info. + +Proposed fix: +https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg05637.html + +Merged: 1d1c4bdb736688b20d864831b90c07dc59c7b10c + +Released with QEMU v5.2.0. + diff --git a/results/classifier/108/other/1884719 b/results/classifier/108/other/1884719 new file mode 100644 index 00000000..ae7515cf --- /dev/null +++ b/results/classifier/108/other/1884719 @@ -0,0 +1,595 @@ +permissions: 0.772 +PID: 0.737 +device: 0.736 +graphic: 0.713 +other: 0.707 +performance: 0.688 +semantic: 0.626 +vnc: 0.550 +files: 0.524 +boot: 0.462 +debug: 0.430 +KVM: 0.388 +network: 0.358 +socket: 0.352 + +Function not implemented when using libaio + +Hello + +I experience "Function not implemented" errors when trying to use Linux libaio library in foreign architecture, e.g. aarch64. + +I've faced this problem while using https://github.com/multiarch/qemu-user-static, i.e. Docker+QEMU. +I understand that I do not use plain QEMU and you may count this report as a "distribution of QEMU"! Just let me know what are the steps to test it with plain QEMU and I will test and update this ticket! + + +Here are the steps to reproduce the issue: + +1) On x86_64 machine register QEMU: + + `docker run -it --rm --privileged multiarch/qemu-user-static --reset --credential yes --persistent yes` + +2) Start a Docker image with foreign CPU architecture, e.g. aarch64 + + `docker run -it arm64v8/centos:8 bash` + +3) Inside the Docker container install GCC and libaio + + `yum install gcc libaio libaio-devel` + +4) Compile the following C program + +``` +#include <stdio.h> +#include <errno.h> +#include <libaio.h> +#include <stdlib.h> + +struct io_control { + io_context_t ioContext; +}; + +int main() { + int queueSize = 10; + + struct io_control * theControl = (struct io_control *) malloc(sizeof(struct io_control)); + if (theControl == NULL) { + printf("theControl is NULL"); + return 123; + } + + int res = io_queue_init(queueSize, &theControl->ioContext); + io_queue_release(theControl->ioContext); + free(theControl); + printf("res is: %d", res); +} +``` + + ``` + cat > test.c + [PASTE THE CODE ABOVE HERE] + ^D + ``` + + `gcc test.c -o out -laio && ./out` + + +When executed directly on aarch64 machine (i.e. without emulation) or on x86_64 Docker image (e.g. centos:8) it prints `res is: 0`, i.e. it successfully initialized a LibAIO queue. + +But when executed on Docker image with foreign/emulated CPU architecture it prints `res is: -38` (ENOSYS). `man io_queue_init` says that error ENOSYS is returned when "Not implemented." + +Environment: + +QEMU version: 5.0.0.2 (https://github.com/multiarch/qemu-user-static/blob/master/.travis.yml#L24-L28) +Container application: Docker +Output of `docker --version`: + +``` +Client: + Version: 19.03.8 + API version: 1.40 + Go version: go1.13.8 + Git commit: afacb8b7f0 + Built: Wed Mar 11 23:42:35 2020 + OS/Arch: linux/amd64 + Experimental: false + +Server: + Engine: + Version: 19.03.8 + API version: 1.40 (minimum version 1.12) + Go version: go1.13.8 + Git commit: afacb8b7f0 + Built: Wed Mar 11 22:48:33 2020 + OS/Arch: linux/amd64 + Experimental: false + containerd: + Version: 1.3.3-0ubuntu2 + GitCommit: + runc: + Version: spec: 1.0.1-dev + GitCommit: + docker-init: + Version: 0.18.0 + GitCommit: +``` + +Same happens with Ubuntu (arm64v8/ubuntu:focal). + +I've tried to `strace` it but : + +``` +/usr/bin/strace: ptrace(PTRACE_TRACEME, ...): Function not implemented +/usr/bin/strace: PTRACE_SETOPTIONS: Function not implemented +/usr/bin/strace: detach: waitpid(112): No child processes +/usr/bin/strace: Process 112 detached +``` + +Here are the steps to reproduce the problem with strace: + + ``` + docker run --rm -it --security-opt seccomp:unconfined --security-opt apparmor:unconfined --privileged --cap-add ALL arm64v8/centos:8 bash + + yum install -y strace` + + strace echo Test + ``` + +Note: I used --privileged, disabled seccomp and apparmor, and added all capabilities + +Disabling security solves the "Permission denied" problem but then comes the "Not implemented" one. + + +Any idea what could be the problem and how to work it around ? +I've googled a lot but I wasn't able to find any problems related to libaio on QEMU. + +Thank you! +Martin + +On Tue, Jun 23, 2020 at 07:39:58AM -0000, Martin Grigorov wrote: +> Public bug reported: + +CCing Filip and Laurent, who may be interested in adding Linux AIO +syscalls to qemu-user. + +> +> Hello +> +> I experience "Function not implemented" errors when trying to use Linux +> libaio library in foreign architecture, e.g. aarch64. +> +> I've faced this problem while using https://github.com/multiarch/qemu-user-static, i.e. Docker+QEMU. +> I understand that I do not use plain QEMU and you may count this report as a "distribution of QEMU"! Just let me know what are the steps to test it with plain QEMU and I will test and update this ticket! +> +> +> Here are the steps to reproduce the issue: +> +> 1) On x86_64 machine register QEMU: +> +> `docker run -it --rm --privileged multiarch/qemu-user-static --reset +> --credential yes --persistent yes` +> +> 2) Start a Docker image with foreign CPU architecture, e.g. aarch64 +> +> `docker run -it arm64v8/centos:8 bash` +> +> 3) Inside the Docker container install GCC and libaio +> +> `yum install gcc libaio libaio-devel` +> +> 4) Compile the following C program +> +> ``` +> #include <stdio.h> +> #include <errno.h> +> #include <libaio.h> +> #include <stdlib.h> +> +> struct io_control { +> io_context_t ioContext; +> }; +> +> int main() { +> int queueSize = 10; +> +> struct io_control * theControl = (struct io_control *) malloc(sizeof(struct io_control)); +> if (theControl == NULL) { +> printf("theControl is NULL"); +> return 123; +> } +> +> int res = io_queue_init(queueSize, &theControl->ioContext); +> io_queue_release(theControl->ioContext); +> free(theControl); +> printf("res is: %d", res); +> } +> ``` +> +> ``` +> cat > test.c +> [PASTE THE CODE ABOVE HERE] +> ^D +> ``` +> +> `gcc test.c -o out -laio && ./out` +> +> +> When executed directly on aarch64 machine (i.e. without emulation) or on x86_64 Docker image (e.g. centos:8) it prints `res is: 0`, i.e. it successfully initialized a LibAIO queue. +> +> But when executed on Docker image with foreign/emulated CPU architecture +> it prints `res is: -38` (ENOSYS). `man io_queue_init` says that error +> ENOSYS is returned when "Not implemented." +> +> Environment: +> +> QEMU version: 5.0.0.2 (https://github.com/multiarch/qemu-user-static/blob/master/.travis.yml#L24-L28) +> Container application: Docker +> Output of `docker --version`: +> +> ``` +> Client: +> Version: 19.03.8 +> API version: 1.40 +> Go version: go1.13.8 +> Git commit: afacb8b7f0 +> Built: Wed Mar 11 23:42:35 2020 +> OS/Arch: linux/amd64 +> Experimental: false +> +> Server: +> Engine: +> Version: 19.03.8 +> API version: 1.40 (minimum version 1.12) +> Go version: go1.13.8 +> Git commit: afacb8b7f0 +> Built: Wed Mar 11 22:48:33 2020 +> OS/Arch: linux/amd64 +> Experimental: false +> containerd: +> Version: 1.3.3-0ubuntu2 +> GitCommit: +> runc: +> Version: spec: 1.0.1-dev +> GitCommit: +> docker-init: +> Version: 0.18.0 +> GitCommit: +> ``` +> +> Same happens with Ubuntu (arm64v8/ubuntu:focal). +> +> I've tried to `strace` it but : +> +> ``` +> /usr/bin/strace: ptrace(PTRACE_TRACEME, ...): Function not implemented +> /usr/bin/strace: PTRACE_SETOPTIONS: Function not implemented +> /usr/bin/strace: detach: waitpid(112): No child processes +> /usr/bin/strace: Process 112 detached +> ``` +> +> Here are the steps to reproduce the problem with strace: +> +> ``` +> docker run --rm -it --security-opt seccomp:unconfined --security-opt apparmor:unconfined --privileged --cap-add ALL arm64v8/centos:8 bash +> +> yum install -y strace` +> +> strace echo Test +> ``` +> +> Note: I used --privileged, disabled seccomp and apparmor, and added all +> capabilities +> +> Disabling security solves the "Permission denied" problem but then comes +> the "Not implemented" one. +> +> +> Any idea what could be the problem and how to work it around ? +> I've googled a lot but I wasn't able to find any problems related to libaio on QEMU. +> +> Thank you! +> Martin +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1884719 +> +> Title: +> Function not implemented when using libaio +> +> Status in QEMU: +> New +> +> Bug description: +> Hello +> +> I experience "Function not implemented" errors when trying to use +> Linux libaio library in foreign architecture, e.g. aarch64. +> +> I've faced this problem while using https://github.com/multiarch/qemu-user-static, i.e. Docker+QEMU. +> I understand that I do not use plain QEMU and you may count this report as a "distribution of QEMU"! Just let me know what are the steps to test it with plain QEMU and I will test and update this ticket! +> +> +> Here are the steps to reproduce the issue: +> +> 1) On x86_64 machine register QEMU: +> +> `docker run -it --rm --privileged multiarch/qemu-user-static +> --reset --credential yes --persistent yes` +> +> 2) Start a Docker image with foreign CPU architecture, e.g. aarch64 +> +> `docker run -it arm64v8/centos:8 bash` +> +> 3) Inside the Docker container install GCC and libaio +> +> `yum install gcc libaio libaio-devel` +> +> 4) Compile the following C program +> +> ``` +> #include <stdio.h> +> #include <errno.h> +> #include <libaio.h> +> #include <stdlib.h> +> +> struct io_control { +> io_context_t ioContext; +> }; +> +> int main() { +> int queueSize = 10; +> +> struct io_control * theControl = (struct io_control *) malloc(sizeof(struct io_control)); +> if (theControl == NULL) { +> printf("theControl is NULL"); +> return 123; +> } +> +> int res = io_queue_init(queueSize, &theControl->ioContext); +> io_queue_release(theControl->ioContext); +> free(theControl); +> printf("res is: %d", res); +> } +> ``` +> +> ``` +> cat > test.c +> [PASTE THE CODE ABOVE HERE] +> ^D +> ``` +> +> `gcc test.c -o out -laio && ./out` +> +> +> When executed directly on aarch64 machine (i.e. without emulation) or on x86_64 Docker image (e.g. centos:8) it prints `res is: 0`, i.e. it successfully initialized a LibAIO queue. +> +> But when executed on Docker image with foreign/emulated CPU +> architecture it prints `res is: -38` (ENOSYS). `man io_queue_init` +> says that error ENOSYS is returned when "Not implemented." +> +> Environment: +> +> QEMU version: 5.0.0.2 (https://github.com/multiarch/qemu-user-static/blob/master/.travis.yml#L24-L28) +> Container application: Docker +> Output of `docker --version`: +> +> ``` +> Client: +> Version: 19.03.8 +> API version: 1.40 +> Go version: go1.13.8 +> Git commit: afacb8b7f0 +> Built: Wed Mar 11 23:42:35 2020 +> OS/Arch: linux/amd64 +> Experimental: false +> +> Server: +> Engine: +> Version: 19.03.8 +> API version: 1.40 (minimum version 1.12) +> Go version: go1.13.8 +> Git commit: afacb8b7f0 +> Built: Wed Mar 11 22:48:33 2020 +> OS/Arch: linux/amd64 +> Experimental: false +> containerd: +> Version: 1.3.3-0ubuntu2 +> GitCommit: +> runc: +> Version: spec: 1.0.1-dev +> GitCommit: +> docker-init: +> Version: 0.18.0 +> GitCommit: +> ``` +> +> Same happens with Ubuntu (arm64v8/ubuntu:focal). +> +> I've tried to `strace` it but : +> +> ``` +> /usr/bin/strace: ptrace(PTRACE_TRACEME, ...): Function not implemented +> /usr/bin/strace: PTRACE_SETOPTIONS: Function not implemented +> /usr/bin/strace: detach: waitpid(112): No child processes +> /usr/bin/strace: Process 112 detached +> ``` +> +> Here are the steps to reproduce the problem with strace: +> +> ``` +> docker run --rm -it --security-opt seccomp:unconfined --security-opt apparmor:unconfined --privileged --cap-add ALL arm64v8/centos:8 bash +> +> yum install -y strace` +> +> strace echo Test +> ``` +> +> Note: I used --privileged, disabled seccomp and apparmor, and added +> all capabilities +> +> Disabling security solves the "Permission denied" problem but then +> comes the "Not implemented" one. +> +> +> Any idea what could be the problem and how to work it around ? +> I've googled a lot but I wasn't able to find any problems related to libaio on QEMU. +> +> Thank you! +> Martin +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1884719/+subscriptions +> + + +ptrace() is not implemented, + +it's why we use gdb server rather than gdb and we use QEMU_STRACE variable rather than strace command. + +You can test it works with: + + QEMU_STRACE= bash -c "echo Test" + +Could you try to execute your test program with it: + + QEMU_STRACE= ./out + + + +The not-implemented syscalls are: + +... +276 io_setup(10,274877981280,33,274877981296,274877981280,274877981184) = -1 errno=38 (Function not implemented) +276 io_destroy(0,274877981280,33,274877981296,274877981280,274877981184) = -1 errno=38 (Function not implemented) +... + +Executing `QEMU_STRACE= ./out` here gives: + + +259 brk(NULL) = 0x0000000000421000 +259 uname(0x40008003d8) = 0 +259 faccessat(AT_FDCWD,"/etc/ld.so.preload",R_OK,AT_SYMLINK_NOFOLLOW|0x50) = -1 errno=2 (No such file or directory) +259 openat(AT_FDCWD,"/etc/ld.so.cache",O_RDONLY|O_CLOEXEC) = 3 +259 fstat(3,0x00000040007ff960) = 0 +259 mmap(NULL,13646,PROT_READ,MAP_PRIVATE,3,0) = 0x0000004000843000 +259 close(3) = 0 +259 openat(AT_FDCWD,"/lib64/libaio.so.1",O_RDONLY|O_CLOEXEC) = 3 +259 read(3,0x7ffb20,832) = 832 +259 fstat(3,0x00000040007ff9b0) = 0 +259 mmap(NULL,131096,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x0000004000847000 +259 mprotect(0x0000004000849000,118784,PROT_NONE) = 0 +259 mmap(0x0000004000866000,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0xf000) = 0x0000004000866000 +259 mmap(0x0000004000867000,24,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x0000004000867000 +259 close(3) = 0 +259 openat(AT_FDCWD,"/lib64/libc.so.6",O_RDONLY|O_CLOEXEC) = 3 +259 read(3,0x7ffb00,832) = 832 +259 fstat(3,0x00000040007ff990) = 0 +259 mmap(NULL,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x0000004000868000 +259 mmap(NULL,1527680,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x000000400086a000 +259 mprotect(0x00000040009c3000,77824,PROT_NONE) = 0 +259 mmap(0x00000040009d6000,24576,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x15c000) = 0x00000040009d6000 +259 mmap(0x00000040009dc000,12160,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x00000040009dc000 +259 close(3) = 0 +259 mprotect(0x00000040009d6000,16384,PROT_READ) = 0 +259 mprotect(0x0000004000866000,4096,PROT_READ) = 0 +259 mprotect(0x000000000041f000,4096,PROT_READ) = 0 +259 mprotect(0x0000004000840000,4096,PROT_READ) = 0 +259 munmap(0x0000004000843000,13646) = 0 +259 brk(NULL) = 0x0000000000421000 +259 brk(0x0000000000442000) = 0x0000000000442000 +259 brk(NULL) = 0x0000000000442000 +259 io_setup(10,4330144,4330160,4330144,274886726560,511) = -1 errno=38 (Function not implemented) +259 io_destroy(0,274886726560,38,274886726560,511,512) = -1 errno=38 (Function not implemented) +259 fstat(1,0x0000004000800388) = 0 +259 write(1,0x4212c0,11)res is: -38 = 11 +259 exit_group(0) + + +Thanks for looking into this issue, Laurent Vivier! + + + +Could I help somehow to resolve this issue ? + +Martin, + +do you want to propose some patches to fix the problem? + +Thanks + +Laurent, + +I am not familiar with the internals of QEMU but if you point me to the source code of similar functionality I could try! + +Thanks! + +Martin, + +after a first look, I can see that asynchronicity introduces more complexity in QEMU than usual ... + +I'm going to try to write the patches. I will ask you some help to test them. + +I've already implemented io_setup and io_destroy, but io_submit introduces more complexity because we can only cleanup qemu internal buffers when the I/O are done. To do that we need to intercept events at io_getevents level. + + +I will push my patches here: + +https://github.com/vivier/qemu/commits/linux-user-libaio + +Thank you for working on this, Laurent! +Just let me know and I will test your changes! + +Hey Laurent! + +I know it is the summer holidays season! +I just wanted to ask you whether I should test your branch or you have more planned work ? + + + +The code in my branch has two problems: + +- it doesn't work if the host is 64bit and the target 32bit (because the context id returned by the host is in fact a virtual address and the data type is long, so the context_id (host long) doesn't fit in target context_id (target long). + +- I played with some stress tests and at some points it crashes. + +I don't have enough time to work on this for the moment. + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting older bugs to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system (but you won't be the reporter of the bug +in the new system and thus won't get notified on changes anymore). + +Thank you and sorry for the inconvenience. + + +Bug has been re-opened here: +https://gitlab.com/qemu-project/qemu/-/issues/210 +Thanks for copying it over, Martin! + diff --git a/results/classifier/108/other/1884831 b/results/classifier/108/other/1884831 new file mode 100644 index 00000000..95cfdd57 --- /dev/null +++ b/results/classifier/108/other/1884831 @@ -0,0 +1,196 @@ +other: 0.943 +debug: 0.935 +semantic: 0.931 +PID: 0.929 +graphic: 0.927 +device: 0.919 +vnc: 0.911 +KVM: 0.906 +performance: 0.904 +permissions: 0.898 +network: 0.865 +socket: 0.847 +boot: 0.832 +files: 0.792 + +qemu-nbd fails to discard bigger chunks + +This report is moved from systemd to here: +https://github.com/systemd/systemd/issues/16242 + +A qemu-nbd device reports that it can discard a lot of bytes: + +cat /sys/block/nbd0/queue/discard_max_bytes +2199023255040 + +And indeed, discard works with small images: + +$ qemu-img create -f qcow2 /tmp/image.img 2M +$ sudo qemu-nbd --connect=/dev/nbd0 /tmp/image.img +$ sudo blkdiscard /dev/nbd0 + +but not for bigger ones (still smaller than discard_max_bytes): + +$ qemu-img create -f qcow2 /tmp/image.img 5G +$ sudo qemu-nbd --connect=/dev/nbd0 /tmp/image.img +$ sudo blkdiscard /dev/nbd0 + +On 6/23/20 3:19 PM, TobiasHunger wrote: +> Public bug reported: +> +> This report is moved from systemd to here: +> https://github.com/systemd/systemd/issues/16242 +> +> A qemu-nbd device reports that it can discard a lot of bytes: +> +> cat /sys/block/nbd0/queue/discard_max_bytes +> 2199023255040 + +That smells fishy. It is 0xffffffff * 512. But in reality, the NBD +protocol is (currently) capped at 32 bits, so it cannot handle any +request 4G or larger. + +It is not qemu-nbd that populates +/sys/block/nbd0/queue/discard_max_bytes, but the kernel. Are you sure +this is not a bug in the kernel's nbd.ko module, where it may be the +case that it is reporting -1 as a 32-bit value which then gets +mistakenly turned into a faulty advertisement? Can you tweak your +software to behave as if /dev/nbd0 had a discard_max_bytes of 0xfffff000 +instead? + +In fact, to prove the bug is in the kernel's nbd.ko and not in qemu-nbd, +I created an NBD server using nbdkit: + +# modprobe nbd +# nbdkit memory 5G +# nbd-client -b 512 localhost /dev/nbd0 +# cat /sys/block/nbd0/queue/discard_max_bytes +2199023255040 + +Same answer, different nbd server. So it's not qemu's fault. + +> +> And indeed, discard works with small images: +> +> $ qemu-img create -f qcow2 /tmp/image.img 2M +> $ sudo qemu-nbd --connect=/dev/nbd0 /tmp/image.img +> $ sudo blkdiscard /dev/nbd0 +> +> but not for bigger ones (still smaller than discard_max_bytes): +> +> $ qemu-img create -f qcow2 /tmp/image.img 5G +> $ sudo qemu-nbd --connect=/dev/nbd0 /tmp/image.img +> $ sudo blkdiscard /dev/nbd0 +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> + +-- +Eric Blake, Principal Software Engineer +Red Hat, Inc. +1-919-301-3226 +Virtualization: qemu.org | libvirt.org + + + +Hmm, carrying on further, with the nbd-client connection, I'm seeing that the kernel DID break things into two separate BLKDISCARD calls, as seen from the nbdkit side of things: + +# from the blkdiscard strace: +ioctl(3, BLKGETSIZE64, [5368709120]) = 0 +ioctl(3, BLKSSZGET, [512]) = 0 +ioctl(3, BLKDISCARD, [0, 5368709120]) = 0 +# from the nbdkit debug log: +nbdkit: memory.0: debug: memory: trim count=4294966784 offset=0 fua=0 +nbdkit: memory.3: debug: memory: trim count=1073742336 offset=4294966784 fua=0 + +I'm now comparing the set of ioctl calls made by nbd-client vs. qemu-nbd to see what might explain the difference for why it worked with nbd-client when the two different servers connect to the kernel nbd.ko module. In the meantime, since nbd-client worked but qemu-nbd did not, it does look like this may be qemu's problem after all. + + +Let's get nbd.ko out of the picture. The problem can be reproduced in user space (here, where I built qemu-nbd to log trace messages to stderr): + +$ truncate --size=3G file +$ qemu-nbd -f raw file --trace=nbd_\* +$ nbdsh -u nbd://localhost:10810 -c 'h.trim(3*1024*1024*1024,0)' +Traceback (most recent call last): + File "/usr/lib64/python3.8/runpy.py", line 194, in _run_module_as_main + return _run_code(code, main_globals, None, + File "/usr/lib64/python3.8/runpy.py", line 87, in _run_code + exec(code, run_globals) + File "/usr/lib64/python3.8/site-packages/nbd.py", line 1762, in <module> + nbdsh.shell() + File "/usr/lib64/python3.8/site-packages/nbdsh.py", line 100, in shell + exec (c, d, d) + File "<string>", line 1, in <module> + File "/usr/lib64/python3.8/site-packages/nbd.py", line 1098, in trim + return libnbdmod.trim (self._o, count, offset, flags) +nbd.Error: nbd_trim: trim: command failed: Input/output error (EIO) + +and looking at the trace output from qemu-nbd, I see: +493771@1592948038.044141:nbd_negotiate_success Negotiation succeeded +493771@1592948038.044167:nbd_trip Reading request +493771@1592948038.044262:nbd_receive_request Got request: { magic = 0x25609513, .flags = 0x0, .type = 0x4, from = 0, len = 3221225472 } +493771@1592948038.044272:nbd_co_receive_request_decode_type Decoding type: handle = 1, type = 4 (trim) +493771@1592948038.044291:nbd_co_send_structured_error Send structured error reply: handle = 1, error = 5 (EIO), msg = 'discard failed' + +so this is definitely a case of qemu as NBD server NOT honoring requests between 2G and 4G. I'll have a patch posted soon. + + + + +On 6/23/20 4:35 PM, Eric Blake wrote: +> Let's get nbd.ko out of the picture. The problem can be reproduced in +> user space (here, where I built qemu-nbd to log trace messages to +> stderr): +> +> $ truncate --size=3G file +> $ qemu-nbd -f raw file --trace=nbd_\* +> $ nbdsh -u nbd://localhost:10810 -c 'h.trim(3*1024*1024*1024,0)' + +> nbd.Error: nbd_trim: trim: command failed: Input/output error (EIO) +> + +> +> so this is definitely a case of qemu as NBD server NOT honoring requests +> between 2G and 4G. I'll have a patch posted soon. + +https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg06592.html + +-- +Eric Blake, Principal Software Engineer +Red Hat, Inc. +1-919-301-3226 +Virtualization: qemu.org | libvirt.org + + + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting older bugs to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system (but you won't be the reporter of the bug +in the new system and thus won't get notified on changes anymore). + +Thank you and sorry for the inconvenience. + + +Commit 890cbccb0 included in upstream release 5.1.0. + diff --git a/results/classifier/108/other/1885 b/results/classifier/108/other/1885 new file mode 100644 index 00000000..32452859 --- /dev/null +++ b/results/classifier/108/other/1885 @@ -0,0 +1,39 @@ +graphic: 0.874 +device: 0.852 +boot: 0.816 +PID: 0.787 +performance: 0.756 +files: 0.653 +permissions: 0.609 +network: 0.600 +socket: 0.576 +other: 0.570 +semantic: 0.543 +vnc: 0.537 +debug: 0.527 +KVM: 0.154 + +mipsel malta machine is broken in avocado console tests +Description of problem: +As noted in #1884 we see failures of the boot_linux_console.py test. Unlikely other avocado failures, these ones are consistent and reproduce locally with 100% success + +``` +./configure --target-list=mipsel-softmmu +make -j 20 +cd build +./pyvenv/bin/python3 -B -m avocado --show=app run --job-results-dir=./tests/results -t arch:mipsel --failfast tests/avocado/boot_linux_console.py:BootLinuxConsole.test_mips_malta32el_nanomips_4k +``` + +This test will reliably fail with a timeout waiting for console output. + +Attempting to run the QEMU command manually + +``` +$ ./qemu-system-mipsel -display none -vga none -machine malta -chardev stdio,id=console -serial chardev:console -cpu I7200 -no-reboot -kernel /home/berrange/src/virt/qemu/build/tests/results/job-2023-09-13T17.14-77de093/test-results/tmp_dir520smana/1-tests_avocado_boot_linux_console.py_BootLinuxConsole.test_mips_malta32el_nanomips_4kkernel -append 'printk.time=0 mem=256m@@0x0 console=ttyS0' +``` + +results in no serial console output at all. + +IMHO either the MIPS malta machine has had a regression, or the kernel we're downloading for testing has had a regression. +Additional information: + diff --git a/results/classifier/108/other/1885175 b/results/classifier/108/other/1885175 new file mode 100644 index 00000000..e56a76f8 --- /dev/null +++ b/results/classifier/108/other/1885175 @@ -0,0 +1,97 @@ +permissions: 0.891 +other: 0.862 +performance: 0.853 +files: 0.836 +graphic: 0.832 +device: 0.822 +debug: 0.818 +semantic: 0.818 +network: 0.812 +KVM: 0.808 +vnc: 0.807 +boot: 0.800 +PID: 0.776 +socket: 0.754 + +memory.c range assertion hit at full invalidating + +I am able to hit this assertion when a Red Hat 7 guest virtio_net device raises an "Invalidation" of all the TLB entries. This happens in the guest's startup if 'intel_iommu=on' argument is passed to the guest kernel and right IOMMU/ATS devices are declared in qemu's command line. + +Command line: /home/qemu/x86_64-softmmu/qemu-system-x86_64 -name guest=rhel7-test,debug-threads=on -machine pc-q35-5.1,accel=kvm,usb=off,dump-guest-core=off,kernel_irqchip=split -cpu Broadwell,vme=on,ss=on,vmx=on,f16c=on,rdrand=on,hypervisor=on,arat=on,tsc-adjust=on,umip=on,arch-capabilities=on,xsaveopt=on,pdpe1gb=on,abm=on,skip-l1dfl-vmentry=on,rtm=on,hle=on -m 8096 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid d022ecbf-679e-4755-87ce-eb87fc5bbc5d -display none -no-user-config -nodefaults -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 -boot strict=on -device intel-iommu,intremap=on,device-iotlb=on -device pcie-root-port,port=0x8,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x1 -device pcie-root-port,port=0x9,chassis=2,id=pci.2,bus=pcie.0,addr=0x1.0x1 -device pcie-root-port,port=0xa,chassis=3,id=pci.3,bus=pcie.0,addr=0x1.0x2 -device pcie-root-port,port=0xb,chassis=4,id=pci.4,bus=pcie.0,addr=0x1.0x3 -device pcie-root-port,port=0xc,chassis=5,id=pci.5,bus=pcie.0,addr=0x1.0x4 -device pcie-root-port,port=0xd,chassis=6,id=pci.6,bus=pcie.0,addr=0x1.0x5 -device pcie-root-port,port=0xe,chassis=7,id=pci.7,bus=pcie.0,addr=0x1.0x6 -device qemu-xhci,p2=15,p3=15,id=usb,bus=pci.2,addr=0x0 -device virtio-serial-pci,id=virtio-serial0,bus=pci.3,addr=0x0 -drive file=/home/virtio-test2.qcow2,format=qcow2,if=none,id=drive-virtio-disk0 -device virtio-blk-pci,scsi=off,bus=pci.4,addr=0x0,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,id=hostnet0,vhost=on,vhostforce=on -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:0d:1d:f2,bus=pci.1,addr=0x0,iommu_platform=on,ats=on -device virtio-balloon-pci,id=balloon0,bus=pci.5,addr=0x0 -object rng-random,id=objrng0,filename=/dev/urandom -device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.6,addr=0x0 -s -msg timestamp=on + +Full backtrace: + +#0 0x00007ffff521370f in raise () at /lib64/libc.so.6 +#1 0x00007ffff51fdb25 in abort () at /lib64/libc.so.6 +#2 0x00007ffff51fd9f9 in _nl_load_domain.cold.0 () at /lib64/libc.so.6 +#3 0x00007ffff520bcc6 in .annobin_assert.c_end () at /lib64/libc.so.6 +#4 0x0000555555888171 in memory_region_notify_one (notifier=0x7ffde05dfde8, entry=0x7ffde5dfe200) at /home/qemu/memory.c:1918 +#5 0x0000555555888247 in memory_region_notify_iommu (iommu_mr=0x555556f6c0b0, iommu_idx=0, entry=...) at /home/qemu/memory.c:1941 +#6 0x0000555555951c8d in vtd_process_device_iotlb_desc (s=0x555557609000, inv_desc=0x7ffde5dfe2d0) + at /home/qemu/hw/i386/intel_iommu.c:2468 +#7 0x0000555555951e6a in vtd_process_inv_desc (s=0x555557609000) at /home/qemu/hw/i386/intel_iommu.c:2531 +#8 0x0000555555951fa5 in vtd_fetch_inv_desc (s=0x555557609000) at /home/qemu/hw/i386/intel_iommu.c:2563 +#9 0x00005555559520e5 in vtd_handle_iqt_write (s=0x555557609000) at /home/qemu/hw/i386/intel_iommu.c:2590 +#10 0x0000555555952b45 in vtd_mem_write (opaque=0x555557609000, addr=136, val=2688, size=4) at /home/qemu/hw/i386/intel_iommu.c:2837 +#11 0x0000555555883e17 in memory_region_write_accessor + (mr=0x555557609330, addr=136, value=0x7ffde5dfe478, size=4, shift=0, mask=4294967295, attrs=...) at /home/qemu/memory.c:483 +#12 0x000055555588401d in access_with_adjusted_size + (addr=136, value=0x7ffde5dfe478, size=4, access_size_min=4, access_size_max=8, access_fn= + 0x555555883d38 <memory_region_write_accessor>, mr=0x555557609330, attrs=...) at /home/qemu/memory.c:544 +#13 0x0000555555886f37 in memory_region_dispatch_write (mr=0x555557609330, addr=136, data=2688, op=MO_32, attrs=...) + at /home/qemu/memory.c:1476 +#14 0x0000555555827a03 in flatview_write_continue + (fv=0x7ffde00935d0, addr=4275634312, attrs=..., ptr=0x7ffff7ff0028, len=4, addr1=136, l=4, mr=0x555557609330) at /home/qemu/exec.c:3146 +#15 0x0000555555827b48 in flatview_write (fv=0x7ffde00935d0, addr=4275634312, attrs=..., buf=0x7ffff7ff0028, len=4) + at /home/qemu/exec.c:3186 +#16 0x0000555555827e9d in address_space_write + (as=0x5555567ca640 <address_space_memory>, addr=4275634312, attrs=..., buf=0x7ffff7ff0028, len=4) at /home/qemu/exec.c:3277 +#17 0x0000555555827f0a in address_space_rw + (as=0x5555567ca640 <address_space_memory>, addr=4275634312, attrs=..., buf=0x7ffff7ff0028, len=4, is_write=true) + at /home/qemu/exec.c:3287 +#18 0x000055555589b633 in kvm_cpu_exec (cpu=0x555556b65640) at /home/qemu/accel/kvm/kvm-all.c:2511 +#19 0x0000555555876ba8 in qemu_kvm_cpu_thread_fn (arg=0x555556b65640) at /home/qemu/cpus.c:1284 +#20 0x0000555555dafff1 in qemu_thread_start (args=0x555556b8c3b0) at util/qemu-thread-posix.c:521 +#21 0x00007ffff55a62de in start_thread () at /lib64/libpthread.so.0 +#22 0x00007ffff52d7e83 in clone () at /lib64/libc.so.6 + +-- + +If we examinate *entry in frame 4 of backtrace: +*entry = {target_as = 0x555556f6c050, iova = 0x0, translated_addr = 0x0, addr_mask = 0xffffffffffffffff, perm = 0x0} + +Which (I think) tries to invalidate all the TLB registers of the device. + +Just deleting that assert is enough for the VM to start and communicate using IOMMU, but maybe a better alternative is possible. We could move it to the caller functions in other cases than IOMMU invalidation, or make it conditional only if not invalidating. + +Guest kernel version: kernel-3.10.0-1136.el7 + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting older bugs to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system (but you won't be the reporter of the bug +in the new system and thus won't get notified on changes anymore). + +Thank you and sorry for the inconvenience. + + diff --git a/results/classifier/108/other/1885332 b/results/classifier/108/other/1885332 new file mode 100644 index 00000000..1f98ce8f --- /dev/null +++ b/results/classifier/108/other/1885332 @@ -0,0 +1,371 @@ +other: 0.841 +permissions: 0.831 +debug: 0.825 +graphic: 0.811 +semantic: 0.797 +device: 0.793 +performance: 0.767 +PID: 0.765 +vnc: 0.731 +files: 0.720 +network: 0.714 +boot: 0.690 +KVM: 0.631 +socket: 0.626 + +Error in user-mode calculation of ELF aux vector's AT_PHDR + + +I have an (admittedly strange) statically-linked ELF binary for Linux that runs just fine on top of the Linux kernel in QEMU full-system emulation, but crashes before main in user-mode emulation. Specifically, it crashes when initializing thread-local storage in glibc's _dl_aux_init, because it reads out a strange value from the AT_PHDR entry of the ELF aux vector. + +The binary has these program headers: + + Program Headers: + Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align + EXIDX 0x065874 0x00075874 0x00075874 0x00570 0x00570 R 0x4 + PHDR 0x0a3000 0x00900000 0x00900000 0x00160 0x00160 R 0x1000 + LOAD 0x0a3000 0x00900000 0x00900000 0x00160 0x00160 R 0x1000 + LOAD 0x000000 0x00010000 0x00010000 0x65de8 0x65de8 R E 0x10000 + LOAD 0x066b7c 0x00086b7c 0x00086b7c 0x02384 0x02384 RW 0x10000 + NOTE 0x000114 0x00010114 0x00010114 0x00044 0x00044 R 0x4 + TLS 0x066b7c 0x00086b7c 0x00086b7c 0x00010 0x00030 R 0x4 + GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x8 + GNU_RELRO 0x066b7c 0x00086b7c 0x00086b7c 0x00484 0x00484 R 0x1 + LOAD 0x07e000 0x00089000 0x00089000 0x03f44 0x03f44 R E 0x1000 + LOAD 0x098000 0x00030000 0x00030000 0x01000 0x01000 RW 0x1000 + +If I build the Linux kernel with the following patch to the very end of create_elf_tables in fs/binfmt_elf.c + + /* Put the elf_info on the stack in the right place. */ + elf_addr_t *my_auxv = (elf_addr_t *) mm->saved_auxv; + int i; + for (i = 0; i < 15; i++) { + printk("0x%x = 0x%x", my_auxv[2*i], my_auxv[(2*i)+ 1]); + } + if (copy_to_user(sp, mm->saved_auxv, ei_index * sizeof(elf_addr_t))) + return -EFAULT; + return 0; + +and run it like this: + + qemu-system-arm \ + -M versatilepb \ + -nographic \ + -dtb ./dts/versatile-pb.dtb \ + -kernel zImage \ + -M versatilepb \ + -m 128M \ + -append "earlyprintk=vga,keep" \ + -initrd initramfs + +after I've built the kernel initramfs like this (where "init" is the binary in question): + + make ARCH=arm versatile_defconfig + make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- all -j10 + cp "$1" arch/arm/boot/init + cd arch/arm/boot + echo init | cpio -o --format=newc > initramfs + +then I get the following output. This is the kernel's view of the aux vector for this binary: + + 0x10 = 0x1d7 + 0x6 = 0x1000 + 0x11 = 0x64 + 0x3 = 0x900000 + 0x4 = 0x20 + 0x5 = 0xb + 0x7 = 0x0 + 0x8 = 0x0 + 0x9 = 0x101b8 + 0xb = 0x0 + 0xc = 0x0 + 0xd = 0x0 + 0xe = 0x0 + 0x17 = 0x0 + 0x19 = 0xbec62fb5 + +However, if I run "qemu-arm -g 12345 binary" and use GDB to peek at the aux vector at the beginning of __libc_start_init (for example, using this Python GDB API script: https://gist.github.com/langston-barrett/5573d64ae0c9953e2fa0fe26847a5e1e), then I see the following values: + + AT_PHDR = 0xae000 + AT_PHENT = 0x20 + AT_PHNUM = 0xb + AT_PAGESZ = 0x1000 + AT_BASE = 0x0 + AT_FLAGS = 0x0 + AT_ENTRY = 0x10230 + AT_UID = 0x3e9 + AT_EUID = 0x3e9 + AT_GID = 0x3e9 + AT_EGID = 0x3e9 + AT_HWCAP = 0x1fb8d7 + AT_CLKTCK = 0x64 + AT_RANDOM = -0x103c0 + AT_HWCAP2 = 0x1f + AT_NULL = 0x0 + +The crucial difference is in AT_PHDR (0x3), which is indeed the virtual address of the PHDR segment when the kernel calculates it, but is not when QEMU calculates it. + +qemu-arm --version +qemu-arm version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.26) + +I just confirmed that this is still a problem on git tag v5.0.0, where I applied the following: + + diff --git a/linux-user/elfload.c b/linux-user/elfload.c + index 619c054cc4..093656d059 100644 + --- a/linux-user/elfload.c + +++ b/linux-user/elfload.c + @@ -2016,6 +2016,7 @@ static abi_ulong create_elf_tables(abi_ulong p, int argc, int envc, + /* There must be exactly DLINFO_ITEMS entries here, or the assert + * on info->auxv_len will trigger. + */ + + printf("PHDR: %x\n", (abi_ulong)(info->load_addr + exec->e_phoff)); + NEW_AUX_ENT(AT_PHDR, (abi_ulong)(info->load_addr + exec->e_phoff)); + NEW_AUX_ENT(AT_PHENT, (abi_ulong)(sizeof (struct elf_phdr))); + NEW_AUX_ENT(AT_PHNUM, (abi_ulong)(exec->e_phnum)); + +and saw: + + PHDR: ae000 + +Taking a peek at how Linux and QEMU calculate AT_PHDR for static binaries reveals the following. Both involve the program headers' offset (e_phoff) added to a value I'll call load_addr (as in the kernel). + +In the kernel, load_addr is + + elf_ppnt->p_vaddr - elf_ppnt->p_offset + +where elf_ppnt is the program header entry of the first segment with type LOAD: https://github.com/torvalds/linux/blob/242b23319809e05170b3cc0d44d3b4bd202bb073/fs/binfmt_elf.c#L1120 + +In QEMU, load_addr is set to an earlier value loaddr, which is set to + + min_i(phdr[i].p_vaddr - phdr[i].p_offset) + +where min_i is the minimum over indices "i" of LOAD segments. https://github.com/qemu/qemu/blob/9e7f1469b9994d910fc1b185c657778bde51639c/linux-user/elfload.c#L2407. If you perform this calculation by hand for the program headers posted at the beginning of this thread, you'll get ae000, as expected. + +The problem here is that QEMU takes a minimum where Linux just takes the first value. Presumably, changing QEMU's behavior to match that of the kernel wouldn't break anything that wouldn't be broken if it really ran on Linux. Unfortunately, Linux's ELF loader is much more picky than the ELF standard, but that's a whole other story... + +@langston0 Thanks for detailed explanation, got the same problem for qemu-s390. + + +The way to reproduce (linux kernel >= 4.8, for example: Ubuntu 18.04): +# Register qemu binfmt_misc handlers +$ docker run --rm --privileged multiarch/qemu-user-static --reset -p yes + +$ cat Dockerfile.s390x +FROM s390x/ubuntu +RUN apt-get update && \ + apt-get install -y \ + gcc make libpcre3-dev libreadline-dev + +RUN cd /home && git clone https://github.com/nginx/njs + +RUN cd /home/njs && ./configure --cc-opt='-O0 -static -lm -lrt -pthread -Wl,--whole-archive -lpthread -ltinfo -Wl,--no-whole-archive' && make njs + +$ docker build -t njs/390x -f Dockerfile.s390x . + +# check the binary (WORKS!) +# inside docker s390 binaries are executed using qemu-s390-static from the host +$ docker run -t njs/390x /home/njs/build/njs -c 'console.log("hello")' +hello + +# copy binary to host +$ docker run -v `pwd`:/m -ti njs/390x cp /home/njs/build/njs /m/njs-s390 + +# deregister binfmt handler +$ sudo bash -c "echo -1 > /proc/sys/fs/binfmt_misc/qemu-s390x" + +# run qemu gdb +$ qemu-s390x -g 12345 ./njs-s390 + +# in a separate terminal +$ gdb-multiarch ./njs-s390 -ex 'target remote localhost:12345' +0x0000000001000520 in _start () +(gdb) si +0x0000000001000524 in _start () +(gdb) si +0x000000000100052a in _start () +(gdb) c +Continuing. + +Program received signal SIGILL, Illegal instruction. +0x00000000011a418c in _dl_aux_init () +(gdb) bt +#0 0x00000000011a418c in _dl_aux_init () +#1 0x00000000011663f0 in __libc_start_main () +#2 0x0000000001000564 in _start () + +qemu-s390x --version +qemu-s390x version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.28) + + + + +BTW, before "sudo bash -c "echo -1 > /proc/sys/fs/binfmt_misc/qemu-s390x" + +njs-s390 also works on the host: + +$ ./njs-s390 -c 'console.log("hello")' +hello + +$ file njs-s390 +njs-s390: ELF 64-bit MSB executable, IBM S/390, version 1 (GNU/Linux), statically linked, BuildID[sha1]=e37618578fb0a8c60f426826167a800e4f314ef3, for GNU/Linux 3.2.0, with debug_info, not stripped + +> runs just fine on top of the Linux kernel in QEMU full-system emulation, but crashes before main in user-mode emulation + +So it seems system vs user-mode is not the issue here, probably it is related to gdb mode in user-mode qemu. + +@Dimitry To confirm that this is really the same issue (and not an unrelated crash in the same function), could you post: + + 1. the ELF headers ("readelf -h"), + 2. the program headers ("readelf -l"), and + 3. the output (the AUX VECTOR section) from this GDB script (suitably modified for your program), when connecting to QEMU's GDB server? https://gist.github.com/langston-barrett/5573d64ae0c9953e2fa0fe26847a5e1e + +@Langston will do tomorrow. s390x ABI requires heavy changes to the python script. + +When I switch to armv7 the issue goes away + +$ cat Dockerfile.armv7 +FROM arm32v7/ubuntu +RUN apt-get update && \ + apt-get install -y \ + gcc make libpcre3-dev libreadline-dev git + +RUN cd /home && git clone https://github.com/nginx/njs + +RUN cd /home/njs && ./configure --cc-opt='-O0 -static -lm -lrt -pthread -Wl,--whole-archive -lpthread -ltinfo -Wl,--no-whole-archive' && make njs + +$ docker run --rm --privileged multiarch/qemu-user-static --reset -p yes +$ docker build -t njs/armv7 -f Dockerfile.armv7 . +$ docker run -v `pwd`:/m -ti njs/armv7 cp /home/njs/build/njs /m/njs-armv7 + +$ readelf -l ./njs-armv7 + +Elf file type is EXEC (Executable file) +Entry point 0x12fb9 +There are 7 program headers, starting at offset 52 + +Program Headers: + Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align + EXIDX 0x1be338 0x001ce338 0x001ce338 0x009b8 0x009b8 R 0x4 + LOAD 0x000000 0x00010000 0x00010000 0x1becf4 0x1becf4 R E 0x10000 + LOAD 0x1bedfc 0x001dedfc 0x001dedfc 0x17674 0x1c2cc RW 0x10000 + NOTE 0x000114 0x00010114 0x00010114 0x00044 0x00044 R 0x4 + TLS 0x1bedfc 0x001dedfc 0x001dedfc 0x00038 0x00060 R 0x4 + GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x10 + GNU_RELRO 0x1bedfc 0x001dedfc 0x001dedfc 0x0e204 0x0e204 R 0x1 + + Section to Segment mapping: + Segment Sections... + 00 .ARM.exidx + 01 .note.ABI-tag .note.gnu.build-id .rel.dyn .init .iplt .text __libc_freeres_fn __libc_thread_freeres_fn .fini .rodata .stapsdt.base __libc_subfreeres __libc_IO_vtables __libc_atexit __libc_thread_subfreeres .ARM.extab .ARM.exidx .eh_frame + 02 .tdata .init_array .fini_array .data.rel.ro .got .data .bss __libc_freeres_ptrs + 03 .note.ABI-tag .note.gnu.build-id + 04 .tdata .tbss + 05 + 06 .tdata .init_array .fini_array .data.rel.ro + +$ readelf -h ./njs-armv7 +ELF Header: + Magic: 7f 45 4c 46 01 01 01 03 00 00 00 00 00 00 00 00 + Class: ELF32 + Data: 2's complement, little endian + Version: 1 (current) + OS/ABI: UNIX - GNU + ABI Version: 0 + Type: EXEC (Executable file) + Machine: ARM + Version: 0x1 + Entry point address: 0x12fb9 + Start of program headers: 52 (bytes into file) + Start of section headers: 5696248 (bytes into file) + Flags: 0x5000400, Version5 EABI, hard-float ABI + Size of this header: 52 (bytes) + Size of program headers: 32 (bytes) + Number of program headers: 7 + Size of section headers: 40 (bytes) + Number of section headers: 42 + Section header string table index: 41 + +$ qemu-arm -g 12345 ./njs-armv7 -c 'console.log("HH")' + +$ gdb-multiarch ./njs-armv7 -ex 'source showstack.py' +ARGUMENTS +--------- +argc = 3 +arg 0 = ./njs-armv7 +arg 1 = -c +arg 2 = console.log("HH") + +... + +AUX VECTOR +---------- +AT_PHDR = 10034 +AT_PHENT = 20 +AT_PHNUM = 7 +AT_PAGESZ = 1000 +AT_BASE = 0 +AT_FLAGS = 0 +AT_ENTRY = 12fb9 +AT_UID = 3e9 +AT_EUID = 3e9 +AT_GID = 3e9 +AT_EGID = 3e9 +AT_HWCAP = 1fb8d7 +AT_CLKTCK = 64 +AT_RANDOM = -104a0 +AT_HWCAP2 = 1f +AT_NULL = 0 + +$ qemu-arm --version +qemu-arm version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.28) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +Built the latest QEMU, the issue goes away + + +$ bin/debug/native/s390x-linux-user/qemu-s390x --version +qemu-s390x version 5.0.50 (v5.0.0-2358-g6c87d9f311-dirty) +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + +$ bin/debug/native/s390x-linux-user/qemu-s390x ../njs/njs-s390 -c 'console.log("HI")' +HI + +So my issue seems unrelated, sorry for bothering. + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system (but you won't be the reporter of the bug +in the new system and thus won't get notified on changes anymore). + +Thank you and sorry for the inconvenience. + + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/275 + + diff --git a/results/classifier/108/other/1885350 b/results/classifier/108/other/1885350 new file mode 100644 index 00000000..722180b7 --- /dev/null +++ b/results/classifier/108/other/1885350 @@ -0,0 +1,62 @@ +other: 0.791 +graphic: 0.693 +semantic: 0.615 +device: 0.515 +PID: 0.442 +performance: 0.412 +debug: 0.360 +socket: 0.349 +boot: 0.321 +vnc: 0.294 +network: 0.261 +permissions: 0.248 +files: 0.128 +KVM: 0.094 + +RISCV dynamic rounding mode is not behaving correctly + +Hello, + +I’ve gone through the RISC-V code in latest QEMU release (qemu-5.0.0-rc2) and when checking the Floating point encodings I found the rounding mode is only updated if the opcode field “rm” is changed “ctx->frm == rm”. But according to RISC-V Volume I: Unprivileged ISA, there’s a dynamic mode when rm=7 where the rounding mode is set with frm value. + +So for the same rm value (=7) and when changing frm value seeking different rounding modes, and according to the below code, the rounding mode won’t be updated. Please correct me if I got this implementation wrong. + +static void gen_set_rm(DisasContext *ctx, int rm) +{ + TCGv_i32 t0; + if (ctx->frm == rm) { + return; + } + ctx->frm = rm; + t0 = tcg_const_i32(rm); + gen_helper_set_rounding_mode(cpu_env, t0); + tcg_temp_free_i32(t0); +} + + +My testcase: +I set statically the rm field in the instruction to 7 and before this execution I changed the value of frm field in fcsr register. For the 1st time it worked (according to the code above, the rm is updated so the round mode will also be updated). But when changing fcsr register an re-execute the instruction, there's no difference and the rounding mode is the same like the previous frm value. + +After checking RISCY RTL code, i found the implementation is straight forward as stated in specs as follows: + if (FPU == 1) begin + if (fp_rnd_mode == 3'b111) + apu_flags = frm_i; + else + apu_flags = fp_rnd_mode; + end else + +where fp_rnd_mode is the round mode field in the instruction opcode. + +This does look like incorrect behaviour. I have sent a patch to the mailing list. You can see the patch here: https://<email address hidden>/ea4f280e6f77e734c8e555e3c98d10085ce9f5b6<email address hidden>/ + +Thank you Alistair Francis. + +As commented on the patch submission, this should already be handled: https://<email address hidden>/msg718331.html + +Can you attach the test case that is failing? + +The QEMU project is currently moving its bug tracking to another system. +Is there still anything left to do here? If so, please provide the test case and switch the state back to "New" or "Confirmed", or open a new ticket in the new bug tracker here: https://gitlab.com/qemu-project/qemu/-/issues + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1885553 b/results/classifier/108/other/1885553 new file mode 100644 index 00000000..1f30f2e5 --- /dev/null +++ b/results/classifier/108/other/1885553 @@ -0,0 +1,59 @@ +graphic: 0.813 +other: 0.813 +device: 0.780 +files: 0.742 +debug: 0.680 +PID: 0.677 +performance: 0.643 +network: 0.628 +semantic: 0.616 +vnc: 0.609 +socket: 0.574 +permissions: 0.554 +boot: 0.540 +KVM: 0.476 + +make-check test failed with "Segmentation fault" + +While running the make-check testing on arm architecture the test failed with error: +"kill_qemu() detected QEMU death from signal 11 (Segmentation fault) (core dumped)". Apart from that make-install test always passes. +The problem doesn't reproduce in 100% +qemu - from the master branch +RHEL-8 kernel 4.18.0-221.el8.aarch64 +Logfile with an error you can to find in attachment + +Thanks + + + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system (but you won't be the reporter of the bug +in the new system and thus won't get notified on changes anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1885719 b/results/classifier/108/other/1885719 new file mode 100644 index 00000000..c844126c --- /dev/null +++ b/results/classifier/108/other/1885719 @@ -0,0 +1,43 @@ +socket: 0.913 +network: 0.868 +graphic: 0.845 +semantic: 0.790 +device: 0.760 +other: 0.668 +permissions: 0.657 +vnc: 0.637 +files: 0.624 +PID: 0.607 +debug: 0.558 +performance: 0.457 +boot: 0.343 +KVM: 0.280 + +qemu/target/nios2/helper.c:261:20: style:inconclusive: Found duplicate branches for 'if' and 'else' + +Source code is + + } else if (address >= 0x80000000) { + /* Kernel virtual page */ + return cpu_nios2_handle_virtual_page(cs, address, rw, mmu_idx); + } else { + /* User virtual page */ + return cpu_nios2_handle_virtual_page(cs, address, rw, mmu_idx); + } + +Which version of QEMU did you use here? Apparently it was an older version, since that code has been removed more than a year ago already: + + https://git.qemu.org/?p=qemu.git;a=commitdiff;h=0137c93ff8cbcebf + +Please make sure to use the latest release of QEMU when reporting bugs. Thanks! + +>Which version of QEMU did you use here? + +git trunk. I have no idea why Richard's patch isn't in my current version +and I am disinclined to find out why. + +Any further work by me on qemu looks somewhat doubtful. Have fun ! + + + + diff --git a/results/classifier/108/other/1885720 b/results/classifier/108/other/1885720 new file mode 100644 index 00000000..5d1ccd30 --- /dev/null +++ b/results/classifier/108/other/1885720 @@ -0,0 +1,37 @@ +socket: 0.753 +device: 0.727 +files: 0.719 +network: 0.680 +semantic: 0.658 +graphic: 0.635 +vnc: 0.628 +debug: 0.550 +PID: 0.543 +permissions: 0.470 +other: 0.307 +performance: 0.286 +KVM: 0.279 +boot: 0.269 + +qemu/migration/postcopy-ram.c:387: bad return expression ? + +qemu/migration/postcopy-ram.c:387:9: style: Non-boolean value returned from function returning bool [returnNonBoolInBooleanFunction] + +Source code is + + return -1; + +but + +bool postcopy_ram_supported_by_host( + +That looks like a bug, indeed! + +Yes, I think a goto out; there makes sense; nearly 5 years old that error :-) + +Posted: +migration: postcopy take proper error return + +Fix has been merged: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=617a32f5295ee4e + diff --git a/results/classifier/108/other/1885889 b/results/classifier/108/other/1885889 new file mode 100644 index 00000000..55b367aa --- /dev/null +++ b/results/classifier/108/other/1885889 @@ -0,0 +1,63 @@ +PID: 0.612 +permissions: 0.593 +device: 0.580 +semantic: 0.547 +debug: 0.547 +files: 0.545 +graphic: 0.543 +other: 0.538 +socket: 0.506 +performance: 0.500 +vnc: 0.467 +network: 0.452 +boot: 0.441 +KVM: 0.392 + +ERROR: core-image-minimal-1.0-r0 do_rootfs: The postinstall intercept hook 'update_font_cache' failed, + +Hello, + +I am trying to build bitbake core-image-minimal getting following error. + +santhosh@santhosh-VirtualBox:~/Denverton/Source/BSP/poky/build$ bitbake core-image-minimal +Loading cache: 100% |###############################################################################################| Time: 0:00:00 +Loaded 1370 entries from dependency cache. +NOTE: Resolving any missing task queue dependencies + +Build Configuration: +BB_VERSION = "1.44.0" +BUILD_SYS = "x86_64-linux" +NATIVELSBSTRING = "universal" +TARGET_SYS = "x86_64-poky-linux" +MACHINE = "ddsmdnv" +DISTRO = "poky" +DISTRO_VERSION = "3.0.2" +TUNE_FEATURES = "m64 corei7" +TARGET_FPU = "" +meta +meta-poky +meta-ddsmdnv = "DDSM_Denverton_PHASE_1_FDJ_Release:471fec241d3a1a4b70ad58135fe229eab2b6a196" + +Initialising tasks: 100% |##########################################################################################| Time: 0:00:05 +Sstate summary: Wanted 413 Found 0 Missed 413 Current 937 (0% match, 69% complete) +NOTE: Executing Tasks +NOTE: Setscene tasks completed +ERROR: core-image-minimal-1.0-r0 do_rootfs: The postinstall intercept hook 'update_font_cache' failed, details in /home/santhosh/Denverton/Source/BSP/poky/build/tmp/work/ddsmdnv-poky-linux/core-image-minimal/1.0-r0/temp/log.do_rootfs +ERROR: Logfile of failure stored in: /home/santhosh/Denverton/Source/BSP/poky/build/tmp/work/ddsmdnv-poky-linux/core-image-minimal/1.0-r0/temp/log.do_rootfs.9682 +ERROR: Task (/home/santhosh/Denverton/Source/BSP/poky/meta-ddsmdnv/recipes-core/images/core-image-minimal.bb:do_rootfs) failed with exit code '1' + + +Could you please help me on how to fix this issue. + +Thank you. + +Santhosh + +I am running this under below ubuntu environment. +santhosh@santhosh-VirtualBox:~/Denverton/Source/BSP/poky$ uname -a +Linux santhosh-VirtualBox 4.15.0-108-generic #109-Ubuntu SMP Fri Jun 19 11:33:10 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux +santhosh@santhosh-VirtualBox:~/Denverton/Source/BSP/poky$ + + +Why do you file this under the upstream "QEMU" component? This does not seem to be related to QEMU at all? + diff --git a/results/classifier/108/other/1886076 b/results/classifier/108/other/1886076 new file mode 100644 index 00000000..1a8b6eaf --- /dev/null +++ b/results/classifier/108/other/1886076 @@ -0,0 +1,67 @@ +performance: 0.877 +device: 0.849 +vnc: 0.847 +PID: 0.822 +graphic: 0.810 +other: 0.797 +semantic: 0.764 +files: 0.745 +socket: 0.714 +permissions: 0.713 +network: 0.650 +boot: 0.641 +debug: 0.517 +KVM: 0.517 + +risc-v pmp implementation error + +QEMU Commit fc1bff958998910ec8d25db86cd2f53ff125f7ab + + +RISC-V PMP implementation is not correct on QEMU. + +When an access is granted there is no more PMP check on the 4KB memory range of the accessed location. +A cache flush is needed in order to force a PMP check on next access to this 4KB memory range. +A correct implementation would be to grant access to the maximum allowed area around the accessed location within the 4KB memory range. + +For instance, if PMP is configured to block all accesses from 0x80003000 to 0x800037FF and from 0x80003C00 to 0x80003FFF: +1st case: + 1) A read access is done @0x80003900 --> access OK as expected + 2) Then a read access is done @0x80003400 --> access OK while it must be blocked! +2nd case: + 1) A read access is done @0x80003900 --> access OK as expected + 2) Cache is flushed (__asm__ __volatile__ ("sfence.vma" : : : "memory");) + 3) A read access is done @0x80003400 --> access blocked as expected + +Analysis: + After the 1st read @0x80003900 QEMU add the memory range 0x80003000 to 0x80003FFF into a TLB entry. + Then no more PMP check is done from 0x80003000 to 0x80003FFF until the TLB is flushed. +What should be done: + Only the range 0x80003800 to 0x80003BFF should be added to the TLB entry. + +The 4KB range is the default size of a TLB page on QEMU for RISCV. +The minimum size that can be set is 64Bytes. However the PMP granularity can be as low as 4Bytes. + +I tested a quick fix and PMP is working as expected. +The quick fix consist in replacing this line: +tlb_set_page(cs, address & TARGET_PAGE_MASK, pa & TARGET_PAGE_MASK, prot, mmu_idx, TARGET_PAGE_SIZE); +By this one in target/riscv/cpu_helper.c: +tlb_set_page(cs, address & ~0x3, pa & ~0x3, prot, mmu_idx, size); + +This quick fix has to be optimized in order to consume less HW resources, as explained at the beginning. + + + +Nicolas, + +to be reviewed your patch must be sent to <email address hidden> + +This should be fixed once the current RISC-V branch is merged into master. + +You can see the patch that fixes this here: https://<email address hidden><email address hidden>/ + +I'm marking this as fix committed, although the fix isn't yet in master it's in the RISC-V tree and will be in master soon. + +Fix has been included here: +https://gitlab.com/qemu-project/qemu/-/commit/af3fc195e3c8e98b + diff --git a/results/classifier/108/other/1886097 b/results/classifier/108/other/1886097 new file mode 100644 index 00000000..86492d52 --- /dev/null +++ b/results/classifier/108/other/1886097 @@ -0,0 +1,86 @@ +other: 0.780 +semantic: 0.774 +graphic: 0.769 +debug: 0.742 +permissions: 0.703 +network: 0.673 +vnc: 0.670 +device: 0.661 +performance: 0.653 +PID: 0.600 +KVM: 0.571 +socket: 0.547 +boot: 0.514 +files: 0.469 + +Error in user-mode calculation of ELF program's brk + +There's a discrepancy between the way QEMU user-mode and Linux calculate the initial program break for statically-linked binaries. I have a binary with the following segments: + + Program Headers: + Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align + EXIDX 0x065a14 0x00075a14 0x00075a14 0x00588 0x00588 R 0x4 + PHDR 0x0a3000 0x000a3000 0x000a3000 0x00160 0x00160 R 0x1000 + LOAD 0x0a3000 0x000a3000 0x000a3000 0x00160 0x00160 R 0x1000 + LOAD 0x000000 0x00010000 0x00010000 0x65fa0 0x65fa0 R E 0x10000 + LOAD 0x066b7c 0x00086b7c 0x00086b7c 0x02384 0x02384 RW 0x10000 + NOTE 0x000114 0x00010114 0x00010114 0x00044 0x00044 R 0x4 + TLS 0x066b7c 0x00086b7c 0x00086b7c 0x00010 0x00030 R 0x4 + GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x8 + GNU_RELRO 0x066b7c 0x00086b7c 0x00086b7c 0x00484 0x00484 R 0x1 + LOAD 0x07e000 0x00089000 0x00089000 0x03ff4 0x03ff4 R E 0x1000 + LOAD 0x098000 0x00030000 0x00030000 0x01000 0x01000 RW 0x1000 + +The call to set_brk in Linux's binfmt_elf.c receives these arguments: + + set_brk(0xa3160, 0xa3160, 1) + +Whereas in QEMU, info->brk gets set to 0x88f00. When the binary is run in QEMU, it crashes on the second call to brk, whereas it runs fine on real ARM hardware. I think the trouble is that the program break is set to an address lower than the virtual address of a LOAD segment (the program headers, in this case). + +I believe that this discrepancy arises because in QEMU, info->brk is only incremented when the LOAD segment in question has PROT_WRITE. For this binary, the LOAD segment with write permissions and the highest virtual address is + + LOAD 0x066b7c 0x00086b7c 0x00086b7c 0x02384 0x02384 RW 0x10000 + +which overlaps with the TLS segment: + + TLS 0x066b7c 0x00086b7c 0x00086b7c 0x00010 0x00030 R 0x4 + +However, the Linux kernel puts the program break after the loadable segment with the highest virtual address, regardless of flags. So I think the fix is for QEMU to do the same. + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system (but you won't be the reporter of the bug +in the new system and thus won't get notified on changes anymore). + +Thank you and sorry for the inconvenience. + + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/276 + + diff --git a/results/classifier/108/other/1886155 b/results/classifier/108/other/1886155 new file mode 100644 index 00000000..25b22b2c --- /dev/null +++ b/results/classifier/108/other/1886155 @@ -0,0 +1,118 @@ +other: 0.702 +graphic: 0.651 +KVM: 0.647 +permissions: 0.603 +performance: 0.589 +vnc: 0.582 +semantic: 0.562 +debug: 0.544 +device: 0.513 +socket: 0.467 +boot: 0.457 +PID: 0.447 +files: 0.442 +network: 0.437 + +error: argument 2 of ‘__atomic_load’ discards ‘const’ qualifier + +GCC 11 reports the following errors: + +[ 125s] In file included from /home/abuild/rpmbuild/BUILD/qemu-5.0.0/include/qemu/seqlock.h:17, +[ 125s] from /home/abuild/rpmbuild/BUILD/qemu-5.0.0/include/qemu/qht.h:10, +[ 125s] from /home/abuild/rpmbuild/BUILD/qemu-5.0.0/util/qht.c:69: +[ 125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/util/qht.c: In function 'qht_do_lookup': +[ 125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/include/qemu/atomic.h:153:5: error: argument 2 of '__atomic_load' discards 'const' qualifier [-Werror=incompatible-pointer-types] +[ 125s] 153 | __atomic_load(ptr, valptr, __ATOMIC_RELAXED); \ +[ 125s] | ^~~~~~~~~~~~~ +[ 125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/include/qemu/atomic.h:161:5: note: in expansion of macro 'atomic_rcu_read__nocheck' +[ 125s] 161 | atomic_rcu_read__nocheck(ptr, &_val); \ +[ 125s] | ^~~~~~~~~~~~~~~~~~~~~~~~ +[ 125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/util/qht.c:499:27: note: in expansion of macro 'atomic_rcu_read' +[ 125s] 499 | void *p = atomic_rcu_read(&b->pointers[i]); +[ 125s] | ^~~~~~~~~~~~~~~ +[ 125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/include/qemu/atomic.h:153:5: error: argument 2 of '__atomic_load' discards 'const' qualifier [-Werror=incompatible-pointer-types] +[ 125s] 153 | __atomic_load(ptr, valptr, __ATOMIC_RELAXED); \ +[ 125s] | ^~~~~~~~~~~~~ +[ 125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/include/qemu/atomic.h:161:5: note: in expansion of macro 'atomic_rcu_read__nocheck' +[ 125s] 161 | atomic_rcu_read__nocheck(ptr, &_val); \ +[ 125s] | ^~~~~~~~~~~~~~~~~~~~~~~~ +[ 125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/util/qht.c:506:13: note: in expansion of macro 'atomic_rcu_read' +[ 125s] 506 | b = atomic_rcu_read(&b->next); +[ 125s] | ^~~~~~~~~~~~~~~ +[ 125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/util/qht.c: In function 'qht_lookup_custom': +[ 125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/include/qemu/atomic.h:153:5: error: argument 2 of '__atomic_load' discards 'const' qualifier [-Werror=incompatible-pointer-types] +[ 125s] 153 | __atomic_load(ptr, valptr, __ATOMIC_RELAXED); \ +[ 125s] | ^~~~~~~~~~~~~ +[ 125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/include/qemu/atomic.h:161:5: note: in expansion of macro 'atomic_rcu_read__nocheck' +[ 125s] 161 | atomic_rcu_read__nocheck(ptr, &_val); \ +[ 125s] | ^~~~~~~~~~~~~~~~~~~~~~~~ +[ 125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/util/qht.c:534:11: note: in expansion of macro 'atomic_rcu_read' +[ 125s] 534 | map = atomic_rcu_read(&ht->map); +[ 125s] | ^~~~~~~~~~~~~~~ +[ 125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/util/qht.c: In function 'qht_statistics_init': +[ 125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/include/qemu/atomic.h:153:5: error: argument 2 of '__atomic_load' discards 'const' qualifier [-Werror=incompatible-pointer-types] +[ 125s] 153 | __atomic_load(ptr, valptr, __ATOMIC_RELAXED); \ +[ 125s] | ^~~~~~~~~~~~~ +[ 125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/include/qemu/atomic.h:161:5: note: in expansion of macro 'atomic_rcu_read__nocheck' +[ 125s] 161 | atomic_rcu_read__nocheck(ptr, &_val); \ +[ 125s] | ^~~~~~~~~~~~~~~~~~~~~~~~ +[ 125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/util/qht.c:907:11: note: in expansion of macro 'atomic_rcu_read' +[ 125s] 907 | map = atomic_rcu_read(&ht->map); +[ 125s] | ^~~~~~~~~~~~~~~ +[ 125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/include/qemu/atomic.h:153:5: error: argument 2 of '__atomic_load' discards 'const' qualifier [-Werror=incompatible-pointer-types] +[ 125s] 153 | __atomic_load(ptr, valptr, __ATOMIC_RELAXED); \ +[ 125s] | ^~~~~~~~~~~~~ +[ 125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/include/qemu/atomic.h:161:5: note: in expansion of macro 'atomic_rcu_read__nocheck' +[ 125s] 161 | atomic_rcu_read__nocheck(ptr, &_val); \ +[ 125s] | ^~~~~~~~~~~~~~~~~~~~~~~~ +[ 125s] /home/abuild/rpmbuild/BUILD/qemu-5.0.0/util/qht.c:941:21: note: in expansion of macro 'atomic_rcu_read' +[ 125s] 941 | b = atomic_rcu_read(&b->next); +[ 125s] | ^~~~~~~~~~~~~~~ + +It looks like `typeof_strip_qual` doesn't work for pointer types. + +Which means that given an argument of type T * const this defines a local variable that is also T * const, and then tries to store the result of the atomic load into that const variable: + + +``` +#define atomic_rcu_read(ptr) \ + ({ \ + typeof_strip_qual(*ptr) _val; \ + atomic_rcu_read__nocheck(ptr, &_val); \ + _val; \ + }) +``` + +GCC 11 correctly diagnoses that write to a const variable. + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system (but you won't be the reporter of the bug +in the new system and thus won't get notified on changes anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1886208 b/results/classifier/108/other/1886208 new file mode 100644 index 00000000..72215550 --- /dev/null +++ b/results/classifier/108/other/1886208 @@ -0,0 +1,35 @@ +graphic: 0.869 +device: 0.816 +semantic: 0.710 +network: 0.680 +PID: 0.601 +boot: 0.584 +files: 0.575 +vnc: 0.539 +performance: 0.522 +permissions: 0.512 +socket: 0.500 +other: 0.326 +debug: 0.215 +KVM: 0.018 + +[Feature request] Haiku VM image + +We already have handy VMs to build QEMU within: + +$ git grep -l basevm.BaseVM +tests/vm/centos +tests/vm/fedora +tests/vm/freebsd +tests/vm/netbsd +tests/vm/openbsd +tests/vm/ubuntu.i386 + +With David Carlier recent work, we can build QEMU on Haiku OS: +https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg01241.html + +To avoid bitrots it would be useful to have a Haiku VM. + +Haiku image has been included now: +https://gitlab.com/qemu-project/qemu/-/commit/9fc33bf4e1d6942 + diff --git a/results/classifier/108/other/1886210 b/results/classifier/108/other/1886210 new file mode 100644 index 00000000..9a01cd26 --- /dev/null +++ b/results/classifier/108/other/1886210 @@ -0,0 +1,40 @@ +device: 0.734 +network: 0.577 +semantic: 0.532 +graphic: 0.516 +socket: 0.511 +PID: 0.446 +files: 0.402 +permissions: 0.393 +vnc: 0.378 +other: 0.323 +boot: 0.281 +performance: 0.263 +debug: 0.216 +KVM: 0.090 + +[Feature request] Illumnos VM image + +We already have handy VMs to build QEMU within: + +$ git grep -l basevm.BaseVM +tests/vm/centos +tests/vm/fedora +tests/vm/freebsd +tests/vm/netbsd +tests/vm/openbsd +tests/vm/ubuntu.i386 + +It would be useful to have a illumos VM to do build testing and avoid regressions. + +Suggested by Thomas Huth: +https://<email address hidden>/msg719202.html + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'invalid' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/258 + + diff --git a/results/classifier/108/other/1886225 b/results/classifier/108/other/1886225 new file mode 100644 index 00000000..7fe3da1c --- /dev/null +++ b/results/classifier/108/other/1886225 @@ -0,0 +1,36 @@ +other: 0.872 +graphic: 0.864 +device: 0.811 +semantic: 0.766 +network: 0.750 +performance: 0.711 +files: 0.687 +vnc: 0.670 +PID: 0.656 +permissions: 0.590 +socket: 0.588 +boot: 0.567 +debug: 0.520 +KVM: 0.323 + +[Feature request] Oracle Solaris 11.4 VM image + +We already have handy VMs to build QEMU within: + +$ git grep -l basevm.BaseVM +tests/vm/centos +tests/vm/fedora +tests/vm/freebsd +tests/vm/netbsd +tests/vm/openbsd +tests/vm/ubuntu.i386 + +Some people have interest in building QEMU on Solaris: +https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg01429.html + +To help them it would be useful to have a Solaris VM. + +Solaris is not open anymore, so I don't think that you can get a distributable VM so easily. + +I'm closing this since it's very unlikely that we get a Solaris VM image, since they are not available for free, as far as I know. Maybe somebody could contribute an illumos-based image one day, but that's nothing that we have to track in the bug tracker, I think. + diff --git a/results/classifier/108/other/1886285 b/results/classifier/108/other/1886285 new file mode 100644 index 00000000..a804c740 --- /dev/null +++ b/results/classifier/108/other/1886285 @@ -0,0 +1,56 @@ +graphic: 0.805 +other: 0.729 +semantic: 0.683 +device: 0.663 +files: 0.651 +network: 0.641 +permissions: 0.601 +debug: 0.589 +PID: 0.583 +performance: 0.583 +socket: 0.491 +vnc: 0.479 +KVM: 0.440 +boot: 0.412 + +Provide SMB option to support Windows 2000 + +As of SAMBA 4.11 (https://www.samba.org/samba/history/samba-4.11.0.html), SMB1 is disabled by default (and may be removed in the future). This breaks SMB shares with Windows 2000 guests. + +Adding the following line to smb.conf fixes this: + +min protocol = NT1 + +I would propose that an option be added to add this line to smb.conf to support these legacy operating systems. + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system (but you won't be the reporter of the bug +in the new system and thus won't get notified on changes anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1886318 b/results/classifier/108/other/1886318 new file mode 100644 index 00000000..c8e6519e --- /dev/null +++ b/results/classifier/108/other/1886318 @@ -0,0 +1,310 @@ +permissions: 0.626 +semantic: 0.560 +other: 0.556 +graphic: 0.541 +debug: 0.511 +vnc: 0.463 +device: 0.455 +PID: 0.449 +performance: 0.436 +KVM: 0.411 +socket: 0.391 +network: 0.365 +boot: 0.344 +files: 0.213 + +Qemu after v5.0.0 breaks macos guests + +The Debian Sid 5.0-6 qemu-kvm package can no longer get further than the Clover bootloader whereas 5.0-6 and earlier worked fine. + +So I built qemu master from github and it has the same problem, whereas git tag v5.0.0 (or 4.2.1) does not, so something between v5.0.0 release and the last few days has caused the problem. + +Here's my qemu script, pretty standard macOS-Simple-KVM setup on a Xeon host: + +qemu-system-x86_64 \ + -enable-kvm \ + -m 4G \ + -machine q35,accel=kvm \ + -smp 4,sockets=1,cores=2,threads=2 \ + -cpu +Penryn,vendor=GenuineIntel,kvm=on,+sse3,+sse4.2,+aes,+xsave,+avx,+xsaveopt,+xsavec,+xgetbv1,+avx2,+bmi2,+smep,+bmi1,+fma,+movbe,+invtsc +\ + -device +isa-applesmc,osk="ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc" +\ + -smbios type=2 \ + -drive if=pflash,format=raw,readonly,file="/tmp/OVMF_CODE.fd" \ + -drive if=pflash,format=raw,file="/tmp/macos_catalina_VARS.fd" \ + -vga qxl \ + -device ich9-ahci,id=sata \ + -drive id=ESP,if=none,format=raw,file=/tmp/ESP.img \ + -device ide-hd,bus=sata.2,drive=ESP \ + -drive id=InstallMedia,format=raw,if=none,file=/tmp/BaseSystem.img \ + -device ide-hd,bus=sata.3,drive=InstallMedia \ + -drive id=SystemDisk,if=none,format=raw,file=/tmp/macos_catalina.img \ + -device ide-hd,bus=sata.4,drive=SystemDisk \ + -usb -device usb-kbd -device usb-mouse + +Perhaps something has changed in Penryn support recently, as that's required for macos? + +See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964247 + +Also on a related note, kernel 5.6/5.7 (on Debian) hard crashes the host when I try GPU passthrough on macos, whereas Ubuntu20/Win10 work fine - as does 5.5 kernel. + +See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961676 + +Is this not the place to report qemu bugs? + +qemu console screenshot, this is as far as it gets after clover: https://i.imgur.com/HWY96Kq.png + +same result with or without usb/pci passthrough, qxl/vnc, git master HEAD or debian 5.0-6 + +Indeed it is, but bear in mind it was QEMU 5.1 release feature freeze this week so most developers are busy rebasing and fixing up bugs from the resulting merge. + +Given that you have already built QEMU from source, what would help enormously is if you can do a "git bisect" between the v5.0.0 tag (working) and your current master (not working) and provide the output of "git bisect log" in this bug report. By identifying the individual commit that broke your test case, it is much easier for developers to understand the issue and propose a fix. + + +ATB, + +Mark. + + +Thanks Mark, what an interesting exercise that was - and sorry, didn't know 5.1 was due. + +So the git bisect revealed this: + +$ git bisect good +5d971f9e672507210e77d020d89e0e89165c8fc9 is the first bad commit +commit 5d971f9e672507210e77d020d89e0e89165c8fc9 +Author: Michael S. Tsirkin <email address hidden> +Date: Wed Jun 10 09:47:49 2020 -0400 + + memory: Revert "memory: accept mismatching sizes in memory_region_access_valid" + + Memory API documentation documents valid .min_access_size and .max_access_size + fields and explains that any access outside these boundaries is blocked. + + This is what devices seem to assume. + + However this is not what the implementation does: it simply + ignores the boundaries unless there's an "accepts" callback. + + Naturally, this breaks a bunch of devices. + + Revert to the documented behaviour. + + Devices that want to allow any access can just drop the valid field, + or add the impl field to have accesses converted to appropriate + length. + + Cc: <email address hidden> + Reviewed-by: Richard Henderson <email address hidden> + Fixes: CVE-2020-13754 + Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1842363 + Fixes: a014ed07bd5a ("memory: accept mismatching sizes in memory_region_access_valid") + Signed-off-by: Michael S. Tsirkin <email address hidden> + Message-Id: <email address hidden> + Signed-off-by: Paolo Bonzini <email address hidden> + + memory.c | 29 +++++++++-------------------- + 1 file changed, 9 insertions(+), 20 deletions(-) + + +Woohoo! Simply reverting that one commit 5d971f9e672507210e77d020d89e0e89165c8fc9 from today's master gets me running again. + +Not sure where that leaves us though....? + +that's an interesting observation. Thank you for finding this one. It'd be much faster to find one of about 10 debian patches which affects this but full qemu bisect works too, ofcourse. + +Simon, I can't reach you by email, your mailserver apparently malfunctioning, - I sent you instructions about how and what to do, but all my emails returned back - connections to your mailserver times out from a few of networks I have access to. + +This commit breaking macos guest is interesting, perhaps we should try to fix that for 5.1.. :) + +the debian patch is: + +revert-memory-accept-mismatching-sizes-in-memory_region_access_valid-CVE-2020-13754.patch + +i'm currently building a deb package without it. + +mailserver has a geoip block and doesn't use ipv6, synapticconsulting at gmail dot com should work. + + +yup, building debian 5.0-6 package minus that single patch gives me working macos catalina again. + +now just got to figure out why any kernel newer than 5.5 crashes the host when using pci passthrough - i don't fancy bisecting a whole kernel! + +Thanks for the bisection, that's really helpful - that particular patch fixes the way in which memory region access sizes are treated as valid. The obvious device to look at here is isa-apple-smc since I suspect that has less CI coverage. + +Looking at the access sizes of all 3 MemoryRegions within hw/misc/applesmc.c I think these would now reject all non-byte accesses - does the following patch help at all? + + +diff --git a/hw/misc/applesmc.c b/hw/misc/applesmc.c +index 1c4addb201..7ca89e5e86 100644 +--- a/hw/misc/applesmc.c ++++ b/hw/misc/applesmc.c +@@ -288,7 +288,7 @@ static const MemoryRegionOps applesmc_data_io_ops = { + .endianness = DEVICE_NATIVE_ENDIAN, + .impl = { + .min_access_size = 1, +- .max_access_size = 1, ++ .max_access_size = 4, + }, + }; + +@@ -298,7 +298,7 @@ static const MemoryRegionOps applesmc_cmd_io_ops = { + .endianness = DEVICE_NATIVE_ENDIAN, + .impl = { + .min_access_size = 1, +- .max_access_size = 1, ++ .max_access_size = 4, + }, + }; + +@@ -308,7 +308,7 @@ static const MemoryRegionOps applesmc_err_io_ops = { + .endianness = DEVICE_NATIVE_ENDIAN, + .impl = { + .min_access_size = 1, +- .max_access_size = 1, ++ .max_access_size = 4, + }, + }; + + +ATB, + +Mark. + +Hi Mark, no that doesn't work sorry, same error. + +No worries - I didn't spot that those memory regions were implemented as single-byte registers which means the access size won't matter anyway. + +I had a quick look at your command line again and the only other obvious thing I spotted was that a 64-bit access to the q35 "blackhole" region might also be affected by this change in logic. Does the diff below help at all? + + +diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c +index b67cb9c29f..e703979488 100644 +--- a/hw/pci-host/q35.c ++++ b/hw/pci-host/q35.c +@@ -281,8 +281,6 @@ static const MemoryRegionOps blackhole_ops = { + .read = blackhole_read, + .write = blackhole_write, + .endianness = DEVICE_NATIVE_ENDIAN, +- .valid.min_access_size = 1, +- .valid.max_access_size = 4, + .impl.min_access_size = 4, + .impl.max_access_size = 4, + .endianness = DEVICE_LITTLE_ENDIAN, + + +ATB, + +Mark. + + +No that doesn't make any difference either, nor does combining the two patches :-( + +In that case please disregard those patches. Can you try this diff below which will log any invalid accesses and see if anything appears on stderr? + + +diff --git a/memory.c b/memory.c +index 9200b20130..5d1a6d4477 100644 +--- a/memory.c ++++ b/memory.c +@@ -1354,10 +1354,12 @@ bool memory_region_access_valid(MemoryRegion *mr, + { + if (mr->ops->valid.accepts + && !mr->ops->valid.accepts(mr->opaque, addr, size, is_write, attrs)) { ++ fprintf(stderr, "invalid accepts: %s addr %"PRIx64 " size: %d\n", mr->name, addr, size); + return false; + } + + if (!mr->ops->valid.unaligned && (addr & (size - 1))) { ++ fprintf(stderr, "invalid aligned: %s addr %"PRIx64 " size: %d\n", mr->name, addr, size); + return false; + } + +@@ -1368,6 +1370,7 @@ bool memory_region_access_valid(MemoryRegion *mr, + + if (size > mr->ops->valid.max_access_size + || size < mr->ops->valid.min_access_size) { ++ fprintf(stderr, "invalid size: %s addr %"PRIx64 " size: %d\n", mr->name, addr, size); + return false; + } + return true; + + + +ATB, + +Mark. + + +i get this over and over (and only this): + +invalid size: acpi-tmr addr 0 size: 2 + +which seems to reside in hw/acpi/core.c + +on a hunch, i applied this, and now macos boots (as 2 from acpi-tmr fits in the 1-4 range): + +diff --git a/hw/acpi/core.c b/hw/acpi/core.c +index f6d9ec4f13..05ff29b9d7 100644 +--- a/hw/acpi/core.c ++++ b/hw/acpi/core.c +@@ -527,7 +527,7 @@ static void acpi_pm_tmr_write(void *opaque, hwaddr addr, uint64_t val, + static const MemoryRegionOps acpi_pm_tmr_ops = { + .read = acpi_pm_tmr_read, + .write = acpi_pm_tmr_write, +- .valid.min_access_size = 4, ++ .valid.min_access_size = 1, + .valid.max_access_size = 4, + .endianness = DEVICE_LITTLE_ENDIAN, + }; + + +all i get on stderr with my patch is: + +invalid accepts: (null) addr fe03601c size: 4 + + +Great work Simon! I'm not an ACPI expert but that certainly seems a plausible solution - I'll have to defer the final review to someone else though. + +The quickest way to get this reviewed is to follow the procedure at https://wiki.qemu.org/Contribute/SubmitAPatch which is basically send a "git format-patch" email to the qemu-devel mailing list. Adding as CC the appropriate maintainers shown by running "./scripts/get_maintainer.pl /path/to/my.patch" as indicated in Section 2.1 "CC the relevant maintainer" will help ensure it gets the attention of the right people. + + +ATB, + +Mark. + + +urgh, that was complicated, think i got it right! + +need to look for "[PATCH] Allow acpi-tmr size=2" to show up in qemu-devel + +I think we should add debugging patch by Mark to qemu too, — I suspect there will be more cases like this, since this check were turned off for a few years. Maybe not as printf's but as logging, I dunno, but the info it collects is really a must-have. + +Hi Simon, + +Just in case you're not getting emails to the git@ email address on the patch, there has been more follow up and discussion on the qemu-devel@ list: + +https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg04006.html +https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg04621.html +https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg04637.html + + +ATB, + +Mark. + + +Hi Mark, + +Yes I am getting the emails from qemu-devel thanks (seems pretty slow though - the website is faster) I replied to a couple but its over my head mostly now! + +I didn't notice Michael had done a v2 patch for 5.1, that's fine with me. + +I wonder if we can get the debian 5.0 package updated with a patch, or if we have to wait for 5.1 to be packaged with the fix already included from upstream? + +Patch has been included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=dba04c3488c4699f5 + diff --git a/results/classifier/108/other/1886343 b/results/classifier/108/other/1886343 new file mode 100644 index 00000000..0c360a6c --- /dev/null +++ b/results/classifier/108/other/1886343 @@ -0,0 +1,36 @@ +graphic: 0.799 +device: 0.746 +semantic: 0.746 +other: 0.677 +performance: 0.667 +files: 0.612 +network: 0.576 +permissions: 0.548 +vnc: 0.504 +boot: 0.485 +debug: 0.453 +socket: 0.434 +PID: 0.433 +KVM: 0.299 + +configure has non-posix bash syntax + +which gives an error when run on a system that uses dash for /bin/sh. + +The problem is at line 6464 which has + if test "$have_keyring" == "yes" +the double equal sign is non-posix bash syntax that isn't accepted by posix shells like dash. This was added 2020-05-25 according to git blame so looks like a recent problem. + +On an Ubuntu 20.04 system with top of tree sources I get +gondor:2027$ ../qemu/configure --prefix=/home/wilson/FOSS/qemu/install-qemu-tmp --target-list=riscv64-linux-user,riscv64-softmmu,riscv32-linux-user,riscv32-softmmu +../qemu/configure: 6464: test: yes: unexpected operator +... + +configure completes OK, so this is a minor problem. It is just one configure test that is failing to work properly. + +Thanks for reporting! Seems like others ran into this problem, too - a patch is already on the list: +https://lists.gnu.org/archive/html/qemu-devel/2020-06/msg08967.html + +Fixed in commit b418d2656112174c; this will be in QEMU 5.1. + + diff --git a/results/classifier/108/other/1886362 b/results/classifier/108/other/1886362 new file mode 100644 index 00000000..5fb86db2 --- /dev/null +++ b/results/classifier/108/other/1886362 @@ -0,0 +1,803 @@ +other: 0.924 +permissions: 0.915 +debug: 0.899 +graphic: 0.893 +performance: 0.892 +device: 0.878 +semantic: 0.847 +PID: 0.821 +vnc: 0.813 +socket: 0.806 +network: 0.806 +KVM: 0.803 +boot: 0.802 +files: 0.788 + +Heap use-after-free in lduw_he_p through e1000e_write_to_rx_buffers + +Hello, +This reproducer causes a heap-use-after free. QEMU Built with --enable-sanitizers: +cat << EOF | ./i386-softmmu/qemu-system-i386 -M q35,accel=qtest \ +-qtest stdio -nographic -monitor none -serial none +outl 0xcf8 0x80001010 +outl 0xcfc 0xe1020000 +outl 0xcf8 0x80001014 +outl 0xcf8 0x80001004 +outw 0xcfc 0x7 +outl 0xcf8 0x800010a2 +write 0xe102003b 0x1 0xff +write 0xe1020103 0x1e 0xffffff055c5e5c30be4511d084ffffffffffffffffffffffffffffffffff +write 0xe1020420 0x4 0xffffffff +write 0xe1020424 0x4 0xffffffff +write 0xe102042b 0x1 0xff +write 0xe1020430 0x4 0x055c5e5c +write 0x5c041 0x1 0x04 +write 0x5c042 0x1 0x02 +write 0x5c043 0x1 0xe1 +write 0x5c048 0x1 0x8a +write 0x5c04a 0x1 0x31 +write 0x5c04b 0x1 0xff +write 0xe1020403 0x1 0xff +EOF + +The Output: +==22689==ERROR: AddressSanitizer: heap-use-after-free on address 0x62500026800e at pc 0x55b93bb18bfa bp 0x7fffdbe844f0 sp 0x7fffdbe83cb8 +READ of size 2 at 0x62500026800e thread T0 + #0 in __asan_memcpy (/build/i386-softmmu/qemu-system-i386+) + #1 in lduw_he_p /include/qemu/bswap.h:332:5 + #2 in ldn_he_p /include/qemu/bswap.h:550:1 + #3 in flatview_write_continue /exec.c:3145:19 + #4 in flatview_write /exec.c:3186:14 + #5 in address_space_write /exec.c:3280:18 + #6 in address_space_rw /exec.c:3290:16 + #7 in dma_memory_rw_relaxed /include/sysemu/dma.h:87:18 + #8 in dma_memory_rw /include/sysemu/dma.h:113:12 + #9 in pci_dma_rw /include/hw/pci/pci.h:789:5 + #10 in pci_dma_write /include/hw/pci/pci.h:802:12 + #11 in e1000e_write_to_rx_buffers /hw/net/e1000e_core.c:1412:9 + #12 in e1000e_write_packet_to_guest /hw/net/e1000e_core.c:1582:21 + #13 in e1000e_receive_iov /hw/net/e1000e_core.c:1709:9 + #14 in e1000e_nc_receive_iov /hw/net/e1000e.c:213:12 + #15 in net_tx_pkt_sendv /hw/net/net_tx_pkt.c:544:9 + #16 in net_tx_pkt_send /hw/net/net_tx_pkt.c:620:9 + #17 in net_tx_pkt_send_loopback /hw/net/net_tx_pkt.c:633:11 + #18 in e1000e_tx_pkt_send /hw/net/e1000e_core.c:664:16 + #19 in e1000e_process_tx_desc /hw/net/e1000e_core.c:743:17 + #20 in e1000e_start_xmit /hw/net/e1000e_core.c:934:9 + #21 in e1000e_set_tctl /hw/net/e1000e_core.c:2431:9 + #22 in e1000e_core_write /hw/net/e1000e_core.c:3265:9 + #23 in e1000e_mmio_write /hw/net/e1000e.c:109:5 + #24 in memory_region_write_accessor /memory.c:483:5 + #25 in access_with_adjusted_size /memory.c:544:18 + #26 in memory_region_dispatch_write /memory.c:1476:16 + #27 in flatview_write_continue /exec.c:3146:23 + #28 in flatview_write /exec.c:3186:14 + #29 in address_space_write /exec.c:3280:18 + #30 in qtest_process_command /qtest.c:567:9 + #31 in qtest_process_inbuf /qtest.c:710:9 + #32 in qtest_read /qtest.c:722:5 + #33 in qemu_chr_be_write_impl /chardev/char.c:188:9 + #34 in qemu_chr_be_write /chardev/char.c:200:9 + #35 in fd_chr_read /chardev/char-fd.c:68:9 + #36 in qio_channel_fd_source_dispatch /io/channel-watch.c:84:12 + #37 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+) + #38 in glib_pollfds_poll /util/main-loop.c:219:9 + #39 in os_host_main_loop_wait /util/main-loop.c:242:5 + #40 in main_loop_wait /util/main-loop.c:518:11 + #41 in qemu_main_loop /softmmu/vl.c:1664:9 + #42 in main /softmmu/main.c:52:5 + #43 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+) + #44 in _start (/build/i386-softmmu/qemu-system-i386+) + +0x62500026800e is located 14 bytes inside of 138-byte region [0x625000268000,0x62500026808a) +freed by thread T0 here: + #0 in free (/build/i386-softmmu/qemu-system-i386+) + #1 in qemu_vfree /util/oslib-posix.c:238:5 + #2 in address_space_unmap /exec.c:3616:5 + #3 in dma_memory_unmap /include/sysemu/dma.h:148:5 + #4 in pci_dma_unmap /include/hw/pci/pci.h:839:5 + #5 in net_tx_pkt_reset /hw/net/net_tx_pkt.c:453:9 + #6 in e1000e_process_tx_desc /hw/net/e1000e_core.c:749:9 + #7 in e1000e_start_xmit /hw/net/e1000e_core.c:934:9 + #8 in e1000e_set_tctl /hw/net/e1000e_core.c:2431:9 + #9 in e1000e_core_write /hw/net/e1000e_core.c:3265:9 + #10 in e1000e_mmio_write /hw/net/e1000e.c:109:5 + #11 in memory_region_write_accessor /memory.c:483:5 + #12 in access_with_adjusted_size /memory.c:544:18 + #13 in memory_region_dispatch_write /memory.c:1476:16 + #14 in flatview_write_continue /exec.c:3146:23 + #15 in flatview_write /exec.c:3186:14 + #16 in address_space_write /exec.c:3280:18 + #17 in address_space_rw /exec.c:3290:16 + #18 in dma_memory_rw_relaxed /include/sysemu/dma.h:87:18 + #19 in dma_memory_rw /include/sysemu/dma.h:113:12 + #20 in pci_dma_rw /include/hw/pci/pci.h:789:5 + #21 in pci_dma_write /include/hw/pci/pci.h:802:12 + #22 in e1000e_write_to_rx_buffers /hw/net/e1000e_core.c:1412:9 + #23 in e1000e_write_packet_to_guest /hw/net/e1000e_core.c:1582:21 + #24 in e1000e_receive_iov /hw/net/e1000e_core.c:1709:9 + #25 in e1000e_nc_receive_iov /hw/net/e1000e.c:213:12 + #26 in net_tx_pkt_sendv /hw/net/net_tx_pkt.c:544:9 + #27 in net_tx_pkt_send /hw/net/net_tx_pkt.c:620:9 + #28 in net_tx_pkt_send_loopback /hw/net/net_tx_pkt.c:633:11 + #29 in e1000e_tx_pkt_send /hw/net/e1000e_core.c:664:16 + +previously allocated by thread T0 here: + #0 in posix_memalign (/build/i386-softmmu/qemu-system-i386+) + #1 in qemu_try_memalign /util/oslib-posix.c:198:11 + #2 in qemu_memalign /util/oslib-posix.c:214:27 + #3 in address_space_map /exec.c:3558:25 + #4 in dma_memory_map /include/sysemu/dma.h:138:9 + #5 in pci_dma_map /include/hw/pci/pci.h:832:11 + #6 in net_tx_pkt_add_raw_fragment /hw/net/net_tx_pkt.c:391:24 + #7 in e1000e_process_tx_desc /hw/net/e1000e_core.c:731:14 + #8 in e1000e_start_xmit /hw/net/e1000e_core.c:934:9 + #9 in e1000e_set_tctl /hw/net/e1000e_core.c:2431:9 + #10 in e1000e_core_write /hw/net/e1000e_core.c:3265:9 + #11 in e1000e_mmio_write /hw/net/e1000e.c:109:5 + #12 in memory_region_write_accessor /memory.c:483:5 + #13 in access_with_adjusted_size /memory.c:544:18 + #14 in memory_region_dispatch_write /memory.c:1476:16 + #15 in flatview_write_continue /exec.c:3146:23 + #16 in flatview_write /exec.c:3186:14 + #17 in address_space_write /exec.c:3280:18 + #18 in qtest_process_command /qtest.c:567:9 + #19 in qtest_process_inbuf /qtest.c:710:9 + #20 in qtest_read /qtest.c:722:5 + #21 in qemu_chr_be_write_impl /chardev/char.c:188:9 + #22 in qemu_chr_be_write /chardev/char.c:200:9 + #23 in fd_chr_read /chardev/char-fd.c:68:9 + #24 in qio_channel_fd_source_dispatch /io/channel-watch.c:84:12 + #25 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+) + +-Alex + +Running with '-trace e1000\*': + +e1000e_cb_pci_realize E1000E PCI realize entry +e1000e_mac_set_permanent Set permanent MAC: 52:54:00:12:34:56 +e1000e_cfg_support_virtio Virtio header supported: 0 +e1000e_rx_set_cso RX CSO state set to 0 +e1000e_cb_qdev_reset E1000E qdev reset entry +e1000x_mac_indicate Indicating MAC to guest: 52:54:00:12:34:56 +e1000x_rx_can_recv_disabled link_up: 1, rx_enabled 0, pci_master 0 +e1000x_rx_can_recv_disabled link_up: 1, rx_enabled 0, pci_master 0 +e1000e_vm_state_running VM state is running +[R +0.094581] outl 0xcf8 0x80001010 +[S +0.094604] OK +[R +0.094632] outl 0xcfc 0xe1020000 +[S +0.094654] OK +[R +0.094668] outl 0xcf8 0x80001014 +[S +0.094675] OK +[R +0.094694] outl 0xcf8 0x80001004 +[S +0.094702] OK +[R +0.094712] outw 0xcfc 0x7 +e1000e_rx_start_recv +[S +0.096938] OK +[R +0.096960] outl 0xcf8 0x800010a2 +[S +0.096972] OK +[R +0.096986] write 0xe102003b 0x1 0xff +e1000e_core_write Write to register 0x38, 4 byte(s), value: 0xff +e1000e_vlan_vet Setting VLAN ethernet type 0xFF +[S +0.097019] OK +[R +0.097034] write 0xe1020103 0x1e 0xffffff055c5e5c30be4511d084ffffffffffffffffffffffffffffffffff +e1000e_core_write Write to register 0x100, 4 byte(s), value: 0xff +e1000e_rx_set_rctl RCTL = 0xff +e1000e_rx_desc_buff_sizes buffer sizes: [2048, 0, 0, 0] +e1000e_rx_desc_len RX descriptor length: 16 +e1000e_rx_start_recv +e1000e_wrn_regs_write_unknown WARNING: Write to unknown register 0x104, 4 byte(s), value: 0x5c05ffff +e1000e_core_write Write to register 0x2820, 4 byte(s), value: 0xbe305c5e +e1000e_irq_rdtr_fpd_not_running FPD written while RDTR was not running +e1000e_wrn_regs_write_unknown WARNING: Write to unknown register 0x10c, 4 byte(s), value: 0x84d01145 +e1000e_core_write Write to register 0x2800, 4 byte(s), value: 0xffffffff +e1000e_core_write Write to register 0x2804, 4 byte(s), value: 0xffffffff +e1000e_core_write Write to register 0x2808, 4 byte(s), value: 0xffffffff +e1000e_wrn_regs_write_unknown WARNING: Write to unknown register 0x11c, 4 byte(s), value: 0xffffffff +e1000e_core_write Write to register 0x2810, 4 byte(s), value: 0xff +[S +0.097143] OK +[R +0.097159] write 0xe1020420 0x4 0xffffffff +e1000e_core_write Write to register 0x3800, 4 byte(s), value: 0xffffffff +[S +0.097173] OK +[R +0.097183] write 0xe1020424 0x4 0xffffffff +e1000e_core_write Write to register 0x3804, 4 byte(s), value: 0xffffffff +[S +0.097196] OK +[R +0.097208] write 0xe102042b 0x1 0xff +e1000e_core_write Write to register 0x3808, 4 byte(s), value: 0xff +[S +0.097221] OK +[R +0.097231] write 0xe1020430 0x4 0x055c5e5c +e1000e_core_write Write to register 0x3810, 4 byte(s), value: 0x5c5e5c05 +[S +0.097243] OK +[R +0.097253] write 0x5c041 0x1 0x04 +[S +0.097914] OK +[R +0.097942] write 0x5c042 0x1 0x02 +[S +0.097953] OK +[R +0.097964] write 0x5c043 0x1 0xe1 +[S +0.097972] OK +[R +0.097984] write 0x5c048 0x1 0x8a +[S +0.097992] OK +[R +0.098003] write 0x5c04a 0x1 0x31 +[S +0.098011] OK +[R +0.098022] write 0x5c04b 0x1 0xff +[S +0.098029] OK +[R +0.098040] write 0xe1020403 0x1 0xff +e1000e_core_write Write to register 0x400, 4 byte(s), value: 0xff +e1000e_tx_descr 0xe1020400 : ff31008a 0 +e1000e_core_read Read from register 0x400, 4 byte(s), value: 0xff +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x404, 4 byte(s) +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x408, 4 byte(s) +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x40c, 4 byte(s) +e1000e_core_read Read from register 0x410, 4 byte(s), value: 0x602008 +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x414, 4 byte(s) +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x418, 4 byte(s) +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x41c, 4 byte(s) +e1000e_core_read Read from register 0x3800, 4 byte(s), value: 0xfffffff0 +e1000e_core_read Read from register 0x3804, 4 byte(s), value: 0xffffffff +e1000e_core_read Read from register 0x3808, 4 byte(s), value: 0x80 +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x42c, 4 byte(s) +e1000e_core_read Read from register 0x3810, 4 byte(s), value: 0x5c05 +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x434, 4 byte(s) +e1000e_core_read Read from register 0x3818, 4 byte(s), value: 0x0 +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x43c, 4 byte(s) +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x3820, 4 byte(s) +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x444, 4 byte(s) +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x448, 4 byte(s) +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x44c, 4 byte(s) +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x450, 4 byte(s) +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x454, 4 byte(s) +e1000e_core_read Read from register 0x458, 4 byte(s), value: 0x0 +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x45c, 4 byte(s) +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x460, 4 byte(s) +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x464, 4 byte(s) +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x468, 4 byte(s) +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x46c, 4 byte(s) +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x470, 4 byte(s) +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x474, 4 byte(s) +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x478, 4 byte(s) +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x47c, 4 byte(s) +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x480, 4 byte(s) +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x484, 4 byte(s) +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x488, 4 byte(s) +e1000e_rx_receive_iov Received vector of 4 fragments +e1000x_vlan_is_vlan_pkt Is VLAN packet: 0, ETH proto: 0x0, VET: 0xFF +e1000e_rx_rss_started Starting RSS processing +e1000e_rx_rss_disabled RSS is disabled +e1000e_rx_rss_dispatched_to_queue Packet being dispatched to queue 0 +e1000e_ring_free_space ring #0: LEN: 1048448, DH: 255, DT: 0 +e1000e_rx_has_buffers ring #0: free descr: 65273, packet size 142, descr buffer size 2048 +e1000e_rx_descr Next RX descriptor: ring #0, PA: 0xfe0, length: 16 +e1000e_rx_null_descriptor Null RX descriptor!! +e1000e_rx_descr Next RX descriptor: ring #0, PA: 0xff0, length: 16 +e1000e_rx_null_descriptor Null RX descriptor!! +e1000e_rx_descr Next RX descriptor: ring #0, PA: 0x1000, length: 16 +e1000e_rx_null_descriptor Null RX descriptor!! +e1000e_rx_descr Next RX descriptor: ring #0, PA: 0x1010, length: 16 +e1000e_rx_null_descriptor Null RX descriptor!! +[...] +e1000e_rx_descr Next RX descriptor: ring #0, PA: 0x5c020, length: 16 +e1000e_rx_null_descriptor Null RX descriptor!! +e1000e_rx_descr Next RX descriptor: ring #0, PA: 0x5c030, length: 16 +e1000e_rx_null_descriptor Null RX descriptor!! +e1000e_rx_descr Next RX descriptor: ring #0, PA: 0x5c040, length: 16 +e1000e_rx_desc_buff_write buffer #0, addr: 0xe1020400, offset: 0, from: 0x631000028830, length: 14 +e1000e_core_write Write to register 0x400, 4 byte(s), value: 0xff +e1000e_tx_descr 0xe1020400 : ff31008a 0 +e1000e_irq_rearm_timer Mitigation timer armed for register 0x3820, delay 0 ns +e1000e_irq_set_cause_entry Going to set IRQ cause 0x2, ICR: 0x0 +e1000e_irq_set_cause_exit Set IRQ cause 0x3, ICR: 0x3 +e1000e_irq_fix_icr_asserted ICR_ASSERTED bit fixed: 0x80000003 +e1000e_irq_pending_interrupts ICR PENDING: 0x0 (ICR: 0x80000003, IMS: 0x0) +e1000e_irq_legacy_notify IRQ line state: 0 +e1000e_wrn_regs_write_unknown WARNING: Write to unknown register 0x404, 4 byte(s), value: 0x0 +e1000e_wrn_regs_write_unknown WARNING: Write to unknown register 0x408, 4 byte(s), value: 0x0 +e1000e_wrn_regs_write_unknown WARNING: Write to unknown register 0x40c, 4 byte(s), value: 0x0 +e1000e_rx_desc_buff_write buffer #0, addr: 0xe1020400, offset: 14, from: 0x62500024200e, length: 124 +================================================================= +==32103==ERROR: AddressSanitizer: heap-use-after-free on address 0x62500024200e at pc 0x55cd3c40c9aa bp 0x7ffd97112bf0 sp 0x7ffd971123a0 + + +On 2020/7/10 下午6:37, Li Qiang wrote: +> Paolo Bonzini <email address hidden> 于2020年7月10日周五 上午1:36写道： +>> On 09/07/20 17:51, Li Qiang wrote: +>>> Maybe we should check whether the address is a RAM address in 'dma_memory_rw'? +>>> But it is a hot path. I'm not sure it is right. Hope more discussion. +>> Half of the purpose of dma-helpers.c (as opposed to address_space_* +>> functions in exec.c) is exactly to support writes to MMIO. This is +> Hi Paolo, +> +> Could you please explain more about this(to support writes to MMIO). +> I can just see the dma helpers with sg DMA, not related with MMIO. + + +Please refer doc/devel/memory.rst. + +The motivation of memory API is to allow support modeling different +memory regions. DMA to MMIO is allowed in hardware so Qemu should +emulate this behaviour. + + +> +> +>> especially true of dma_blk_io, which takes care of doing the DMA via a +>> bounce buffer, possibly in multiple steps and even blocking due to +>> cpu_register_map_client. +>> +>> For dma_memory_rw this is not needed, so it only needs to handle +>> QEMUSGList, but I think the design should be the same. +>> +>> However, this is indeed a nightmare for re-entrancy. The easiest +>> solution is to delay processing of descriptors to a bottom half whenever +>> MMIO is doing something complicated. This is also better for latency +>> because it will free the vCPU thread more quickly and leave the work to +>> the I/O thread. +> Do you mean we define a per-e1000e bottom half. And in the MMIO write +> or packet send +> trigger this bh? + + +Probably a TX bh. + + +> So even if we again trigger the MMIO write, then +> second bh will not be executed? + + +Bh is serialized so no re-entrancy issue. + +Thanks + + +> +> +> Thanks, +> Li Qiang +> +>> Paolo +>> + + + + +On 2020/7/14 下午6:48, Li Qiang wrote: +> Jason Wang <email address hidden> 于2020年7月14日周二 下午4:56写道： +>> +>> On 2020/7/10 下午6:37, Li Qiang wrote: +>>> Paolo Bonzini <email address hidden> 于2020年7月10日周五 上午1:36写道： +>>>> On 09/07/20 17:51, Li Qiang wrote: +>>>>> Maybe we should check whether the address is a RAM address in 'dma_memory_rw'? +>>>>> But it is a hot path. I'm not sure it is right. Hope more discussion. +>>>> Half of the purpose of dma-helpers.c (as opposed to address_space_* +>>>> functions in exec.c) is exactly to support writes to MMIO. This is +>>> Hi Paolo, +>>> +>>> Could you please explain more about this(to support writes to MMIO). +>>> I can just see the dma helpers with sg DMA, not related with MMIO. +>> +>> Please refer doc/devel/memory.rst. +>> +>> The motivation of memory API is to allow support modeling different +>> memory regions. DMA to MMIO is allowed in hardware so Qemu should +>> emulate this behaviour. +>> +> I just read the code again. +> So the dma_blk_io is used for some device that will need DMA to +> MMIO(may be related with +> device spec). But for most of the devices(networking card for +> example) there is no need this DMA to MMIO. +> So we just ksuse dma_memory_rw. Is this understanding right? +> +> Then another question. +> Though the dma helpers uses a bouncing buffer, it finally write to the +> device addressspace in 'address_space_unmap'. +> Is there any posibility that we can again write to the MMIO like this issue? + + +I think the point is to make DMA to MMIO work as real hardware. For +e1000e and other networking devices we need make sure such DMA doesn't +break anything. + +Thanks + + +> +> +>>> +>>>> especially true of dma_blk_io, which takes care of doing the DMA via a +>>>> bounce buffer, possibly in multiple steps and even blocking due to +>>>> cpu_register_map_client. +>>>> +>>>> For dma_memory_rw this is not needed, so it only needs to handle +>>>> QEMUSGList, but I think the design should be the same. +>>>> +>>>> However, this is indeed a nightmare for re-entrancy. The easiest +>>>> solution is to delay processing of descriptors to a bottom half whenever +>>>> MMIO is doing something complicated. This is also better for latency +>>>> because it will free the vCPU thread more quickly and leave the work to +>>>> the I/O thread. +>>> Do you mean we define a per-e1000e bottom half. And in the MMIO write +>>> or packet send +>>> trigger this bh? +>> +>> Probably a TX bh. +>> +> I will try to write this tx bh to strength my understanding in this part. +> Maybe reference the virtio-net implementation I think. +> +> +> +> Thanks, +> Li Qiang +> +>>> So even if we again trigger the MMIO write, then +>>> second bh will not be executed? +>> +>> Bh is serialized so no re-entrancy issue. +>> +>> Thanks +>> +>> +>>> +>>> Thanks, +>>> Li Qiang +>>> +>>>> Paolo +>>>> + + + +Another reproducer: (just to record) + +cat << EOF | ./i386-softmmu/qemu-system-i386 -M pc-q35-5.0 \ +-netdev user,id=qtest-bn0 -device e1000e,netdev=qtest-bn0 \ +-display none -nodefaults -nographic -qtest stdio +outl 0xcf8 0x80000810 +outl 0xcfc 0xe0000000 +outl 0xcf8 0x80000804 +outw 0xcfc 0x7 +write 0xe0000758 0x4 0xfffff1ff +write 0xe0000760 0x6 0xffffdf000000 +write 0xe0000768 0x4 0x0efffff1 +write 0xe0005008 0x4 0x18ffff27 +write 0xe0000c 0x1 0x66 +write 0xe03320 0x1 0xff +write 0xe03620 0x1 0xff +write 0xe00000f3 0x1 0xdf +write 0xe0000100 0x6 0xdfffffdf0000 +write 0xe0000110 0x5 0xdfffffdf00 +write 0xe000011a 0x3 0xffffff +write 0xe0000128 0x5 0x7e00ffffff +write 0xe0000403 0x1 0xdf +write 0xe0000420 0x4 0xdfffffdf +write 0xe000042a 0x3 0xffffff +write 0xe0000438 0x1 0x7e +EOF + +-> https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg05709.html + +On Wed, 15 Jul 2020 at 09:36, Jason Wang <email address hidden> wrote: +> I think the point is to make DMA to MMIO work as real hardware. + +I wouldn't care to give a 100% guarantee that asking a real +h/w device to DMA to itself didn't cause it to misbehave :-) +It's more likely to happen-to-work because the DMA engine bit +of a real h/w device is going to be decoupled somewhat from +the respond-to-memory-transactions-for-registers logic, but +it probably wasn't something the designers were actively +thinking about either... + +> For +> e1000e and other networking devices we need make sure such DMA doesn't +> break anything. + +Yeah, this is the interesting part for QEMU. How should we +structure devices that do DMA so that we can be sure that +the device emulation at least doesn't crash? We could have +a rule that all devices that do DMA must always postpone +all of that DMA to a bottom-half, but that's a lot of +refactoring of a lot of device code... + +thanks +-- PMM + + + +On 2020/7/21 下午8:31, Peter Maydell wrote: +> On Wed, 15 Jul 2020 at 09:36, Jason Wang <email address hidden> wrote: +>> I think the point is to make DMA to MMIO work as real hardware. +> I wouldn't care to give a 100% guarantee that asking a real +> h/w device to DMA to itself didn't cause it to misbehave :-) +> It's more likely to happen-to-work because the DMA engine bit +> of a real h/w device is going to be decoupled somewhat from +> the respond-to-memory-transactions-for-registers logic, but +> it probably wasn't something the designers were actively +> thinking about either... + + +I think some device want such peer to peer transactions: + +https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/driver-api/pci/p2pdma.rst + + +> +>> For +>> e1000e and other networking devices we need make sure such DMA doesn't +>> break anything. +> Yeah, this is the interesting part for QEMU. How should we +> structure devices that do DMA so that we can be sure that +> the device emulation at least doesn't crash? We could have +> a rule that all devices that do DMA must always postpone +> all of that DMA to a bottom-half, but that's a lot of +> refactoring of a lot of device code... + + +It looks to me the issue happens only for device with loopback + +Simply git grep loopback in hw/net tells me we probably need only to +audit dp8393x and rtl8139. + +Qiang, want to help to audit those devices? + +Thanks + + +> +> thanks +> -- PMM +> + + + +On Tue, 21 Jul 2020 at 14:21, Jason Wang <email address hidden> wrote: +> On 2020/7/21 下午8:31, Peter Maydell wrote: +> > On Wed, 15 Jul 2020 at 09:36, Jason Wang <email address hidden> wrote: +> >> I think the point is to make DMA to MMIO work as real hardware. +> > I wouldn't care to give a 100% guarantee that asking a real +> > h/w device to DMA to itself didn't cause it to misbehave :-) +> > It's more likely to happen-to-work because the DMA engine bit +> > of a real h/w device is going to be decoupled somewhat from +> > the respond-to-memory-transactions-for-registers logic, but +> > it probably wasn't something the designers were actively +> > thinking about either... + +> I think some device want such peer to peer transactions: +> +> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/driver-api/pci/p2pdma.rst + +That's a device DMAing to another device, not DMAing to *itself* +(device-to-another-device DMA should work fine in QEMU). And only +a very few devices will ever be sensible targets of the DMA -- +basically things like nvme that have a looks-like-memory area, +or special cases like doorbell registers. + +> > Yeah, this is the interesting part for QEMU. How should we +> > structure devices that do DMA so that we can be sure that +> > the device emulation at least doesn't crash? We could have +> > a rule that all devices that do DMA must always postpone +> > all of that DMA to a bottom-half, but that's a lot of +> > refactoring of a lot of device code... +> +> +> It looks to me the issue happens only for device with loopback + +I think in principle we have a problem for any device that +(a) has memory mapped registers and (b) does DMA reads +whose address is guest-controlled. Loopback isn't a +requirement -- if the guest programs, say, an RX descriptor +base address to point at the device's own registers, you +get exactly the same kind of unexpected-reentrancy. + +thanks +-- PMM + + +On 200721 1444, Peter Maydell wrote: +> On Tue, 21 Jul 2020 at 14:21, Jason Wang <email address hidden> wrote: +> > On 2020/7/21 下午8:31, Peter Maydell wrote: +> > > On Wed, 15 Jul 2020 at 09:36, Jason Wang <email address hidden> wrote: +> > >> I think the point is to make DMA to MMIO work as real hardware. +> > > I wouldn't care to give a 100% guarantee that asking a real +> > > h/w device to DMA to itself didn't cause it to misbehave :-) +> > > It's more likely to happen-to-work because the DMA engine bit +> > > of a real h/w device is going to be decoupled somewhat from +> > > the respond-to-memory-transactions-for-registers logic, but +> > > it probably wasn't something the designers were actively +> > > thinking about either... +> +I searched around but couldn't find anything talking about this case for +real hardware. I also looked at some HDL code for FPGAs that do DMA, but +it seems most of the PCI DMA components are contained in proprietary +IPs, though maybe I'm missing something (I've never programmed +a DMA-capable FPGA). + +> > I think some device want such peer to peer transactions: +> > +> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/driver-api/pci/p2pdma.rst +> +> That's a device DMAing to another device, not DMAing to *itself* +> (device-to-another-device DMA should work fine in QEMU). And only +> a very few devices will ever be sensible targets of the DMA -- +> basically things like nvme that have a looks-like-memory area, +> or special cases like doorbell registers. +> +> > > Yeah, this is the interesting part for QEMU. How should we +> > > structure devices that do DMA so that we can be sure that +> > > the device emulation at least doesn't crash? We could have +> > > a rule that all devices that do DMA must always postpone +> > > all of that DMA to a bottom-half, but that's a lot of +> > > refactoring of a lot of device code... +> > +> > +> > It looks to me the issue happens only for device with loopback +> +> I think in principle we have a problem for any device that +> (a) has memory mapped registers and (b) does DMA reads +> whose address is guest-controlled. Loopback isn't a +> requirement -- if the guest programs, say, an RX descriptor +> base address to point at the device's own registers, you +> get exactly the same kind of unexpected-reentrancy. + +Could this be something that we check for in the +pci_dma_* functions in hw/pci/pci.h? There we still have context about +the source device for the dma read/write and could, compare addr against +the device's PCI BARr's. Not sure about: +1.) How to do this without the overhead of convering the addr +to a MemoryRegion, which is normally done, once, at the flatview_write +stage. +2.) What to do if we catch such a DMA request? Quietly drop it? +3.) Non-PCI devices. + +I think this still doesn't cover the even crazier case where: +CPU writes to DEV_A's MMIO +DEV_A writes to DEV_B's MMIO +DEV_B writes to DEV_A's MMIO +and neither DEV_A or DEV_B use BHs... + +-Alex + +> thanks +> -- PMM +> + + + +On 2020/7/21 下午9:44, Peter Maydell wrote: +> On Tue, 21 Jul 2020 at 14:21, Jason Wang <email address hidden> wrote: +>> On 2020/7/21 下午8:31, Peter Maydell wrote: +>>> On Wed, 15 Jul 2020 at 09:36, Jason Wang <email address hidden> wrote: +>>>> I think the point is to make DMA to MMIO work as real hardware. +>>> I wouldn't care to give a 100% guarantee that asking a real +>>> h/w device to DMA to itself didn't cause it to misbehave :-) +>>> It's more likely to happen-to-work because the DMA engine bit +>>> of a real h/w device is going to be decoupled somewhat from +>>> the respond-to-memory-transactions-for-registers logic, but +>>> it probably wasn't something the designers were actively +>>> thinking about either... +>> I think some device want such peer to peer transactions: +>> +>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/driver-api/pci/p2pdma.rst +> That's a device DMAing to another device, not DMAing to *itself* +> (device-to-another-device DMA should work fine in QEMU). And only +> a very few devices will ever be sensible targets of the DMA -- +> basically things like nvme that have a looks-like-memory area, +> or special cases like doorbell registers. + + +Well, my understanding is: + +- it's not about whether or not we have an actual device that can do DMA +into itself but whether it's allowed by PCI spec +- it's not really matter whether or not it tries to DMA into itself. +Devices could be taught to DMA into each other's RX: + +e1000e(1) RX DMA to e1000e(2) MMIO (RX) +e1000e(2) RX DMA to e1000e(1) RX + +So we get re-reentrancy again. + + +> +>>> Yeah, this is the interesting part for QEMU. How should we +>>> structure devices that do DMA so that we can be sure that +>>> the device emulation at least doesn't crash? We could have +>>> a rule that all devices that do DMA must always postpone +>>> all of that DMA to a bottom-half, but that's a lot of +>>> refactoring of a lot of device code... +>> +>> It looks to me the issue happens only for device with loopback +> I think in principle we have a problem for any device that +> (a) has memory mapped registers and (b) does DMA reads +> whose address is guest-controlled. Loopback isn't a +> requirement -- if the guest programs, say, an RX descriptor +> base address to point at the device's own registers, you +> get exactly the same kind of unexpected-reentrancy. + + +Right, so about the solution, instead of refactoring DMA I wonder we can +simply detect and fail the RX by device itself. + +Thanks + + +> +> thanks +> -- PMM +> + + + + +On 2020/7/21 下午9:46, Li Qiang wrote: +> Jason Wang <email address hidden> 于2020年7月21日周二 下午9:21写道： +>> +>> On 2020/7/21 下午8:31, Peter Maydell wrote: +>>> On Wed, 15 Jul 2020 at 09:36, Jason Wang <email address hidden> wrote: +>>>> I think the point is to make DMA to MMIO work as real hardware. +>>> I wouldn't care to give a 100% guarantee that asking a real +>>> h/w device to DMA to itself didn't cause it to misbehave :-) +>>> It's more likely to happen-to-work because the DMA engine bit +>>> of a real h/w device is going to be decoupled somewhat from +>>> the respond-to-memory-transactions-for-registers logic, but +>>> it probably wasn't something the designers were actively +>>> thinking about either... +>> +>> I think some device want such peer to peer transactions: +>> +>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/driver-api/pci/p2pdma.rst +>> +>> +>>>> For +>>>> e1000e and other networking devices we need make sure such DMA doesn't +>>>> break anything. +>>> Yeah, this is the interesting part for QEMU. How should we +>>> structure devices that do DMA so that we can be sure that +>>> the device emulation at least doesn't crash? We could have +>>> a rule that all devices that do DMA must always postpone +>>> all of that DMA to a bottom-half, but that's a lot of +>>> refactoring of a lot of device code... +>> +>> It looks to me the issue happens only for device with loopback +> IMO I think this is not related-loopback. +> +> It happens when the guest write the MMIO address to the device's +> DMA-related registers. +> The one we see UAF occurs in loopback device because the same +> structure uses in re-entry. +> But we can't say there are no issue for non-loopback device. + + +Yes. + + +>> Simply git grep loopback in hw/net tells me we probably need only to +>> audit dp8393x and rtl8139. +>> +>> Qiang, want to help to audit those devices? +> No problem. Once I finish the e1000e patch I will try to audit those and +> also try to audit some no-loopback device re-entry issue. + + +Thanks. + + +> +> Thanks, +> Li Qiang +> +>> Thanks +>> +>> +>>> thanks +>>> -- PMM +>>> + + + +I can reproduce this problem with QEMU v5.0, but with the current +version, it does not run into this assertion anymore. Seems like this +problem got fixed in the course of time? Could you please check whether +you could still reproduce this? + +This should have been fixed by the qemu_receive_packet/network loopback patches from a few months ago + +Ok, let's mark this as fixed. + diff --git a/results/classifier/108/other/1886602 b/results/classifier/108/other/1886602 new file mode 100644 index 00000000..785e2f60 --- /dev/null +++ b/results/classifier/108/other/1886602 @@ -0,0 +1,145 @@ +performance: 0.913 +permissions: 0.911 +graphic: 0.905 +other: 0.904 +semantic: 0.900 +debug: 0.856 +network: 0.855 +boot: 0.836 +PID: 0.825 +device: 0.814 +files: 0.789 +socket: 0.773 +vnc: 0.741 +KVM: 0.660 + +Windows 10 very slow with OVMF + +Debian Buster + +Kernel 4.19.0-9-amd64 +qemu-kvm 1:3.1+dfsg-8+deb10u5 +ovmf 0~20181115.85588389-3+deb10u1 + +Machine: Thinkpad T470, i7-7500u, 20GB RAM +VM: 4 CPUs, 8GB RAM, Broadwell-noTSX CPU Model + +Windows 10, under this VM, seems to be exceedingly slow with all operations. This is a clean install with very few services running. Task Manager can take 30% CPU looking at an idle system. + +# dmidecode 3.2 +Getting SMBIOS data from sysfs. +SMBIOS 3.0.0 present. +Table at 0x9A694000. + +... + +Handle 0x000A, DMI type 4, 48 bytes +Processor Information + Socket Designation: U3E1 + Type: Central Processor + Family: Core i7 +... + Core Count: 2 + Core Enabled: 2 + Thread Count: 4 + Characteristics: + 64-bit capable + Multi-Core + Hardware Thread + Execute Protection + Enhanced Virtualization + Power/Performance Control + + +Handle 0x000B, DMI type 0, 24 bytes +BIOS Information + Vendor: LENOVO + Version: N1QET88W (1.63 ) + Release Date: 04/22/2020 + Address: 0xE0000 + Runtime Size: 128 kB + ROM Size: 16 MB + Characteristics: + PCI is supported + PNP is supported + BIOS is upgradeable + BIOS shadowing is allowed + Boot from CD is supported + Selectable boot is supported + EDD is supported + 3.5"/720 kB floppy services are supported (int 13h) + Print screen service is supported (int 5h) + 8042 keyboard services are supported (int 9h) + Serial services are supported (int 14h) + Printer services are supported (int 17h) + CGA/mono video services are supported (int 10h) + ACPI is supported + USB legacy is supported + BIOS boot specification is supported + Targeted content distribution is supported + UEFI is supported + BIOS Revision: 1.63 + Firmware Revision: 1.35 + + + +Sorry, no input from me. OVMF is apparently from November 2018, and QEMU is version 3.1. Please try to reproduce with recent upstream components (build both OVMF and QEMU from source), and if the issue persists, please provide the complete QEMU command line, capture the OVMF debug log (see OvmfPkg/README for instructions on that), and please also provide the host CPU characteristics (/proc/cpuinfo, /sys/module/kvm_*/parameters/*). + +I did try the most recent OVMF from QEMU 5.0 (https://git.qemu.org/?p=qemu.git;a=blob_plain;f=pc-bios/edk2-x86_64-code.fd.bz2;hb=fdd76fecdde) and there was no difference. + +I will re-build qemu sometime soon. + +======= +$ cat /proc/cpuinfo +processor : 0 +vendor_id : GenuineIntel +cpu family : 6 +model : 142 +model name : Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz +stepping : 9 +microcode : 0xca +cpu MHz : 659.478 +cache size : 4096 KB +physical id : 0 +siblings : 4 +core id : 0 +cpu cores : 2 +apicid : 0 +initial apicid : 0 +fpu : yes +fpu_exception : yes +cpuid level : 22 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d +bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit srbds +bogomips : 5808.00 +clflush size : 64 +cache_alignment : 64 +address sizes : 39 bits physical, 48 bits virtual +power management: + +======= +$ grep . /sys/module/kvm_*/parameters/* +/sys/module/kvm_intel/parameters/emulate_invalid_guest_state:Y +/sys/module/kvm_intel/parameters/enable_apicv:N +/sys/module/kvm_intel/parameters/enable_shadow_vmcs:N +/sys/module/kvm_intel/parameters/enlightened_vmcs:N +/sys/module/kvm_intel/parameters/ept:Y +/sys/module/kvm_intel/parameters/eptad:Y +/sys/module/kvm_intel/parameters/fasteoi:Y +/sys/module/kvm_intel/parameters/flexpriority:Y +/sys/module/kvm_intel/parameters/nested:N +/sys/module/kvm_intel/parameters/ple_gap:128 +/sys/module/kvm_intel/parameters/ple_window:4096 +/sys/module/kvm_intel/parameters/ple_window_grow:2 +/sys/module/kvm_intel/parameters/ple_window_max:4294967295 +/sys/module/kvm_intel/parameters/ple_window_shrink:0 +/sys/module/kvm_intel/parameters/pml:Y +/sys/module/kvm_intel/parameters/preemption_timer:Y +/sys/module/kvm_intel/parameters/unrestricted_guest:Y +/sys/module/kvm_intel/parameters/vmentry_l1d_flush:cond +/sys/module/kvm_intel/parameters/vnmi:Y +/sys/module/kvm_intel/parameters/vpid:Y + +Inactive for more than a month, significant amount of info was not provided. Closing. + diff --git a/results/classifier/108/other/1886811 b/results/classifier/108/other/1886811 new file mode 100644 index 00000000..f45d7866 --- /dev/null +++ b/results/classifier/108/other/1886811 @@ -0,0 +1,99 @@ +device: 0.813 +graphic: 0.799 +semantic: 0.795 +performance: 0.783 +PID: 0.783 +files: 0.780 +other: 0.779 +network: 0.776 +permissions: 0.769 +boot: 0.763 +KVM: 0.762 +debug: 0.758 +vnc: 0.740 +socket: 0.731 + +systemd complains Failed to enqueue loopback interface start request: Operation not supported + +This symptom seems similar to +https://bugs.launchpad.net/qemu/+bug/1823790 + +Host Linux: Debian 11 Bullseye (testing) on x84-64 architecture +qemu version: latest git of git commit hash eb2c66b10efd2b914b56b20ae90655914310c925 +compiled with "./configure --static --disable-system" + +Down stream bug report at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964289 +Bug report (closed) to systemd: https://github.com/systemd/systemd/issues/16359 + +systemd in armhf and armel (both little endian 32-bit) containers fail to start with +Failed to enqueue loopback interface start request: Operation not supported + +How to reproduce on Debian (and probably Ubuntu): +mmdebstrap --components="main contrib non-free" --architectures=armhf --variant=important bullseye /var/lib/machines/armhf-bullseye +systemd-nspawn -D /var/lib/machines/armhf-bullseye -b + +When "armhf" architecture is replaced with "mips" (32-bit big endian) or "ppc64" +(64-bit big endian), the container starts up fine. + +The same symptom is also observed with "powerpc" (32-bit big endian) architecture. + +It would help to know which operation is not supported. + +Could you get the coredump? +Is it possible to run the operation with "QEMU_STRACE" set in the environment? +Normally loop ioctls are supported. + +But it seems the following ones are not implemented in QEMU: LOOP_SET_CAPACITY, LOOP_SET_DIRECT_IO, LOOP_SET_BLOCK_SIZE. + +It seems systemd is trying to use RTM_SETLINK. + +Could you try this patch: + +diff --git a/linux-user/fd-trans.c b/linux-user/fd-trans.c +index c0687c52e62b..b09b5b7c13e0 100644 +--- a/linux-user/fd-trans.c ++++ b/linux-user/fd-trans.c +@@ -1200,6 +1200,7 @@ static abi_long target_to_host_data_route(struct nlmsghdr *nlh) + break; + case RTM_NEWLINK: + case RTM_DELLINK: ++ case RTM_SETLINK: + if (nlh->nlmsg_len >= NLMSG_LENGTH(sizeof(*ifi))) { + ifi = NLMSG_DATA(nlh); + ifi->ifi_type = tswap16(ifi->ifi_type); + + +> It seems systemd is trying to use RTM_SETLINK. +> Could you try this patch: + +Yes, you are right! +With the patch, I am able to boot containers of +Debian Bullseye of armhf and armel architectures!! + +https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1887606 + +Fixed here: + +65b261a63a48 linux-user: add netlink RTM_SETLINK command +https://git.qemu.org/?p=qemu.git;a=commit;h=65b261a63a48fbb3b11193361d4ea0c38a3c3dfd + +qemu (1:5.0-5ubuntu3) groovy; urgency=medium + +has the merge with this fix: + + - linux-user-add-netlink-RTM_SETLINK-command.patch (Closes: #964289) + + +@Ryutaroh - could you test [1] if it gets you around this bug (1886811) and if bug 1890881 is present in focal as well? + +[1]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4197 + +To fully work this also needs the fix for bug 1890881 as identified there. + +SRU need the bug 1890881 fix to be really helpful, but the dependency chain of that is not SRUable. +See: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1890881/comments/17 + +Users (of this valid but rare use case) can either use Groovy which will fix this or wait until Openstack Victoria will make it available for Focal via the Ubuntu Cloud Archive [1]. + +[1]: https://wiki.ubuntu.com/OpenStack/CloudArchive + diff --git a/results/classifier/108/other/1887 b/results/classifier/108/other/1887 new file mode 100644 index 00000000..25390cc6 --- /dev/null +++ b/results/classifier/108/other/1887 @@ -0,0 +1,24 @@ +device: 0.906 +graphic: 0.800 +debug: 0.712 +performance: 0.670 +vnc: 0.596 +semantic: 0.578 +PID: 0.537 +boot: 0.527 +permissions: 0.477 +network: 0.400 +other: 0.267 +files: 0.260 +socket: 0.253 +KVM: 0.135 + +Window VM failed to resume when using GPU passthrough(GVT-d) on Intel platform if add 'hv-stimer' option, seems like it happened after V6.2.0 +Description of problem: +Windows VM failed to be resumed if adding 'hv-stimer' after Qemu v6.2.0. +Steps to reproduce: +1.Set up GVTd env and launch Windows 10 VM as guest; +2. Sleep the Windows VM with Sleep button; +3. Resume Windows VM via telnet to qemu ,e.g.,'telnet 127.0.0.1 2222', then input 'system_wakeup' to resume Windows VM. +Additional information: + diff --git a/results/classifier/108/other/1887303 b/results/classifier/108/other/1887303 new file mode 100644 index 00000000..2d1f91f6 --- /dev/null +++ b/results/classifier/108/other/1887303 @@ -0,0 +1,240 @@ +other: 0.756 +permissions: 0.644 +graphic: 0.636 +KVM: 0.634 +debug: 0.608 +files: 0.587 +device: 0.576 +PID: 0.565 +performance: 0.564 +network: 0.555 +semantic: 0.513 +socket: 0.491 +boot: 0.466 +vnc: 0.452 + +Assertion failure in *bmdma_active_if `bmdma->bus->retry_unit != (uint8_t)-1' failed. + +Hello, +Here is a QTest Reproducer: + +cat << EOF | ./i386-softmmu/qemu-system-i386 -M pc,accel=qtest\ + -qtest null -nographic -vga qxl -qtest stdio -nodefaults\ + -drive if=none,id=drive0,file=null-co://,file.read-zeroes=on,format=raw\ + -drive if=none,id=drive1,file=null-co://,file.read-zeroes=on,format=raw\ + -device ide-cd,drive=drive0 -device ide-hd,drive=drive1 +outw 0x176 0x3538 +outw 0x376 0x6007 +outw 0x376 0x6b6b +outw 0x176 0x985c +outl 0xcf8 0x80000903 +outl 0xcfc 0x2f2931 +outl 0xcf8 0x80000920 +outb 0xcfc 0x6b +outb 0x68 0x7 +outw 0x176 0x2530 +EOF + +Here is the call-stack: + + #8 0x7f00e0443091 in __assert_fail /build/glibc-GwnBeO/glibc-2.30/assert/assert.c:101:3 + #9 0x55e163f5a1af in bmdma_active_if /home/alxndr/Development/qemu/include/hw/ide/pci.h:59:5 + #10 0x55e163f5a1af in bmdma_prepare_buf /home/alxndr/Development/qemu/hw/ide/pci.c:132:19 + #11 0x55e163f4f00d in ide_dma_cb /home/alxndr/Development/qemu/hw/ide/core.c:898:17 + #12 0x55e163de86ad in dma_complete /home/alxndr/Development/qemu/dma-helpers.c:120:9 + #13 0x55e163de86ad in dma_blk_cb /home/alxndr/Development/qemu/dma-helpers.c:138:9 + #14 0x55e1642ade85 in blk_aio_complete /home/alxndr/Development/qemu/block/block-backend.c:1402:9 + #15 0x55e1642ade85 in blk_aio_complete_bh /home/alxndr/Development/qemu/block/block-backend.c:1412:5 + #16 0x55e16443556f in aio_bh_call /home/alxndr/Development/qemu/util/async.c:136:5 + #17 0x55e16443556f in aio_bh_poll /home/alxndr/Development/qemu/util/async.c:164:13 + #18 0x55e16440fac3 in aio_dispatch /home/alxndr/Development/qemu/util/aio-posix.c:380:5 + #19 0x55e164436dac in aio_ctx_dispatch /home/alxndr/Development/qemu/util/async.c:306:5 + #20 0x7f00e16e29ed in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e9ed) + #21 0x55e164442f2b in glib_pollfds_poll /home/alxndr/Development/qemu/util/main-loop.c:219:9 + #22 0x55e164442f2b in os_host_main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:242:5 + #23 0x55e164442f2b in main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:518:11 + #24 0x55e164376953 in flush_events /home/alxndr/Development/qemu/tests/qtest/fuzz/fuzz.c:47:9 + #25 0x55e16437b8fa in general_fuzz /home/alxndr/Development/qemu/tests/qtest/fuzz/general_fuzz.c:544:17 + +================================= + +Here is the same assertion failure but triggered through a different call-stack: + +cat << EOF | ./i386-softmmu/qemu-system-i386 -M pc,accel=qtest\ + -qtest null -nographic -vga qxl -qtest stdio -nodefaults\ + -drive if=none,id=drive0,file=null-co://,file.read-zeroes=on,format=raw\ + -drive if=none,id=drive1,file=null-co://,file.read-zeroes=on,format=raw\ + -device ide-cd,drive=drive0 -device ide-hd,drive=drive1 +outw 0x171 0x2fe9 +outb 0x177 0xa0 +outl 0x170 0x928 +outl 0x170 0x2b923b31 +outl 0x170 0x800a24d7 +outl 0xcf8 0x80000903 +outl 0xcfc 0x842700 +outl 0xcf8 0x80000920 +outb 0xcfc 0x5e +outb 0x58 0x7 +outb 0x376 0x5 +outw 0x376 0x11 +outw 0x176 0x3538 +EOF + +Call-stack: + #8 0x7f00e0443091 in __assert_fail /build/glibc-GwnBeO/glibc-2.30/assert/assert.c:101:3 + #9 0x55e163f5a622 in bmdma_active_if /home/alxndr/Development/qemu/include/hw/ide/pci.h:59:5 + #10 0x55e163f5a622 in bmdma_rw_buf /home/alxndr/Development/qemu/hw/ide/pci.c:187:19 + #11 0x55e163f57577 in ide_atapi_cmd_read_dma_cb /home/alxndr/Development/qemu/hw/ide/atapi.c:375:13 + #12 0x55e163f44c55 in ide_buffered_readv_cb /home/alxndr/Development/qemu/hw/ide/core.c:650:9 + #13 0x55e1642ade85 in blk_aio_complete /home/alxndr/Development/qemu/block/block-backend.c:1402:9 + #14 0x55e1642ade85 in blk_aio_complete_bh /home/alxndr/Development/qemu/block/block-backend.c:1412:5 + #15 0x55e16443556f in aio_bh_call /home/alxndr/Development/qemu/util/async.c:136:5 + #16 0x55e16443556f in aio_bh_poll /home/alxndr/Development/qemu/util/async.c:164:13 + #17 0x55e16440fac3 in aio_dispatch /home/alxndr/Development/qemu/util/aio-posix.c:380:5 + #18 0x55e164436dac in aio_ctx_dispatch /home/alxndr/Development/qemu/util/async.c:306:5 + #19 0x7f00e16e29ed in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e9ed) + #20 0x55e164442f2b in glib_pollfds_poll /home/alxndr/Development/qemu/util/main-loop.c:219:9 + #21 0x55e164442f2b in os_host_main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:242:5 + #22 0x55e164442f2b in main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:518:11 + #23 0x55e164376953 in flush_events /home/alxndr/Development/qemu/tests/qtest/fuzz/fuzz.c:47:9 + #24 0x55e16437b8fa in general_fuzz /home/alxndr/Development/qemu/tests/qtest/fuzz/general_fuzz.c:544:17 + +================================= + +The first reproducer with -trace ide*: +[I 1594579788.601818] OPENED +26995@1594579788.617583:ide_reset IDEstate 0x565534a7b898 +26995@1594579788.617684:ide_reset IDEstate 0x565534a7bc68 +26995@1594579788.618019:ide_reset IDEstate 0x565534a7c188 +26995@1594579788.618087:ide_reset IDEstate 0x565534a7c558 +26995@1594579788.619271:ide_reset IDEstate 0x565534a7c188 +26995@1594579788.619377:ide_reset IDEstate 0x565534a7c558 +26995@1594579788.623224:ide_reset IDEstate 0x565534a7b898 +26995@1594579788.623267:ide_reset IDEstate 0x565534a7bc68 +26995@1594579788.623273:ide_reset IDEstate 0x565534a7c188 +26995@1594579788.623275:ide_reset IDEstate 0x565534a7c558 +[R +0.023386] outw 0x176 0x3538 +26995@1594579788.625224:ide_ioport_write IDE PIO wr @ 0x176 (Device/Head); val 0x38; bus 0x565534a7c100 IDEState 0x565534a7c188 +26995@1594579788.625228:ide_ioport_write IDE PIO wr @ 0x177 (Command); val 0x35; bus 0x565534a7c100 IDEState 0x565534a7c558 +26995@1594579788.625230:ide_exec_cmd IDE exec cmd: bus 0x565534a7c100; state 0x565534a7c558; cmd 0x35 +[S +0.023416] OK +[R +0.023442] outw 0x376 0x6007 +26995@1594579788.625263:ide_cmd_write IDE PIO wr @ 0x376 (Device Control); val 0x07; bus 0x565534a7c100 +[S +0.023447] OK +[R +0.023455] outw 0x376 0x6b6b +26995@1594579788.625276:ide_cmd_write IDE PIO wr @ 0x376 (Device Control); val 0x6b; bus 0x565534a7c100 +[S +0.023460] OK +[R +0.023464] outw 0x176 0x985c +26995@1594579788.625285:ide_ioport_write IDE PIO wr @ 0x176 (Device/Head); val 0x5c; bus 0x565534a7c100 IDEState 0x565534a7c558 +26995@1594579788.625287:ide_ioport_write IDE PIO wr @ 0x177 (Command); val 0x98; bus 0x565534a7c100 IDEState 0x565534a7c558 +26995@1594579788.625289:ide_exec_cmd IDE exec cmd: bus 0x565534a7c100; state 0x565534a7c558; cmd 0x98 +[S +0.023473] OK +[R +0.023477] outl 0xcf8 0x80000903 +[S +0.023481] OK +[R +0.023485] outl 0xcfc 0x2f2931 +[S +0.023492] OK +[R +0.023496] outl 0xcf8 0x80000920 +[S +0.023498] OK +[R +0.023503] outb 0xcfc 0x6b +[S +0.023644] OK +[R +0.023651] outb 0x68 0x7 +26995@1594579788.625548:ide_dma_cb IDEState 0x565534a7c558; sector_num=1 n=255 cmd=DMA WRITE +[S +0.023809] OK +[R +0.023817] outw 0x176 0x2530 +26995@1594579788.625638:ide_ioport_write IDE PIO wr @ 0x176 (Device/Head); val 0x30; bus 0x565534a7c100 IDEState 0x565534a7c558 +26995@1594579788.625640:ide_ioport_write IDE PIO wr @ 0x177 (Command); val 0x25; bus 0x565534a7c100 IDEState 0x565534a7c558 +26995@1594579788.625642:ide_exec_cmd IDE exec cmd: bus 0x565534a7c100; state 0x565534a7c558; cmd 0x25 +[S +0.023827] OK +qemu-system-i386: /home/alxndr/Development/qemu/include/hw/ide/pci.h:59: IDEState *bmdma_active_if(BMDMAState *): Assertion `bmdma->bus->retry_unit != (uint8_t)-1' failed. + +================================= + +The second reproducer with -trace ide*: + +[I 1594579681.691528] OPENED +8293@1594579681.707423:ide_reset IDEstate 0x55fc044c3898 +8293@1594579681.707540:ide_reset IDEstate 0x55fc044c3c68 +8293@1594579681.707902:ide_reset IDEstate 0x55fc044c4188 +8293@1594579681.707969:ide_reset IDEstate 0x55fc044c4558 +8293@1594579681.709859:ide_reset IDEstate 0x55fc044c4188 +8293@1594579681.709976:ide_reset IDEstate 0x55fc044c4558 +8293@1594579681.714051:ide_reset IDEstate 0x55fc044c3898 +8293@1594579681.714073:ide_reset IDEstate 0x55fc044c3c68 +8293@1594579681.714076:ide_reset IDEstate 0x55fc044c4188 +8293@1594579681.714079:ide_reset IDEstate 0x55fc044c4558 +[R +0.024386] outw 0x171 0x2fe9 +8293@1594579681.715950:ide_ioport_write IDE PIO wr @ 0x171 (Features); val 0xe9; bus 0x55fc044c4100 IDEState 0x55fc044c4188 +8293@1594579681.715955:ide_ioport_write IDE PIO wr @ 0x172 (Sector Count); val 0x2f; bus 0x55fc044c4100 IDEState 0x55fc044c4188 +OK +[S +0.024430] OK +[R +0.024436] outb 0x177 0xa0 +8293@1594579681.715967:ide_ioport_write IDE PIO wr @ 0x177 (Command); val 0xa0; bus 0x55fc044c4100 IDEState 0x55fc044c4188 +8293@1594579681.715970:ide_exec_cmd IDE exec cmd: bus 0x55fc044c4100; state 0x55fc044c4188; cmd 0xa0 +OK +[S +0.024444] OK +[R +0.024448] outl 0x170 0x928 +8293@1594579681.715978:ide_data_writel IDE PIO wr @ 0x170 (Data: Long); val 0x00000928; bus 0x55fc044c4100; IDEState 0x55fc044c4188 +OK +[S +0.024453] OK +[R +0.024456] outl 0x170 0x2b923b31 +8293@1594579681.715986:ide_data_writel IDE PIO wr @ 0x170 (Data: Long); val 0x2b923b31; bus 0x55fc044c4100; IDEState 0x55fc044c4188 +OK +[S +0.024460] OK +[R +0.024464] outl 0x170 0x800a24d7 +8293@1594579681.715994:ide_data_writel IDE PIO wr @ 0x170 (Data: Long); val 0x800a24d7; bus 0x55fc044c4100; IDEState 0x55fc044c4188 +8293@1594579681.715996:ide_atapi_cmd IDEState: 0x55fc044c4188; cmd: 0x28 +8293@1594579681.716000:ide_atapi_cmd_packet IDEState: 0x55fc044c4188; limit=0xeb14 packet: 28 09 00 00 31 3b 92 2b d7 24 0a 80 +8293@1594579681.716004:ide_atapi_cmd_read IDEState: 0x55fc044c4188; read dma: LBA=12603 nb_sectors=11223 +OK +[S +0.024479] OK +[R +0.024483] outl 0xcf8 0x80000903 +OK +[S +0.024485] OK +[R +0.024489] outl 0xcfc 0x842700 +OK +[S +0.024604] OK +[R +0.024610] outl 0xcf8 0x80000920 +OK +[S +0.024613] OK +[R +0.024616] outb 0xcfc 0x5e +OK +[S +0.024720] OK +[R +0.024726] outb 0x58 0x7 +8293@1594579681.716258:ide_atapi_cmd_read_dma_cb_aio IDEState: 0x55fc044c4188; aio read: lba=12603 n=64 +OK +[S +0.024786] OK +[R +0.024791] outb 0x376 0x5 +8293@1594579681.716322:ide_cmd_write IDE PIO wr @ 0x376 (Device Control); val 0x05; bus 0x55fc044c4100 +OK +[S +0.024797] OK +[R +0.024800] outw 0x376 0x11 +8293@1594579681.716330:ide_cmd_write IDE PIO wr @ 0x376 (Device Control); val 0x11; bus 0x55fc044c4100 +OK +[S +0.024804] OK +[R +0.024807] outw 0x176 0x3538 +8293@1594579681.716337:ide_ioport_write IDE PIO wr @ 0x176 (Device/Head); val 0x38; bus 0x55fc044c4100 IDEState 0x55fc044c4188 +8293@1594579681.716340:ide_ioport_write IDE PIO wr @ 0x177 (Command); val 0x35; bus 0x55fc044c4100 IDEState 0x55fc044c4558 +8293@1594579681.716342:ide_exec_cmd IDE exec cmd: bus 0x55fc044c4100; state 0x55fc044c4558; cmd 0x35 +8293@1594579681.716388:ide_dma_cb IDEState 0x55fc044c4558; sector_num=504 n=257 cmd=DMA WRITE +OK +[S +0.024882] OK +qemu-system-i386: /home/alxndr/Development/qemu/include/hw/ide/pci.h:59: IDEState *bmdma_active_if(BMDMAState *): Assertion `bmdma->bus->retry_unit != (uint8_t)-1' failed. + +Proposed fix: +https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg05408.html + +This is another manifestation of the SRST bug. + +New proposal: https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg06974.html + +More analysis of the problem in response to Philippe's proposed fix: https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg06237.html + +Merged upstream: + +55adb3c45620c31f29978f209e2a44a08d34e2da +4ac4e7281a2dd1ca5158812198c4d2cbacf2ae25 +b45bcd81e05dea2781f2164ca1c9dd86069502ea +1a9925e3390b6adf1125e3abaa17c80ca012bede + +Released with QEMU v5.2.0. + diff --git a/results/classifier/108/other/1887306 b/results/classifier/108/other/1887306 new file mode 100644 index 00000000..49d6432b --- /dev/null +++ b/results/classifier/108/other/1887306 @@ -0,0 +1,112 @@ +other: 0.926 +graphic: 0.923 +semantic: 0.901 +performance: 0.900 +debug: 0.895 +permissions: 0.879 +socket: 0.828 +PID: 0.827 +device: 0.810 +boot: 0.799 +files: 0.798 +network: 0.791 +vnc: 0.746 +KVM: 0.742 + +qemu-user deadlocks when forked in a multithreaded process + +The following program (also attached) deadlocks when run under QEMU user on Linux. + +#include <pthread.h> +#include <stdio.h> +#include <stdlib.h> +#include <sys/types.h> +#include <sys/wait.h> +#include <unistd.h> + +#define NUM_THREADS 100 +#define NUM_FORKS 10 + +pthread_barrier_t barrier; + +void *t(void *arg) { + for (int i = 0; i < NUM_FORKS; i++) { + pid_t pid = fork(); + if (pid < 0) + abort(); + if (!pid) + _exit(0); + if (waitpid(pid, NULL, 0) < 0) + abort(); + } + //pthread_barrier_wait(&barrier); + return NULL; +} + +int main(void) { + pthread_barrier_init(&barrier, NULL, NUM_THREADS); + pthread_t ts[NUM_THREADS]; + for (size_t i = 0; i < NUM_THREADS; i++) { + if (pthread_create(&ts[i], NULL, t, NULL)) + abort(); + } + for (size_t i = 0; i < NUM_THREADS; i++) { + pthread_join(ts[i], NULL); + } + printf("Done: %d\n", getpid()); + return 0; +} + +To reproduce: +$ gcc test.c -pthread +$ while qemu-x86_64 ./a.out; do :; done + +(Be careful, Ctrl-C/SIGINT doesn't kill the deadlocked child). + +Larger values of NUM_THREADS/NUM_FORKS lead to more often deadlocks. With the values above it often deadlocks on the first try on my machine. When it deadlocks, there is a child qemu process with two threads which is waited upon by one of the worker threads of the parent. + +I tried to avoid the deadlock by serializing fork() with a mutex, but it didn't help. However, ensuring that no thread exits until all forks are done (by adding a barrier to t()) does seem to help, at least, the program above could run for a half an hour until I terminated it. + +Tested on QEMU 5.0.0, 4.2.0 and 2.11.1, with x86_64 and AArch64 linux-user targets. + + + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system (but you won't be the reporter of the bug +in the new system and thus won't get notified on changes anymore). + +Thank you and sorry for the inconvenience. + + +Still reproduces with QEMU 6.0.0. + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/358 + + diff --git a/results/classifier/108/other/1887309 b/results/classifier/108/other/1887309 new file mode 100644 index 00000000..0d0be36b --- /dev/null +++ b/results/classifier/108/other/1887309 @@ -0,0 +1,327 @@ +other: 0.696 +KVM: 0.620 +performance: 0.607 +graphic: 0.603 +device: 0.592 +debug: 0.563 +boot: 0.549 +permissions: 0.532 +vnc: 0.531 +semantic: 0.522 +files: 0.484 +PID: 0.471 +socket: 0.437 +network: 0.406 + +Floating-point exception in ide_set_sector + +Hello, +Here is a reproducer: +cat << EOF | ./i386-softmmu/qemu-system-i386 -M pc,accel=qtest\ + -qtest null -nographic -vga qxl -qtest stdio -nodefaults\ + -drive if=none,id=drive0,file=null-co://,file.read-zeroes=on,format=raw\ + -drive if=none,id=drive1,file=null-co://,file.read-zeroes=on,format=raw\ + -device ide-cd,drive=drive0 -device ide-hd,drive=drive1 +outw 0x176 0x3538 +outl 0xcf8 0x80000903 +outl 0xcfc 0x184275c +outb 0x376 0x2f +outb 0x376 0x0 +outw 0x176 0xa1a4 +outl 0xcf8 0x80000920 +outb 0xcfc 0xff +outb 0xf8 0x9 +EOF + +The stack-trace: +==16513==ERROR: UndefinedBehaviorSanitizer: FPE on unknown address 0x556783603fdc (pc 0x556783603fdc bp 0x7fff82143b10 sp 0x7fff82143ab0 T16513) + #0 0x556783603fdc in ide_set_sector /home/alxndr/Development/qemu/hw/ide/core.c:626:26 + #1 0x556783603fdc in ide_dma_cb /home/alxndr/Development/qemu/hw/ide/core.c:883:9 + #2 0x55678349d74d in dma_complete /home/alxndr/Development/qemu/dma-helpers.c:120:9 + #3 0x55678349d74d in dma_blk_cb /home/alxndr/Development/qemu/dma-helpers.c:138:9 + #4 0x556783962f25 in blk_aio_complete /home/alxndr/Development/qemu/block/block-backend.c:1402:9 + #5 0x556783962f25 in blk_aio_complete_bh /home/alxndr/Development/qemu/block/block-backend.c:1412:5 + #6 0x556783ac030f in aio_bh_call /home/alxndr/Development/qemu/util/async.c:136:5 + #7 0x556783ac030f in aio_bh_poll /home/alxndr/Development/qemu/util/async.c:164:13 + #8 0x556783a9a863 in aio_dispatch /home/alxndr/Development/qemu/util/aio-posix.c:380:5 + #9 0x556783ac1b4c in aio_ctx_dispatch /home/alxndr/Development/qemu/util/async.c:306:5 + #10 0x7f4f1c0fe9ed in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e9ed) + #11 0x556783acdccb in glib_pollfds_poll /home/alxndr/Development/qemu/util/main-loop.c:219:9 + #12 0x556783acdccb in os_host_main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:242:5 + #13 0x556783acdccb in main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:518:11 + #14 0x5567833613e5 in qemu_main_loop /home/alxndr/Development/qemu/softmmu/vl.c:1664:9 + #15 0x556783a07a4d in main /home/alxndr/Development/qemu/softmmu/main.c:49:5 + #16 0x7f4f1ac84e0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 + #17 0x5567830a9089 in _start (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0x7d2089) + +With -trace ide* + +12163@1594585516.671265:ide_reset IDEstate 0x56162a269058 +[R +0.024963] outw 0x176 0x3538 +12163@1594585516.673676:ide_ioport_write IDE PIO wr @ 0x176 (Device/Head); val 0x38; bus 0x56162a268c00 IDEState 0x56162a268c88 +12163@1594585516.673683:ide_ioport_write IDE PIO wr @ 0x177 (Command); val 0x35; bus 0x56162a268c00 IDEState 0x56162a269058 +12163@1594585516.673686:ide_exec_cmd IDE exec cmd: bus 0x56162a268c00; state 0x56162a269058; cmd 0x35 +OK +[S +0.025002] OK +[R +0.025012] outl 0xcf8 0x80000903 +OK +[S +0.025018] OK +[R +0.025026] outl 0xcfc 0x184275c +OK +[S +0.025210] OK +[R +0.025219] outb 0x376 0x2f +12163@1594585516.673916:ide_cmd_write IDE PIO wr @ 0x376 (Device Control); val 0x2f; bus 0x56162a268c00 +OK +[S +0.025229] OK +[R +0.025234] outb 0x376 0x0 +12163@1594585516.673928:ide_cmd_write IDE PIO wr @ 0x376 (Device Control); val 0x00; bus 0x56162a268c00 +OK +[S +0.025240] OK +[R +0.025246] outw 0x176 0xa1a4 +12163@1594585516.673940:ide_ioport_write IDE PIO wr @ 0x176 (Device/Head); val 0xa4; bus 0x56162a268c00 IDEState 0x56162a269058 +12163@1594585516.673943:ide_ioport_write IDE PIO wr @ 0x177 (Command); val 0xa1; bus 0x56162a268c00 IDEState 0x56162a268c88 +12163@1594585516.673946:ide_exec_cmd IDE exec cmd: bus 0x56162a268c00; state 0x56162a268c88; cmd 0xa1 +OK +[S +0.025265] OK +[R +0.025270] outl 0xcf8 0x80000920 +OK +[S +0.025274] OK +[R +0.025279] outb 0xcfc 0xff +OK +[S +0.025443] OK +[R +0.025451] outb 0xf8 0x9 +12163@1594585516.674221:ide_dma_cb IDEState 0x56162a268c88; sector_num=0 n=1 cmd=DMA READ +OK +[S +0.025724] OK +UndefinedBehaviorSanitizer:DEADLYSIGNAL +==12163==ERROR: UndefinedBehaviorSanitizer: FPE on unknown address 0x5616279cffdc (pc 0x5616279cffdc bp 0x7ffcdaabae90 sp 0x7ffcdaabae30 T12163) + +-Alex + +On 200712 2025, Alexander Bulekov wrote: +> Public bug reported: +> +> Hello, +> Here is a reproducer: +> cat << EOF | ./i386-softmmu/qemu-system-i386 -M pc,accel=qtest\ +> -qtest null -nographic -vga qxl -qtest stdio -nodefaults\ +> -drive if=none,id=drive0,file=null-co://,file.read-zeroes=on,format=raw\ +> -drive if=none,id=drive1,file=null-co://,file.read-zeroes=on,format=raw\ +> -device ide-cd,drive=drive0 -device ide-hd,drive=drive1 +> outw 0x176 0x3538 +> outl 0xcf8 0x80000903 +> outl 0xcfc 0x184275c +> outb 0x376 0x2f +> outb 0x376 0x0 +> outw 0x176 0xa1a4 +> outl 0xcf8 0x80000920 +> outb 0xcfc 0xff +> outb 0xf8 0x9 +> EOF +> +> The stack-trace: +> ==16513==ERROR: UndefinedBehaviorSanitizer: FPE on unknown address 0x556783603fdc (pc 0x556783603fdc bp 0x7fff82143b10 sp 0x7fff82143ab0 T16513) +> #0 0x556783603fdc in ide_set_sector /home/alxndr/Development/qemu/hw/ide/core.c:626:26 +> #1 0x556783603fdc in ide_dma_cb /home/alxndr/Development/qemu/hw/ide/core.c:883:9 +> #2 0x55678349d74d in dma_complete /home/alxndr/Development/qemu/dma-helpers.c:120:9 +> #3 0x55678349d74d in dma_blk_cb /home/alxndr/Development/qemu/dma-helpers.c:138:9 +> #4 0x556783962f25 in blk_aio_complete /home/alxndr/Development/qemu/block/block-backend.c:1402:9 +> #5 0x556783962f25 in blk_aio_complete_bh /home/alxndr/Development/qemu/block/block-backend.c:1412:5 +> #6 0x556783ac030f in aio_bh_call /home/alxndr/Development/qemu/util/async.c:136:5 +> #7 0x556783ac030f in aio_bh_poll /home/alxndr/Development/qemu/util/async.c:164:13 +> #8 0x556783a9a863 in aio_dispatch /home/alxndr/Development/qemu/util/aio-posix.c:380:5 +> #9 0x556783ac1b4c in aio_ctx_dispatch /home/alxndr/Development/qemu/util/async.c:306:5 +> #10 0x7f4f1c0fe9ed in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e9ed) +> #11 0x556783acdccb in glib_pollfds_poll /home/alxndr/Development/qemu/util/main-loop.c:219:9 +> #12 0x556783acdccb in os_host_main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:242:5 +> #13 0x556783acdccb in main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:518:11 +> #14 0x5567833613e5 in qemu_main_loop /home/alxndr/Development/qemu/softmmu/vl.c:1664:9 +> #15 0x556783a07a4d in main /home/alxndr/Development/qemu/softmmu/main.c:49:5 +> #16 0x7f4f1ac84e0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 +> #17 0x5567830a9089 in _start (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0x7d2089) +> +> With -trace ide* +> +> 12163@1594585516.671265:ide_reset IDEstate 0x56162a269058 +> [R +0.024963] outw 0x176 0x3538 +> 12163@1594585516.673676:ide_ioport_write IDE PIO wr @ 0x176 (Device/Head); val 0x38; bus 0x56162a268c00 IDEState 0x56162a268c88 +> 12163@1594585516.673683:ide_ioport_write IDE PIO wr @ 0x177 (Command); val 0x35; bus 0x56162a268c00 IDEState 0x56162a269058 +> 12163@1594585516.673686:ide_exec_cmd IDE exec cmd: bus 0x56162a268c00; state 0x56162a269058; cmd 0x35 +> OK +> [S +0.025002] OK +> [R +0.025012] outl 0xcf8 0x80000903 +> OK +> [S +0.025018] OK +> [R +0.025026] outl 0xcfc 0x184275c +> OK +> [S +0.025210] OK +> [R +0.025219] outb 0x376 0x2f +> 12163@1594585516.673916:ide_cmd_write IDE PIO wr @ 0x376 (Device Control); val 0x2f; bus 0x56162a268c00 +> OK +> [S +0.025229] OK +> [R +0.025234] outb 0x376 0x0 +> 12163@1594585516.673928:ide_cmd_write IDE PIO wr @ 0x376 (Device Control); val 0x00; bus 0x56162a268c00 +> OK +> [S +0.025240] OK +> [R +0.025246] outw 0x176 0xa1a4 +> 12163@1594585516.673940:ide_ioport_write IDE PIO wr @ 0x176 (Device/Head); val 0xa4; bus 0x56162a268c00 IDEState 0x56162a269058 +> 12163@1594585516.673943:ide_ioport_write IDE PIO wr @ 0x177 (Command); val 0xa1; bus 0x56162a268c00 IDEState 0x56162a268c88 +> 12163@1594585516.673946:ide_exec_cmd IDE exec cmd: bus 0x56162a268c00; state 0x56162a268c88; cmd 0xa1 +> OK +> [S +0.025265] OK +> [R +0.025270] outl 0xcf8 0x80000920 +> OK +> [S +0.025274] OK +> [R +0.025279] outb 0xcfc 0xff +> OK +> [S +0.025443] OK +> [R +0.025451] outb 0xf8 0x9 +> 12163@1594585516.674221:ide_dma_cb IDEState 0x56162a268c88; sector_num=0 n=1 cmd=DMA READ +> OK +> [S +0.025724] OK +> UndefinedBehaviorSanitizer:DEADLYSIGNAL +> ==12163==ERROR: UndefinedBehaviorSanitizer: FPE on unknown address 0x5616279cffdc (pc 0x5616279cffdc bp 0x7ffcdaabae90 sp 0x7ffcdaabae30 T12163) +> +> -Alex +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1887309 +> +> Title: +> Floating-point exception in ide_set_sector +> +> Status in QEMU: +> New +> +> Bug description: +> Hello, +> Here is a reproducer: +> cat << EOF | ./i386-softmmu/qemu-system-i386 -M pc,accel=qtest\ +> -qtest null -nographic -vga qxl -qtest stdio -nodefaults\ +> -drive if=none,id=drive0,file=null-co://,file.read-zeroes=on,format=raw\ +> -drive if=none,id=drive1,file=null-co://,file.read-zeroes=on,format=raw\ +> -device ide-cd,drive=drive0 -device ide-hd,drive=drive1 +> outw 0x176 0x3538 +> outl 0xcf8 0x80000903 +> outl 0xcfc 0x184275c +> outb 0x376 0x2f +> outb 0x376 0x0 +> outw 0x176 0xa1a4 +> outl 0xcf8 0x80000920 +> outb 0xcfc 0xff +> outb 0xf8 0x9 +> EOF +> +> The stack-trace: +> ==16513==ERROR: UndefinedBehaviorSanitizer: FPE on unknown address 0x556783603fdc (pc 0x556783603fdc bp 0x7fff82143b10 sp 0x7fff82143ab0 T16513) +> #0 0x556783603fdc in ide_set_sector /home/alxndr/Development/qemu/hw/ide/core.c:626:26 +> #1 0x556783603fdc in ide_dma_cb /home/alxndr/Development/qemu/hw/ide/core.c:883:9 +> #2 0x55678349d74d in dma_complete /home/alxndr/Development/qemu/dma-helpers.c:120:9 +> #3 0x55678349d74d in dma_blk_cb /home/alxndr/Development/qemu/dma-helpers.c:138:9 +> #4 0x556783962f25 in blk_aio_complete /home/alxndr/Development/qemu/block/block-backend.c:1402:9 +> #5 0x556783962f25 in blk_aio_complete_bh /home/alxndr/Development/qemu/block/block-backend.c:1412:5 +> #6 0x556783ac030f in aio_bh_call /home/alxndr/Development/qemu/util/async.c:136:5 +> #7 0x556783ac030f in aio_bh_poll /home/alxndr/Development/qemu/util/async.c:164:13 +> #8 0x556783a9a863 in aio_dispatch /home/alxndr/Development/qemu/util/aio-posix.c:380:5 +> #9 0x556783ac1b4c in aio_ctx_dispatch /home/alxndr/Development/qemu/util/async.c:306:5 +> #10 0x7f4f1c0fe9ed in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e9ed) +> #11 0x556783acdccb in glib_pollfds_poll /home/alxndr/Development/qemu/util/main-loop.c:219:9 +> #12 0x556783acdccb in os_host_main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:242:5 +> #13 0x556783acdccb in main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:518:11 +> #14 0x5567833613e5 in qemu_main_loop /home/alxndr/Development/qemu/softmmu/vl.c:1664:9 +> #15 0x556783a07a4d in main /home/alxndr/Development/qemu/softmmu/main.c:49:5 +> #16 0x7f4f1ac84e0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 +> #17 0x5567830a9089 in _start (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0x7d2089) +> + +This adds a check to avoid the FPE, but I don't know how to properly +report the error, and whether this is the correct place to add this +check. + +diff --git a/hw/ide/core.c b/hw/ide/core.c +index d997a78e47..c191d74ca6 100644 +--- a/hw/ide/core.c ++++ b/hw/ide/core.c +@@ -622,7 +622,7 @@ void ide_set_sector(IDEState *s, int64_t sector_num) + s->hob_lcyl = sector_num >> 32; + s->hob_hcyl = sector_num >> 40; + } +- } else { ++ } else if (s->heads && s->sectors){ + cyl = sector_num / (s->heads * s->sectors); + r = sector_num % (s->heads * s->sectors); + s->hcyl = cyl >> 8; + +> With -trace ide* +> +> 12163@1594585516.671265:ide_reset IDEstate 0x56162a269058 +> [R +0.024963] outw 0x176 0x3538 +> 12163@1594585516.673676:ide_ioport_write IDE PIO wr @ 0x176 (Device/Head); val 0x38; bus 0x56162a268c00 IDEState 0x56162a268c88 +> 12163@1594585516.673683:ide_ioport_write IDE PIO wr @ 0x177 (Command); val 0x35; bus 0x56162a268c00 IDEState 0x56162a269058 +> 12163@1594585516.673686:ide_exec_cmd IDE exec cmd: bus 0x56162a268c00; state 0x56162a269058; cmd 0x35 +> OK +> [S +0.025002] OK +> [R +0.025012] outl 0xcf8 0x80000903 +> OK +> [S +0.025018] OK +> [R +0.025026] outl 0xcfc 0x184275c +> OK +> [S +0.025210] OK +> [R +0.025219] outb 0x376 0x2f +> 12163@1594585516.673916:ide_cmd_write IDE PIO wr @ 0x376 (Device Control); val 0x2f; bus 0x56162a268c00 +> OK +> [S +0.025229] OK +> [R +0.025234] outb 0x376 0x0 +> 12163@1594585516.673928:ide_cmd_write IDE PIO wr @ 0x376 (Device Control); val 0x00; bus 0x56162a268c00 +> OK +> [S +0.025240] OK +> [R +0.025246] outw 0x176 0xa1a4 +> 12163@1594585516.673940:ide_ioport_write IDE PIO wr @ 0x176 (Device/Head); val 0xa4; bus 0x56162a268c00 IDEState 0x56162a269058 +> 12163@1594585516.673943:ide_ioport_write IDE PIO wr @ 0x177 (Command); val 0xa1; bus 0x56162a268c00 IDEState 0x56162a268c88 +> 12163@1594585516.673946:ide_exec_cmd IDE exec cmd: bus 0x56162a268c00; state 0x56162a268c88; cmd 0xa1 +> OK +> [S +0.025265] OK +> [R +0.025270] outl 0xcf8 0x80000920 +> OK +> [S +0.025274] OK +> [R +0.025279] outb 0xcfc 0xff +> OK +> [S +0.025443] OK +> [R +0.025451] outb 0xf8 0x9 +> 12163@1594585516.674221:ide_dma_cb IDEState 0x56162a268c88; sector_num=0 n=1 cmd=DMA READ +> OK +> [S +0.025724] OK +> UndefinedBehaviorSanitizer:DEADLYSIGNAL +> ==12163==ERROR: UndefinedBehaviorSanitizer: FPE on unknown address 0x5616279cffdc (pc 0x5616279cffdc bp 0x7ffcdaabae90 sp 0x7ffcdaabae30 T12163) +> +> -Alex +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1887309/+subscriptions +> + + +Proposed fix: +https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg05528.html + +New proposal: https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg06974.html + +(The root cause is that SRST is not handled correctly.) + +More analysis in the replies to Philippe's patch: https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg05949.html + +Merged upstream: + +55adb3c45620c31f29978f209e2a44a08d34e2da +4ac4e7281a2dd1ca5158812198c4d2cbacf2ae25 +b45bcd81e05dea2781f2164ca1c9dd86069502ea +1a9925e3390b6adf1125e3abaa17c80ca012bede + +Released with QEMU v5.2.0. + diff --git a/results/classifier/108/other/1887318 b/results/classifier/108/other/1887318 new file mode 100644 index 00000000..1bc15d7a --- /dev/null +++ b/results/classifier/108/other/1887318 @@ -0,0 +1,99 @@ +performance: 0.804 +semantic: 0.779 +socket: 0.725 +files: 0.719 +device: 0.691 +network: 0.680 +graphic: 0.652 +PID: 0.569 +permissions: 0.554 +debug: 0.496 +other: 0.493 +vnc: 0.430 +boot: 0.406 +KVM: 0.267 + +impossible to install in OSX Yosemite 10.10.5 + +the Brew method has glib problems, glib is impossible to install. +the MacPorts method has a very long .log file. + + + +console log + +i installed Xcode 6.3 as recommended by MacPorts +"better than 6.1" +for Yosemite + + +https://github.com/Homebrew/brew/issues/7667 + +https://security.stackexchange.com/questions/232445/https-connection-to-specific-sites-fail-with-curl-on-macos + +This is a Cat & Mouse game... +Catch 22... + +its Not a Brew problemm +is Not a glib problem, +is not a git problem, +so we dont care... +its an Apple problem, +Apple does Not care. + +End of Story. + +QEMU only supports the two most recent versions of macOS (see https://www.qemu.org/docs/master/system/build-platforms.html). Support for older versions has been removed (see https://git.qemu.org/?p=qemu.git;a=commitdiff;h=483644c25b93236001), so if you still want to use QEMU on such an old system, you better use an older version of QEMU instead. + + +On Jul 12, 2020, at 10:02 PM, <email address hidden> wrote: + +> Message: 6 +> Date: Mon, 13 Jul 2020 00:17:30 -0000 +> From: JuanPabloCuervo <email address hidden> +> To: <email address hidden> +> Subject: [Bug 1887318] [NEW] impossible to install in OSX Yosemite +> 10.10.5 +> Message-ID: +> +> <<email address hidden> +> al.com> +> +> Content-Type: text/plain; charset="utf-8" +> +> Public bug reported: +> +> the Brew method has glib problems, glib is impossible to install. +> the MacPorts method has a very long .log file. +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> ** Attachment added: "main.log" +> https://bugs.launchpad.net/bugs/1887318/+attachment/5392136/ +> +files/main.log +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1887318 +> +> Title: +> impossible to install in OSX Yosemite 10.10.5 +> +> Status in QEMU: +> New +> +> Bug description: +> the Brew method has glib problems, glib is impossible to install. +> the MacPorts method has a very long .log file. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1887318/+subscriptions + +This is why we need installer files for QEMU. They make life so much +easier than building from source. + + + diff --git a/results/classifier/108/other/1887641 b/results/classifier/108/other/1887641 new file mode 100644 index 00000000..d3fdb465 --- /dev/null +++ b/results/classifier/108/other/1887641 @@ -0,0 +1,58 @@ +boot: 0.905 +device: 0.895 +PID: 0.894 +permissions: 0.885 +graphic: 0.880 +socket: 0.874 +other: 0.872 +performance: 0.862 +semantic: 0.847 +files: 0.837 +debug: 0.820 +network: 0.810 +vnc: 0.806 +KVM: 0.802 + +PCI bus not available for hda + +I'm trying to boot Mac OS 9.2.2 image in order to install it on a qcow disk image. I'm using Linux Mint MATE 20 and QEMU emulator version 4.2.0 (Debian 1:4.2-3ubuntu6.3). When I boot, I've got this error message and boot fails : + +$ /usr/bin/qemu-system-ppc -monitor stdio -soundhw hda -k fr -machine accel=tcg -m 512 -cdrom /home/david/Bureau/debian-10.0.0-powerpc-NETINST-1.iso -drive file="/home/david/.aqemu/iMacG3_hard_disk_HDA.img",if=ide,index=0 -virtfs local,id=shared_folder_dev_0,path=/home/david/Bureau,security_model=none,mount_tag=shared0 -boot order=dc,menu=on -net nic,macaddr=00:a2:6d:80:10:8f,model=rtl8139 -net user -net user,smb=/home/david/Bureau -rtc base=localtime -name "Debian + LXDE sur iMac G3" -M mac99 +QEMU 4.2.0 monitor - type 'help' for more information +(qemu) qemu-system-ppc: PCI bus not available for hda + +MLas OS 9.2.2 ISO is here if you need to test : https://infolib.re/tests/OS9General.iso + +On Wed, 15 Jul 2020, InfoLibre wrote: +> Public bug reported: +> +> I'm trying to boot Mac OS 9.2.2 image in order to install it on a qcow +> disk image. I'm using Linux Mint MATE 20 and QEMU emulator version 4.2.0 +> (Debian 1:4.2-3ubuntu6.3). When I boot, I've got this error message and +> boot fails : +> +> $ /usr/bin/qemu-system-ppc -monitor stdio -soundhw hda -k fr -machine +> accel=tcg -m 512 -cdrom +> /home/david/Bureau/debian-10.0.0-powerpc-NETINST-1.iso -drive +> file="/home/david/.aqemu/iMacG3_hard_disk_HDA.img",if=ide,index=0 +> -virtfs +> local,id=shared_folder_dev_0,path=/home/david/Bureau,security_model=none,mount_tag=shared0 +> -boot order=dc,menu=on -net nic,macaddr=00:a2:6d:80:10:8f,model=rtl8139 +> -net user -net user,smb=/home/david/Bureau -rtc base=localtime -name +> "Debian + LXDE sur iMac G3" -M mac99 +> QEMU 4.2.0 monitor - type 'help' for more information +> (qemu) qemu-system-ppc: PCI bus not available for hda + +You have several problems in your command line. For one you have -cdrom +debian-10.0.0-powerpc-NETINST-1.iso insead of MacOS-9.2.2.iso but your +problem is the -soundhw hda option. Just remove this as it does not make +sense to add Intel HDA audio to a Macintosh and it won't work. Sound is +not currently supported in QEMU for MacOS guest yet, if you want +experimental build with sound support for running MacOS see forum at +emaculation.com. + + +Sorry, I made a mistake, I'm trying to boot PowerPC Debian edition, not Mac OS 9.2.2. I removed the sound card and it boots now. Thank uou very much for your help. + +How to close this bug report ??? + diff --git a/results/classifier/108/other/1887745 b/results/classifier/108/other/1887745 new file mode 100644 index 00000000..a568c53d --- /dev/null +++ b/results/classifier/108/other/1887745 @@ -0,0 +1,41 @@ +other: 0.965 +graphic: 0.858 +boot: 0.835 +device: 0.826 +performance: 0.812 +PID: 0.709 +vnc: 0.704 +debug: 0.696 +semantic: 0.635 +permissions: 0.523 +network: 0.469 +socket: 0.416 +files: 0.353 +KVM: 0.054 + +call-method block-size failed with error ffffffdf + +I start Debian 10 PowerPC version in QEMU with this command : + +/usr/bin/qemu-system-ppc -monitor stdio -M mac99 -k fr -machine accel=tcg -m 512 -cdrom /home/david/Bureau/debian-10.0.0-powerpc-NETINST-1.iso -hda /home/david/Documents/Informatique et téléphone/Documentation informatique/Macintosh/Debian_10_LXDE -virtfs local,id=shared_folder_dev_0,path=/home/david/Bureau,security_model=none,mount_tag=shared0 -boot order=dc,menu=on -net nic,macaddr=00:a2:6d:80:10:8f,model=rtl8139 -net user -net user,smb=/home/david/Bureau -rtc base=localtime -name "Debian + LXDE sur iMac G3" -M mac99 + +GRUB menu appears. Then, I choose "Default install", the screen is cleaned and "Loading..." appears. But after, nothing happens and I've got this error message : + +C>> annot manage 'undefined' PCI device type '<NULL>': +>> 1af4 1009 (0 2 0) + +>> ============================================================= +>> OpenBIOS 1.1 [Mar 12 2020 14:02] +>> Configuration device id QEMU version 1 machine id 1 +>> CPUs: 1 +>> Memory: 512M +>> UUID: 00000000-0000-0000-0000-000000000000 +>> CPU type PowerPC,G4 +milliseconds isn't unique. +>> switching to new context: +>> call-method block-size failed with error ffffffdf +>> call-method block-size failed with error ffffffdf + + +I found this post, I don't know if it could help... : https://lists.gnu.org/archive/html/grub ... 00001.html + diff --git a/results/classifier/108/other/1887820 b/results/classifier/108/other/1887820 new file mode 100644 index 00000000..a55bf22d --- /dev/null +++ b/results/classifier/108/other/1887820 @@ -0,0 +1,31 @@ +device: 0.804 +graphic: 0.694 +other: 0.667 +network: 0.646 +semantic: 0.598 +performance: 0.596 +socket: 0.587 +vnc: 0.583 +files: 0.581 +PID: 0.437 +permissions: 0.375 +debug: 0.355 +boot: 0.351 +KVM: 0.327 + +TCG test targets missing from 'make check-help' + +We can run the TCG tests using: + +$ make run-tcg-tests-$TARGET-softmmu + +This is not listed in 'make check-help'. + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'invalid' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/228 + + diff --git a/results/classifier/108/other/1888303 b/results/classifier/108/other/1888303 new file mode 100644 index 00000000..11aed30b --- /dev/null +++ b/results/classifier/108/other/1888303 @@ -0,0 +1,69 @@ +performance: 0.711 +files: 0.648 +socket: 0.629 +permissions: 0.628 +device: 0.625 +network: 0.610 +graphic: 0.599 +debug: 0.595 +other: 0.574 +semantic: 0.546 +PID: 0.513 +boot: 0.491 +vnc: 0.477 +KVM: 0.418 + +Intermittent buggines with user mode emulation of x86-64 on aarch64 + +QEMU Version: 5.0.0 +./configure --target-list=x86_64-linux-user --enable-user --prefix=/opt/qemu --static + +Testing using node_exporter from pmm-client-1.17.4-1.el8.x86_64.rpm + +aarch64 system is running CentOS 8 with a mainline 5.4.52 kernel built for 4KB memory pages. + +On aarch64 machine, invoke: + +./qemu-x86_64-static /usr/local/percona/pmm-client/node_exporter.x86_64 -web.listen-address=192.168.0.10:42000 -web.auth-file=/usr/local/percona/pmm-client/pmm.yml -web.ssl-key-file=/usr/local/percona/pmm-client/server.key -web.ssl-cert-file=/usr/local/percona/pmm-client/server.crt -collectors.enabled=diskstats,filefd,filesystem,loadavg,meminfo,netdev,netstat,stat,time,uname,vmstat,meminfo_numa,textfile + +Most of the time it will outright segfault within a few seconds, seemingly when the prometheus server polls for data. + +But, about once every 10 times, it will not sefault and will continue working just fine forever. + +The dynamically linked version of qemu (built without --static) always works without segfaulting, but it just doesn't work, the prometheus server gets no data from it. Again, once in a while it will work, but even when it doesn't work it won't segfault. + +This vaguely feels like a memory alignment issue somewhere, but my debug-fu is not quite strong enough to attack the problem. + +As another interesting data point - with dynamically linked qemu-x86_64, when it doesn't work, the process is consuming about 140% of CPU. On a successful run, the process is consuming about 30% of CPU. + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system (but you won't be the reporter of the bug +in the new system and thus won't get notified on changes anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1888417 b/results/classifier/108/other/1888417 new file mode 100644 index 00000000..02f53555 --- /dev/null +++ b/results/classifier/108/other/1888417 @@ -0,0 +1,52 @@ +boot: 0.863 +vnc: 0.850 +device: 0.780 +graphic: 0.773 +other: 0.762 +performance: 0.706 +files: 0.700 +PID: 0.686 +semantic: 0.676 +permissions: 0.632 +socket: 0.590 +network: 0.543 +debug: 0.521 +KVM: 0.405 + +Latest QEMU git build on Arch linux causes PCI Passthrough host to hang on guest reboot. + +Current Arch linux release, up-to-date as of 7/21/2020. + +Running a windows 7 virtual machine (also happens with windows 10, possibly more OSes), with an nvidia GTX 1060 passthrough, if the VM is attempted to be restarted, either through the guest interface, or by libvirt's gui interface "Virtual Machine Manager", it hangs in a "paused" state once the VM shutsdown, and just before the reboot can take place. A force-stop of the VM allows the VM to be properly booted without any disk error checks, alluding to a clean shutdown, but failed reboot. The VM can be properly shutdown using the guests shutdown function, or the libvirt manager shutdown, without any hangs. Reverting to Arch stable build QEMU 5.0.0-7 fixes the issue. + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system (but you won't be the reporter of the bug +in the new system and thus won't get notified on changes anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1888431 b/results/classifier/108/other/1888431 new file mode 100644 index 00000000..a151d11b --- /dev/null +++ b/results/classifier/108/other/1888431 @@ -0,0 +1,100 @@ +vnc: 0.672 +graphic: 0.613 +PID: 0.564 +other: 0.537 +KVM: 0.501 +semantic: 0.490 +device: 0.485 +socket: 0.481 +files: 0.469 +performance: 0.452 +debug: 0.414 +permissions: 0.414 +boot: 0.409 +network: 0.374 + +v5.1.0-rc1 build fails on Mac OS X 10.11.6 + +Hi all, + +build of tag v5.1.0-rc1 fails on Mac OS X 10.11.6 (El Capitan) with the following error: + +git clone https://git.qemu.org/git/qemu.git + <output elided, but all OK> +cd qemu +git submodule init + <output elided, but all OK> +git submodule update --recursive + <output elided, but all OK> +./configure + <output elided, but all OK> +make + <output elided, but all OK up until fail> + + CC trace/control.o +In file included from trace/control.c:29: +In file included from /Users/rtb/src/qemu/include/monitor/monitor.h:4: +In file included from /Users/rtb/src/qemu/include/block/block.h:4: +In file included from /Users/rtb/src/qemu/include/block/aio.h:23: +/Users/rtb/src/qemu/include/qemu/timer.h:843:9: warning: implicit declaration of function 'clock_gettime' is invalid in C99 + [-Wimplicit-function-declaration] + clock_gettime(CLOCK_MONOTONIC, &ts); + ^ +/Users/rtb/src/qemu/include/qemu/timer.h:843:23: error: use of undeclared identifier 'CLOCK_MONOTONIC' + clock_gettime(CLOCK_MONOTONIC, &ts); + ^ +1 warning and 1 error generated. +make: *** [trace/control.o] Error 1 + + +rtb:qemu rtb$ git log -n1 +commit c8004fe6bbfc0d9c2e7b942c418a85efb3ac4b00 (HEAD -> master, tag: v5.1.0-rc1, origin/master, origin/HEAD) +Author: Peter Maydell <email address hidden> +Date: Tue Jul 21 20:28:59 2020 +0100 + + Update version for v5.1.0-rc1 release + + Signed-off-by: Peter Maydell <email address hidden> +rtb:qemu rtb$ + + +Please find the full output of all the commands (from git clone of the repo, to the make) in the attached file "buildfail.txt". + +Thank you! + +Best regards, + +Robert Ball + + + +I'm sorry, but the QEMU project only supports the two most recent versions of macOS (see https://www.qemu.org/docs/master/system/build-platforms.html#macos ), i.e. everything that is older than macOS 10.14 is not supported anymore. + +OK, thank you for pointing that out. + +Question, can you help me identify the most recent release/tag/commit that I could back up to which would support Mac OS X 10.11.6? + +Thank you! + +Best regards, + +Robert Ball + + +Hmm, let's see ... the work-arounds for old Mac OS X versions have been removed here: + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=483644c25b932360018 + +It mentiones that this commit has broken compilation earlier: + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=50290c002c045280f8d + +... so the newest version that still might be compilable is v4.0. + +Fantastic. Thank you Thomas, greatly appreciated! + +Best regards, + +Robert Ball + + diff --git a/results/classifier/108/other/1888467 b/results/classifier/108/other/1888467 new file mode 100644 index 00000000..971e252a --- /dev/null +++ b/results/classifier/108/other/1888467 @@ -0,0 +1,91 @@ +other: 0.860 +graphic: 0.848 +performance: 0.808 +semantic: 0.803 +permissions: 0.787 +device: 0.751 +debug: 0.749 +PID: 0.745 +files: 0.731 +network: 0.681 +boot: 0.647 +KVM: 0.632 +vnc: 0.589 +socket: 0.577 + +qemu-img http convert bug + +Hello, Why the file sizes of http conversion and local conversion are inconsistent? + +Use the http method of qemu-img for conversion. The size of some formats after conversion is different from the local method of qemu-img. Such as vhd, vdi. qcow2 and vmdk are normal。 +My image size is 40 G, raw format. + +The source is the same file, but the access method is different +http method of qemu-img： qemu-img convert -f raw -O vdi http://xxx xxx.vdi（19G，after conversion） +local method of qemu-img： qemu-img convert -f raw -O vdi xxx.raw xxx.vdi（3G，after conversion） + +thank you + +Hi, + +What exactly do you mean by “file size”? The file length (as reported by ls -l) or the bytes used on disk (reported as “disk size” by qemu-img, or by du -B1)? + +You say that qcow2 and vmdk are normal – do you mean as input or as output formats? + +One thing that comes to my mind is that from http, we have no way of inquiring about holes in the source file, so we have to scan the file for ranges that are zero, which may not be optimal. OTOH, the default minimum-zero length is 4 kB, which should basically be the granularity at which filesystems can record and report holes, too. +(And if that’s the problem, it should present itself regardless of the output format.) + +Can you paste the output for “qemu-img map” on your source file somewhere (the local one), or is that too long? + +first, what I said "file size" is file length as reported by ls -l?field.comment=first, what I said "file size" is file length as reported by ls -l. + +The following attachment shows the size of the same source file after different conversion methods， + +http -> local: qemu-img convert -f raw -O vdi localfile localfile1 +local -> local: qemu-img convert -f raw -O vdi localfile localfile2 +localfile1's size is different from localfile2 + +secondly, the conversion of qcow2 and vmdk is normal. +http -> local: qemu-img convert -f raw -O qcow2 localfile localfile1 +local -> local: qemu-img convert -f raw -O qcow2 localfile localfile2 +localfile1's size is the same size as localfile2 + +OK, that’s interesting. To be honest, I have no idea. I’ll keep this in mind and I’ll try to play around with it, but I can’t promise anything. + +hello, I have an other question。 +Why does qemu-img support http reader mode but not http writer mode? +think you. + +Because nobody has implemented it so far. + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system (but you won't be the reporter of the bug +in the new system and thus won't get notified on changes anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1888492 b/results/classifier/108/other/1888492 new file mode 100644 index 00000000..650eac78 --- /dev/null +++ b/results/classifier/108/other/1888492 @@ -0,0 +1,84 @@ +device: 0.796 +other: 0.735 +permissions: 0.731 +boot: 0.709 +graphic: 0.694 +socket: 0.681 +semantic: 0.675 +network: 0.668 +debug: 0.654 +vnc: 0.642 +PID: 0.615 +performance: 0.607 +files: 0.603 +KVM: 0.537 + +After installing Ubuntu, restart and pop up the CMD command prompt + +QEMU release version： V5.1.0 +time：2020年7月22日10:34:40 +Operation: 安装完Ubuntu后重新启动，并弹出CMD命令提示符 +Question: +Command used：qemu-system-x86_64.exe -name test -m 4096 -machine accel=hax -cdrom .\workspace\ubuntu\ubuntu-20.04-desktop-amd64.iso .\workspace\img\ubuntu.img +HAX is working and emulator runs in fast virt mode. +*** BUG *** +In pixman_region32_init_rect: Invalid rectangle passed +Set a breakpoint on '_pixman_log_error' to debug + +*** BUG *** +In pixman_region32_init_rect: Invalid rectangle passed +Set a breakpoint on '_pixman_log_error' to debug + +*** BUG *** +In pixman_region32_init_rect: Invalid rectangle passed +Set a breakpoint on '_pixman_log_error' to debug + +*** BUG *** +In pixman_region32_init_rect: Invalid rectangle passed +Set a breakpoint on '_pixman_log_error' to debug + +*** BUG *** +In pixman_region32_init_rect: Invalid rectangle passed +Set a breakpoint on '_pixman_log_error' to debug + +*** BUG *** +In pixman_region32_init_rect: Invalid rectangle passed +Set a breakpoint on '_pixman_log_error' to debug + +*** BUG *** +In pixman_region32_init_rect: Invalid rectangle passed +Set a breakpoint on '_pixman_log_error' to debug + +*** BUG *** +In pixman_region32_init_rect: Invalid rectangle passed +Set a breakpoint on '_pixman_log_error' to debug + +*** BUG *** +In pixman_region32_init_rect: Invalid rectangle passed +Set a breakpoint on '_pixman_log_error' to debug + +*** BUG *** +In pixman_region32_init_rect: Invalid rectangle passed +Set a breakpoint on '_pixman_log_error' to debug + + +(qemu:660): Gtk-WARNING **: Negative content width -7 (allocation 1, extents 4x4) while allocating gadget (node headerbar, owner GtkHeaderBar) + +(qemu:660): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -102 and height 16 + +(qemu:660): Gtk-WARNING **: Negative content width -23 (allocation 1, extents 12x12) while allocating gadget (node label, owner GtkLabel) +qemu-system-x86_64.exe: Gtk: gtk_distribute_natural_allocation: assertion 'extra_space >= 0' failed + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting older bugs to "Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1888606 b/results/classifier/108/other/1888606 new file mode 100644 index 00000000..254b853e --- /dev/null +++ b/results/classifier/108/other/1888606 @@ -0,0 +1,860 @@ +other: 0.954 +debug: 0.914 +permissions: 0.913 +graphic: 0.910 +semantic: 0.909 +performance: 0.899 +device: 0.896 +PID: 0.892 +socket: 0.888 +files: 0.872 +vnc: 0.861 +KVM: 0.842 +network: 0.842 +boot: 0.833 + +Heap-use-after-free in virtio_gpu_ctrl_response + +Hello, +Here is a reproducer (build with --enable-sanitizers): +cat << EOF | ./i386-softmmu/qemu-system-i386 -nographic -M pc -nodefaults -m 512M -device virtio-vga -qtest stdio +outl 0xcf8 0x80001018 +outl 0xcfc 0xe0800000 +outl 0xcf8 0x80001020 +outl 0xcf8 0x80001004 +outw 0xcfc 0x7 +writeq 0xe0801024 0x10646c00776c6cff +writeq 0xe080102d 0xe0801000320000 +writeq 0xe0801015 0x12b2901ba000000 +write 0x10646c02 0x1 0x2c +write 0x999 0x1 0x25 +write 0x8 0x1 0x78 +write 0x2c7 0x1 0x32 +write 0x2cb 0x1 0xff +write 0x2cc 0x1 0x7e +writeq 0xe0803000 0xf2b8f0540ff83 +EOF + +The ASAN trace: +==29798==ERROR: AddressSanitizer: heap-use-after-free on address 0x60d0000050e8 at pc 0x560629814761 bp 0x7ffe916eb1e0 sp 0x7ffe916eb1d8 +READ of size 8 at 0x60d0000050e8 thread T0 + #0 0x560629814760 in virtio_gpu_ctrl_response /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:181:42 + #1 0x56062981adc8 in virtio_gpu_ctrl_response_nodata /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:193:5 + #2 0x56062981adc8 in virtio_gpu_simple_process_cmd /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:791:9 + #3 0x5606298175f8 in virtio_gpu_process_cmdq /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:820:9 + #4 0x56062a8f1c96 in aio_bh_poll /home/alxndr/Development/qemu/util/async.c:164:13 + #5 0x56062a887b9d in aio_dispatch /home/alxndr/Development/qemu/util/aio-posix.c:380:5 + #6 0x56062a8f6b1c in aio_ctx_dispatch /home/alxndr/Development/qemu/util/async.c:306:5 + #7 0x7f0d5e1cf9ed in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e9ed) + #8 0x56062a919571 in glib_pollfds_poll /home/alxndr/Development/qemu/util/main-loop.c:217:9 + #9 0x56062a919571 in os_host_main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:240:5 + #10 0x56062a919571 in main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:516:11 + #11 0x560629094a64 in qemu_main_loop /home/alxndr/Development/qemu/softmmu/vl.c:1676:9 + #12 0x56062a749ab5 in main /home/alxndr/Development/qemu/softmmu/main.c:49:5 + #13 0x7f0d5cd55e0a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x26e0a) + #14 0x5606288ba889 in _start (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0x24d0889) + +0x60d0000050e8 is located 56 bytes inside of 136-byte region [0x60d0000050b0,0x60d000005138) +freed by thread T0 here: + #0 0x56062893250d in free (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0x254850d) + #1 0x560629827730 in virtio_gpu_reset /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:1160:9 + #2 0x560628e81d34 in virtio_reset /home/alxndr/Development/qemu/hw/virtio/virtio.c:1999:9 + #3 0x560629f08773 in virtio_pci_reset /home/alxndr/Development/qemu/hw/virtio/virtio-pci.c:1841:5 + #4 0x560629043ab6 in memory_region_write_accessor /home/alxndr/Development/qemu/softmmu/memory.c:483:5 + #5 0x560629043473 in access_with_adjusted_size /home/alxndr/Development/qemu/softmmu/memory.c:544:18 + #6 0x560629042c99 in memory_region_dispatch_write /home/alxndr/Development/qemu/softmmu/memory.c + #7 0x560628990a37 in flatview_write_continue /home/alxndr/Development/qemu/exec.c:3176:23 + #8 0x56062899041a in address_space_write_cached_slow /home/alxndr/Development/qemu/exec.c:3789:12 + #9 0x560628e6f9bb in vring_used_write /home/alxndr/Development/qemu/hw/virtio/virtio.c:347:5 + #10 0x560628e6f9bb in virtqueue_split_fill /home/alxndr/Development/qemu/hw/virtio/virtio.c:788:5 + #11 0x560628e6f9bb in virtqueue_fill /home/alxndr/Development/qemu/hw/virtio/virtio.c:852:9 + #12 0x560628e7205e in virtqueue_push /home/alxndr/Development/qemu/hw/virtio/virtio.c:917:5 + #13 0x560629814246 in virtio_gpu_ctrl_response /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:180:5 + #14 0x56062981adc8 in virtio_gpu_ctrl_response_nodata /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:193:5 + #15 0x56062981adc8 in virtio_gpu_simple_process_cmd /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:791:9 + #16 0x5606298175f8 in virtio_gpu_process_cmdq /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:820:9 + #17 0x56062a8f1c96 in aio_bh_poll /home/alxndr/Development/qemu/util/async.c:164:13 + #18 0x56062a887b9d in aio_dispatch /home/alxndr/Development/qemu/util/aio-posix.c:380:5 + #19 0x56062a8f6b1c in aio_ctx_dispatch /home/alxndr/Development/qemu/util/async.c:306:5 + #20 0x7f0d5e1cf9ed in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e9ed) + +previously allocated by thread T0 here: + #0 0x56062893278d in malloc (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0x254878d) + #1 0x7f0d5e1d5500 in g_malloc (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x54500) + #2 0x560628e7844b in virtqueue_split_pop /home/alxndr/Development/qemu/hw/virtio/virtio.c:1524:12 + #3 0x560628e7844b in virtqueue_pop /home/alxndr/Development/qemu/hw/virtio/virtio.c:1693:16 + #4 0x560629829633 in virtio_gpu_handle_ctrl /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:878:15 + #5 0x560629829633 in virtio_gpu_ctrl_bh /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:893:5 + #6 0x56062a8f1c96 in aio_bh_poll /home/alxndr/Development/qemu/util/async.c:164:13 + #7 0x56062a887b9d in aio_dispatch /home/alxndr/Development/qemu/util/aio-posix.c:380:5 + #8 0x56062a8f6b1c in aio_ctx_dispatch /home/alxndr/Development/qemu/util/async.c:306:5 + #9 0x7f0d5e1cf9ed in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e9ed) + + +With -trace virtio\* -trace pci\* : +[I 1595480025.666147] OPENED +31900@1595480025.706962:virtio_set_status vdev 0x633000019640 val 0 +31900@1595480025.710297:virtio_set_status vdev 0x633000019640 val 0 +[R +0.046276] outl 0xcf8 0x80001018 +OK +[S +0.046313] OK +[R +0.046332] outl 0xcfc 0xe0800000 +31900@1595480025.712490:pci_cfg_write virtio-vga 02:0 @0x18 <- 0xe0800000 +OK +[S +0.046356] OK +[R +0.046365] outl 0xcf8 0x80001020 +OK +[S +0.046370] OK +[R +0.046379] outl 0xcf8 0x80001004 +OK +[S +0.046383] OK +[R +0.046391] outw 0xcfc 0x7 +31900@1595480025.712544:pci_cfg_write virtio-vga 02:0 @0x4 <- 0x7 +31900@1595480025.712551:pci_update_mappings_add d=0x633000000800 00:02.0 2,0xe0800000+0x4000 +OK +[S +0.047572] OK +[R +0.047597] writeq 0xe0801024 0x10646c00776c6cff +OK +[S +0.047610] OK +[R +0.047619] writeq 0xe080102d 0xe0801000320000 +OK +[S +0.047627] OK +[R +0.047636] writeq 0xe0801015 0x12b2901ba000000 +OK +[S +0.047650] OK +[R +0.047660] write 0x10646c02 0x1 0x2c +OK +[S +0.047769] OK +[R +0.047782] write 0x999 0x1 0x25 +OK +[S +0.047907] OK +[R +0.047920] write 0x8 0x1 0x78 +OK +[S +0.047927] OK +[R +0.047935] write 0x2c7 0x1 0x32 +OK +[S +0.047941] OK +[R +0.047949] write 0x2cb 0x1 0xff +OK +[S +0.047954] OK +[R +0.047962] write 0x2cc 0x1 0x7e +OK +[S +0.047967] OK +[R +0.047975] writeq 0xe0803000 0xf2b8f0540ff83 +31900@1595480025.714133:virtio_queue_notify vdev 0x633000019640 n 0 vq 0x7fe20b13d800 +OK +[S +0.047996] OK +31900@1595480025.714386:virtio_notify vdev 0x633000019640 vq 0x7fe20b13d800 +31900@1595480025.714406:virtio_gpu_features virgl 0 +31900@1595480025.714413:virtio_notify vdev 0x633000019640 vq 0x7fe20b13d800 +31900@1595480025.714421:virtio_set_status vdev 0x633000019640 val 0 +*CRASH* + +Please let me know if I can provide any further info. +-Alex + +CC-ing virtio-gpu Maintainers. + +On 200723 0455, Alexander Bulekov wrote: +> Public bug reported: +> +> Hello, +> Here is a reproducer (build with --enable-sanitizers): +> cat << EOF | ./i386-softmmu/qemu-system-i386 -nographic -M pc -nodefaults -m 512M -device virtio-vga -qtest stdio +> outl 0xcf8 0x80001018 +> outl 0xcfc 0xe0800000 +> outl 0xcf8 0x80001020 +> outl 0xcf8 0x80001004 +> outw 0xcfc 0x7 +> writeq 0xe0801024 0x10646c00776c6cff +> writeq 0xe080102d 0xe0801000320000 +> writeq 0xe0801015 0x12b2901ba000000 +> write 0x10646c02 0x1 0x2c +> write 0x999 0x1 0x25 +> write 0x8 0x1 0x78 +> write 0x2c7 0x1 0x32 +> write 0x2cb 0x1 0xff +> write 0x2cc 0x1 0x7e +> writeq 0xe0803000 0xf2b8f0540ff83 +> EOF +> +> The ASAN trace: +> ==29798==ERROR: AddressSanitizer: heap-use-after-free on address 0x60d0000050e8 at pc 0x560629814761 bp 0x7ffe916eb1e0 sp 0x7ffe916eb1d8 +> READ of size 8 at 0x60d0000050e8 thread T0 +> #0 0x560629814760 in virtio_gpu_ctrl_response /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:181:42 +> #1 0x56062981adc8 in virtio_gpu_ctrl_response_nodata /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:193:5 +> #2 0x56062981adc8 in virtio_gpu_simple_process_cmd /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:791:9 +> #3 0x5606298175f8 in virtio_gpu_process_cmdq /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:820:9 +> #4 0x56062a8f1c96 in aio_bh_poll /home/alxndr/Development/qemu/util/async.c:164:13 +> #5 0x56062a887b9d in aio_dispatch /home/alxndr/Development/qemu/util/aio-posix.c:380:5 +> #6 0x56062a8f6b1c in aio_ctx_dispatch /home/alxndr/Development/qemu/util/async.c:306:5 +> #7 0x7f0d5e1cf9ed in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e9ed) +> #8 0x56062a919571 in glib_pollfds_poll /home/alxndr/Development/qemu/util/main-loop.c:217:9 +> #9 0x56062a919571 in os_host_main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:240:5 +> #10 0x56062a919571 in main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:516:11 +> #11 0x560629094a64 in qemu_main_loop /home/alxndr/Development/qemu/softmmu/vl.c:1676:9 +> #12 0x56062a749ab5 in main /home/alxndr/Development/qemu/softmmu/main.c:49:5 +> #13 0x7f0d5cd55e0a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x26e0a) +> #14 0x5606288ba889 in _start (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0x24d0889) +> +> 0x60d0000050e8 is located 56 bytes inside of 136-byte region [0x60d0000050b0,0x60d000005138) +> freed by thread T0 here: +> #0 0x56062893250d in free (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0x254850d) +> #1 0x560629827730 in virtio_gpu_reset /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:1160:9 +> #2 0x560628e81d34 in virtio_reset /home/alxndr/Development/qemu/hw/virtio/virtio.c:1999:9 +> #3 0x560629f08773 in virtio_pci_reset /home/alxndr/Development/qemu/hw/virtio/virtio-pci.c:1841:5 +> #4 0x560629043ab6 in memory_region_write_accessor /home/alxndr/Development/qemu/softmmu/memory.c:483:5 +> #5 0x560629043473 in access_with_adjusted_size /home/alxndr/Development/qemu/softmmu/memory.c:544:18 +> #6 0x560629042c99 in memory_region_dispatch_write /home/alxndr/Development/qemu/softmmu/memory.c +> #7 0x560628990a37 in flatview_write_continue /home/alxndr/Development/qemu/exec.c:3176:23 +> #8 0x56062899041a in address_space_write_cached_slow /home/alxndr/Development/qemu/exec.c:3789:12 +> #9 0x560628e6f9bb in vring_used_write /home/alxndr/Development/qemu/hw/virtio/virtio.c:347:5 +> #10 0x560628e6f9bb in virtqueue_split_fill /home/alxndr/Development/qemu/hw/virtio/virtio.c:788:5 +> #11 0x560628e6f9bb in virtqueue_fill /home/alxndr/Development/qemu/hw/virtio/virtio.c:852:9 +> #12 0x560628e7205e in virtqueue_push /home/alxndr/Development/qemu/hw/virtio/virtio.c:917:5 +> #13 0x560629814246 in virtio_gpu_ctrl_response /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:180:5 +> #14 0x56062981adc8 in virtio_gpu_ctrl_response_nodata /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:193:5 +> #15 0x56062981adc8 in virtio_gpu_simple_process_cmd /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:791:9 +> #16 0x5606298175f8 in virtio_gpu_process_cmdq /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:820:9 +> #17 0x56062a8f1c96 in aio_bh_poll /home/alxndr/Development/qemu/util/async.c:164:13 +> #18 0x56062a887b9d in aio_dispatch /home/alxndr/Development/qemu/util/aio-posix.c:380:5 +> #19 0x56062a8f6b1c in aio_ctx_dispatch /home/alxndr/Development/qemu/util/async.c:306:5 +> #20 0x7f0d5e1cf9ed in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e9ed) +> +> previously allocated by thread T0 here: +> #0 0x56062893278d in malloc (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0x254878d) +> #1 0x7f0d5e1d5500 in g_malloc (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x54500) +> #2 0x560628e7844b in virtqueue_split_pop /home/alxndr/Development/qemu/hw/virtio/virtio.c:1524:12 +> #3 0x560628e7844b in virtqueue_pop /home/alxndr/Development/qemu/hw/virtio/virtio.c:1693:16 +> #4 0x560629829633 in virtio_gpu_handle_ctrl /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:878:15 +> #5 0x560629829633 in virtio_gpu_ctrl_bh /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:893:5 +> #6 0x56062a8f1c96 in aio_bh_poll /home/alxndr/Development/qemu/util/async.c:164:13 +> #7 0x56062a887b9d in aio_dispatch /home/alxndr/Development/qemu/util/aio-posix.c:380:5 +> #8 0x56062a8f6b1c in aio_ctx_dispatch /home/alxndr/Development/qemu/util/async.c:306:5 +> #9 0x7f0d5e1cf9ed in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e9ed) +> +> +> With -trace virtio\* -trace pci\* : +> [I 1595480025.666147] OPENED +> 31900@1595480025.706962:virtio_set_status vdev 0x633000019640 val 0 +> 31900@1595480025.710297:virtio_set_status vdev 0x633000019640 val 0 +> [R +0.046276] outl 0xcf8 0x80001018 +> OK +> [S +0.046313] OK +> [R +0.046332] outl 0xcfc 0xe0800000 +> 31900@1595480025.712490:pci_cfg_write virtio-vga 02:0 @0x18 <- 0xe0800000 +> OK +> [S +0.046356] OK +> [R +0.046365] outl 0xcf8 0x80001020 +> OK +> [S +0.046370] OK +> [R +0.046379] outl 0xcf8 0x80001004 +> OK +> [S +0.046383] OK +> [R +0.046391] outw 0xcfc 0x7 +> 31900@1595480025.712544:pci_cfg_write virtio-vga 02:0 @0x4 <- 0x7 +> 31900@1595480025.712551:pci_update_mappings_add d=0x633000000800 00:02.0 2,0xe0800000+0x4000 +> OK +> [S +0.047572] OK +> [R +0.047597] writeq 0xe0801024 0x10646c00776c6cff +> OK +> [S +0.047610] OK +> [R +0.047619] writeq 0xe080102d 0xe0801000320000 +> OK +> [S +0.047627] OK +> [R +0.047636] writeq 0xe0801015 0x12b2901ba000000 +> OK +> [S +0.047650] OK +> [R +0.047660] write 0x10646c02 0x1 0x2c +> OK +> [S +0.047769] OK +> [R +0.047782] write 0x999 0x1 0x25 +> OK +> [S +0.047907] OK +> [R +0.047920] write 0x8 0x1 0x78 +> OK +> [S +0.047927] OK +> [R +0.047935] write 0x2c7 0x1 0x32 +> OK +> [S +0.047941] OK +> [R +0.047949] write 0x2cb 0x1 0xff +> OK +> [S +0.047954] OK +> [R +0.047962] write 0x2cc 0x1 0x7e +> OK +> [S +0.047967] OK +> [R +0.047975] writeq 0xe0803000 0xf2b8f0540ff83 +> 31900@1595480025.714133:virtio_queue_notify vdev 0x633000019640 n 0 vq 0x7fe20b13d800 +> OK +> [S +0.047996] OK +> 31900@1595480025.714386:virtio_notify vdev 0x633000019640 vq 0x7fe20b13d800 +> 31900@1595480025.714406:virtio_gpu_features virgl 0 +> 31900@1595480025.714413:virtio_notify vdev 0x633000019640 vq 0x7fe20b13d800 +> 31900@1595480025.714421:virtio_set_status vdev 0x633000019640 val 0 +> *CRASH* +> +> Please let me know if I can provide any further info. +> -Alex +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1888606 +> +> Title: +> Heap-use-after-free in virtio_gpu_ctrl_response +> +> Status in QEMU: +> New +> +> Bug description: +> Hello, +> Here is a reproducer (build with --enable-sanitizers): +> cat << EOF | ./i386-softmmu/qemu-system-i386 -nographic -M pc -nodefaults -m 512M -device virtio-vga -qtest stdio +> outl 0xcf8 0x80001018 +> outl 0xcfc 0xe0800000 +> outl 0xcf8 0x80001020 +> outl 0xcf8 0x80001004 +> outw 0xcfc 0x7 +> writeq 0xe0801024 0x10646c00776c6cff +> writeq 0xe080102d 0xe0801000320000 +> writeq 0xe0801015 0x12b2901ba000000 +> write 0x10646c02 0x1 0x2c +> write 0x999 0x1 0x25 +> write 0x8 0x1 0x78 +> write 0x2c7 0x1 0x32 +> write 0x2cb 0x1 0xff +> write 0x2cc 0x1 0x7e +> writeq 0xe0803000 0xf2b8f0540ff83 +> EOF +> +> The ASAN trace: +> ==29798==ERROR: AddressSanitizer: heap-use-after-free on address 0x60d0000050e8 at pc 0x560629814761 bp 0x7ffe916eb1e0 sp 0x7ffe916eb1d8 +> READ of size 8 at 0x60d0000050e8 thread T0 +> #0 0x560629814760 in virtio_gpu_ctrl_response /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:181:42 +> #1 0x56062981adc8 in virtio_gpu_ctrl_response_nodata /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:193:5 +> #2 0x56062981adc8 in virtio_gpu_simple_process_cmd /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:791:9 +> #3 0x5606298175f8 in virtio_gpu_process_cmdq /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:820:9 +> #4 0x56062a8f1c96 in aio_bh_poll /home/alxndr/Development/qemu/util/async.c:164:13 +> #5 0x56062a887b9d in aio_dispatch /home/alxndr/Development/qemu/util/aio-posix.c:380:5 +> #6 0x56062a8f6b1c in aio_ctx_dispatch /home/alxndr/Development/qemu/util/async.c:306:5 +> #7 0x7f0d5e1cf9ed in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e9ed) +> #8 0x56062a919571 in glib_pollfds_poll /home/alxndr/Development/qemu/util/main-loop.c:217:9 +> #9 0x56062a919571 in os_host_main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:240:5 +> #10 0x56062a919571 in main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:516:11 +> #11 0x560629094a64 in qemu_main_loop /home/alxndr/Development/qemu/softmmu/vl.c:1676:9 +> #12 0x56062a749ab5 in main /home/alxndr/Development/qemu/softmmu/main.c:49:5 +> #13 0x7f0d5cd55e0a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x26e0a) +> #14 0x5606288ba889 in _start (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0x24d0889) +> +> 0x60d0000050e8 is located 56 bytes inside of 136-byte region [0x60d0000050b0,0x60d000005138) +> freed by thread T0 here: +> #0 0x56062893250d in free (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0x254850d) +> #1 0x560629827730 in virtio_gpu_reset /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:1160:9 +> #2 0x560628e81d34 in virtio_reset /home/alxndr/Development/qemu/hw/virtio/virtio.c:1999:9 +> #3 0x560629f08773 in virtio_pci_reset /home/alxndr/Development/qemu/hw/virtio/virtio-pci.c:1841:5 +> #4 0x560629043ab6 in memory_region_write_accessor /home/alxndr/Development/qemu/softmmu/memory.c:483:5 +> #5 0x560629043473 in access_with_adjusted_size /home/alxndr/Development/qemu/softmmu/memory.c:544:18 +> #6 0x560629042c99 in memory_region_dispatch_write /home/alxndr/Development/qemu/softmmu/memory.c +> #7 0x560628990a37 in flatview_write_continue /home/alxndr/Development/qemu/exec.c:3176:23 +> #8 0x56062899041a in address_space_write_cached_slow /home/alxndr/Development/qemu/exec.c:3789:12 +> #9 0x560628e6f9bb in vring_used_write /home/alxndr/Development/qemu/hw/virtio/virtio.c:347:5 +> #10 0x560628e6f9bb in virtqueue_split_fill /home/alxndr/Development/qemu/hw/virtio/virtio.c:788:5 +> #11 0x560628e6f9bb in virtqueue_fill /home/alxndr/Development/qemu/hw/virtio/virtio.c:852:9 +> #12 0x560628e7205e in virtqueue_push /home/alxndr/Development/qemu/hw/virtio/virtio.c:917:5 +> #13 0x560629814246 in virtio_gpu_ctrl_response /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:180:5 +> #14 0x56062981adc8 in virtio_gpu_ctrl_response_nodata /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:193:5 +> #15 0x56062981adc8 in virtio_gpu_simple_process_cmd /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:791:9 +> #16 0x5606298175f8 in virtio_gpu_process_cmdq /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:820:9 +> #17 0x56062a8f1c96 in aio_bh_poll /home/alxndr/Development/qemu/util/async.c:164:13 +> #18 0x56062a887b9d in aio_dispatch /home/alxndr/Development/qemu/util/aio-posix.c:380:5 +> #19 0x56062a8f6b1c in aio_ctx_dispatch /home/alxndr/Development/qemu/util/async.c:306:5 +> #20 0x7f0d5e1cf9ed in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e9ed) +> +> previously allocated by thread T0 here: +> #0 0x56062893278d in malloc (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0x254878d) +> #1 0x7f0d5e1d5500 in g_malloc (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x54500) +> #2 0x560628e7844b in virtqueue_split_pop /home/alxndr/Development/qemu/hw/virtio/virtio.c:1524:12 +> #3 0x560628e7844b in virtqueue_pop /home/alxndr/Development/qemu/hw/virtio/virtio.c:1693:16 +> #4 0x560629829633 in virtio_gpu_handle_ctrl /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:878:15 +> #5 0x560629829633 in virtio_gpu_ctrl_bh /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:893:5 +> #6 0x56062a8f1c96 in aio_bh_poll /home/alxndr/Development/qemu/util/async.c:164:13 +> #7 0x56062a887b9d in aio_dispatch /home/alxndr/Development/qemu/util/aio-posix.c:380:5 +> #8 0x56062a8f6b1c in aio_ctx_dispatch /home/alxndr/Development/qemu/util/async.c:306:5 +> #9 0x7f0d5e1cf9ed in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e9ed) +> +> +> With -trace virtio\* -trace pci\* : +> [I 1595480025.666147] OPENED +> 31900@1595480025.706962:virtio_set_status vdev 0x633000019640 val 0 +> 31900@1595480025.710297:virtio_set_status vdev 0x633000019640 val 0 +> [R +0.046276] outl 0xcf8 0x80001018 +> OK +> [S +0.046313] OK +> [R +0.046332] outl 0xcfc 0xe0800000 +> 31900@1595480025.712490:pci_cfg_write virtio-vga 02:0 @0x18 <- 0xe0800000 +> OK +> [S +0.046356] OK +> [R +0.046365] outl 0xcf8 0x80001020 +> OK +> [S +0.046370] OK +> [R +0.046379] outl 0xcf8 0x80001004 +> OK +> [S +0.046383] OK +> [R +0.046391] outw 0xcfc 0x7 +> 31900@1595480025.712544:pci_cfg_write virtio-vga 02:0 @0x4 <- 0x7 +> 31900@1595480025.712551:pci_update_mappings_add d=0x633000000800 00:02.0 2,0xe0800000+0x4000 +> OK +> [S +0.047572] OK +> [R +0.047597] writeq 0xe0801024 0x10646c00776c6cff +> OK +> [S +0.047610] OK +> [R +0.047619] writeq 0xe080102d 0xe0801000320000 +> OK +> [S +0.047627] OK +> [R +0.047636] writeq 0xe0801015 0x12b2901ba000000 +> OK +> [S +0.047650] OK +> [R +0.047660] write 0x10646c02 0x1 0x2c +> OK +> [S +0.047769] OK +> [R +0.047782] write 0x999 0x1 0x25 +> OK +> [S +0.047907] OK +> [R +0.047920] write 0x8 0x1 0x78 +> OK +> [S +0.047927] OK +> [R +0.047935] write 0x2c7 0x1 0x32 +> OK +> [S +0.047941] OK +> [R +0.047949] write 0x2cb 0x1 0xff +> OK +> [S +0.047954] OK +> [R +0.047962] write 0x2cc 0x1 0x7e +> OK +> [S +0.047967] OK +> [R +0.047975] writeq 0xe0803000 0xf2b8f0540ff83 +> 31900@1595480025.714133:virtio_queue_notify vdev 0x633000019640 n 0 vq 0x7fe20b13d800 +> OK +> [S +0.047996] OK +> 31900@1595480025.714386:virtio_notify vdev 0x633000019640 vq 0x7fe20b13d800 +> 31900@1595480025.714406:virtio_gpu_features virgl 0 +> 31900@1595480025.714413:virtio_notify vdev 0x633000019640 vq 0x7fe20b13d800 +> 31900@1595480025.714421:virtio_set_status vdev 0x633000019640 val 0 +> *CRASH* +> +> Please let me know if I can provide any further info. +> -Alex +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1888606/+subscriptions +> + + +On 200723 1351, Li Qiang wrote: +> Alexander Bulekov <email address hidden> 于2020年7月23日周四 下午1:02写道： +> > +> > Public bug reported: +> > +> > Hello, +> > Here is a reproducer (build with --enable-sanitizers): +> > cat << EOF | ./i386-softmmu/qemu-system-i386 -nographic -M pc -nodefaults -m 512M -device virtio-vga -qtest stdio +> > outl 0xcf8 0x80001018 +> > outl 0xcfc 0xe0800000 +> > outl 0xcf8 0x80001020 +> > outl 0xcf8 0x80001004 +> > outw 0xcfc 0x7 +> > writeq 0xe0801024 0x10646c00776c6cff +> > writeq 0xe080102d 0xe0801000320000 +> > writeq 0xe0801015 0x12b2901ba000000 +> > write 0x10646c02 0x1 0x2c +> > write 0x999 0x1 0x25 +> > write 0x8 0x1 0x78 +> > write 0x2c7 0x1 0x32 +> > write 0x2cb 0x1 0xff +> > write 0x2cc 0x1 0x7e +> > writeq 0xe0803000 0xf2b8f0540ff83 +> > EOF +> > +> > The ASAN trace: +> > ==29798==ERROR: AddressSanitizer: heap-use-after-free on address 0x60d0000050e8 at pc 0x560629814761 bp 0x7ffe916eb1e0 sp 0x7ffe916eb1d8 +> > READ of size 8 at 0x60d0000050e8 thread T0 +> > #0 0x560629814760 in virtio_gpu_ctrl_response /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:181:42 +> > #1 0x56062981adc8 in virtio_gpu_ctrl_response_nodata /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:193:5 +> > #2 0x56062981adc8 in virtio_gpu_simple_process_cmd /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:791:9 +> > #3 0x5606298175f8 in virtio_gpu_process_cmdq /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:820:9 +> > #4 0x56062a8f1c96 in aio_bh_poll /home/alxndr/Development/qemu/util/async.c:164:13 +> > #5 0x56062a887b9d in aio_dispatch /home/alxndr/Development/qemu/util/aio-posix.c:380:5 +> > #6 0x56062a8f6b1c in aio_ctx_dispatch /home/alxndr/Development/qemu/util/async.c:306:5 +> > #7 0x7f0d5e1cf9ed in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e9ed) +> > #8 0x56062a919571 in glib_pollfds_poll /home/alxndr/Development/qemu/util/main-loop.c:217:9 +> > #9 0x56062a919571 in os_host_main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:240:5 +> > #10 0x56062a919571 in main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:516:11 +> > #11 0x560629094a64 in qemu_main_loop /home/alxndr/Development/qemu/softmmu/vl.c:1676:9 +> > #12 0x56062a749ab5 in main /home/alxndr/Development/qemu/softmmu/main.c:49:5 +> > #13 0x7f0d5cd55e0a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x26e0a) +> > #14 0x5606288ba889 in _start (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0x24d0889) +> > +> > 0x60d0000050e8 is located 56 bytes inside of 136-byte region [0x60d0000050b0,0x60d000005138) +> > freed by thread T0 here: +> > #0 0x56062893250d in free (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0x254850d) +> > #1 0x560629827730 in virtio_gpu_reset /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:1160:9 +> > #2 0x560628e81d34 in virtio_reset /home/alxndr/Development/qemu/hw/virtio/virtio.c:1999:9 +> > #3 0x560629f08773 in virtio_pci_reset /home/alxndr/Development/qemu/hw/virtio/virtio-pci.c:1841:5 +> > #4 0x560629043ab6 in memory_region_write_accessor /home/alxndr/Development/qemu/softmmu/memory.c:483:5 +> > #5 0x560629043473 in access_with_adjusted_size /home/alxndr/Development/qemu/softmmu/memory.c:544:18 +> > #6 0x560629042c99 in memory_region_dispatch_write /home/alxndr/Development/qemu/softmmu/memory.c +> > #7 0x560628990a37 in flatview_write_continue /home/alxndr/Development/qemu/exec.c:3176:23 +> > #8 0x56062899041a in address_space_write_cached_slow /home/alxndr/Development/qemu/exec.c:3789:12 +> > #9 0x560628e6f9bb in vring_used_write /home/alxndr/Development/qemu/hw/virtio/virtio.c:347:5 +> > #10 0x560628e6f9bb in virtqueue_split_fill /home/alxndr/Development/qemu/hw/virtio/virtio.c:788:5 +> > #11 0x560628e6f9bb in virtqueue_fill /home/alxndr/Development/qemu/hw/virtio/virtio.c:852:9 +> > #12 0x560628e7205e in virtqueue_push /home/alxndr/Development/qemu/hw/virtio/virtio.c:917:5 +> > #13 0x560629814246 in virtio_gpu_ctrl_response /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:180:5 +> > #14 0x56062981adc8 in virtio_gpu_ctrl_response_nodata /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:193:5 +> > #15 0x56062981adc8 in virtio_gpu_simple_process_cmd /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:791:9 +> > #16 0x5606298175f8 in virtio_gpu_process_cmdq /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:820:9 +> > #17 0x56062a8f1c96 in aio_bh_poll /home/alxndr/Development/qemu/util/async.c:164:13 +> > #18 0x56062a887b9d in aio_dispatch /home/alxndr/Development/qemu/util/aio-posix.c:380:5 +> > #19 0x56062a8f6b1c in aio_ctx_dispatch /home/alxndr/Development/qemu/util/async.c:306:5 +> > #20 0x7f0d5e1cf9ed in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e9ed) +> > +> +> Seems again when we write back to virtio used vring, we write to the +> MMIO addresspace. + +Yes it seems to have a similar flavor as LP#1886362, but this time with +BHes in the mix, which we would hope avoid the reentrancy issues. +-Alex + +> Thanks, +> Li Qiang +> +> +> > previously allocated by thread T0 here: +> > #0 0x56062893278d in malloc (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0x254878d) +> > #1 0x7f0d5e1d5500 in g_malloc (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x54500) +> > #2 0x560628e7844b in virtqueue_split_pop /home/alxndr/Development/qemu/hw/virtio/virtio.c:1524:12 +> > #3 0x560628e7844b in virtqueue_pop /home/alxndr/Development/qemu/hw/virtio/virtio.c:1693:16 +> > #4 0x560629829633 in virtio_gpu_handle_ctrl /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:878:15 +> > #5 0x560629829633 in virtio_gpu_ctrl_bh /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:893:5 +> > #6 0x56062a8f1c96 in aio_bh_poll /home/alxndr/Development/qemu/util/async.c:164:13 +> > #7 0x56062a887b9d in aio_dispatch /home/alxndr/Development/qemu/util/aio-posix.c:380:5 +> > #8 0x56062a8f6b1c in aio_ctx_dispatch /home/alxndr/Development/qemu/util/async.c:306:5 +> > #9 0x7f0d5e1cf9ed in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e9ed) +> > +> > +> > With -trace virtio\* -trace pci\* : +> > [I 1595480025.666147] OPENED +> > 31900@1595480025.706962:virtio_set_status vdev 0x633000019640 val 0 +> > 31900@1595480025.710297:virtio_set_status vdev 0x633000019640 val 0 +> > [R +0.046276] outl 0xcf8 0x80001018 +> > OK +> > [S +0.046313] OK +> > [R +0.046332] outl 0xcfc 0xe0800000 +> > 31900@1595480025.712490:pci_cfg_write virtio-vga 02:0 @0x18 <- 0xe0800000 +> > OK +> > [S +0.046356] OK +> > [R +0.046365] outl 0xcf8 0x80001020 +> > OK +> > [S +0.046370] OK +> > [R +0.046379] outl 0xcf8 0x80001004 +> > OK +> > [S +0.046383] OK +> > [R +0.046391] outw 0xcfc 0x7 +> > 31900@1595480025.712544:pci_cfg_write virtio-vga 02:0 @0x4 <- 0x7 +> > 31900@1595480025.712551:pci_update_mappings_add d=0x633000000800 00:02.0 2,0xe0800000+0x4000 +> > OK +> > [S +0.047572] OK +> > [R +0.047597] writeq 0xe0801024 0x10646c00776c6cff +> > OK +> > [S +0.047610] OK +> > [R +0.047619] writeq 0xe080102d 0xe0801000320000 +> > OK +> > [S +0.047627] OK +> > [R +0.047636] writeq 0xe0801015 0x12b2901ba000000 +> > OK +> > [S +0.047650] OK +> > [R +0.047660] write 0x10646c02 0x1 0x2c +> > OK +> > [S +0.047769] OK +> > [R +0.047782] write 0x999 0x1 0x25 +> > OK +> > [S +0.047907] OK +> > [R +0.047920] write 0x8 0x1 0x78 +> > OK +> > [S +0.047927] OK +> > [R +0.047935] write 0x2c7 0x1 0x32 +> > OK +> > [S +0.047941] OK +> > [R +0.047949] write 0x2cb 0x1 0xff +> > OK +> > [S +0.047954] OK +> > [R +0.047962] write 0x2cc 0x1 0x7e +> > OK +> > [S +0.047967] OK +> > [R +0.047975] writeq 0xe0803000 0xf2b8f0540ff83 +> > 31900@1595480025.714133:virtio_queue_notify vdev 0x633000019640 n 0 vq 0x7fe20b13d800 +> > OK +> > [S +0.047996] OK +> > 31900@1595480025.714386:virtio_notify vdev 0x633000019640 vq 0x7fe20b13d800 +> > 31900@1595480025.714406:virtio_gpu_features virgl 0 +> > 31900@1595480025.714413:virtio_notify vdev 0x633000019640 vq 0x7fe20b13d800 +> > 31900@1595480025.714421:virtio_set_status vdev 0x633000019640 val 0 +> > *CRASH* +> > +> > Please let me know if I can provide any further info. +> > -Alex +> > +> > ** Affects: qemu +> > Importance: Undecided +> > Status: New +> > +> > -- +> > You received this bug notification because you are a member of qemu- +> > devel-ml, which is subscribed to QEMU. +> > https://bugs.launchpad.net/bugs/1888606 +> > +> > Title: +> > Heap-use-after-free in virtio_gpu_ctrl_response +> > +> > Status in QEMU: +> > New +> > +> > Bug description: +> > Hello, +> > Here is a reproducer (build with --enable-sanitizers): +> > cat << EOF | ./i386-softmmu/qemu-system-i386 -nographic -M pc -nodefaults -m 512M -device virtio-vga -qtest stdio +> > outl 0xcf8 0x80001018 +> > outl 0xcfc 0xe0800000 +> > outl 0xcf8 0x80001020 +> > outl 0xcf8 0x80001004 +> > outw 0xcfc 0x7 +> > writeq 0xe0801024 0x10646c00776c6cff +> > writeq 0xe080102d 0xe0801000320000 +> > writeq 0xe0801015 0x12b2901ba000000 +> > write 0x10646c02 0x1 0x2c +> > write 0x999 0x1 0x25 +> > write 0x8 0x1 0x78 +> > write 0x2c7 0x1 0x32 +> > write 0x2cb 0x1 0xff +> > write 0x2cc 0x1 0x7e +> > writeq 0xe0803000 0xf2b8f0540ff83 +> > EOF +> > +> > The ASAN trace: +> > ==29798==ERROR: AddressSanitizer: heap-use-after-free on address 0x60d0000050e8 at pc 0x560629814761 bp 0x7ffe916eb1e0 sp 0x7ffe916eb1d8 +> > READ of size 8 at 0x60d0000050e8 thread T0 +> > #0 0x560629814760 in virtio_gpu_ctrl_response /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:181:42 +> > #1 0x56062981adc8 in virtio_gpu_ctrl_response_nodata /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:193:5 +> > #2 0x56062981adc8 in virtio_gpu_simple_process_cmd /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:791:9 +> > #3 0x5606298175f8 in virtio_gpu_process_cmdq /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:820:9 +> > #4 0x56062a8f1c96 in aio_bh_poll /home/alxndr/Development/qemu/util/async.c:164:13 +> > #5 0x56062a887b9d in aio_dispatch /home/alxndr/Development/qemu/util/aio-posix.c:380:5 +> > #6 0x56062a8f6b1c in aio_ctx_dispatch /home/alxndr/Development/qemu/util/async.c:306:5 +> > #7 0x7f0d5e1cf9ed in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e9ed) +> > #8 0x56062a919571 in glib_pollfds_poll /home/alxndr/Development/qemu/util/main-loop.c:217:9 +> > #9 0x56062a919571 in os_host_main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:240:5 +> > #10 0x56062a919571 in main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:516:11 +> > #11 0x560629094a64 in qemu_main_loop /home/alxndr/Development/qemu/softmmu/vl.c:1676:9 +> > #12 0x56062a749ab5 in main /home/alxndr/Development/qemu/softmmu/main.c:49:5 +> > #13 0x7f0d5cd55e0a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x26e0a) +> > #14 0x5606288ba889 in _start (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0x24d0889) +> > +> > 0x60d0000050e8 is located 56 bytes inside of 136-byte region [0x60d0000050b0,0x60d000005138) +> > freed by thread T0 here: +> > #0 0x56062893250d in free (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0x254850d) +> > #1 0x560629827730 in virtio_gpu_reset /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:1160:9 +> > #2 0x560628e81d34 in virtio_reset /home/alxndr/Development/qemu/hw/virtio/virtio.c:1999:9 +> > #3 0x560629f08773 in virtio_pci_reset /home/alxndr/Development/qemu/hw/virtio/virtio-pci.c:1841:5 +> > #4 0x560629043ab6 in memory_region_write_accessor /home/alxndr/Development/qemu/softmmu/memory.c:483:5 +> > #5 0x560629043473 in access_with_adjusted_size /home/alxndr/Development/qemu/softmmu/memory.c:544:18 +> > #6 0x560629042c99 in memory_region_dispatch_write /home/alxndr/Development/qemu/softmmu/memory.c +> > #7 0x560628990a37 in flatview_write_continue /home/alxndr/Development/qemu/exec.c:3176:23 +> > #8 0x56062899041a in address_space_write_cached_slow /home/alxndr/Development/qemu/exec.c:3789:12 +> > #9 0x560628e6f9bb in vring_used_write /home/alxndr/Development/qemu/hw/virtio/virtio.c:347:5 +> > #10 0x560628e6f9bb in virtqueue_split_fill /home/alxndr/Development/qemu/hw/virtio/virtio.c:788:5 +> > #11 0x560628e6f9bb in virtqueue_fill /home/alxndr/Development/qemu/hw/virtio/virtio.c:852:9 +> > #12 0x560628e7205e in virtqueue_push /home/alxndr/Development/qemu/hw/virtio/virtio.c:917:5 +> > #13 0x560629814246 in virtio_gpu_ctrl_response /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:180:5 +> > #14 0x56062981adc8 in virtio_gpu_ctrl_response_nodata /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:193:5 +> > #15 0x56062981adc8 in virtio_gpu_simple_process_cmd /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:791:9 +> > #16 0x5606298175f8 in virtio_gpu_process_cmdq /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:820:9 +> > #17 0x56062a8f1c96 in aio_bh_poll /home/alxndr/Development/qemu/util/async.c:164:13 +> > #18 0x56062a887b9d in aio_dispatch /home/alxndr/Development/qemu/util/aio-posix.c:380:5 +> > #19 0x56062a8f6b1c in aio_ctx_dispatch /home/alxndr/Development/qemu/util/async.c:306:5 +> > #20 0x7f0d5e1cf9ed in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e9ed) +> > +> > previously allocated by thread T0 here: +> > #0 0x56062893278d in malloc (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0x254878d) +> > #1 0x7f0d5e1d5500 in g_malloc (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x54500) +> > #2 0x560628e7844b in virtqueue_split_pop /home/alxndr/Development/qemu/hw/virtio/virtio.c:1524:12 +> > #3 0x560628e7844b in virtqueue_pop /home/alxndr/Development/qemu/hw/virtio/virtio.c:1693:16 +> > #4 0x560629829633 in virtio_gpu_handle_ctrl /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:878:15 +> > #5 0x560629829633 in virtio_gpu_ctrl_bh /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:893:5 +> > #6 0x56062a8f1c96 in aio_bh_poll /home/alxndr/Development/qemu/util/async.c:164:13 +> > #7 0x56062a887b9d in aio_dispatch /home/alxndr/Development/qemu/util/aio-posix.c:380:5 +> > #8 0x56062a8f6b1c in aio_ctx_dispatch /home/alxndr/Development/qemu/util/async.c:306:5 +> > #9 0x7f0d5e1cf9ed in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e9ed) +> > +> > +> > With -trace virtio\* -trace pci\* : +> > [I 1595480025.666147] OPENED +> > 31900@1595480025.706962:virtio_set_status vdev 0x633000019640 val 0 +> > 31900@1595480025.710297:virtio_set_status vdev 0x633000019640 val 0 +> > [R +0.046276] outl 0xcf8 0x80001018 +> > OK +> > [S +0.046313] OK +> > [R +0.046332] outl 0xcfc 0xe0800000 +> > 31900@1595480025.712490:pci_cfg_write virtio-vga 02:0 @0x18 <- 0xe0800000 +> > OK +> > [S +0.046356] OK +> > [R +0.046365] outl 0xcf8 0x80001020 +> > OK +> > [S +0.046370] OK +> > [R +0.046379] outl 0xcf8 0x80001004 +> > OK +> > [S +0.046383] OK +> > [R +0.046391] outw 0xcfc 0x7 +> > 31900@1595480025.712544:pci_cfg_write virtio-vga 02:0 @0x4 <- 0x7 +> > 31900@1595480025.712551:pci_update_mappings_add d=0x633000000800 00:02.0 2,0xe0800000+0x4000 +> > OK +> > [S +0.047572] OK +> > [R +0.047597] writeq 0xe0801024 0x10646c00776c6cff +> > OK +> > [S +0.047610] OK +> > [R +0.047619] writeq 0xe080102d 0xe0801000320000 +> > OK +> > [S +0.047627] OK +> > [R +0.047636] writeq 0xe0801015 0x12b2901ba000000 +> > OK +> > [S +0.047650] OK +> > [R +0.047660] write 0x10646c02 0x1 0x2c +> > OK +> > [S +0.047769] OK +> > [R +0.047782] write 0x999 0x1 0x25 +> > OK +> > [S +0.047907] OK +> > [R +0.047920] write 0x8 0x1 0x78 +> > OK +> > [S +0.047927] OK +> > [R +0.047935] write 0x2c7 0x1 0x32 +> > OK +> > [S +0.047941] OK +> > [R +0.047949] write 0x2cb 0x1 0xff +> > OK +> > [S +0.047954] OK +> > [R +0.047962] write 0x2cc 0x1 0x7e +> > OK +> > [S +0.047967] OK +> > [R +0.047975] writeq 0xe0803000 0xf2b8f0540ff83 +> > 31900@1595480025.714133:virtio_queue_notify vdev 0x633000019640 n 0 vq 0x7fe20b13d800 +> > OK +> > [S +0.047996] OK +> > 31900@1595480025.714386:virtio_notify vdev 0x633000019640 vq 0x7fe20b13d800 +> > 31900@1595480025.714406:virtio_gpu_features virgl 0 +> > 31900@1595480025.714413:virtio_notify vdev 0x633000019640 vq 0x7fe20b13d800 +> > 31900@1595480025.714421:virtio_set_status vdev 0x633000019640 val 0 +> > *CRASH* +> > +> > Please let me know if I can provide any further info. +> > -Alex +> > +> > To manage notifications about this bug go to: +> > https://bugs.launchpad.net/qemu/+bug/1888606/+subscriptions +> > +> + + + Hi, + +> > The ASAN trace: +> > ==29798==ERROR: AddressSanitizer: heap-use-after-free on address 0x60d0000050e8 at pc 0x560629814761 bp 0x7ffe916eb1e0 sp 0x7ffe916eb1d8 +> > READ of size 8 at 0x60d0000050e8 thread T0 +> > #0 0x560629814760 in virtio_gpu_ctrl_response /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:181:42 +> > #4 0x56062a8f1c96 in aio_bh_poll /home/alxndr/Development/qemu/util/async.c:164:13 + +> > #1 0x560629827730 in virtio_gpu_reset /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:1160:9 + +So it looks like the bottom half accesses stuff released by reset. + +Guess the reset should cancel any scheduled bh calls to avoid that ... + +Does the patch below help? + +thanks, + Gerd + +diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c +index 5f0dd7c15002..18f0011b5a0a 100644 +--- a/hw/display/virtio-gpu.c ++++ b/hw/display/virtio-gpu.c +@@ -1144,6 +1144,9 @@ static void virtio_gpu_reset(VirtIODevice *vdev) + struct virtio_gpu_simple_resource *res, *tmp; + struct virtio_gpu_ctrl_command *cmd; + ++ qemu_bh_cancel(g->ctrl_bh); ++ qemu_bh_cancel(g->cursor_bh); ++ + #ifdef CONFIG_VIRGL + if (g->parent_obj.use_virgl_renderer) { + virtio_gpu_virgl_reset(g); + + + +Hi Gerd, +Strange... After applying your patch, I re-ran the reproducer, but +I still see the same crash. +-Alex + +On 200803 0856, Gerd Hoffmann wrote: +> Hi, +> +> > > The ASAN trace: +> > > ==29798==ERROR: AddressSanitizer: heap-use-after-free on address 0x60d0000050e8 at pc 0x560629814761 bp 0x7ffe916eb1e0 sp 0x7ffe916eb1d8 +> > > READ of size 8 at 0x60d0000050e8 thread T0 +> > > #0 0x560629814760 in virtio_gpu_ctrl_response /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:181:42 +> > > #4 0x56062a8f1c96 in aio_bh_poll /home/alxndr/Development/qemu/util/async.c:164:13 +> +> > > #1 0x560629827730 in virtio_gpu_reset /home/alxndr/Development/qemu/hw/display/virtio-gpu.c:1160:9 +> +> So it looks like the bottom half accesses stuff released by reset. +> +> Guess the reset should cancel any scheduled bh calls to avoid that ... +> +> Does the patch below help? +> +> thanks, +> Gerd +> +> diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c +> index 5f0dd7c15002..18f0011b5a0a 100644 +> --- a/hw/display/virtio-gpu.c +> +++ b/hw/display/virtio-gpu.c +> @@ -1144,6 +1144,9 @@ static void virtio_gpu_reset(VirtIODevice *vdev) +> struct virtio_gpu_simple_resource *res, *tmp; +> struct virtio_gpu_ctrl_command *cmd; +> +> + qemu_bh_cancel(g->ctrl_bh); +> + qemu_bh_cancel(g->cursor_bh); +> + +> #ifdef CONFIG_VIRGL +> if (g->parent_obj.use_virgl_renderer) { +> virtio_gpu_virgl_reset(g); +> + + +I can reproduce this problem with QEMU v5.0, but with the current +version, it does not run into this problem anymore. Seems like this +problem got fixed in the course of time? Could you please check whether +you could still reproduce this? + + +OSS-Fuzz says it was fixed some months ago, and it has not found a reproducer since. + +Ok, thanks for checking, so let's mark this as fixed. + diff --git a/results/classifier/108/other/1888663 b/results/classifier/108/other/1888663 new file mode 100644 index 00000000..1e10d7d7 --- /dev/null +++ b/results/classifier/108/other/1888663 @@ -0,0 +1,39 @@ +other: 0.876 +performance: 0.721 +graphic: 0.692 +device: 0.677 +boot: 0.585 +semantic: 0.560 +PID: 0.440 +files: 0.398 +permissions: 0.304 +socket: 0.291 +network: 0.269 +debug: 0.240 +vnc: 0.197 +KVM: 0.018 + +msmouse not recognized in guest + +The msmouse option for emulating a serial mouse does not seem to work in a DOS guest. + +I'm on Windows 10 X64, I have tried launching qemu (commit d0cc248164961a7ba9d43806feffd76f9f6d7f41 but also way older) with: +./qemu-system-i386 -serial msmouse -fda mousetest.img +./qemu-system-i386 -chardev msmouse,id=msmouse -device isa-serial,chardev=msmouse -fda mousetest.img +./qemu-system-i386 -chardev msmouse,id=msmouse -device pci-serial,chardev=msmouse -chardev msmouse,id=msmouse -fda mousetest.img + +Then I boot FreeDOS (but regular DOS shows same behavior), start the CuteMouse driver and force the scan of a serial mouse with CTM /S. +The mouse is never found. With other drivers (in the attachment), the mouse is probably not found but the driver is installed anyway, but it does not work (there's a MOUSETST in the same floppy; it works iwth CTM and PS/2 mouse emulation). + +Using a serial port sniffer inside the guest, it would seem that data is indeed transmitted. Setting a few printf in msmouse.c also confirms that the mouse gets initilized and starts transmitting data. However, it does not work... + + + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/77 + + diff --git a/results/classifier/108/other/1888714 b/results/classifier/108/other/1888714 new file mode 100644 index 00000000..98545b9e --- /dev/null +++ b/results/classifier/108/other/1888714 @@ -0,0 +1,81 @@ +other: 0.935 +permissions: 0.881 +performance: 0.863 +graphic: 0.858 +debug: 0.848 +device: 0.841 +files: 0.834 +semantic: 0.829 +PID: 0.780 +vnc: 0.778 +network: 0.777 +KVM: 0.763 +boot: 0.759 +socket: 0.757 + +Memory Leak in hpet_timer results in unusable machine + +Fair warning: this might be specific to QTest (specifically its clock_step) command. This reproducer only works with -accel qtest. Build with --enable-sanitizers to exit once we hit 1G RSS. + +export ASAN_OPTIONS=hard_rss_limit_mb=1000 +cat << EOF | ./i386-softmmu/qemu-system-i386 -nographic \ +-nodefaults -qtest stdio -accel qtest +writeq 0xfed0000e 0x15151515151515f1 +clock_step +clock_step +clock_step +clock_step +writeq 0xfed00100 0x5e90c5be00ff5e9e +writeq 0xfed00109 0xffffe0ff5cfec0ff +clock_step +EOF + +On my machine it takes around 10 seconds to reach the RSS limit. + +Unfortunately, I can't find a way to tell ASAN to log each malloc to figure out whats going on, but running the original fuzzing test case with the libfuzzer -trace_malloc=2 flag, I found that the allocations happen here: + +MALLOC[130968] 0x60300069ac90 32 + #0 0x55fa3f615851 in __sanitizer_print_stack_trace (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-fuzz-i386+0x2683851) + #1 0x55fa3f55fe88 in fuzzer::PrintStackTrace() (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-fuzz-i386+0x25cde88) + #2 0x55fa3f5447d6 in fuzzer::MallocHook(void const volatile*, unsigned long) (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-fuzz-i386+0x25b27d6) + #3 0x55fa3f61bbb7 in __sanitizer::RunMallocHooks(void const*, unsigned long) (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-fuzz-i386+0x2689bb7) + #4 0x55fa3f596d75 in __asan::Allocator::Allocate(unsigned long, unsigned long, __sanitizer::BufferedStackTrace*, __asan::AllocType, bool) (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-fuzz-i386+0x2604d75) + #5 0x55fa3f596f7a in __asan::asan_calloc(unsigned long, unsigned long, __sanitizer::BufferedStackTrace*) (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-fuzz-i386+0x2604f7a) + #6 0x55fa3f60d173 in calloc (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-fuzz-i386+0x267b173) + #7 0x7fb300737548 in g_malloc0 (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x54548) + #8 0x55fa40157689 in async_run_on_cpu /home/alxndr/Development/qemu/cpus-common.c:163:10 + #9 0x55fa409fab83 in hpet_timer /home/alxndr/Development/qemu/hw/timer/hpet.c:376:9 + #10 0x55fa416a5751 in timerlist_run_timers /home/alxndr/Development/qemu/util/qemu-timer.c:572:9 + #11 0x55fa3fcfdac4 in qtest_clock_warp /home/alxndr/Development/qemu/softmmu/cpus.c:507:9 + #12 0x55fa3fd65c35 in qtest_process_command /home/alxndr/Development/qemu/softmmu/qtest.c:665:9 + #13 0x55fa3fd5e128 in qtest_process_inbuf /home/alxndr/Development/qemu/softmmu/qtest.c:710:9 + #14 0x55fa3fd5de67 in qtest_server_inproc_recv /home/alxndr/Development/qemu/softmmu/qtest.c:817:9 + #15 0x55fa4142b64b in qtest_sendf /home/alxndr/Development/qemu/tests/qtest/libqtest.c:424:5 + #16 0x55fa4142c482 in qtest_clock_step_next /home/alxndr/Development/qemu/tests/qtest/libqtest.c:864:5 + #17 0x55fa414b12d1 in general_fuzz /home/alxndr/Development/qemu/tests/qtest/fuzz/general_fuzz.c:581:17 + +It doesn't look like we ever exit out of the loop in timerlist_run_timers, ie timer_list->active_timers is always True. + + +Info From GDB: +#0 0x0000555558070d31 in address_space_stl_internal (as=0x55555f0e8f20 <address_space_memory>, addr=0x0, val=0x0, attrs=..., result=0x0, endian=DEVICE_LITTLE_ENDIAN) at /home/alxndr/Development/qemu/memory_ldst.inc.c:323 +#1 0x0000555558071339 in address_space_stl_le (as=0x55555f0e8f20 <address_space_memory>, addr=0x0, val=0x0, attrs=..., result=0x0) at /home/alxndr/Development/qemu/memory_ldst.inc.c:357 +#2 0x000055555a6a6f95 in update_irq (timer=0x61f0000005b8, set=0x1) at /home/alxndr/Development/qemu/hw/timer/hpet.c:210 +#3 0x000055555a6ae55f in hpet_timer (opaque=0x61f0000005b8) at /home/alxndr/Development/qemu/hw/timer/hpet.c:386 +#4 0x000055555c03d178 in timerlist_run_timers (timer_list=0x60b0000528f0) at /home/alxndr/Development/qemu/util/qemu-timer.c:572 +#5 0x000055555c03d6b5 in qemu_clock_run_timers (type=QEMU_CLOCK_VIRTUAL) at /home/alxndr/Development/qemu/util/qemu-timer.c:586 +#6 0x0000555558c3d0c4 in qtest_clock_warp (dest=0x3461864) at /home/alxndr/Development/qemu/softmmu/cpus.c:507 + + +-Alex + +Still reproduces with the current git version (commit 7fe7fae8b48e3f9c647) + +I moved this report over to QEMU's new bug tracker on gitlab.com. +Please continue with the discussion here: + +https://gitlab.com/qemu-project/qemu/-/issues/538 + +Thanks for moving it over! ... let's close this one here on Launchpad now. + + diff --git a/results/classifier/108/other/1888728 b/results/classifier/108/other/1888728 new file mode 100644 index 00000000..cb33c5a5 --- /dev/null +++ b/results/classifier/108/other/1888728 @@ -0,0 +1,49 @@ +performance: 0.688 +device: 0.688 +files: 0.668 +vnc: 0.644 +PID: 0.616 +debug: 0.599 +permissions: 0.569 +graphic: 0.566 +network: 0.558 +boot: 0.521 +socket: 0.486 +semantic: 0.446 +other: 0.436 +KVM: 0.381 + +Bare chroot in linux-user fails with pgb_reserved_va: Assertion `guest_base != 0' failed. + +Trying to run a bare chroot with no additional bind mounts fails on git master (8ffa52c20d5693d454f65f2024a1494edfea65d4) with: + +root@nofan:~/qemu> chroot /local_scratch/sid-m68k-sbuild/ +qemu-m68k-static: /root/qemu/linux-user/elfload.c:2315: pgb_reserved_va: Assertion `guest_base != 0' failed. +Aborted +root@nofan:~/qemu> + +The problem can be worked around by bind-mounting /proc from the host system into the target chroot: + +root@nofan:~/qemu> mount -o bind /proc/ /local_scratch/sid-m68k-sbuild/proc/ +root@nofan:~/qemu> chroot /local_scratch/sid-m68k-sbuild/ +bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) +(sid-m68k-sbuild)root@nofan:/# + +Host system is an up-to-date Debian unstable (2020-07-23). + +I have not been able to bisect the issue yet since there is another annoying linux-user bug (virtual memory exhaustion) that was somewhere introduced and fixed between v5.0.0 and HEAD and overshadows the original Assertion failure bug. + +Could you point me to a tar.gz with your rootfs? + +Here you go: https://people.debian.org/~glaubitz/sid-m68k-sbuild.tgz + +Thanks for looking into it! + +For the record, reproducing this problem requires root, thus +trying to reproduce it outside of a chroot is non-obvious. + +https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg07224.html + +Fixed here: +https://github.com/qemu/qemu/commit/c9f8066697e0d3e77b97f6df423e9d6540b693be + diff --git a/results/classifier/108/other/1888918 b/results/classifier/108/other/1888918 new file mode 100644 index 00000000..f911e456 --- /dev/null +++ b/results/classifier/108/other/1888918 @@ -0,0 +1,186 @@ +other: 0.927 +permissions: 0.890 +debug: 0.882 +vnc: 0.881 +graphic: 0.880 +semantic: 0.870 +performance: 0.867 +KVM: 0.866 +socket: 0.855 +PID: 0.843 +device: 0.828 +files: 0.804 +boot: 0.782 +network: 0.782 + +qemu-system-ppc: Floating point instructions do not properly generate the SPE/Embedded Floating-Point Unavailable interrupt + +When emulating certain floating point instructions or vector instructions on PowerPC machines, QEMU does not properly generate the SPE/Embedded Floating-Point Unavailable interrupt. + +As described in the Signal Processing Engine (SPE) Programming Environments Manual, Rev. 0, available at https://www.nxp.com/docs/en/reference-manual/SPEPEM.pdf: + +> An SPE/embedded floating-point unavailable exception occurs on an attempt to execute any of the +> following instructions and MSR[SPV] is not set: +> * SPE instruction (except brinc) +> * An embedded scalar double-precision instruction +> * A vector single-precision floating-point instructions +> It is not used by embedded scalar single-precision floating-point instructions + +This behavior was partially reported in Bug #1611394, however the issue is larger than what is described in that bug. As mentioned in that bug, some single-precision instructions generate the exception (while they should not), which is incorrect but does not typically produce an incorrect output. What is more of an issue is that several double-precision and vector instructions do not generate the exception (while they should), and this break support for lazy FPU/vector context switching in Linux (for example). + +The upper 32-bit of the double-precision/vector registers (which are in fact hidden in the general purpose registers) is not properly saved/restored, and this causes arithmetic errors. This was observed very frequently on a commercial project that does a lot of double-precision computations. The application works perfectly fine on an MPC8548 CPU, but fails often with QEMU. + +The issue can be reproduced using the attached Linux program "spe-bug.c". This program properly prints the number 42 (as the result of some very simple double-precision computation) on real PowerPC hardware, but prints an incorrect result (typically 0) on QEMU. + +This issue was first discovered in an older version of QEMU, but is also reproduced in the latest: + +# git rev-parse HEAD +7adfbea8fd1efce36019a0c2f198ca73be9d3f18 +# ppc-softmmu/qemu-system-ppc --version +QEMU emulator version 5.0.91 (v5.1.0-rc1-28-g7adfbea8fd-dirty) +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + +Upon further analysis a total of 39 instructions are misbehaving: + +efsabs: raised: 1, expected: 0 +efsnabs: raised: 1, expected: 0 +efsneg: raised: 1, expected: 0 +efdcfs: raised: 0, expected: 1 +efdcfsf: raised: 0, expected: 1 +efdcfsi: raised: 0, expected: 1 +efdcfuf: raised: 0, expected: 1 +efdcfui: raised: 0, expected: 1 +efdctsf: raised: 0, expected: 1 +efdctsi: raised: 0, expected: 1 +efdctsiz: raised: 0, expected: 1 +efdctuf: raised: 0, expected: 1 +efdctui: raised: 0, expected: 1 +efdctuiz: raised: 0, expected: 1 +efscfd: raised: 0, expected: 1 +evfscfsf: raised: 0, expected: 1 +evfscfsi: raised: 0, expected: 1 +evfscfuf: raised: 0, expected: 1 +evfscfui: raised: 0, expected: 1 +evfsctsf: raised: 0, expected: 1 +evfsctsi: raised: 0, expected: 1 +evfsctsiz: raised: 0, expected: 1 +evfsctuf: raised: 0, expected: 1 +evfsctui: raised: 0, expected: 1 +evfsctuiz: raised: 0, expected: 1 +brinc: raised: 0, expected: 1 +efsadd: raised: 1, expected: 0 +efsdiv: raised: 1, expected: 0 +efsmul: raised: 1, expected: 0 +efssub: raised: 1, expected: 0 +evsplatfi: raised: 0, expected: 1 +evsplati: raised: 0, expected: 1 +efscmpeq: raised: 1, expected: 0 +efscmpgt: raised: 1, expected: 0 +efscmplt: raised: 1, expected: 0 +efststeq: raised: 1, expected: 0 +efststgt: raised: 1, expected: 0 +efststlt: raised: 1, expected: 0 +evsel: raised: 0, expected: 1 + +When "raised" is 0 and "expected" is 1, this means that the SPE/Embedded Floating-Point Unavailable interrupt was not generated while it should have. +When "raised" is 1 and "expected" is 0, this means that the SPE/Embedded Floating-Point Unavailable interrupt was generated while it should not have (Bug #1611394). + +A comprehensive program testing all the instructions listed in the Signal Processing Engine (SPE) Programming Environments Manual, Rev. 0 is posted in the comments of this ticket, and can be used to reproduce the issue, and validate the future fix. + + + +Attaching the test program mentioned in the description. This program (a kernel module, in fact) can be loaded on a Linux system both in QEMU or on real hardware. + +In the next comments, I will attach the detailed output of the test program. + +Attaching the output of the test module (above) when run on a real MPC8548. This is to establish a baseline validating which instructions shall or shall not generate the SPE/Embedded Floating-Point Unavailable interrupt. + +Note that on the MPC8548, it is observed that the "brinc" instruction does generate the interrupt, which contradicts section 4.2.3 SPE/Embedded Floating-Point Unavailable Interrupt of the Signal Processing Engine (SPE) Programming Environments Manual, Rev. 0 (see the quote in the description). The test program was modified to pass 100% on real hardware, hence claiming that "brinc" shall generate the interrupt. + +Attaching the output of the test module run on QEMU. As shown in the description, 39 instructions do not comply with the rule described in the Signal Processing Engine (SPE) Programming Environments Manual, Rev. 0. + +QEMU was run as follows: + +# qemu/ppc-softmmu/qemu-system-ppc -nographic -machine mpc8544ds -kernel buildroot/output/images/uImage -hda buildroot/output/images/rootfs.cpio -append "root=/dev/sda rw single" + +The Linux image is built using buildroot, and the selected configuration is qemu_ppc_mpc8544ds_defconfig with some very mild changes to setup an overlay and initramfs. + +Then, the module is loaded, output can be observed directly in the console, or using dmesg: + +# insmod spe-test.ko + + +I have already written a patch for this issue, that I will be submitting to the community in the next few days. + + +> Note that on the MPC8548, it is observed that the "brinc" +> instruction does generate the interrupt, which contradicts +> section 4.2.3 SPE/Embedded Floating-Point Unavailable Interrupt +> of the Signal Processing Engine (SPE) Programming Environments +> Manual, Rev. 0 (see the quote in the description). The test +> program was modified to pass 100% on real hardware, hence +> claiming that "brinc" shall generate the interrupt. + +I have actually dug up some more on this and changed my mind. There are more references in the PowerPC documentation indicating that "brinc" shall NOT generate the interrupt. + +In the EREF: A Programmer’s Reference Manual for Freescale Power Architecture Processors, Rev. 1 (EIS 2.1), Table 4-22. MSR Field Descriptions clearly states that when SPV==0: + +> The processor cannot execute any category SPE, SP.FD, or SP.FV +> instructions except for the brinc instruction. + +The patch that I am submitting to fix this bug will leave the behavior of "brinc" unchanged (ie: to not generate the interrupt). + + +Testing performed on the patch sent to the mailing list: + +1) make check + +2) Run the "spe-bug.c" userspace program, observed the correct result: + +# qemu/ppc-softmmu/qemu-system-ppc -nographic -machine mpc8544ds -kernel buildroot/output/images/uImage -hda buildroot/output/images/rootfs.cpio -append "root=/dev/sda rw single" +[...] +Run /init as init process +# ./spe-bug +42.000000 +# + +This used to return 0.000000 without the fix. + +3) Run the "spe-test" test module, and observed the correct result: + +# qemu/ppc-softmmu/qemu-system-ppc -nographic -machine mpc8544ds -kernel buildroot/output/images/uImage -hda buildroot/output/images/rootfs.cpio -append "root=/dev/sda rw single" +[...] +Run /init as init process +# insmod spe-test.ko +spe_test: loading out-of-tree module taints kernel. +Begin testing... +Testing efdabs +SPE used in kernel (task=(ptrval), pc=c9042048) +[...] +No errors. +End testing. + +This used to count 39 errors. Attached the full output as well. + +Note that per my previous comment, I have modified the "spe-test" code to expect that the "brinc" instruction does not generate the interrupt, using this diff from the previously attached "spe-test" source code: + +--- spe-test.c.orig 2020-07-25 12:22:23.628315553 -0700 ++++ spe-test.c 2020-07-24 23:12:27.508234566 -0700 +@@ -84,7 +84,7 @@ + TEST_INSN_RD_RA (evfsctuf, 1) \ + TEST_INSN_RD_RA (evfsctui, 1) \ + TEST_INSN_RD_RA (evfsctuiz, 1) \ +- TEST_INSN_RD_RA_RB (brinc, 1) \ ++ TEST_INSN_RD_RA_RB (brinc, 0) \ + TEST_INSN_RD_RA_RB (efdadd, 1) \ + TEST_INSN_RD_RA_RB (efddiv, 1) \ + TEST_INSN_RD_RA_RB (efdmul, 1) \ + + +Assuming that this commit: +https://gitlab.com/qemu-project/qemu/-/commit/8dcdb535d7cc4ba6270bb756e12e1d323254ed4e + +is sufficient to mark this bug as Fix Committed. Please re-open if I am mistaken. + +Released with QEMU v5.2.0. + diff --git a/results/classifier/108/other/1888923 b/results/classifier/108/other/1888923 new file mode 100644 index 00000000..27a7dbc5 --- /dev/null +++ b/results/classifier/108/other/1888923 @@ -0,0 +1,403 @@ +permissions: 0.757 +other: 0.751 +graphic: 0.736 +semantic: 0.729 +debug: 0.701 +performance: 0.679 +PID: 0.649 +device: 0.634 +KVM: 0.623 +boot: 0.600 +vnc: 0.595 +network: 0.579 +socket: 0.573 +files: 0.475 + +Configured Memory access latency and bandwidth not taking effect + +I was trying to configure latencies and bandwidths between nodes in a NUMA emulation using QEMU 5.0.0. + +Host : Ubuntu 20.04 64 bit +Guest : Ubuntu 18.04 64 bit + +The machine configured has 2 nodes. Each node has 2 CPUs and has been allocated 3GB of memory. The memory access latencies and bandwidths for a local access (i.e from initiator 0 to target 0, and from initiator 1 to target 1) are set as 40ns and 10GB/s respectively. The memory access latencies and bandwidths for a remote access (i.e from initiator 1 to target 0, and from initiator 0 to target 1) are set as 80ns and 5GB/s respectively. + +The command line launch is as follows. + +sudo x86_64-softmmu/qemu-system-x86_64 \ +-machine hmat=on \ +-boot c \ +-enable-kvm \ +-m 6G,slots=2,maxmem=7G \ +-object memory-backend-ram,size=3G,id=m0 \ +-object memory-backend-ram,size=3G,id=m1 \ +-numa node,nodeid=0,memdev=m0 \ +-numa node,nodeid=1,memdev=m1 \ +-smp 4,sockets=4,maxcpus=4 \ +-numa cpu,node-id=0,socket-id=0 \ +-numa cpu,node-id=0,socket-id=1 \ +-numa cpu,node-id=1,socket-id=2 \ +-numa cpu,node-id=1,socket-id=3 \ +-numa dist,src=0,dst=1,val=20 \ +-net nic \ +-net user \ +-hda testing.img \ +-numa hmat-lb,initiator=0,target=0,hierarchy=memory,data-type=access-latency,latency=40 \ +-numa hmat-lb,initiator=0,target=0,hierarchy=memory,data-type=access-bandwidth,bandwidth=10G \ +-numa hmat-lb,initiator=0,target=1,hierarchy=memory,data-type=access-latency,latency=80 \ +-numa hmat-lb,initiator=0,target=1,hierarchy=memory,data-type=access-bandwidth,bandwidth=5G \ +-numa hmat-lb,initiator=1,target=0,hierarchy=memory,data-type=access-latency,latency=80 \ +-numa hmat-lb,initiator=1,target=0,hierarchy=memory,data-type=access-bandwidth,bandwidth=5G \ +-numa hmat-lb,initiator=1,target=1,hierarchy=memory,data-type=access-latency,latency=40 \ +-numa hmat-lb,initiator=1,target=1,hierarchy=memory,data-type=access-bandwidth,bandwidth=10G \ + +Then the latencies and bandwidths between the nodes were tested using the Intel Memory Latency Checker v3.9 (https://software.intel.com/content/www/us/en/develop/articles/intelr-memory-latency-checker.html). But the obtained results did not match the configuration. The following are the results obtained. + +Latency_matrix with idle latencies (in ns) + +Numa +Node 0 1 +0 36.2 36.4 +1 34.9 35.4 + +Bandwidth_matrix with memory bandwidths (in MB/s) + +Numa +Node 0 1 +0 15167.1 15308.9 +1 15226.0 15234.0 + +A test was also conducted with the tool “lat_mem_rd” from lmbench to measure the memory read latencies. This also gave results which did not match the config. + +Any information on why the config latency and bandwidth values are not applied, would be appreciated. + +On Sat, 25 Jul 2020 07:26:38 -0000 +Vishnu Dixit <email address hidden> wrote: + +> Public bug reported: +> +> I was trying to configure latencies and bandwidths between nodes in a +> NUMA emulation using QEMU 5.0.0. +> +> Host : Ubuntu 20.04 64 bit +> Guest : Ubuntu 18.04 64 bit +> +> The machine configured has 2 nodes. Each node has 2 CPUs and has been +> allocated 3GB of memory. The memory access latencies and bandwidths for +> a local access (i.e from initiator 0 to target 0, and from initiator 1 +> to target 1) are set as 40ns and 10GB/s respectively. The memory access +> latencies and bandwidths for a remote access (i.e from initiator 1 to +> target 0, and from initiator 0 to target 1) are set as 80ns and 5GB/s +> respectively. +> +> The command line launch is as follows. +> +> sudo x86_64-softmmu/qemu-system-x86_64 \ +> -machine hmat=on \ +> -boot c \ +> -enable-kvm \ +> -m 6G,slots=2,maxmem=7G \ +> -object memory-backend-ram,size=3G,id=m0 \ +> -object memory-backend-ram,size=3G,id=m1 \ +> -numa node,nodeid=0,memdev=m0 \ +> -numa node,nodeid=1,memdev=m1 \ +> -smp 4,sockets=4,maxcpus=4 \ +> -numa cpu,node-id=0,socket-id=0 \ +> -numa cpu,node-id=0,socket-id=1 \ +> -numa cpu,node-id=1,socket-id=2 \ +> -numa cpu,node-id=1,socket-id=3 \ +> -numa dist,src=0,dst=1,val=20 \ +> -net nic \ +> -net user \ +> -hda testing.img \ +> -numa hmat-lb,initiator=0,target=0,hierarchy=memory,data-type=access-latency,latency=40 \ +> -numa hmat-lb,initiator=0,target=0,hierarchy=memory,data-type=access-bandwidth,bandwidth=10G \ +> -numa hmat-lb,initiator=0,target=1,hierarchy=memory,data-type=access-latency,latency=80 \ +> -numa hmat-lb,initiator=0,target=1,hierarchy=memory,data-type=access-bandwidth,bandwidth=5G \ +> -numa hmat-lb,initiator=1,target=0,hierarchy=memory,data-type=access-latency,latency=80 \ +> -numa hmat-lb,initiator=1,target=0,hierarchy=memory,data-type=access-bandwidth,bandwidth=5G \ +> -numa hmat-lb,initiator=1,target=1,hierarchy=memory,data-type=access-latency,latency=40 \ +> -numa hmat-lb,initiator=1,target=1,hierarchy=memory,data-type=access-bandwidth,bandwidth=10G \ +> +> Then the latencies and bandwidths between the nodes were tested using +> the Intel Memory Latency Checker v3.9 +> (https://software.intel.com/content/www/us/en/develop/articles/intelr- +> memory-latency-checker.html). But the obtained results did not match the +> configuration. The following are the results obtained. +> +> Latency_matrix with idle latencies (in ns) +> +> Numa Node +> . .0. . .1. +> 0 36.2 36.4 +> 1 34.9 35.4 +> +> Bandwidth_matrix with memory bandwidths (in MB/s) +> +> Numa Node +> . . .0. . . .1. +> 0 15167.1 15308.9 +> 1 15226.0 15234.0 +> +> A test was also conducted with the tool “lat_mem_rd” from lmbench to +> measure the memory read latencies. This also gave results which did not +> match the config. +> +> Any information on why the config latency and bandwidth values are not +> applied, would be appreciated. + +There is no information about host hardware, so I'd onldy hazard a guess +that host is non NUMA machine so all guest RAM and CPUs are in the same +latency domain, so that's why you are seeing pretty much the same timings. + +QEMU nor KMV do not simullate HW latencies at all, all that is configured +with '-numa hmat-lb' is intended for guest OS consumption as a hint for +smarter memory allocation and it's on to user to pin CPUs and RAM to +concrete host NUMA nodes and use host's values in '-numa hmat-lb' to +actually get performance benefits from it on 'NUMA' machine. +On non NUMA host it's rather pointless except of the cases where one +needs to fake NUMA config (like testing some aspects of NUMA related code +in guest OS). + +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> +> ** Tags: bandwidth hmat hmat-lb latency +> +> ** Description changed: +> +> I was trying to configure latencies and bandwidths between nodes in a +> NUMA emulation using QEMU 5.0.0. +> +> Host : Ubuntu 20.04 64 bit +> Guest : Ubuntu 18.04 64 bit +> - +> - The machine configured has 2 nodes. Each node has 2 CPUs and has been allocated 3GB of memory. The memory access latencies and bandwidths for a local access (i.e from initiator 0 to target 0, and from initiator 1 to target 1) are set as 40ns and 10GB/s respectively. The memory access latencies and bandwidths for a remote access (i.e from initiator 1 to target 0, and from initiator 0 to target 1) are set as 80ns and 5GB/s respectively. +> + +> + The machine configured has 2 nodes. Each node has 2 CPUs and has been +> + allocated 3GB of memory. The memory access latencies and bandwidths for +> + a local access (i.e from initiator 0 to target 0, and from initiator 1 +> + to target 1) are set as 40ns and 10GB/s respectively. The memory access +> + latencies and bandwidths for a remote access (i.e from initiator 1 to +> + target 0, and from initiator 0 to target 1) are set as 80ns and 5GB/s +> + respectively. +> +> The command line launch is as follows. +> +> sudo x86_64-softmmu/qemu-system-x86_64 \ +> -machine hmat=on \ +> -boot c \ +> -enable-kvm \ +> -m 6G,slots=2,maxmem=7G \ +> -object memory-backend-ram,size=3G,id=m0 \ +> -object memory-backend-ram,size=3G,id=m1 \ +> -numa node,nodeid=0,memdev=m0 \ +> -numa node,nodeid=1,memdev=m1 \ +> -smp 4,sockets=4,maxcpus=4 \ +> -numa cpu,node-id=0,socket-id=0 \ +> -numa cpu,node-id=0,socket-id=1 \ +> -numa cpu,node-id=1,socket-id=2 \ +> -numa cpu,node-id=1,socket-id=3 \ +> -numa dist,src=0,dst=1,val=20 \ +> -net nic \ +> -net user \ +> -hda testing.img \ +> -numa hmat-lb,initiator=0,target=0,hierarchy=memory,data-type=access-latency,latency=40 \ +> -numa hmat-lb,initiator=0,target=0,hierarchy=memory,data-type=access-bandwidth,bandwidth=10G \ +> -numa hmat-lb,initiator=0,target=1,hierarchy=memory,data-type=access-latency,latency=80 \ +> -numa hmat-lb,initiator=0,target=1,hierarchy=memory,data-type=access-bandwidth,bandwidth=5G \ +> -numa hmat-lb,initiator=1,target=0,hierarchy=memory,data-type=access-latency,latency=80 \ +> -numa hmat-lb,initiator=1,target=0,hierarchy=memory,data-type=access-bandwidth,bandwidth=5G \ +> -numa hmat-lb,initiator=1,target=1,hierarchy=memory,data-type=access-latency,latency=40 \ +> -numa hmat-lb,initiator=1,target=1,hierarchy=memory,data-type=access-bandwidth,bandwidth=10G \ +> +> Then the latencies and bandwidths between the nodes were tested using +> the Intel Memory Latency Checker v3.9 +> (https://software.intel.com/content/www/us/en/develop/articles/intelr- +> memory-latency-checker.html). But the obtained results did not match the +> configuration. The following are the results obtained. +> +> Latency_matrix with idle latencies (in ns) +> +> Numa +> - Node 0 1 +> + lat node0 node1 +> 0 36.2 36.4 +> 1 34.9 35.4 +> +> Bandwidth_matrix with memory bandwidths (in MB/s) +> +> - Numa +> - Node 0 1 +> + Numa Node +> + bw node0 .bw node1 +> 0 15167.1 15308.9 +> 1 15226.0 15234.0 +> +> A test was also conducted with the tool “lat_mem_rd” from lmbench to +> measure the memory read latencies. This also gave results which did not +> match the config. +> +> Any information on why the config latency and bandwidth values are not +> applied, would be appreciated. +> +> ** Description changed: +> +> I was trying to configure latencies and bandwidths between nodes in a +> NUMA emulation using QEMU 5.0.0. +> +> Host : Ubuntu 20.04 64 bit +> Guest : Ubuntu 18.04 64 bit +> +> The machine configured has 2 nodes. Each node has 2 CPUs and has been +> allocated 3GB of memory. The memory access latencies and bandwidths for +> a local access (i.e from initiator 0 to target 0, and from initiator 1 +> to target 1) are set as 40ns and 10GB/s respectively. The memory access +> latencies and bandwidths for a remote access (i.e from initiator 1 to +> target 0, and from initiator 0 to target 1) are set as 80ns and 5GB/s +> respectively. +> +> The command line launch is as follows. +> +> sudo x86_64-softmmu/qemu-system-x86_64 \ +> -machine hmat=on \ +> -boot c \ +> -enable-kvm \ +> -m 6G,slots=2,maxmem=7G \ +> -object memory-backend-ram,size=3G,id=m0 \ +> -object memory-backend-ram,size=3G,id=m1 \ +> -numa node,nodeid=0,memdev=m0 \ +> -numa node,nodeid=1,memdev=m1 \ +> -smp 4,sockets=4,maxcpus=4 \ +> -numa cpu,node-id=0,socket-id=0 \ +> -numa cpu,node-id=0,socket-id=1 \ +> -numa cpu,node-id=1,socket-id=2 \ +> -numa cpu,node-id=1,socket-id=3 \ +> -numa dist,src=0,dst=1,val=20 \ +> -net nic \ +> -net user \ +> -hda testing.img \ +> -numa hmat-lb,initiator=0,target=0,hierarchy=memory,data-type=access-latency,latency=40 \ +> -numa hmat-lb,initiator=0,target=0,hierarchy=memory,data-type=access-bandwidth,bandwidth=10G \ +> -numa hmat-lb,initiator=0,target=1,hierarchy=memory,data-type=access-latency,latency=80 \ +> -numa hmat-lb,initiator=0,target=1,hierarchy=memory,data-type=access-bandwidth,bandwidth=5G \ +> -numa hmat-lb,initiator=1,target=0,hierarchy=memory,data-type=access-latency,latency=80 \ +> -numa hmat-lb,initiator=1,target=0,hierarchy=memory,data-type=access-bandwidth,bandwidth=5G \ +> -numa hmat-lb,initiator=1,target=1,hierarchy=memory,data-type=access-latency,latency=40 \ +> -numa hmat-lb,initiator=1,target=1,hierarchy=memory,data-type=access-bandwidth,bandwidth=10G \ +> +> Then the latencies and bandwidths between the nodes were tested using +> the Intel Memory Latency Checker v3.9 +> (https://software.intel.com/content/www/us/en/develop/articles/intelr- +> memory-latency-checker.html). But the obtained results did not match the +> configuration. The following are the results obtained. +> +> Latency_matrix with idle latencies (in ns) +> +> - Numa +> + Numa Node +> lat node0 node1 +> 0 36.2 36.4 +> 1 34.9 35.4 +> +> Bandwidth_matrix with memory bandwidths (in MB/s) +> +> - Numa Node +> - bw node0 .bw node1 +> + Numa Node +> + bw node0 bw node1 +> 0 15167.1 15308.9 +> 1 15226.0 15234.0 +> +> A test was also conducted with the tool “lat_mem_rd” from lmbench to +> measure the memory read latencies. This also gave results which did not +> match the config. +> +> Any information on why the config latency and bandwidth values are not +> applied, would be appreciated. +> +> ** Description changed: +> +> I was trying to configure latencies and bandwidths between nodes in a +> NUMA emulation using QEMU 5.0.0. +> +> Host : Ubuntu 20.04 64 bit +> Guest : Ubuntu 18.04 64 bit +> +> The machine configured has 2 nodes. Each node has 2 CPUs and has been +> allocated 3GB of memory. The memory access latencies and bandwidths for +> a local access (i.e from initiator 0 to target 0, and from initiator 1 +> to target 1) are set as 40ns and 10GB/s respectively. The memory access +> latencies and bandwidths for a remote access (i.e from initiator 1 to +> target 0, and from initiator 0 to target 1) are set as 80ns and 5GB/s +> respectively. +> +> The command line launch is as follows. +> +> sudo x86_64-softmmu/qemu-system-x86_64 \ +> -machine hmat=on \ +> -boot c \ +> -enable-kvm \ +> -m 6G,slots=2,maxmem=7G \ +> -object memory-backend-ram,size=3G,id=m0 \ +> -object memory-backend-ram,size=3G,id=m1 \ +> -numa node,nodeid=0,memdev=m0 \ +> -numa node,nodeid=1,memdev=m1 \ +> -smp 4,sockets=4,maxcpus=4 \ +> -numa cpu,node-id=0,socket-id=0 \ +> -numa cpu,node-id=0,socket-id=1 \ +> -numa cpu,node-id=1,socket-id=2 \ +> -numa cpu,node-id=1,socket-id=3 \ +> -numa dist,src=0,dst=1,val=20 \ +> -net nic \ +> -net user \ +> -hda testing.img \ +> -numa hmat-lb,initiator=0,target=0,hierarchy=memory,data-type=access-latency,latency=40 \ +> -numa hmat-lb,initiator=0,target=0,hierarchy=memory,data-type=access-bandwidth,bandwidth=10G \ +> -numa hmat-lb,initiator=0,target=1,hierarchy=memory,data-type=access-latency,latency=80 \ +> -numa hmat-lb,initiator=0,target=1,hierarchy=memory,data-type=access-bandwidth,bandwidth=5G \ +> -numa hmat-lb,initiator=1,target=0,hierarchy=memory,data-type=access-latency,latency=80 \ +> -numa hmat-lb,initiator=1,target=0,hierarchy=memory,data-type=access-bandwidth,bandwidth=5G \ +> -numa hmat-lb,initiator=1,target=1,hierarchy=memory,data-type=access-latency,latency=40 \ +> -numa hmat-lb,initiator=1,target=1,hierarchy=memory,data-type=access-bandwidth,bandwidth=10G \ +> +> Then the latencies and bandwidths between the nodes were tested using +> the Intel Memory Latency Checker v3.9 +> (https://software.intel.com/content/www/us/en/develop/articles/intelr- +> memory-latency-checker.html). But the obtained results did not match the +> configuration. The following are the results obtained. +> +> Latency_matrix with idle latencies (in ns) +> +> Numa Node +> - lat node0 node1 +> - 0 36.2 36.4 +> - 1 34.9 35.4 +> + . .0. . .1. +> + 0 36.2 36.4 +> + 1 34.9 35.4 +> +> Bandwidth_matrix with memory bandwidths (in MB/s) +> +> Numa Node +> - bw node0 bw node1 +> + . . .0. . . .1. +> 0 15167.1 15308.9 +> 1 15226.0 15234.0 +> +> A test was also conducted with the tool “lat_mem_rd” from lmbench to +> measure the memory read latencies. This also gave results which did not +> match the config. +> +> Any information on why the config latency and bandwidth values are not +> applied, would be appreciated. +> + + + +It indeed was a non NUMA machine + + diff --git a/results/classifier/108/other/1888964 b/results/classifier/108/other/1888964 new file mode 100644 index 00000000..c0d1ec08 --- /dev/null +++ b/results/classifier/108/other/1888964 @@ -0,0 +1,87 @@ +semantic: 0.875 +graphic: 0.867 +other: 0.846 +permissions: 0.842 +performance: 0.810 +debug: 0.726 +boot: 0.724 +PID: 0.648 +device: 0.640 +files: 0.561 +network: 0.486 +socket: 0.457 +KVM: 0.380 +vnc: 0.341 + +Segfault using GTK display with dmabuf (iGVT-g) on Wayland + +When using... + a) Intel virtualized graphics (iGVT-g) with dmabuf output + b) QEMU's GTK display with GL output enabled (-display gtk,gl=on) + c) A Wayland compositor (Sway in my case) +a segfault occurs at some point on boot (I guess as soon as the guest starts using the virtual graphics card?) + +The origin is the function dpy_gl_scanout_dmabuf in ui/console.c, where it calls + con->gl->ops->dpy_gl_scanout_dmabuf(con->gl, dmabuf); +However, the ops field (struct DisplayChangeListenerOps) does not have dpy_gl_scanout_dmabuf set because it is set to dcl_gl_area_ops which does not have dpy_gl_scanout_dmabuf set. +Only dcl_egl_ops has dpy_gl_scanout_dmabuf set. +Currently, the GTK display uses EGL on X11 displays, but GtkGLArea on Wayland. This can be observed in early_gtk_display_init() in ui/gtk.c, where it says (simplified code): + +if (opts->has_gl && opts->gl != DISPLAYGL_MODE_OFF) { + if (GDK_IS_WAYLAND_DISPLAY(gdk_display_get_default())) { + gtk_use_gl_area = true; + gtk_gl_area_init(); + } else { + DisplayGLMode mode = opts->has_gl ? opts->gl : DISPLAYGL_MODE_ON; + gtk_egl_init(mode); + } +} + +To reproduce the findings above, add this assertion to dpy_gl_scanout_dmabuf: + assert(con->gl->ops->dpy_gl_scanout_dmabuf); +This will make the segfault turn into an assertion failure. + +A workaround is to force QEMU to use GDK's X11 backend (using GDK_BACKEND=x11). + +Note: This might be a duplicate of 1775011, however the information provided in that bug report is not sufficient to make the assertion. + +QEMU version: b0ce3f021e0157e9a5ab836cb162c48caac132e1 (from Git master branch) +OS: Arch Linux, Kernel Version 5.17.0-1 + +Relevant flags of the QEMU invocation: +qemu-system-x86_64 \ + -vga none \ + -device vfio-pci-nohotplug,sysfsdev="$GVT_DEV",romfile="${ROMFILE}",display=on,x-igd-opregion=on,ramfb=on \ + -display gtk,gl=on + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system (but you won't be the reporter of the bug +in the new system and thus won't get notified on changes anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1889033 b/results/classifier/108/other/1889033 new file mode 100644 index 00000000..ea0c1871 --- /dev/null +++ b/results/classifier/108/other/1889033 @@ -0,0 +1,146 @@ +other: 0.905 +debug: 0.889 +device: 0.869 +permissions: 0.858 +performance: 0.843 +graphic: 0.831 +KVM: 0.821 +PID: 0.817 +files: 0.815 +semantic: 0.815 +network: 0.795 +socket: 0.793 +vnc: 0.743 +boot: 0.730 + +qemu-img permission denied on vmdk creation on CIFS share + + +- on a CIFS mount qemu-img claims not to have permissions to write into a file. +- VMDK sparse file creation succeeds +- VMDK Flat file creation create the flat-file, but fails to write the description-file +- VMDK flat file creation succeeds on native linux mount such as ~/tmp or /tmp +- same effect as root or non-root +- same effect with selinux setenforce 0 + +a) I would have expected that the monolithic flat would have created only one large file just like sparse, but it seems to create a description file, in addition to the storing file. +b) I am aware that qemu-img may have problem opening very large files on CIFS, however, this file is not very large + +Windows-10 latest updated 2004 19041.388 +Linux VM, Fedora-32 in Virtualbox 6.1.12 +# rpm -qa | grep qemu-img +qemu-img-4.2.0-7.fc32.x86_64 + +mount options: +mount -t cifs //10.x,x,x/$shname /mnt/hshare -o defaults,username=gana,rw,uid=1000,gid=1000,vers=3.0 + +[root@fedora ~]# cd /mnt/hshare/some/folder/createvmdk/ +[root@fedora createvmdk]# qemu-img create -f vmdk test1.vmdk 100M -o subformat=monolithicFlat +Formatting 'test1.vmdk', fmt=vmdk size=104857600 compat6=off hwversion=undefined subformat=monolithicFlat +qemu-img: test1.vmdk: Could not write description: Permission denied +[root@fedora createvmdk]# ls -l test1*.* +-rwxr-xr-x. 1 gana gana 104857600 Jul 26 23:02 test1-flat.vmdk +-rwxr-xr-x. 1 gana gana 0 Jul 26 23:02 test1.vmdk +[root@fedora createvmdk]# du -k test1*.* +0 test1-flat.vmdk +0 test1.vmdk +# (doesn't seem to be really flat) + +creation in /tmp works +# cd /tmp +[root@fedora tmp]# qemu-img create -f vmdk test1.vmdk 100M -o subformat=monolithicFlat +Formatting 'test1.vmdk', fmt=vmdk size=104857600 compat6=off hwversion=undefined subformat=monolithicFlat +[root@fedora tmp]# ls -l /tmp/test1*.* +-rw-r--r--. 1 root root 104857600 Jul 26 22:43 /tmp/test1-flat.vmdk +-rw-r--r--. 1 root root 313 Jul 26 22:43 /tmp/test1.vmdk +[root@fedora createvmdk]# du -k /tmp/test1*.* +4 /tmp/test1-flat.vmdk +4 /tmp/test1.vmdk + +[root@fedora createvmdk]# cat /tmp/test1.vmdk +# Disk DescriptorFile +version=1 +CID=5f13c13d +parentCID=ffffffff +createType="monolithicFlat" + +# Extent description +RW 204800 FLAT "test1-flat.vmdk" 0 + +# The Disk Data Base +#DDB + +ddb.virtualHWVersion = "4" +ddb.geometry.cylinders = "203" +ddb.geometry.heads = "16" +ddb.geometry.sectors = "63" +ddb.adapterType = "ide" + + +On the other-hand creating a sparse file works +cd /mnt/hshare/some/folder/createvmdk/ +[root@fedora createvmdk]# qemu-img create -f vmdk test2.vmdk 100M -o subformat=monolithicSparse +Formatting 'test2.vmdk', fmt=vmdk size=104857600 compat6=off hwversion=undefined subformat=monolithicSparse +[root@fedora createvmdk]# ls l test2*.* +-rwxr-xr-x. 1 gana gana 65536 Jul 26 22:52 test2.vmdk +[root@fedora createvmdk]# du -k /tmp/test2*.* +12 /tmp/test2.vmdk + +test2.vmdk is a binary file +inside it, located among garbled ascii characters is an embedded VMDK description +```` +# Disk DescriptorFile +version=1 +CID=cf302a20 +parentCID=ffffffff +createType="monolithicSparse" + +# Extent description +RW 204800 SPARSE "test2.vmdk" + +# The Disk Data Base +#DDB + +ddb.virtualHWVersion = "4" +ddb.geometry.cylinders = "203" +ddb.geometry.heads = "16" +ddb.geometry.sectors = "63" +ddb.adapterType = "ide" +``` + +I retract comment "a)I would have expected that the monolithic flat would have created only one large file just like sparse, but it seems to create a description file, in addition to the storing file." + +pdf vmdk_specs-1.pdf "Virtual Disk Format 1.1" (https://www.vmware.com/app/vmdk/?src=vmdk) on page 7, line-34, a note is mentioned that says that is just how it is. +"A virtual disk described as monolithic and flat consists of two files. One file contains the descriptor. The other file is the extent used to store virtual machine data" + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system (but you won't be the reporter of the bug +in the new system and thus won't get notified on changes anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1889411 b/results/classifier/108/other/1889411 new file mode 100644 index 00000000..3a7acc70 --- /dev/null +++ b/results/classifier/108/other/1889411 @@ -0,0 +1,83 @@ +debug: 0.892 +performance: 0.849 +graphic: 0.811 +files: 0.742 +PID: 0.699 +other: 0.696 +semantic: 0.693 +device: 0.603 +network: 0.451 +socket: 0.415 +permissions: 0.380 +boot: 0.256 +vnc: 0.218 +KVM: 0.076 + +RISC-V: Unable to unwind the stack upon signals + +Consider the following program: + +=============================================================== +#include <stdio.h> +#include <stdlib.h> + +#define NOINLINE __attribute__ ((noinline)) + +void NOINLINE abort_me(void) { abort(); /* trigger SIGABRT */ } + +void NOINLINE level1(void) { abort_me(); } + +void NOINLINE level2(void) { level1(); } + +void NOINLINE level3(void) { level2(); } + +void NOINLINE level4(void) { level3();} + +int main(void) { + level4(); + return 0; +} +=============================================================== + +$ riscv64-linux-gnu-gcc -march=rv64imafdc -O0 -g c.c +$ qemu-riscv64 -g 31337 ./c & +$ riscv64-unknown-linux-gnu-gdb -q -ex 'target remote localhost:31337' -ex 'b abort_me' -ex c -ex bt ./c +Reading symbols from c... +Remote debugging using localhost:31337 +Reading symbols from /home/lewurm/riscv/sysroot/lib/ld-linux-riscv64-lp64d.so.1... +0x0000004000804f30 in _start () from /home/lewurm/riscv/sysroot/lib/ld-linux-riscv64-lp64d.so.1 +Breakpoint 1 at 0x4000000632: file c.c, line 7. +Continuing. + +Breakpoint 1, abort_me () at c.c:7 +7 abort(); /* trigger SIGABRT */ +#0 abort_me () at c.c:7 +#1 0x0000004000000642 in level1 () at c.c:11 +#2 0x0000004000000658 in level2 () at c.c:15 +#3 0x000000400000066e in level3 () at c.c:19 +#4 0x0000004000000684 in level4 () at c.c:23 +#5 0x000000400000069a in main () at c.c:27 +=============================================================== + +So far so good, I get a proper backtrace as expected. If I let the signal trigger however, gdb is not able to unwind the stack: + +(gdb) c +Continuing. + +Program received signal SIGABRT, Aborted. +0x0000004000858074 in ?? () +(gdb) bt +#0 0x0000004000858074 in ?? () + + + +I get the same behaviour for SIGSEGV and SIGILL, I didn't try other signals. Apparently this scenario works on real hardware (see linked gdb issue below), and presumably it would work with system qemu (I haven't tested that yet though). So my guess is that qemu does something differently around signal handling than the linux kernel. + + +Full reproducer: https://gist.github.com/lewurm/befb9ddf5894bad9628b1df77258598b +RISC-V GDB issue: https://github.com/riscv/riscv-binutils-gdb/issues/223 + +Can you test with mainline GDB and not a fork? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1889421 b/results/classifier/108/other/1889421 new file mode 100644 index 00000000..4f319134 --- /dev/null +++ b/results/classifier/108/other/1889421 @@ -0,0 +1,62 @@ +files: 0.858 +graphic: 0.848 +network: 0.834 +other: 0.805 +permissions: 0.775 +performance: 0.758 +device: 0.740 +semantic: 0.711 +vnc: 0.692 +PID: 0.614 +boot: 0.590 +socket: 0.505 +debug: 0.497 +KVM: 0.472 + +VVFAT is not writable from Windows NT 3.5, 3.51 and 4.0 + +I'm running Windows NT 3.5, 3.51 and 4.0 in QEMU 4.2.0 on Linux. I'm using a VVFAT filesystem. Command lines: + +$ qemu-system-i386 -L pc -cpu 486 -m 64 -vga cirrus -drive file=nt351.img,format=raw -net nic,model=pcnet -net user -soundhw sb16,pcspk -drive file=fat:rw:drived,format=raw + +$ qemu-system-i386 --version +QEMU emulator version 4.2.0 (Debian 1:4.2-6) +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers + +Creating a new directory or file on drive D: (the VVFAT filesystem) fails on Windows NT 3.5, 3.51 and 4.0 (see screenshot). It succeeds on Windows NT 3.1. + +Is there a workaround, e.g. a QEMU flag or a change in the Windows NT driver settings? + + + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system (but you won't be the reporter of the bug +in the new system and thus won't get notified on changes anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1889621 b/results/classifier/108/other/1889621 new file mode 100644 index 00000000..be0e42d5 --- /dev/null +++ b/results/classifier/108/other/1889621 @@ -0,0 +1,414 @@ +other: 0.876 +KVM: 0.732 +graphic: 0.703 +device: 0.678 +permissions: 0.662 +semantic: 0.647 +vnc: 0.635 +debug: 0.624 +performance: 0.611 +files: 0.597 +PID: 0.594 +boot: 0.588 +network: 0.586 +socket: 0.559 + +ARM Highbank Crashes Realted to GIC + +Hello, +Here are some QTest reproducers for crashes on ARM Highbank that all seem to be related to the gic device. + +Reproducer 1: +cat << EOF | ./arm-softmmu/qemu-system-arm -machine highbank \ +-nographic -monitor none -serial none -qtest stdio +writel 0xfff11f00 0x8405f559 +writel 0xfff117fd 0x5c057bd8 +EOF + +==10595==ERROR: AddressSanitizer: SEGV on unknown address 0x62b000013e01 (pc 0x55b6ab85cc91 bp 0x7fff60bd4d70 sp 0x7fff60bd4ce0 T0) +==10595==The signal is caused by a READ memory access. + #0 0x55b6ab85cc91 in gic_get_current_cpu /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:60:12 + #1 0x55b6ab85e1bd in gic_dist_writeb /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:1182:11 + #2 0x55b6ab855a97 in gic_dist_write /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:1514:9 + #3 0x55b6aa1650d4 in memory_region_write_with_attrs_accessor /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:503:12 + #4 0x55b6aa163ac6 in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:544:18 + #5 0x55b6aa161f35 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:1473:13 + #6 0x55b6a9313949 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/exec.c:3176:23 + #7 0x55b6a92fca11 in flatview_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3216:14 + #8 0x55b6a92fc54e in address_space_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3308:18 +================================================================= + +Reproducer 2: +cat << EOF | ./arm-softmmu/qemu-system-arm -machine highbank \ +-nographic -monitor none -serial none -qtest stdio +writeq 0xfff11f00 0x613a650f0fda6555 +EOF + +==1375==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x608000001c80 at pc 0x5618928c486e bp 0x7ffe22c4ee10 sp 0x7ffe22c4ee08 +READ of size 8 at 0x608000001c80 thread T0 + #0 0x5618928c486d in address_space_translate_iommu /home/alxndr/Development/qemu/general-fuzz/exec.c:451:23 + #1 0x561892850acc in flatview_do_translate /home/alxndr/Development/qemu/general-fuzz/exec.c:524:16 + #2 0x5618928514ad in flatview_translate /home/alxndr/Development/qemu/general-fuzz/exec.c:584:15 + #3 0x5618928b1e14 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/exec.c:3199:14 + #4 0x56189289aa11 in flatview_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3216:14 + #5 0x56189289a54e in address_space_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3308:18 + #6 0x5618937a5e13 in qtest_process_command /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:452:13 + #7 0x56189379d89f in qtest_process_inbuf /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:710:9 + #8 0x56189379c680 in qtest_read /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:722:5 +================================================================= + +Reproducer 3: +cat << EOF | ./arm-softmmu/qemu-system-arm -machine highbank \ +-nographic -monitor none -serial none -qtest stdio +writeq 0xfff11000 0x700000b +writeq 0xfff11f00 0x4f4f4fff54a7afaf +writel 0xfff10100 0x600001ff +EOF + +==23743==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62b000006a92 at pc 0x55d690d980e1 bp 0x7ffe606082d0 sp 0x7ffe606082c8 +READ of size 1 at 0x62b000006a92 thread T0 + #0 0x55d690d980e0 in gic_get_best_irq /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:94:13 + #1 0x55d690d9485b in gic_update_internal /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:185:13 + #2 0x55d690d90376 in gic_update /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:226:5 + #3 0x55d690dc0879 in gic_cpu_write /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:1758:9 + #4 0x55d690da41c0 in gic_thiscpu_write /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:1777:12 + #5 0x55d68f6b30d4 in memory_region_write_with_attrs_accessor /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:503:12 + #6 0x55d68f6b1ac6 in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:544:18 + #7 0x55d68f6aff35 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:1473:13 + #8 0x55d68e861949 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/exec.c:3176:23 + #9 0x55d68e84aa11 in flatview_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3216:14 + #10 0x55d68e84a54e in address_space_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3308:18 + #11 0x55d68f755537 in qtest_process_command /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:447:13 + #12 0x55d68f74d89f in qtest_process_inbuf /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:710:9 + #13 0x55d68f74c680 in qtest_read /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:722:5 + #14 0x55d692dddc36 in qemu_chr_be_write_impl /home/alxndr/Development/qemu/general-fuzz/chardev/char.c:188:9 + #15 0x55d692dddd79 in qemu_chr_be_write /home/alxndr/Development/qemu/general-fuzz/chardev/char.c:200:9 + #16 0x55d692df105e in fd_chr_read /home/alxndr/Development/qemu/general-fuzz/chardev/char-fd.c:68:9 + #17 0x55d692f395df in qio_channel_fd_source_dispatch /home/alxndr/Development/qemu/general-fuzz/io/channel-watch.c:84:12 + #18 0x7f69a1b50897 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e897) + #19 0x55d6932f5c83 in glib_pollfds_poll /home/alxndr/Development/qemu/general-fuzz/util/main-loop.c:217:9 + #20 0x55d6932f35b6 in os_host_main_loop_wait /home/alxndr/Development/qemu/general-fuzz/util/main-loop.c:240:5 + #21 0x55d6932f2f97 in main_loop_wait /home/alxndr/Development/qemu/general-fuzz/util/main-loop.c:516:11 + #22 0x55d68f76c62d in qemu_main_loop /home/alxndr/Development/qemu/general-fuzz/softmmu/vl.c:1676:9 + #23 0x55d692f6f20c in main /home/alxndr/Development/qemu/general-fuzz/softmmu/main.c:49:5 + #24 0x7f69a06d6e0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 + #25 0x55d68e753459 in _start (/home/alxndr/Development/qemu/general-fuzz/build/arm-softmmu/qemu-system-arm+0x3254459) + +0x62b000006a92 is located 2 bytes to the right of 26768-byte region [0x62b000000200,0x62b000006a90) +allocated by thread T0 here: + #0 0x55d68e7cbe4d in malloc (/home/alxndr/Development/qemu/general-fuzz/build/arm-softmmu/qemu-system-arm+0x32cce4d) + #1 0x7f69a1b56500 in g_malloc (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x54500) + #2 0x55d69254f231 in object_new /home/alxndr/Development/qemu/general-fuzz/qom/object.c:708:12 + #3 0x55d69034bf01 in qdev_new /home/alxndr/Development/qemu/general-fuzz/hw/core/qdev.c:136:12 + #4 0x55d68f2b7aa4 in calxeda_init /home/alxndr/Development/qemu/general-fuzz/hw/arm/highbank.c:319:15 + #5 0x55d68f2b6466 in highbank_init /home/alxndr/Development/qemu/general-fuzz/hw/arm/highbank.c:411:5 + #6 0x55d6903d43f1 in machine_run_board_init /home/alxndr/Development/qemu/general-fuzz/hw/core/machine.c:1134:5 + #7 0x55d68f77e0ee in qemu_init /home/alxndr/Development/qemu/general-fuzz/softmmu/vl.c:4356:5 + #8 0x55d692f6f207 in main /home/alxndr/Development/qemu/general-fuzz/softmmu/main.c:48:5 + #9 0x7f69a06d6e0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 + + +Let me know if I can provide any further info. +-Alex + +Why put all these bugs in the same ticket? + +For reproducer #2: + +writeq 0xfff11f00 0x613a650f0fda6555 does: + +gic_dist_write dist write at 0x00000f00 size 4: 0x0fda6555 + +0x0fda6555 => IRQ 341, mask type 3 illegal -> DPRINTF("Bad Soft Int target filter\n"); + +mask = ALL_CPU_MASK = 0xff + +Having: + +#define GIC_NR_SGIS 16 +uint8_t sgi_pending[GIC_NR_SGIS][GIC_NCPU]; + +s->sgi_pending[irq][target_cpu] |= (1 << cpu); + ^^^ + \ OOB access. + +I haven't looked at reproducer #1, but is it a fuzzer-specific variant of LP:1602247 (trying to read the "for this CPU" registers from something other than a CPU doesn't work) ? + + +On 200730 1531, Philippe Mathieu-Daudé wrote: +> Why put all these bugs in the same ticket? + +Thought they might have a similar root cause, though that is evidently +wrong.. + +> For reproducer #2: +> +> writeq 0xfff11f00 0x613a650f0fda6555 does: +> +> gic_dist_write dist write at 0x00000f00 size 4: 0x0fda6555 +> +> 0x0fda6555 => IRQ 341, mask type 3 illegal -> DPRINTF("Bad Soft Int +> target filter\n"); +> +> mask = ALL_CPU_MASK = 0xff +> +> Having: +> +> #define GIC_NR_SGIS 16 +> uint8_t sgi_pending[GIC_NR_SGIS][GIC_NCPU]; +> +> s->sgi_pending[irq][target_cpu] |= (1 << cpu); +> ^^^ +> \ OOB access. +> +> ** Changed in: qemu +> Status: New => Confirmed +> +> ** Tags added: arm +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1889621 +> +> Title: +> ARM Highbank Crashes Realted to GIC +> +> Status in QEMU: +> Confirmed +> +> Bug description: +> Hello, +> Here are some QTest reproducers for crashes on ARM Highbank that all seem to be related to the gic device. +> +> Reproducer 1: +> cat << EOF | ./arm-softmmu/qemu-system-arm -machine highbank \ +> -nographic -monitor none -serial none -qtest stdio +> writel 0xfff11f00 0x8405f559 +> writel 0xfff117fd 0x5c057bd8 +> EOF +> +> ==10595==ERROR: AddressSanitizer: SEGV on unknown address 0x62b000013e01 (pc 0x55b6ab85cc91 bp 0x7fff60bd4d70 sp 0x7fff60bd4ce0 T0) +> ==10595==The signal is caused by a READ memory access. +> #0 0x55b6ab85cc91 in gic_get_current_cpu /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:60:12 +> #1 0x55b6ab85e1bd in gic_dist_writeb /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:1182:11 +> #2 0x55b6ab855a97 in gic_dist_write /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:1514:9 +> #3 0x55b6aa1650d4 in memory_region_write_with_attrs_accessor /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:503:12 +> #4 0x55b6aa163ac6 in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:544:18 +> #5 0x55b6aa161f35 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:1473:13 +> #6 0x55b6a9313949 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/exec.c:3176:23 +> #7 0x55b6a92fca11 in flatview_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3216:14 +> #8 0x55b6a92fc54e in address_space_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3308:18 +> ================================================================= +> +> Reproducer 2: +> cat << EOF | ./arm-softmmu/qemu-system-arm -machine highbank \ +> -nographic -monitor none -serial none -qtest stdio +> writeq 0xfff11f00 0x613a650f0fda6555 +> EOF +> +> ==1375==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x608000001c80 at pc 0x5618928c486e bp 0x7ffe22c4ee10 sp 0x7ffe22c4ee08 +> READ of size 8 at 0x608000001c80 thread T0 +> #0 0x5618928c486d in address_space_translate_iommu /home/alxndr/Development/qemu/general-fuzz/exec.c:451:23 +> #1 0x561892850acc in flatview_do_translate /home/alxndr/Development/qemu/general-fuzz/exec.c:524:16 +> #2 0x5618928514ad in flatview_translate /home/alxndr/Development/qemu/general-fuzz/exec.c:584:15 +> #3 0x5618928b1e14 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/exec.c:3199:14 +> #4 0x56189289aa11 in flatview_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3216:14 +> #5 0x56189289a54e in address_space_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3308:18 +> #6 0x5618937a5e13 in qtest_process_command /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:452:13 +> #7 0x56189379d89f in qtest_process_inbuf /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:710:9 +> #8 0x56189379c680 in qtest_read /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:722:5 +> ================================================================= +> +> Reproducer 3: +> cat << EOF | ./arm-softmmu/qemu-system-arm -machine highbank \ +> -nographic -monitor none -serial none -qtest stdio +> writeq 0xfff11000 0x700000b +> writeq 0xfff11f00 0x4f4f4fff54a7afaf +> writel 0xfff10100 0x600001ff +> EOF +> +> ==23743==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62b000006a92 at pc 0x55d690d980e1 bp 0x7ffe606082d0 sp 0x7ffe606082c8 +> READ of size 1 at 0x62b000006a92 thread T0 +> #0 0x55d690d980e0 in gic_get_best_irq /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:94:13 +> #1 0x55d690d9485b in gic_update_internal /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:185:13 +> #2 0x55d690d90376 in gic_update /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:226:5 +> #3 0x55d690dc0879 in gic_cpu_write /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:1758:9 +> #4 0x55d690da41c0 in gic_thiscpu_write /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:1777:12 +> #5 0x55d68f6b30d4 in memory_region_write_with_attrs_accessor /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:503:12 +> #6 0x55d68f6b1ac6 in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:544:18 +> #7 0x55d68f6aff35 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:1473:13 +> #8 0x55d68e861949 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/exec.c:3176:23 +> #9 0x55d68e84aa11 in flatview_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3216:14 +> #10 0x55d68e84a54e in address_space_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3308:18 +> #11 0x55d68f755537 in qtest_process_command /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:447:13 +> #12 0x55d68f74d89f in qtest_process_inbuf /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:710:9 +> #13 0x55d68f74c680 in qtest_read /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:722:5 +> #14 0x55d692dddc36 in qemu_chr_be_write_impl /home/alxndr/Development/qemu/general-fuzz/chardev/char.c:188:9 +> #15 0x55d692dddd79 in qemu_chr_be_write /home/alxndr/Development/qemu/general-fuzz/chardev/char.c:200:9 +> #16 0x55d692df105e in fd_chr_read /home/alxndr/Development/qemu/general-fuzz/chardev/char-fd.c:68:9 +> #17 0x55d692f395df in qio_channel_fd_source_dispatch /home/alxndr/Development/qemu/general-fuzz/io/channel-watch.c:84:12 +> #18 0x7f69a1b50897 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e897) +> #19 0x55d6932f5c83 in glib_pollfds_poll /home/alxndr/Development/qemu/general-fuzz/util/main-loop.c:217:9 +> #20 0x55d6932f35b6 in os_host_main_loop_wait /home/alxndr/Development/qemu/general-fuzz/util/main-loop.c:240:5 +> #21 0x55d6932f2f97 in main_loop_wait /home/alxndr/Development/qemu/general-fuzz/util/main-loop.c:516:11 +> #22 0x55d68f76c62d in qemu_main_loop /home/alxndr/Development/qemu/general-fuzz/softmmu/vl.c:1676:9 +> #23 0x55d692f6f20c in main /home/alxndr/Development/qemu/general-fuzz/softmmu/main.c:49:5 +> #24 0x7f69a06d6e0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 +> #25 0x55d68e753459 in _start (/home/alxndr/Development/qemu/general-fuzz/build/arm-softmmu/qemu-system-arm+0x3254459) +> +> 0x62b000006a92 is located 2 bytes to the right of 26768-byte region [0x62b000000200,0x62b000006a90) +> allocated by thread T0 here: +> #0 0x55d68e7cbe4d in malloc (/home/alxndr/Development/qemu/general-fuzz/build/arm-softmmu/qemu-system-arm+0x32cce4d) +> #1 0x7f69a1b56500 in g_malloc (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x54500) +> #2 0x55d69254f231 in object_new /home/alxndr/Development/qemu/general-fuzz/qom/object.c:708:12 +> #3 0x55d69034bf01 in qdev_new /home/alxndr/Development/qemu/general-fuzz/hw/core/qdev.c:136:12 +> #4 0x55d68f2b7aa4 in calxeda_init /home/alxndr/Development/qemu/general-fuzz/hw/arm/highbank.c:319:15 +> #5 0x55d68f2b6466 in highbank_init /home/alxndr/Development/qemu/general-fuzz/hw/arm/highbank.c:411:5 +> #6 0x55d6903d43f1 in machine_run_board_init /home/alxndr/Development/qemu/general-fuzz/hw/core/machine.c:1134:5 +> #7 0x55d68f77e0ee in qemu_init /home/alxndr/Development/qemu/general-fuzz/softmmu/vl.c:4356:5 +> #8 0x55d692f6f207 in main /home/alxndr/Development/qemu/general-fuzz/softmmu/main.c:48:5 +> #9 0x7f69a06d6e0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 +> +> +> Let me know if I can provide any further info. +> -Alex +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1889621/+subscriptions + + +On 200730 1550, Peter Maydell wrote: +> I haven't looked at reproducer #1, but is it a fuzzer-specific variant +> of LP:1602247 (trying to read the "for this CPU" registers from +> something other than a CPU doesn't work) ? + +That was my initial suspicion as well, but it looks like the SEGV +happens here: +if (s->num_cpu > 1) { +rather than here: + return current_cpu->cpu_index; + +-Alex + +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1889621 +> +> Title: +> ARM Highbank Crashes Realted to GIC +> +> Status in QEMU: +> Confirmed +> +> Bug description: +> Hello, +> Here are some QTest reproducers for crashes on ARM Highbank that all seem to be related to the gic device. +> +> Reproducer 1: +> cat << EOF | ./arm-softmmu/qemu-system-arm -machine highbank \ +> -nographic -monitor none -serial none -qtest stdio +> writel 0xfff11f00 0x8405f559 +> writel 0xfff117fd 0x5c057bd8 +> EOF +> +> ==10595==ERROR: AddressSanitizer: SEGV on unknown address 0x62b000013e01 (pc 0x55b6ab85cc91 bp 0x7fff60bd4d70 sp 0x7fff60bd4ce0 T0) +> ==10595==The signal is caused by a READ memory access. +> #0 0x55b6ab85cc91 in gic_get_current_cpu /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:60:12 +> #1 0x55b6ab85e1bd in gic_dist_writeb /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:1182:11 +> #2 0x55b6ab855a97 in gic_dist_write /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:1514:9 +> #3 0x55b6aa1650d4 in memory_region_write_with_attrs_accessor /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:503:12 +> #4 0x55b6aa163ac6 in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:544:18 +> #5 0x55b6aa161f35 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:1473:13 +> #6 0x55b6a9313949 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/exec.c:3176:23 +> #7 0x55b6a92fca11 in flatview_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3216:14 +> #8 0x55b6a92fc54e in address_space_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3308:18 +> ================================================================= +> +> Reproducer 2: +> cat << EOF | ./arm-softmmu/qemu-system-arm -machine highbank \ +> -nographic -monitor none -serial none -qtest stdio +> writeq 0xfff11f00 0x613a650f0fda6555 +> EOF +> +> ==1375==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x608000001c80 at pc 0x5618928c486e bp 0x7ffe22c4ee10 sp 0x7ffe22c4ee08 +> READ of size 8 at 0x608000001c80 thread T0 +> #0 0x5618928c486d in address_space_translate_iommu /home/alxndr/Development/qemu/general-fuzz/exec.c:451:23 +> #1 0x561892850acc in flatview_do_translate /home/alxndr/Development/qemu/general-fuzz/exec.c:524:16 +> #2 0x5618928514ad in flatview_translate /home/alxndr/Development/qemu/general-fuzz/exec.c:584:15 +> #3 0x5618928b1e14 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/exec.c:3199:14 +> #4 0x56189289aa11 in flatview_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3216:14 +> #5 0x56189289a54e in address_space_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3308:18 +> #6 0x5618937a5e13 in qtest_process_command /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:452:13 +> #7 0x56189379d89f in qtest_process_inbuf /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:710:9 +> #8 0x56189379c680 in qtest_read /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:722:5 +> ================================================================= +> +> Reproducer 3: +> cat << EOF | ./arm-softmmu/qemu-system-arm -machine highbank \ +> -nographic -monitor none -serial none -qtest stdio +> writeq 0xfff11000 0x700000b +> writeq 0xfff11f00 0x4f4f4fff54a7afaf +> writel 0xfff10100 0x600001ff +> EOF +> +> ==23743==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62b000006a92 at pc 0x55d690d980e1 bp 0x7ffe606082d0 sp 0x7ffe606082c8 +> READ of size 1 at 0x62b000006a92 thread T0 +> #0 0x55d690d980e0 in gic_get_best_irq /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:94:13 +> #1 0x55d690d9485b in gic_update_internal /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:185:13 +> #2 0x55d690d90376 in gic_update /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:226:5 +> #3 0x55d690dc0879 in gic_cpu_write /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:1758:9 +> #4 0x55d690da41c0 in gic_thiscpu_write /home/alxndr/Development/qemu/general-fuzz/hw/intc/arm_gic.c:1777:12 +> #5 0x55d68f6b30d4 in memory_region_write_with_attrs_accessor /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:503:12 +> #6 0x55d68f6b1ac6 in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:544:18 +> #7 0x55d68f6aff35 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:1473:13 +> #8 0x55d68e861949 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/exec.c:3176:23 +> #9 0x55d68e84aa11 in flatview_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3216:14 +> #10 0x55d68e84a54e in address_space_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3308:18 +> #11 0x55d68f755537 in qtest_process_command /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:447:13 +> #12 0x55d68f74d89f in qtest_process_inbuf /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:710:9 +> #13 0x55d68f74c680 in qtest_read /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:722:5 +> #14 0x55d692dddc36 in qemu_chr_be_write_impl /home/alxndr/Development/qemu/general-fuzz/chardev/char.c:188:9 +> #15 0x55d692dddd79 in qemu_chr_be_write /home/alxndr/Development/qemu/general-fuzz/chardev/char.c:200:9 +> #16 0x55d692df105e in fd_chr_read /home/alxndr/Development/qemu/general-fuzz/chardev/char-fd.c:68:9 +> #17 0x55d692f395df in qio_channel_fd_source_dispatch /home/alxndr/Development/qemu/general-fuzz/io/channel-watch.c:84:12 +> #18 0x7f69a1b50897 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e897) +> #19 0x55d6932f5c83 in glib_pollfds_poll /home/alxndr/Development/qemu/general-fuzz/util/main-loop.c:217:9 +> #20 0x55d6932f35b6 in os_host_main_loop_wait /home/alxndr/Development/qemu/general-fuzz/util/main-loop.c:240:5 +> #21 0x55d6932f2f97 in main_loop_wait /home/alxndr/Development/qemu/general-fuzz/util/main-loop.c:516:11 +> #22 0x55d68f76c62d in qemu_main_loop /home/alxndr/Development/qemu/general-fuzz/softmmu/vl.c:1676:9 +> #23 0x55d692f6f20c in main /home/alxndr/Development/qemu/general-fuzz/softmmu/main.c:49:5 +> #24 0x7f69a06d6e0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 +> #25 0x55d68e753459 in _start (/home/alxndr/Development/qemu/general-fuzz/build/arm-softmmu/qemu-system-arm+0x3254459) +> +> 0x62b000006a92 is located 2 bytes to the right of 26768-byte region [0x62b000000200,0x62b000006a90) +> allocated by thread T0 here: +> #0 0x55d68e7cbe4d in malloc (/home/alxndr/Development/qemu/general-fuzz/build/arm-softmmu/qemu-system-arm+0x32cce4d) +> #1 0x7f69a1b56500 in g_malloc (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x54500) +> #2 0x55d69254f231 in object_new /home/alxndr/Development/qemu/general-fuzz/qom/object.c:708:12 +> #3 0x55d69034bf01 in qdev_new /home/alxndr/Development/qemu/general-fuzz/hw/core/qdev.c:136:12 +> #4 0x55d68f2b7aa4 in calxeda_init /home/alxndr/Development/qemu/general-fuzz/hw/arm/highbank.c:319:15 +> #5 0x55d68f2b6466 in highbank_init /home/alxndr/Development/qemu/general-fuzz/hw/arm/highbank.c:411:5 +> #6 0x55d6903d43f1 in machine_run_board_init /home/alxndr/Development/qemu/general-fuzz/hw/core/machine.c:1134:5 +> #7 0x55d68f77e0ee in qemu_init /home/alxndr/Development/qemu/general-fuzz/softmmu/vl.c:4356:5 +> #8 0x55d692f6f207 in main /home/alxndr/Development/qemu/general-fuzz/softmmu/main.c:48:5 +> #9 0x7f69a06d6e0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 +> +> +> Let me know if I can provide any further info. +> -Alex +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1889621/+subscriptions + + +Can you still reproduce one of these issues with the current master branch of QEMU? For me, all three reproduces do not seem to cause any trouble anymore... + +I believe these were all taken care of by +edfe2eb436 ("hw/intc/arm_gic: Fix interrupt ID in GICD_SGIR register") +09bbdb89bc ("hw/intc/arm_gic: Allow to use QTest without crashing") + +Ok, thanks, then let's close this (and open new tickets on gitlab if it happens again) + diff --git a/results/classifier/108/other/1889943 b/results/classifier/108/other/1889943 new file mode 100644 index 00000000..e937388d --- /dev/null +++ b/results/classifier/108/other/1889943 @@ -0,0 +1,383 @@ +other: 0.863 +semantic: 0.839 +permissions: 0.838 +graphic: 0.822 +performance: 0.814 +vnc: 0.795 +network: 0.793 +device: 0.784 +KVM: 0.779 +PID: 0.778 +socket: 0.776 +debug: 0.768 +boot: 0.761 +files: 0.697 + +Improper TCP/IP packet splitting on e1000e/vmxnet3 + +Problem Description: +When using a tap interface and the guest sends a TCP packet that would need to be segmented, it is fragmented using IP fragmentation. The host does not reassemble the IP fragments and forwards them to the next hop. This causes issues on certain ISPs, which seemingly reject IP fragments(Verizon Fios). +This issue occurs on the e1000e and vmxnet3 NIC models, and possibly others. It does not occur on the virtio(which passes the entire packet through to the host w/o fragmentation or segmentation) or the e1000 model(). + +Test scenario: +Setup a tap and network bridge using the directions here: https://gist.github.com/extremecoders-re/e8fd8a67a515fee0c873dcafc81d811c +Boot the machine into any modern guest(a Fedora 31 live iso was used for testing) +Begin a wireshark capture on the host machine +On the host(or another machine on the network) run: npx http-echo-server(See https://github.com/watson/http-echo-server) +On the guest run +Curl -d “Lorem ipsum dolor sit amet, consectetur adipiscing elit. Maecenas venenatis viverra ipsum, ac tincidunt est rhoncus eu. Suspendisse vehicula congue ante, non rhoncus elit tempus vitae. Duis ac leo massa. Donec rutrum condimentum turpis nec ultricies. Duis laoreet elit eu arcu pulvinar, vitae congue neque mattis. Mauris sed ante nunc. Vestibulum vitae urna a tellus maximus sagittis. Vivamus luctus pellentesque neque, vel tempor purus porta ut. Phasellus at quam bibendum, fermentum libero sit amet, ullamcorper mauris. In rutrum sit amet dui id maximus. Ut lectus ligula, hendrerit nec aliquam non, finibus a turpis. Proin scelerisque convallis ante, et pharetra elit. Donec nunc nisl, viverra vitae dui at, posuere rhoncus nibh. Mauris in massa quis neque posuere placerat quis quis massa. Donec quis lacus ligula. Donec mollis vel nisi eget elementum. Nam id magna porta nunc consectetur efficitur ac quis lorem. Cras faucibus vel ex porttitor mattis. Praesent in mattis tortor. In venenatis convallis quam, in posuere nibh. Proin non dignissim massa. Cras at mi ut lorem tristique fringilla. Nulla ac quam condimentum metus tincidunt vulputate ut at leo. Nunc pellentesque, nunc vel rhoncus condimentum, arcu sem molestie augue, in suscipit mauris odio mollis odio. Integer hendrerit lectus a leo facilisis, in accumsan urna maximus. Nam nec odio volutpat, varius est id, tempus libero. Vestibulum lobortis tortor quam, ac scelerisque urna rhoncus in. Etiam tempor, est sit amet vulputate molestie, urna neque sodales leo, sit amet blandit risus felis sed est. Nulla eu eros nec tortor dapibus maximus faucibus ut erat. Ut pharetra tempor massa in bibendum. Interdum et malesuada fames ac ante ipsum primis in faucibus. Etiam mattis molestie felis eu efficitur. Morbi tincidunt consectetur diam tincidunt feugiat. Morbi euismod ut lorem finibus pellentesque. Aliquam eu porta ex. Aliquam cursus, orci sit amet volutpat egestas, est est pulvinar erat, sed luctus nisl ligula eget justo vestibulum.” <ECHOSERVERIP:PORT> + +2000 bytes of Lorem Ipsum taken from https://www.lipsum.com/ + +Compare results from an e1000, a virtio, and a e1000e card: ++--------+-----------+---------+------------+ +| Model | Fragment | Segment | Wire Size | ++--------+-----------+---------+------------+ +| e1000e | Yes | NO | 1484 + 621 | ++--------+-----------+---------+------------+ +| e1000 | No | Yes | 1516 + 620 | ++--------+-----------+---------+------------+ +| Virtio | NO | NO | 2068 | ++--------+-----------+---------+------------+ + +Expected Results: +TCP Segment to proper size OR pass full size to host and let the host split if necessary. + +Configuration changes that did not work: +Disable host, guest, router firewalls +Different Hosts +Different Physical NICs +Libvirt based NAT/Routed modes +Fedora 32 vs 31 +Qemu 4.2.0 vs github commit d74824cf7c8b352f9045e949dc636c7207a41eee + +System Information: +lsb_release -rd +Description: Fedora release 32 (Thirty Two) +Release: 32 + +uname -a +Linux pats-laptop-linux 5.7.10-201.fc32.x86_64 #1 SMP Thu Jul 23 00:58:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux + +I can provide additional logs, debug info, etc. if needed. + +After reading through some of the code for the e1000, e1000e, and vmxnet3 device models, it appears that all 3 are capable of performing tcp segementation, however, in the net_tx_pkt_send function, there is a check + +if (pkt->has_virt_hdr || + pkt->virt_hdr.gso_type == VIRTIO_NET_HDR_GSO_NONE) + +that if true will send the tcp segmented packets. However, if false, it will do IP fragmentation instead. I could not easily decipher what determines whether or not the pkt->has_virt_hdr value would be true or false. +What differs is that in the e1000, there is no such check. It directly calls qemu_send_packet without first going through the net_tx_pkt_send. +I will have to add in some debug prints on my local build to confirm that the tcp fragments are being created and then ignored. + +After stepping through the code, it has become clear that the e1000e/vmxnet3 emulated models do not implement TCP segmentation, however they still "advertise" it as a feature to the guest OS. + +Regarding my prior interpretation, the implementation is written to forward the entire packet to the host OS if the has_vnet_hdr variable is set, which is passed all the way up from the IFF_VNET_HDR on the tap/tun interface. I am not sure what the kernel considers when setting that flag, but it appears that it is true when in a host-only configuration, and false otherwise. I may look into the virtio implementation to see how it affects that because they are linked. + +In order to fix this, it would likely be possible to modify the net_tx_pkt_do_sw_fragmentation function in net_tx_pkt.c to incorporate the full set of offloads, not just ipv4. + +Because both the e1000e and the vmxnet3 implmentations share net_tx_pkt functions, this could fix both. + +Some more clarifications: +It appears the QEMU does turn on the vnet_hdr flag of the tap interface in most cases, not just host-only networks. My previous assumption was due to the way the libvirt manages it, only setting it if the virtio interface is used. + +Still, for software fragmentation implementations, ip fragmentation should be a last resort. + +I have also confirmed a suspicion that the current implementation of sw fragmentation will not work with IPV6. It creates malformed packets as ipv6 requires a different setup of headers to fragment. Thanks to the many redundancies in the network stack, the packets eventually arrive at the host server correctly formed, but we should not rely on this fact. + +Hello Yan, + +I tryed the patches mentioned(the first one was already implemented in +the git master, the second wasn't). It did fix the IPv6 fragmentation +issue. So therefore, the focus needs to be on implementing proper layer +4 segmentation. + +--Patrick +On Mon, 2020-08-03 at 09:37 +0300, Yan Vugenfirer wrote: +> Hello Patrick, +> +> If you are using QEMU version 4.2, then it is missing recent patches +> fixing IPv6 and TSO behaviour: +> https://<email address hidden>/msg723411.html +> https://<email address hidden>/msg723412.html +> +> Can you check that the above patches solve your issues? +> +> +> Best regards, +> Yan. +> +> > On 2 Aug 2020, at 6:59 PM, Patrick Magauran < +> > <email address hidden>> wrote: +> > +> > Some more clarifications: +> > It appears the QEMU does turn on the vnet_hdr flag of the tap +> > interface in most cases, not just host-only networks. My previous +> > assumption was due to the way the libvirt manages it, only setting +> > it if the virtio interface is used. +> > +> > Still, for software fragmentation implementations, ip fragmentation +> > should be a last resort. +> > +> > I have also confirmed a suspicion that the current implementation +> > of sw +> > fragmentation will not work with IPV6. It creates malformed packets +> > as +> > ipv6 requires a different setup of headers to fragment. Thanks to +> > the +> > many redundancies in the network stack, the packets eventually +> > arrive at +> > the host server correctly formed, but we should not rely on this +> > fact. +> > +> > ** Description changed: +> > +> > + Update: The sw implementation of fragmentation also creates +> > malformed +> > + IPv6 packets when their size is above the MTU. See comment #3 +> > + +> > Problem Description: +> > - When using a tap interface and the guest sends a TCP packet that +> > would need to be segmented, it is fragmented using IP +> > fragmentation. The host does not reassemble the IP fragments and +> > forwards them to the next hop. This causes issues on certain ISPs, +> > which seemingly reject IP fragments(Verizon Fios). +> > - This issue occurs on the e1000e and vmxnet3 NIC models, and +> > possibly others. It does not occur on the virtio(which passes the +> > entire packet through to the host w/o fragmentation or +> > segmentation) or the e1000 model(). +> > + When using a tap interface and the guest sends a TCP packet that +> > would need to be segmented, it is fragmented using IP +> > fragmentation. The host does not reassemble the IP fragments and +> > forwards them to the next hop. This causes issues on certain ISPs, +> > which seemingly reject IP fragments(Verizon Fios). +> > + This issue occurs on the e1000e and vmxnet3 NIC models, and +> > possibly others. It does not occur on the virtio(which passes the +> > entire packet through to the host w/o fragmentation or +> > segmentation) or the e1000 model(). +> > +> > Test scenario: +> > Setup a tap and network bridge using the directions here: +> > https://gist.github.com/extremecoders-re/e8fd8a67a515fee0c873dcafc81d811c +> > Boot the machine into any modern guest(a Fedora 31 live iso was +> > used for testing) +> > Begin a wireshark capture on the host machine +> > On the host(or another machine on the network) run: npx http-echo- +> > server(See https://github.com/watson/http-echo-server) +> > On the guest run +> > Curl -d “Lorem ipsum dolor sit amet, consectetur adipiscing elit. +> > Maecenas venenatis viverra ipsum, ac tincidunt est rhoncus eu. +> > Suspendisse vehicula congue ante, non rhoncus elit tempus vitae. +> > Duis ac leo massa. Donec rutrum condimentum turpis nec ultricies. +> > Duis laoreet elit eu arcu pulvinar, vitae congue neque mattis. +> > Mauris sed ante nunc. Vestibulum vitae urna a tellus maximus +> > sagittis. Vivamus luctus pellentesque neque, vel tempor purus porta +> > ut. Phasellus at quam bibendum, fermentum libero sit amet, +> > ullamcorper mauris. In rutrum sit amet dui id maximus. Ut lectus +> > ligula, hendrerit nec aliquam non, finibus a turpis. Proin +> > scelerisque convallis ante, et pharetra elit. Donec nunc nisl, +> > viverra vitae dui at, posuere rhoncus nibh. Mauris in massa quis +> > neque posuere placerat quis quis massa. Donec quis lacus ligula. +> > Donec mollis vel nisi eget elementum. Nam id magna porta nunc +> > consectetur efficitur ac quis lorem. Cras faucibus vel ex porttitor +> > mattis. Praesent in mattis tortor. In venenatis convallis quam, in +> > posuere nibh. Proin non dignissim massa. Cras at mi ut lorem +> > tristique fringilla. Nulla ac quam condimentum metus tincidunt +> > vulputate ut at leo. Nunc pellentesque, nunc vel rhoncus +> > condimentum, arcu sem molestie augue, in suscipit mauris odio +> > mollis odio. Integer hendrerit lectus a leo facilisis, in accumsan +> > urna maximus. Nam nec odio volutpat, varius est id, tempus libero. +> > Vestibulum lobortis tortor quam, ac scelerisque urna rhoncus in. +> > Etiam tempor, est sit amet vulputate molestie, urna neque sodales +> > leo, sit amet blandit risus felis sed est. Nulla eu eros nec tortor +> > dapibus maximus faucibus ut erat. Ut pharetra tempor massa in +> > bibendum. Interdum et malesuada fames ac ante ipsum primis in +> > faucibus. Etiam mattis molestie felis eu efficitur. Morbi tincidunt +> > consectetur diam tincidunt feugiat. Morbi euismod ut lorem finibus +> > pellentesque. Aliquam eu porta ex. Aliquam cursus, orci sit amet +> > volutpat egestas, est est pulvinar erat, sed luctus nisl ligula +> > eget justo vestibulum.” <ECHOSERVERIP:PORT> +> > +> > 2000 bytes of Lorem Ipsum taken from https://www.lipsum.com/ +> > +> > Compare results from an e1000, a virtio, and a e1000e card: +> > +--------+-----------+---------+------------+ +> > | Model | Fragment | Segment | Wire Size | +> > +--------+-----------+---------+------------+ +> > | e1000e | Yes | NO | 1484 + 621 | +> > +--------+-----------+---------+------------+ +> > | e1000 | No | Yes | 1516 + 620 | +> > +--------+-----------+---------+------------+ +> > | Virtio | NO | NO | 2068 | +> > +--------+-----------+---------+------------+ +> > +> > Expected Results: +> > TCP Segment to proper size OR pass full size to host and let the +> > host split if necessary. +> > +> > Configuration changes that did not work: +> > Disable host, guest, router firewalls +> > Different Hosts +> > Different Physical NICs +> > Libvirt based NAT/Routed modes +> > Fedora 32 vs 31 +> > Qemu 4.2.0 vs github commit +> > d74824cf7c8b352f9045e949dc636c7207a41eee +> > +> > System Information: +> > lsb_release -rd +> > Description: Fedora release 32 (Thirty Two) +> > Release: 32 +> > +> > uname -a +> > Linux pats-laptop-linux 5.7.10-201.fc32.x86_64 #1 SMP Thu Jul 23 +> > 00:58:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux +> > +> > I can provide additional logs, debug info, etc. if needed. +> > +> > -- +> > You received this bug notification because you are a member of +> > qemu- +> > devel-ml, which is subscribed to QEMU. +> > https://bugs.launchpad.net/bugs/1889943 +> > +> > Title: +> > Improper TCP/IP packet splitting on e1000e/vmxnet3 +> > +> > Status in QEMU: +> > New +> > +> > Bug description: +> > Update: The sw implementation of fragmentation also creates +> > malformed +> > IPv6 packets when their size is above the MTU. See comment #3 +> > +> > Problem Description: +> > When using a tap interface and the guest sends a TCP packet that +> > would need to be segmented, it is fragmented using IP +> > fragmentation. The host does not reassemble the IP fragments and +> > forwards them to the next hop. This causes issues on certain ISPs, +> > which seemingly reject IP fragments(Verizon Fios). +> > This issue occurs on the e1000e and vmxnet3 NIC models, and +> > possibly others. It does not occur on the virtio(which passes the +> > entire packet through to the host w/o fragmentation or +> > segmentation) or the e1000 model(). +> > +> > Test scenario: +> > Setup a tap and network bridge using the directions here: +> > https://gist.github.com/extremecoders-re/e8fd8a67a515fee0c873dcafc81d811c +> > Boot the machine into any modern guest(a Fedora 31 live iso was +> > used for testing) +> > Begin a wireshark capture on the host machine +> > On the host(or another machine on the network) run: npx http-echo- +> > server(See https://github.com/watson/http-echo-server) +> > On the guest run +> > Curl -d “Lorem ipsum dolor sit amet, consectetur adipiscing elit. +> > Maecenas venenatis viverra ipsum, ac tincidunt est rhoncus eu. +> > Suspendisse vehicula congue ante, non rhoncus elit tempus vitae. +> > Duis ac leo massa. Donec rutrum condimentum turpis nec ultricies. +> > Duis laoreet elit eu arcu pulvinar, vitae congue neque mattis. +> > Mauris sed ante nunc. Vestibulum vitae urna a tellus maximus +> > sagittis. Vivamus luctus pellentesque neque, vel tempor purus porta +> > ut. Phasellus at quam bibendum, fermentum libero sit amet, +> > ullamcorper mauris. In rutrum sit amet dui id maximus. Ut lectus +> > ligula, hendrerit nec aliquam non, finibus a turpis. Proin +> > scelerisque convallis ante, et pharetra elit. Donec nunc nisl, +> > viverra vitae dui at, posuere rhoncus nibh. Mauris in massa quis +> > neque posuere placerat quis quis massa. Donec quis lacus ligula. +> > Donec mollis vel nisi eget elementum. Nam id magna porta nunc +> > consectetur efficitur ac quis lorem. Cras faucibus vel ex porttitor +> > mattis. Praesent in mattis tortor. In venenatis convallis quam, in +> > posuere nibh. Proin non dignissim massa. Cras at mi ut lorem +> > tristique fringilla. Nulla ac quam condimentum metus tincidunt +> > vulputate ut at leo. Nunc pellentesque, nunc vel rhoncus +> > condimentum, arcu sem molestie augue, in suscipit mauris odio +> > mollis odio. Integer hendrerit lectus a leo facilisis, in accumsan +> > urna maximus. Nam nec odio volutpat, varius est id, tempus libero. +> > Vestibulum lobortis tortor quam, ac scelerisque urna rhoncus in. +> > Etiam tempor, est sit amet vulputate molestie, urna neque sodales +> > leo, sit amet blandit risus felis sed est. Nulla eu eros nec tortor +> > dapibus maximus faucibus ut erat. Ut pharetra tempor massa in +> > bibendum. Interdum et malesuada fames ac ante ipsum primis in +> > faucibus. Etiam mattis molestie felis eu efficitur. Morbi tincidunt +> > consectetur diam tincidunt feugiat. Morbi euismod ut lorem finibus +> > pellentesque. Aliquam eu porta ex. Aliquam cursus, orci sit amet +> > volutpat egestas, est est pulvinar erat, sed luctus nisl ligula +> > eget justo vestibulum.” <ECHOSERVERIP:PORT> +> > +> > 2000 bytes of Lorem Ipsum taken from https://www.lipsum.com/ +> > +> > Compare results from an e1000, a virtio, and a e1000e card: +> > +--------+-----------+---------+------------+ +> > | Model | Fragment | Segment | Wire Size | +> > +--------+-----------+---------+------------+ +> > | e1000e | Yes | NO | 1484 + 621 | +> > +--------+-----------+---------+------------+ +> > | e1000 | No | Yes | 1516 + 620 | +> > +--------+-----------+---------+------------+ +> > | Virtio | NO | NO | 2068 | +> > +--------+-----------+---------+------------+ +> > +> > Expected Results: +> > TCP Segment to proper size OR pass full size to host and let the +> > host split if necessary. +> > +> > Configuration changes that did not work: +> > Disable host, guest, router firewalls +> > Different Hosts +> > Different Physical NICs +> > Libvirt based NAT/Routed modes +> > Fedora 32 vs 31 +> > Qemu 4.2.0 vs github commit +> > d74824cf7c8b352f9045e949dc636c7207a41eee +> > +> > System Information: +> > lsb_release -rd +> > Description: Fedora release 32 (Thirty Two) +> > Release: 32 +> > +> > uname -a +> > Linux pats-laptop-linux 5.7.10-201.fc32.x86_64 #1 SMP Thu Jul 23 +> > 00:58:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux +> > +> > I can provide additional logs, debug info, etc. if needed. +> > +> > To manage notifications about this bug go to: +> > https://bugs.launchpad.net/qemu/+bug/1889943/+subscriptions +> > +> +> + + + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system (but you won't be the reporter of the bug +in the new system and thus won't get notified on changes anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1889945 b/results/classifier/108/other/1889945 new file mode 100644 index 00000000..734b417b --- /dev/null +++ b/results/classifier/108/other/1889945 @@ -0,0 +1,163 @@ +KVM: 0.677 +vnc: 0.661 +other: 0.649 +network: 0.636 +performance: 0.632 +boot: 0.628 +debug: 0.626 +graphic: 0.624 +permissions: 0.622 +device: 0.621 +files: 0.620 +socket: 0.620 +PID: 0.620 +semantic: 0.614 + +virtiofsd exits when iommu_platform is enabled after virtiofs driver is loaded + +Bug in QEMU 5.0.0: + +virtiofsd exits when iommu_platform is enabled after virtiofs driver is loaded. +If iommu_platform is disabled the guest immediately locks up as a result of the configured PCIe-Passthrough. + +Host system: +- Arch Linux amd64 +- AMD Ryzen Platform +- QEMU 5.0.0 + +Guest system: +- Windows Server 2019 (also happens in linux installations) +- PCIe GPU hostdev +- virtiofs passthrough + +Many thanks for any advice. + +QEMU LOG: +2020-07-28 19:20:07.197+0000: Starting external device: virtiofsd +/usr/lib/qemu/virtiofsd --fd=29 -o source=/viofstest +2020-07-28 19:20:07.207+0000: starting up libvirt version: 6.5.0, qemu version: 5.0.0, kernel: 5.7.10-arch1-1, hostname: mspc +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/bin \ +HOME=/var/lib/libvirt/qemu/domain-7-win \ +XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-7-win/.local/share \ +XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-7-win/.cache \ +XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-7-win/.config \ +QEMU_AUDIO_DRV=none \ +/usr/bin/qemu-system-x86_64 \ +-name guest=win,debug-threads=on \ +-S \ +-object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-7-win/master-key.aes \ +-blockdev '{"driver":"file","filename":"/usr/share/ovmf/x64/OVMF_CODE.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"}' \ +-blockdev '{"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/win_VARS.fd","node-name":"libvirt-pflash1-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-pflash1-format","read-only":false,"driver":"raw","file":"libvirt-pflash1-storage"}' \ +-machine pc-q35-5.0,accel=kvm,usb=off,vmport=off,dump-guest-core=off,kernel_irqchip=on,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-format \ +-cpu host,migratable=on,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff,hv-vendor-id=whatever,kvm=off \ +-m 2048 \ +-overcommit mem-lock=off \ +-smp 8,sockets=8,cores=1,threads=1 \ +-object memory-backend-file,id=ram-node0,prealloc=yes,mem-path=/dev/hugepages/libvirt/qemu/7-win,share=yes,size=2147483648 \ +-numa node,nodeid=0,cpus=0-7,memdev=ram-node0 \ +-uuid c8efa194-52f8-4526-a0f8-29a254839b55 \ +-display none \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=29,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=localtime,driftfix=slew \ +-global kvm-pit.lost_tick_policy=delay \ +-no-hpet \ +-no-shutdown \ +-global ICH9-LPC.disable_s3=1 \ +-global ICH9-LPC.disable_s4=1 \ +-boot menu=off,strict=on \ +-device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2 \ +-device pcie-pci-bridge,id=pci.2,bus=pci.1,addr=0x0 \ +-device pcie-root-port,port=0x11,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x1 \ +-device pcie-root-port,port=0x12,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x2 \ +-device pcie-root-port,port=0x13,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x3 \ +-device pcie-root-port,port=0x14,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x4 \ +-device pcie-root-port,port=0x15,chassis=7,id=pci.7,bus=pcie.0,addr=0x2.0x5 \ +-device pcie-root-port,port=0x16,chassis=8,id=pci.8,bus=pcie.0,addr=0x2.0x6 \ +-device pcie-root-port,port=0x17,chassis=9,id=pci.9,bus=pcie.0,addr=0x2.0x7 \ +-device pcie-root-port,port=0x18,chassis=10,id=pci.10,bus=pcie.0,multifunction=on,addr=0x3 \ +-device pcie-root-port,port=0x19,chassis=11,id=pci.11,bus=pcie.0,addr=0x3.0x1 \ +-device pcie-root-port,port=0x1a,chassis=12,id=pci.12,bus=pcie.0,addr=0x3.0x2 \ +-device pcie-root-port,port=0x8,chassis=13,id=pci.13,bus=pcie.0,multifunction=on,addr=0x1 \ +-device pcie-root-port,port=0x9,chassis=14,id=pci.14,bus=pcie.0,addr=0x1.0x1 \ +-device pcie-root-port,port=0xa,chassis=15,id=pci.15,bus=pcie.0,addr=0x1.0x2 \ +-device pcie-root-port,port=0xb,chassis=16,id=pci.16,bus=pcie.0,addr=0x1.0x3 \ +-device nec-usb-xhci,id=usb,bus=pci.7,addr=0x0 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.14,addr=0x0 \ +-blockdev '{"driver":"host_device","filename":"/dev/zvol/ssd/windows","aio":"threads","node-name":"libvirt-3-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-3-format","read-only":false,"cache":{"direct":true,"no-flush":false},"driver":"raw","file":"libvirt-3-storage"}' \ +-device virtio-blk-pci,bus=pci.3,addr=0x0,drive=libvirt-3-format,id=virtio-disk0,bootindex=1,write-cache=on \ +-blockdev '{"driver":"host_device","filename":"/dev/zvol/ssd/windows-ssdgames1","aio":"threads","node-name":"libvirt-2-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-2-format","read-only":false,"cache":{"direct":true,"no-flush":false},"driver":"raw","file":"libvirt-2-storage"}' \ +-device virtio-blk-pci,bus=pci.9,addr=0x0,drive=libvirt-2-format,id=virtio-disk1,write-cache=on \ +-blockdev '{"driver":"host_device","filename":"/dev/zvol/hdd/win-games1","aio":"threads","node-name":"libvirt-1-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"cache":{"direct":true,"no-flush":false},"driver":"raw","file":"libvirt-1-storage"}' \ +-device virtio-blk-pci,bus=pci.13,addr=0x0,drive=libvirt-1-format,id=virtio-disk2,write-cache=on \ +-chardev socket,id=chr-vu-fs0,path=/var/lib/libvirt/qemu/domain-7-win/fs0-fs.sock \ +-device vhost-user-fs-pci,chardev=chr-vu-fs0,tag=viofstest,iommu_platform=on,ats=on,bus=pci.15,addr=0x0 \ +-netdev tap,fd=32,id=hostnet0,vhost=on,vhostfd=34 \ +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:fb:0c:28,bus=pci.10,addr=0x0 \ +-chardev spicevmc,id=charchannel0,name=vdagent \ +-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 \ +-device virtio-keyboard-pci,id=input0,bus=pci.12,addr=0x0 \ +-device virtio-tablet-pci,id=input1,bus=pci.8,addr=0x0 \ +-device virtio-mouse-pci,id=input2,bus=pci.11,addr=0x0 \ +-device ich9-intel-hda,id=sound0,bus=pci.2,addr=0x1 \ +-device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 \ +-device vfio-pci,host=0000:08:00.0,id=hostdev0,bus=pci.5,addr=0x0,rombar=1 \ +-device vfio-pci,host=0000:08:00.1,id=hostdev1,bus=pci.6,addr=0x0,rombar=1 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.4,addr=0x0 \ +-object input-linux,id=kbd1,evdev=/dev/input/by-path/pci-0000:0a:00.3-usb-0:3:1.0-event-kbd,grab_all=on,repeat=on \ +-object input-linux,id=mouse1,evdev=/dev/input/by-path/pci-0000:0a:00.3-usb-0:4:1.0-event-mouse \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on +2020-07-28 19:20:07.207+0000: Domain id=7 is tainted: high-privileges +2020-07-28 19:20:07.207+0000: Domain id=7 is tainted: custom-argv +2020-07-28 19:20:07.207+0000: Domain id=7 is tainted: host-cpu +<--- VIOFS DRIVER GETS LOADED HERE ---> +2020-07-28T19:20:57.568089Z qemu-system-x86_64: Failed to read msg header. Read -1 instead of 12. Original request 1566376224. +2020-07-28T19:20:57.568120Z qemu-system-x86_64: Fail to update device iotlb +2020-07-28T19:20:57.568147Z qemu-system-x86_64: Failed to read msg header. Read 0 instead of 12. Original request 1566376528. +2020-07-28T19:20:57.568151Z qemu-system-x86_64: Fail to update device iotlb +2020-07-28T19:20:57.568153Z qemu-system-x86_64: Failed to set msg fds. +2020-07-28T19:20:57.568156Z qemu-system-x86_64: vhost_set_vring_call failed: Invalid argument (22) +2020-07-28T19:20:57.568160Z qemu-system-x86_64: Failed to set msg fds. +2020-07-28T19:20:57.568162Z qemu-system-x86_64: vhost_set_vring_call failed: Invalid argument (22) +2020-07-28T19:20:57.568296Z qemu-system-x86_64: Failed to read from slave. + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system (but you won't be the reporter of the bug +in the new system and thus won't get notified on changes anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + |