diff options
Diffstat (limited to 'results/classifier/105/mistranslation')
500 files changed, 46985 insertions, 0 deletions
diff --git a/results/classifier/105/mistranslation/1015 b/results/classifier/105/mistranslation/1015 new file mode 100644 index 000000000..aae1d5581 --- /dev/null +++ b/results/classifier/105/mistranslation/1015 @@ -0,0 +1,14 @@ +mistranslation: 0.721 +other: 0.405 +semantic: 0.392 +graphic: 0.380 +instruction: 0.192 +device: 0.121 +network: 0.105 +assembly: 0.083 +boot: 0.052 +vnc: 0.035 +KVM: 0.027 +socket: 0.027 + +qemu-7.0 there is no device "hostdev0" defined diff --git a/results/classifier/105/mistranslation/1027525 b/results/classifier/105/mistranslation/1027525 new file mode 100644 index 000000000..1fe9772f6 --- /dev/null +++ b/results/classifier/105/mistranslation/1027525 @@ -0,0 +1,64 @@ +mistranslation: 0.882 +semantic: 0.781 +vnc: 0.702 +device: 0.699 +graphic: 0.626 +instruction: 0.572 +other: 0.530 +socket: 0.481 +KVM: 0.407 +network: 0.388 +boot: 0.312 +assembly: 0.289 + +Unable to insert cd media located on ro nfs mount + +When issuing a "change" command via the monitor, qemu is unable to open the iso file if it is mounted on a read-only nfs share. If I mount read-write (and make sure the file is writable by the qemu process), then the change command succeeds. Note that this doesn't affect media specified on the command line when starting qemu, only when changing via the monitor. + +To reproduce, mount cd images directory read only, e.g. + +[root@kvmhost0 ~]# grep iso /etc/fstab +10.48.50.20:/iso /srv/kvm/iso nfs4 defaults,ro 0 0 + +Start qemu with minimal options, just need access to the monitor: + +[root@kvmhost0 ~]# kvm -vnc 127.0.0.1:0 -S + +Connect to the monitor and issue a change command: + +(qemu) change ide1-cd0 /srv/kvm/iso/ubuntu-12.04-server-amd64.iso +Could not open '/srv/kvm/iso/ubuntu-12.04-server-amd64.iso + +Re-mount the iso directory read-write and notice that the command succeeds: + +[root@kvmhost0 ~]# mount -o remount,rw /srv/kvm/iso + +(qemu) change ide1-cd0 /srv/kvm/iso/ubuntu-12.04-server-amd64.iso +(qemu) + +[root@kvmhost0 ~]# kvm --version +QEMU emulator version 1.1.1 (qemu-kvm-1.1.1), Copyright (c) 2003-2008 Fabrice Bellard +[root@kvmhost0 ~]# uname -a +Linux kvmhost0 3.4.5-1-ARCH #1 SMP PREEMPT Mon Jul 16 21:35:54 CEST 2012 x86_64 GNU/Linux + +I ran strace while running the test and I see few times: + +open("/srv/kvm/iso/ubuntu-12.04-server-amd64.iso", O_RDONLY|O_NONBLOCK) = 12 +fstat(12, {st_mode=S_IFREG|0666, st_size=717533184, ...}) = 0 +close(12) + +But the final open looks like this: + +open("/srv/kvm/iso/ubuntu-12.04-server-amd64.iso", O_RDWR|O_DSYNC|O_CLOEXEC) = -1 EROFS (Read-only file system) + +For some reason, the O_RDRW flag was requested. + + +Looks like the read_only flag in the block device state never gets set. This needs to be set otherwise qmp_change_blockdev tries to open the device read only. This patch works for me. + +Of course, I mean "qmp_change_blockdev tries to open the device read-write". + +Can you still reproduce this problem with the latest version of QEMU? If so, could you please refresh your patch and send it to the qemu-devel mailing list? (we do not accept patches from the bug tracker) + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1030 b/results/classifier/105/mistranslation/1030 new file mode 100644 index 000000000..09292c607 --- /dev/null +++ b/results/classifier/105/mistranslation/1030 @@ -0,0 +1,14 @@ +mistranslation: 0.632 +semantic: 0.490 +other: 0.378 +graphic: 0.299 +device: 0.285 +instruction: 0.230 +KVM: 0.210 +assembly: 0.160 +vnc: 0.159 +boot: 0.147 +network: 0.104 +socket: 0.058 + +Property 'rv32-riscv-cpu.x-v' not found diff --git a/results/classifier/105/mistranslation/1035042 b/results/classifier/105/mistranslation/1035042 new file mode 100644 index 000000000..429a99e45 --- /dev/null +++ b/results/classifier/105/mistranslation/1035042 @@ -0,0 +1,30 @@ +mistranslation: 0.898 +graphic: 0.683 +semantic: 0.548 +device: 0.488 +socket: 0.394 +network: 0.362 +vnc: 0.227 +boot: 0.167 +other: 0.147 +instruction: 0.104 +KVM: 0.061 +assembly: 0.025 + +Inconsistency in x509-dh-key-file parameter + +Hello, + +At source it is x509-dh-file, at config[2] it is x509-dh-key-file, at man[3] it is also x509-dh-key-file. + +I guess that [1] is not correct? + +Thanks! + +[1] http://git.qemu.org/?p=qemu.git;a=blob;f=ui/spice-core.c;h=4fc48f89026944fa91c4be349436041e97fc8654;hb=HEAD#l615 +[2] http://git.qemu.org/?p=qemu.git;a=blob;f=qemu-config.c;h=5c3296b8c6f0ec85201579f9a5f4e085adc33314;hb=HEAD#l498 +[3] http://git.qemu.org/?p=qemu.git;a=blob;f=qemu-options.hx;h=5e7d0dc035978945e692efe3ef063b6a69e73b29;hb=HEAD#l888 + +Fix has been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=9995c0b706a2270a49c + diff --git a/results/classifier/105/mistranslation/1036987 b/results/classifier/105/mistranslation/1036987 new file mode 100644 index 000000000..50013dfd2 --- /dev/null +++ b/results/classifier/105/mistranslation/1036987 @@ -0,0 +1,62 @@ +mistranslation: 0.885 +graphic: 0.824 +other: 0.782 +network: 0.769 +instruction: 0.765 +socket: 0.751 +semantic: 0.712 +device: 0.692 +KVM: 0.646 +vnc: 0.618 +boot: 0.514 +assembly: 0.504 + +compilation error due to bug in savevm.c + +Since + +302dfbeb21fc5154c24ca50d296e865a3778c7da + +Add xbzrle_encode_buffer and xbzrle_decode_buffer functions + + For performance we are encoding long word at a time. + For nzrun we use long-word-at-a-time NULL-detection tricks from strcmp(): + using ((lword - 0x0101010101010101) & (~lword) & 0x8080808080808080) test + to find out if any byte in the long word is zero. + + Signed-off-by: Benoit Hudzia <email address hidden> + Signed-off-by: Petter Svard <email address hidden> + Signed-off-by: Aidan Shribman <email address hidden> + Signed-off-by: Orit Wasserman <email address hidden> + Signed-off-by: Eric Blake <email address hidden> + + Reviewed-by: Luiz Capitulino <email address hidden> + Reviewed-by: Eric Blake <email address hidden> + + commit arrived into master barnch, I can't compile qemu at all: + +savevm.c:2476:13: error: overflow in implicit constant conversion [-Werror=overflow] + +Patch is available at http://patchwork.ozlabs.org/patch/177217/ + +On 15 August 2012 08:44, Evgeny Voevodin <email address hidden> wrote: +> Since +> +> 302dfbeb21fc5154c24ca50d296e865a3778c7da +> +> Add xbzrle_encode_buffer and xbzrle_decode_buffer functions +> commit arrived into master barnch, I can't compile qemu at all: +> +> savevm.c:2476:13: error: overflow in implicit constant conversion +> [-Werror=overflow] + +Fixed by this patch by Alex yesterday: + http://patchwork.ozlabs.org/patch/177217/ + +(not yet in master) + +-- PMM + + +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=a5b71725c7067f6805eb30 + diff --git a/results/classifier/105/mistranslation/1048 b/results/classifier/105/mistranslation/1048 new file mode 100644 index 000000000..59a600481 --- /dev/null +++ b/results/classifier/105/mistranslation/1048 @@ -0,0 +1,19 @@ +mistranslation: 0.834 +device: 0.825 +graphic: 0.725 +instruction: 0.694 +other: 0.563 +network: 0.527 +socket: 0.518 +vnc: 0.502 +semantic: 0.338 +boot: 0.301 +KVM: 0.045 +assembly: 0.040 + +usb/ohci does not reset HccaPad1 after frame number update. +Description of problem: +When the OHCI controller's framenumber is incremented, HccaPad1 register should be set to zero. Ref OHCI Spec 4.4.1. +Relevant code section: https://gitlab.com/qemu-project/qemu/-/blob/master/hw/usb/hcd-ohci.c#L1201 + +ReactOS uses hccaPad1 to determine if the OHCI hardware is running, consequently it fails this check in current qemu master. diff --git a/results/classifier/105/mistranslation/1050694 b/results/classifier/105/mistranslation/1050694 new file mode 100644 index 000000000..c28bf47ea --- /dev/null +++ b/results/classifier/105/mistranslation/1050694 @@ -0,0 +1,97 @@ +mistranslation: 0.907 +semantic: 0.864 +graphic: 0.863 +device: 0.857 +instruction: 0.857 +other: 0.854 +assembly: 0.852 +boot: 0.843 +socket: 0.843 +vnc: 0.833 +KVM: 0.818 +network: 0.807 + +Interrupt 0xffffffff when debug is turned on + +Hi, + +I have been getting a GPF when I enable interrupts, working on implementing processes and a scheduler. When I comment out the scheduler code, I still get the GPF. I used the following QEMU command line to capture a log: + +qemu-system-i386 -smp 4 -monitor stdio -cpu core2duo -D /home/adam/century/util/qemu.log -d int,in_asm -s -hda "$harddisk_image" -m 3.5G + +Rather than posting the entire log, I need some help interpreting the following section (notice "INT=0xffffffff" on the top line): +Servicing hardware INT=0xffffffff +1: v=ffffffff e=0000 i=0 cpl=0 IP=0008:0010b63f pc=0010b63f SP=0010:0012b768 EAX=00000000 +EAX=00000000 EBX=00002000 ECX=00000018 EDX=05a00780 +ESI=00112faa EDI=000b8fa0 EBP=0012b780 ESP=0012b768 +EIP=0010b63f EFL=00207202 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-] +SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +LDT=0000 00000000 00000000 00008200 DPL=0 LDT +TR =0008 00000580 00000067 00008900 DPL=0 TSS32-avl +GDT= 00127760 00000027 +IDT= 00122f40 000007ff +CR0=80000011 CR2=00000000 CR3=0014a000 CR4=00000000 +DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000 +DR6=ffff0ff0 DR7=00000400 +CCS=00000024 CCD=0012b75c CCO=ADDL +EFER=0000000000000000 +check_exception old: 0xffffffff new 0xd +2: v=0d e=fffffffa i=0 cpl=0 IP=0008:0010b63f pc=0010b63f SP=0010:0012b768 EAX=00000000 +EAX=00000000 EBX=00002000 ECX=00000018 EDX=05a00780 +ESI=00112faa EDI=000b8fa0 EBP=0012b780 ESP=0012b768 +EIP=0010b63f EFL=00207202 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-] +SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +LDT=0000 00000000 00000000 00008200 DPL=0 LDT +TR =0008 00000580 00000067 00008900 DPL=0 TSS32-avl +GDT= 00127760 00000027 +IDT= 00122f40 000007ff +CR0=80000011 CR2=00000000 CR3=0014a000 CR4=00000000 +DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000 +DR6=ffff0ff0 DR7=00000400 +CCS=00000024 CCD=0012b75c CCO=ADDL +EFER=0000000000000000 + +To the best of my ability to interpret, I an getting an undefined interrupt, which is then triggering a GPF, which is caught. However, do not know where it might be coming from. + +Some additional information: + + +This command works: + +qemu-system-i386 -smp 4 -monitor stdio -cpu core2duo -s -hda "$harddisk_image" -m 3.5G + + +This command works: + +qemu-system-i386 -monitor stdio -cpu core2duo -D /home/adam/century/util/qemu.log -d int,in_asm -s -hda "$harddisk_image" -m 3.5G + + +And, as above, this does not: + +qemu-system-i386 -smp 4 -monitor stdio -cpu core2duo -D /home/adam/century/util/qemu.log -d int,in_asm -s -hda "$harddisk_image" -m 3.5G + + +[adam@os-development ~]$ qemu-system-i386 -version +QEMU emulator version 1.2.0, Copyright (c) 2003-2008 Fabrice Bellard + + +Attached is an image as a test case. Please let me know if you need any additional information. + + + +Original conversation about this issue on osdev.org: http://forum.osdev.org/viewtopic.php?f=1&t=25795 + +Triaging old bug tickets ... is there still something left to do here, or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1054831 b/results/classifier/105/mistranslation/1054831 new file mode 100644 index 000000000..a839ef001 --- /dev/null +++ b/results/classifier/105/mistranslation/1054831 @@ -0,0 +1,67 @@ +mistranslation: 0.198 +network: 0.173 +device: 0.169 +other: 0.150 +instruction: 0.142 +semantic: 0.116 +vnc: 0.106 +socket: 0.104 +graphic: 0.058 +KVM: 0.054 +boot: 0.046 +assembly: 0.043 + +qemu-user-static for sparc32plus : bash: fork: Invalid argument + +On Debian x86-64 host system I setup a sparc chroot using: + +host $ mkdir sparc +host $ sudo debootstrap --arch=sparc --foreign wheezy sparc http://ftp.au.debian.org/debian +host $ sudo cp ~/Git/qemu/sparc32plus-linux-user/qemu-sparc32plus sparc/usr/bin/qemu-sparc32plus-static +host $ LANG=C sudo chroot sparc/ /usr/bin/qemu-sparc32plus-static /bin/bash + +When I then run the second stage of debootstrap I get: + +target $ /debootstrap/debootstrap --second-stage +bash: fork: Invalid argument + +The above procedures works perfectly for armhf. + +This is with current git HEAD (commit 93b6599734f81328ee3d608f57667742cafeea72). + +This is due to QEMU sparc32plus-linux-user not being compiled with NPTL support. + +Dillon Amburgey wrote: + +> This is due to QEMU sparc32plus-linux-user not being compiled with NPTL +> support. + +I just check, and NPTL is enabled. I also did this on the binary I +compiled: + + $ strings /usr/bin/qemu-sparc32plus-static | grep nptl + ../nptl/sysdeps/pthread/createthread.c + ../nptl/pthread_mutex_lock.c + nptl-init.c + ../nptl/sysdeps/unix/sysv/linux/x86_64/../fork.c + +which suggests that it has been compiled with NPTL. + + +What I mean is that QEMU isn't compiled with guest support for NPTL on every architecture. + +If you look in the configure script around line 3900, you'll see some architectures have target_nptl="yes" while others (including sparc) do not. + +Unfortunately it looks like the code isn't complete for sparc support, so it isn't a simple matter of enabling it in the configure script. + +The reason you get "bash: fork: Invalid argument" is because glibc makes a call to clone() with NPTL arguments that aren't supported. + +This bug should be fixed by a combination of: + * the enable-NPTL-everywhere patchset: http://lists.nongnu.org/archive/html/qemu-devel/2013-07/msg02614.html + * a fix for pipe() on sparc: http://lists.nongnu.org/archive/html/qemu-devel/2013-07/msg01072.html +which I hope will make it into QEMU 1.6. + + +This was fixed years ago... + + diff --git a/results/classifier/105/mistranslation/1066909 b/results/classifier/105/mistranslation/1066909 new file mode 100644 index 000000000..b41673920 --- /dev/null +++ b/results/classifier/105/mistranslation/1066909 @@ -0,0 +1,31 @@ +mistranslation: 0.809 +instruction: 0.562 +semantic: 0.560 +device: 0.537 +other: 0.510 +network: 0.499 +vnc: 0.456 +graphic: 0.438 +socket: 0.376 +boot: 0.345 +assembly: 0.179 +KVM: 0.115 + +App-level clone emulation for microblaze is broken + +When CLONE_THREAD is used, the new process starts with the program counter pointing to the system call instruction, rather than the instruction immediately following it. This causes an infinite cascade (linear growth, not exponential) of thread creation, which quickly crashes when the threads start running and they're all using the same stack. + +I'm using qemu 1.1.2 packaged with Debian, but I'm not aware of any fixes since then that would address the problem. + +I can provide a test program if needed; a short C program using syscall() directly or an even-shorter asm program can demonstrate the issue without need for debugging around pthread library routines. + +Here is a minimal test case showing the problem. + + +I accidentally posted the patch, which is here, on the wrong bug report (1068900 instead of here). Apologies. For reference here is the patch; it was committed and fixes this issue: + +https://lists.eait.uq.edu.au/pipermail/microblaze-linux/2012-October/005760.html + +Issue # 1068900, where I mistakenly posted the patch, is unrelated and not fixed; it should be reopened and this issue (1066909) should be marked fixed. + + diff --git a/results/classifier/105/mistranslation/1068900 b/results/classifier/105/mistranslation/1068900 new file mode 100644 index 000000000..ac7abbc6a --- /dev/null +++ b/results/classifier/105/mistranslation/1068900 @@ -0,0 +1,30 @@ +mistranslation: 0.977 +other: 0.744 +device: 0.738 +instruction: 0.665 +semantic: 0.612 +graphic: 0.588 +network: 0.588 +socket: 0.479 +vnc: 0.478 +boot: 0.368 +KVM: 0.152 +assembly: 0.120 + +Thread cancellation broken in app-level emulation + +Thread cancellation (and certain other implementation-internal things such as set*id() and timers) are implemented in userspace on Linux by stealing a couple of the realtime signals for internal use by the implementation, leaving them unavailable to applications. Unfortunately, this bites qemu application-level emulation when the application being run uses thread cancellation or other features that need such signals. The signal handler is unable to be set (because sigaction on the host rejects the signal numbers) and attempts to send the signals result in it being received not by the emulated application code, but by the libc/libpthread code on which qemu is running; this in turn seems to cause qemu to crash. + +The best solution I can think of is for qemu to steal one of the realtime signals for its own use, and multiplex signal numbers outside the range SIGRTMIN..SIGRTMAX, as well as the stolen signal itself, on top of this stolen signal. This would both allow cancellation to work, and would allow applications the full range of realtime signals when the guest has more signals than the host (e.g. MIPS running on x86 host). + +Patch for the issue is available here: + +https://lists.eait.uq.edu.au/pipermail/microblaze-linux/2012-October/005760.html + + +Arg, somehow I added the above comment on the wrong bug. Thus bug is not fixed. The other bug report I recently filed was fixed. + +The URL from comment #1 is unfortunately not valid anymore. If this issue is still pending, could you please post your patch again to the qemu-devel mailing list to get it discussed and included? Thanks! + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1077806 b/results/classifier/105/mistranslation/1077806 new file mode 100644 index 000000000..44acabf94 --- /dev/null +++ b/results/classifier/105/mistranslation/1077806 @@ -0,0 +1,21 @@ +mistranslation: 0.917 +other: 0.847 +device: 0.789 +boot: 0.714 +vnc: 0.710 +graphic: 0.700 +semantic: 0.625 +socket: 0.596 +network: 0.530 +assembly: 0.423 +instruction: 0.354 +KVM: 0.238 + +Integrate Virtualbox/Qemu Guest booting as a desktop environment listing (request) + +I had seen this new way to install Chromium OS and "boot" it using LightDM's session select menu, and it made me think of an idea: + +What if you were able to boot virtual machines in the same manner? It would simplify the Ubuntu user's life GREATLY if they had easy access to a Windows VM that can synchronize their files to and fro (Guest additions) and not require a reboot to use it. Modern computers have more than enough power to do something like this, and it should be even easier if the system is using a dedicated virtual machine environment rather than a full blown desktop. + +I think this would make using Ubuntu a LOT less of a hassle for the new user who came from Windows :) + diff --git a/results/classifier/105/mistranslation/108 b/results/classifier/105/mistranslation/108 new file mode 100644 index 000000000..8f5035bff --- /dev/null +++ b/results/classifier/105/mistranslation/108 @@ -0,0 +1,14 @@ +mistranslation: 0.993 +device: 0.908 +graphic: 0.546 +semantic: 0.545 +boot: 0.250 +other: 0.184 +network: 0.144 +instruction: 0.126 +vnc: 0.081 +assembly: 0.064 +socket: 0.013 +KVM: 0.005 + +Windows ME falsely detects qemu's videocards as Number Nine Imagine 128 diff --git a/results/classifier/105/mistranslation/1081 b/results/classifier/105/mistranslation/1081 new file mode 100644 index 000000000..cef2b76fe --- /dev/null +++ b/results/classifier/105/mistranslation/1081 @@ -0,0 +1,14 @@ +mistranslation: 0.685 +device: 0.676 +semantic: 0.431 +network: 0.381 +graphic: 0.336 +instruction: 0.214 +other: 0.189 +vnc: 0.150 +boot: 0.079 +socket: 0.074 +assembly: 0.047 +KVM: 0.009 + +A issue for QLIST_INSERT_BEFORE in include/qemu/queue.h diff --git a/results/classifier/105/mistranslation/1084 b/results/classifier/105/mistranslation/1084 new file mode 100644 index 000000000..7510d3dea --- /dev/null +++ b/results/classifier/105/mistranslation/1084 @@ -0,0 +1,14 @@ +mistranslation: 0.947 +device: 0.876 +graphic: 0.613 +semantic: 0.609 +vnc: 0.521 +network: 0.195 +other: 0.124 +instruction: 0.077 +boot: 0.061 +socket: 0.020 +assembly: 0.011 +KVM: 0.002 + +Qemu - VCPU shutdown request error diff --git a/results/classifier/105/mistranslation/1090604 b/results/classifier/105/mistranslation/1090604 new file mode 100644 index 000000000..05667e3dc --- /dev/null +++ b/results/classifier/105/mistranslation/1090604 @@ -0,0 +1,37 @@ +mistranslation: 0.644 +device: 0.638 +other: 0.603 +network: 0.495 +semantic: 0.495 +graphic: 0.489 +socket: 0.470 +vnc: 0.432 +boot: 0.297 +instruction: 0.288 +assembly: 0.227 +KVM: 0.190 + +RFE: Implement support for SMBIOS Type 41 structures + +This was originally filed in Fedora bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=669955 + +""" +Please extend the existing support for SMBIOS in qemu to add a capability to provide "Onboard Devices Extended Information" (Type 41). Not only is this replacing one of the existing types, but it also provides a mapping between devices and physical system chassis locations. But there is no physical chassis! Right. However, this doesn't mean you don't want to tell the guest OS which virtual (e.g. network) interface is which. You can do that, if you implement this extension that is already going into real hardware, and likely other VMs too. + +See also page 117 of the v2.7 of the SMBIOS spec. + +FWIW, VMware ESX and Workstation expose their PCI NICs in the PCI IRQ Routing Table. Kind of odd the first time you see it with biosdevname, as your NIC becomes pci3#1, but that's "correct" from a BIOS perspective. :-) +""" + +Hello, I'm intersted in this bug fix and have some free time. maybe I can do this bug-fix. + +I have sent a first patch around this: https://lists.nongnu.org/archive/html/qemu-devel/2021-03/msg09391.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 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/91 + + diff --git a/results/classifier/105/mistranslation/1095531 b/results/classifier/105/mistranslation/1095531 new file mode 100644 index 000000000..f26f67795 --- /dev/null +++ b/results/classifier/105/mistranslation/1095531 @@ -0,0 +1,168 @@ +mistranslation: 0.833 +other: 0.724 +semantic: 0.674 +graphic: 0.655 +instruction: 0.640 +device: 0.639 +assembly: 0.607 +KVM: 0.579 +vnc: 0.552 +boot: 0.518 +socket: 0.508 +network: 0.409 + +sparc32plus (and others?) has x86 code generation errors on 64bit hosts + +On 64bit hosts, the load and store functions compile improperly. The issue is the call to gen_address_mask() under the ld and st functions in target-sparc/translate.c. Below are some snips from the log file. Doing a gdb debug, this results in constant access violation errors which I do not see when debugging qemu in powerpc mode. + +-------------- +IN: +0x0000000040804aa8: st %i0, [ %fp + 0x44 ] + +OP: + ---- 0x40804aa8 + ld_i64 tmp1,regwptr,$0xb0 + mov_i64 tmp0,tmp1 + movi_i64 tmp2,$0x44 + add_i64 tmp0,tmp0,tmp2 + ld_i64 tmp2,regwptr,$0x80 + ext32u_i64 tmp0,tmp0 + qemu_st32 tmp2,tmp0,$0x0 + +OUT: [size=345] +0x6032d7f0: mov 0x40(%r14),%rbp +0x6032d7f4: mov 0xb0(%rbp),%rbx +0x6032d7fb: add $0x44,%rbx +0x6032d7ff: mov 0x80(%rbp),%rbp +0x6032d806: mov %ebx,%ebx <- bug +0x6032d808: mov %ebp,%edi +0x6032d80a: bswap %edi +0x6032d80c: mov %edi,(%rbx) + +-------------- +IN: +0x0000000040804aec: add %l7, %o7, %l7 +0x0000000040804af0: ld [ %l7 ], %g2 + +OP: + ---- 0x40804aec + ld_i64 tmp1,regwptr,$0x78 + ld_i64 tmp2,regwptr,$0x38 + add_i64 tmp0,tmp1,tmp2 + st_i64 tmp0,regwptr,$0x78 + + ---- 0x40804af0 + ld_i64 tmp1,regwptr,$0x78 + mov_i64 tmp0,tmp1 + ext32u_i64 tmp0,tmp0 + qemu_ld32u g2,tmp0,$0x0 + +OUT: [size=395] +0x6032da80: mov 0x40(%r14),%rbp +0x6032da84: mov 0x78(%rbp),%rbx +0x6032da88: mov 0x38(%rbp),%r12 +0x6032da8c: add %r12,%rbx +0x6032da8f: mov %rbx,0x78(%rbp) +0x6032da93: mov 0x78(%rbp),%rbx +0x6032da97: mov %ebx,%ebx <- bug +0x6032da99: mov (%rbx),%ebx + +In 64bit mode, doing a 32bit operation will result in the top 32bit's being zero'd. I attempted to simply disable the call to gen_address_mask() but that did not fix the issue and actually caused the sparc32plus I was testing to become unusable. + +I forgot to add, this is on the latest master branch as of this post. I am doing a static compile with debug enabled. My test is doing a chroot of a sparc system built from debootstrap. + +Can you still reproduce this problem wit the latest release of QEMU (currently version 2.9.0), or could we close this bug nowadays? + +I no longer have a setup to test this so I can only say to close it. + +On Jul 11, 2017 4:15 PM, "Thomas Huth" <email address hidden> wrote: + +> Can you still reproduce this problem wit the latest release of QEMU +> (currently version 2.9.0), or could we close this bug nowadays? +> +> ** Changed in: qemu +> Status: New => Incomplete +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1095531 +> +> Title: +> sparc32plus (and others?) has x86 code generation errors on 64bit +> hosts +> +> Status in QEMU: +> Incomplete +> +> Bug description: +> On 64bit hosts, the load and store functions compile improperly. The +> issue is the call to gen_address_mask() under the ld and st functions +> in target-sparc/translate.c. Below are some snips from the log file. +> Doing a gdb debug, this results in constant access violation errors +> which I do not see when debugging qemu in powerpc mode. +> +> -------------- +> IN: +> 0x0000000040804aa8: st %i0, [ %fp + 0x44 ] +> +> OP: +> ---- 0x40804aa8 +> ld_i64 tmp1,regwptr,$0xb0 +> mov_i64 tmp0,tmp1 +> movi_i64 tmp2,$0x44 +> add_i64 tmp0,tmp0,tmp2 +> ld_i64 tmp2,regwptr,$0x80 +> ext32u_i64 tmp0,tmp0 +> qemu_st32 tmp2,tmp0,$0x0 +> +> OUT: [size=345] +> 0x6032d7f0: mov 0x40(%r14),%rbp +> 0x6032d7f4: mov 0xb0(%rbp),%rbx +> 0x6032d7fb: add $0x44,%rbx +> 0x6032d7ff: mov 0x80(%rbp),%rbp +> 0x6032d806: mov %ebx,%ebx <- bug +> 0x6032d808: mov %ebp,%edi +> 0x6032d80a: bswap %edi +> 0x6032d80c: mov %edi,(%rbx) +> +> -------------- +> IN: +> 0x0000000040804aec: add %l7, %o7, %l7 +> 0x0000000040804af0: ld [ %l7 ], %g2 +> +> OP: +> ---- 0x40804aec +> ld_i64 tmp1,regwptr,$0x78 +> ld_i64 tmp2,regwptr,$0x38 +> add_i64 tmp0,tmp1,tmp2 +> st_i64 tmp0,regwptr,$0x78 +> +> ---- 0x40804af0 +> ld_i64 tmp1,regwptr,$0x78 +> mov_i64 tmp0,tmp1 +> ext32u_i64 tmp0,tmp0 +> qemu_ld32u g2,tmp0,$0x0 +> +> OUT: [size=395] +> 0x6032da80: mov 0x40(%r14),%rbp +> 0x6032da84: mov 0x78(%rbp),%rbx +> 0x6032da88: mov 0x38(%rbp),%r12 +> 0x6032da8c: add %r12,%rbx +> 0x6032da8f: mov %rbx,0x78(%rbp) +> 0x6032da93: mov 0x78(%rbp),%rbx +> 0x6032da97: mov %ebx,%ebx <- bug +> 0x6032da99: mov (%rbx),%ebx +> +> In 64bit mode, doing a 32bit operation will result in the top 32bit's +> being zero'd. I attempted to simply disable the call to +> gen_address_mask() but that did not fix the issue and actually caused +> the sparc32plus I was testing to become unusable. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1095531/+subscriptions +> + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1100 b/results/classifier/105/mistranslation/1100 new file mode 100644 index 000000000..082690303 --- /dev/null +++ b/results/classifier/105/mistranslation/1100 @@ -0,0 +1,14 @@ +mistranslation: 0.904 +device: 0.389 +graphic: 0.381 +other: 0.321 +semantic: 0.307 +instruction: 0.192 +boot: 0.192 +KVM: 0.150 +network: 0.119 +socket: 0.097 +vnc: 0.061 +assembly: 0.035 + +It riscv64 platform support user model?? diff --git a/results/classifier/105/mistranslation/1119 b/results/classifier/105/mistranslation/1119 new file mode 100644 index 000000000..35dfb0e95 --- /dev/null +++ b/results/classifier/105/mistranslation/1119 @@ -0,0 +1,28 @@ +mistranslation: 0.998 +device: 0.916 +instruction: 0.900 +graphic: 0.892 +network: 0.839 +socket: 0.814 +vnc: 0.809 +semantic: 0.794 +other: 0.729 +KVM: 0.705 +boot: 0.585 +assembly: 0.482 + +end_code set incorrectly +Description of problem: +https://github.com/qemu/qemu/blob/c99e34e537f13a431a80e3e414e5904e9dd0a116/linux-user/flatload.c#L811 + +This line says: + +``` +info->end_code = libinfo[0].start_code = libinfo[0].text_len; +``` + +but should be + +``` +info->end_code = libinfo[0].start_code + libinfo[0].text_len; +``` diff --git a/results/classifier/105/mistranslation/1120383 b/results/classifier/105/mistranslation/1120383 new file mode 100644 index 000000000..2320f6fab --- /dev/null +++ b/results/classifier/105/mistranslation/1120383 @@ -0,0 +1,160 @@ +mistranslation: 0.581 +graphic: 0.444 +KVM: 0.424 +semantic: 0.404 +other: 0.393 +instruction: 0.378 +vnc: 0.368 +device: 0.301 +network: 0.289 +socket: 0.287 +assembly: 0.286 +boot: 0.285 + +incremental live block migration of qemu 1.3.1 doesn't work + +We tested qemu 1.3.1 for live migration of block device. It failed with error. Since qemu-kvm 1.2.0 is ok for this test, we think this problem is introduced by new qemu 1.3.x releases. + +To reproduce: + +1. compile qemu 1.3.1: + # cd qemu-1.3.1 + # ./configure --prefix=/usr --sysconfdir=/etc --target-list=x86_64-softmmu + # make; make install + +2. prepare source(172.16.1.13): + # qemu-img create -f qcow2 os.img -b /home/reno/wheezyx64 ###Note: wheezyx64 is a template image for Debian Wheezy + # qemu-system-x86_64 -hda os.img -m 512 --enable-kvm -vnc :51 -monitor stdio + +3. prepare destination(172.16.1.14): + # qemu-img create -f qcow2 os.img -b /home/reno/wheezyx64 + # qemu-system-x86_64 -hda os.img -m 512 --enable-kvm -vnc :51 -incoming tcp:0:4444 + +4. do live migrate: + on source monitor command prompt, input: + (qemu) migrate -i tcp:172.16.1.14:4444 + +monitor command will quit immediately and on destination host, there are errors thrown: + Receiving block device images + Co-routine re-entered recursively + Aborted + +On Sat, Feb 9, 2013 at 3:46 PM, Reno Gan <email address hidden> wrote: +> Public bug reported: +> +> We tested qemu 1.3.1 for live migration of block device. It failed with +> error. Since qemu-kvm 1.2.0 is ok for this test, we think this problem +> is introduced by new qemu 1.3.x releases. + +Thanks for reporting this bug. It is a known issue and a fix is being +worked on for the QEMU 1.4 release. + +Stefan + + +On Sat, Feb 9, 2013 at 3:46 PM, Reno Gan <email address hidden> wrote: +> Public bug reported: +> +> We tested qemu 1.3.1 for live migration of block device. It failed with +> error. Since qemu-kvm 1.2.0 is ok for this test, we think this problem +> is introduced by new qemu 1.3.x releases. + +I have posted fixes to the qemu-devel mailing list. + +You can try them like this: +git clone -b block-migration-fixes-for-1.4 +git://github.com/stefanha/qemu.git qemu +cd qemu +./configure --target-list=x86_64-softmmu +make + + +I have tried this patch and it works. Thanks for your work and can't wait 1.4 coming out + +Another thing i want to mention about live block migration, though i don't know if this is really an issue of qemu or downstream libvirt. + +When I was testing live migration of qemu-kvm-1.2.0 for long run, i found a problem that block data are not completed transferred to target host. I traced that and found block migration thinks migration is completed when "block_mig_state.submitted == 0", but actually in some cases, data are not really transferred yet. + +I think the reasonable judgement for whether block migration is completed is "block_mig_state.submitted == 0 && block_mig_state.read_done == 0", that is all data have been transferred. + +I don't see anything about this in block-migration-fixes-for-1.4. Maybe it has been addressed somewhere else, but if it is not, please consider this issue and make sure data is integrated during block migration. + +On Sun, Feb 10, 2013 at 3:48 AM, Reno Gan <email address hidden> wrote: +> Another thing i want to mention about live block migration, though i +> don't know if this is really an issue of qemu or downstream libvirt. +> +> When I was testing live migration of qemu-kvm-1.2.0 for long run, i +> found a problem that block data are not completed transferred to target +> host. I traced that and found block migration thinks migration is +> completed when "block_mig_state.submitted == 0", but actually in some +> cases, data are not really transferred yet. +> +> I think the reasonable judgement for whether block migration is +> completed is "block_mig_state.submitted == 0 && +> block_mig_state.read_done == 0", that is all data have been transferred. +> +> I don't see anything about this in block-migration-fixes-for-1.4. Maybe +> it has been addressed somewhere else, but if it is not, please consider +> this issue and make sure data is integrated during block migration. + +Is there a way to reproduce this issue easily? + +How do you know that not all data has been transferred? + +Stefan + + +If you want to reproduce it, you can refer to my test case in this bug description, only differences are: + 1) make sure "os.img" is big enough, for example, > 300M + 2) write a script to migrate it in a loop: + a) migrate from A to B + b) shutdown guest on B and start it again + c) check if guest os is healthy. (I use guestfs to do this, you can use ssh to write a simple file in the guest file system) + +If error happens, the guest os will be mounted as read-only and a lot of root file system errors will be thrown out in syslog. + +I checked the image size from A to B and noticed that image size is shrinked dramatically. For example, if source size is 300M, only 10M is left on host B after migration. + +I also print out values of "block_mig_state.submitted", "block_mig_state.read_done", and "block_mig_state.transferred", and found that if error happened, "submitted" is zero and "read_done" is not zero. + +For example, if 52 blocks are to be migrated from A to B, when migration is completed, the three values will be: + submitted = 0, read_done = 40, transferred = 12 + +That is : a lot of data are actually "readed" but not "transferred", only part of data are migrated. + + +On Sun, Feb 10, 2013 at 3:48 AM, Reno Gan <email address hidden> wrote: +> Another thing i want to mention about live block migration, though i +> don't know if this is really an issue of qemu or downstream libvirt. +> +> When I was testing live migration of qemu-kvm-1.2.0 for long run, i +> found a problem that block data are not completed transferred to target +> host. I traced that and found block migration thinks migration is +> completed when "block_mig_state.submitted == 0", but actually in some +> cases, data are not really transferred yet. +> +> I think the reasonable judgement for whether block migration is +> completed is "block_mig_state.submitted == 0 && +> block_mig_state.read_done == 0", that is all data have been transferred. +> +> I don't see anything about this in block-migration-fixes-for-1.4. Maybe +> it has been addressed somewhere else, but if it is not, please consider +> this issue and make sure data is integrated during block migration. + +You are right. Thanks for pointing out this bug. + +I have changed it to: ++ /* Complete when bulk transfer is done and all dirty blocks have been ++ * transferred. ++ */ ++ return block_mig_state.bulk_completed && ++ block_mig_state.submitted == 0 && ++ block_mig_state.read_done == 0; + +Stefan + + +That's great, thanks + +If I've got the comments right, this bug has been fixed, so closing this now. If there is an issue remaining, please open a new bug. + diff --git a/results/classifier/105/mistranslation/1121 b/results/classifier/105/mistranslation/1121 new file mode 100644 index 000000000..83a5d99d4 --- /dev/null +++ b/results/classifier/105/mistranslation/1121 @@ -0,0 +1,83 @@ +mistranslation: 0.682 +vnc: 0.672 +other: 0.664 +KVM: 0.602 +graphic: 0.580 +device: 0.538 +instruction: 0.530 +semantic: 0.518 +assembly: 0.507 +socket: 0.484 +network: 0.470 +boot: 0.461 + +Segmentation fault in aspeed-hace +Description of problem: + +Steps to reproduce: +1. run qemu-machine nf5280m7-bmc +2. it will seg falult when load fitimage +Additional information: +Captured by gdb + +``` +0x00007ffff6e08a06 in has_padding (pad_offset=<synthetic pointer>, total_msg_len=<synthetic pointer>, req_len=17, total_req_len=56476, iov=0x7ffff5e973c0) at ../hw/misc/aspeed_hace.c:129 +129 if (padding[*pad_offset] == 0x80) { +(gdb) p padding_size +$1 = 45 +(gdb) p *padding_offset +No symbol "padding_offset" in current context. +(gdb) p *pad_offset +$2 = 4294967268 +(gdb) bt +#0 0x00007ffff6e08a06 in has_padding (pad_offset=<synthetic pointer>, total_msg_len=<synthetic pointer>, req_len=17, total_req_len=56476, + iov=0x7ffff5e973c0) at ../hw/misc/aspeed_hace.c:129 +#1 gen_acc_mode_iov (cache=0x7ffff7fd5600 <iov_cache>, total_req_len=0x7ffff7fd55e4 <total_len>, count=0x7ffff7fd55e0 <count>, + req_len=0x7ffff5e973a8, id=<optimized out>, iov=0x7ffff5e973b0) at ../hw/misc/aspeed_hace.c:176 +#2 do_hash_operation (s=s@entry=0x7ffff60077b0, algo=3, sg_mode=sg_mode@entry=true, acc_mode=acc_mode@entry=true) + at ../hw/misc/aspeed_hace.c:235 +#3 0x00007ffff6e09001 in aspeed_hace_write (opaque=<optimized out>, addr=12, data=262488, size=<optimized out>) + at ../hw/misc/aspeed_hace.c:372 +#4 0x00007ffff706ad54 in memory_region_write_accessor (mr=mr@entry=0x7ffff6007ad0, addr=48, value=value@entry=0x7ffff5e98548, + size=size@entry=4, shift=<optimized out>, mask=mask@entry=4294967295, attrs=...) at ../softmmu/memory.c:492 +#5 0x00007ffff7068266 in access_with_adjusted_size_aligned (addr=addr@entry=48, value=value@entry=0x7ffff5e98548, size=size@entry=4, + access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=0x7ffff706acd0 <memory_region_write_accessor>, + mr=0x7ffff6007ad0, attrs=...) at ../softmmu/memory.c:553 +#6 0x00007ffff706c948 in memory_region_dispatch_write (mr=mr@entry=0x7ffff6007ad0, addr=addr@entry=48, data=<optimized out>, + data@entry=262488, op=op@entry=MO_32, attrs=...) at ../softmmu/memory.c:1650 +#7 0x00007ffff7157ea9 in io_writex (env=env@entry=0x7ffff5fe7f10, iotlbentry=0x7fff6803f200, mmu_idx=mmu_idx@entry=7, val=val@entry=262488, + addr=addr@entry=510459952, retaddr=retaddr@entry=140736149505328, op=MO_32) at ../accel/tcg/cputlb.c:1429 +#8 0x00007ffff715c7dc in store_helper (op=MO_32, retaddr=140736149505328, oi=<optimized out>, val=262488, addr=510459952, + env=0x7ffff5fe7f10) at ../accel/tcg/cputlb.c:2363 +#9 full_le_stl_mmu (env=0x7ffff5fe7f10, addr=<optimized out>, val=262488, oi=<optimized out>, retaddr=140736149505328) + at ../accel/tcg/cputlb.c:2451 +#10 0x00007fffb032c530 in code_gen_buffer () +#11 0x00007ffff714eace in cpu_tb_exec (cpu=cpu@entry=0x7ffff5fde1b0, itb=itb@entry=0x7fffb033e7c0 <code_gen_buffer+3401619>, + tb_exit=tb_exit@entry=0x7ffff5e98c2c) at ../accel/tcg/cpu-exec.c:357 +#12 0x00007ffff714fc68 in cpu_loop_exec_tb (tb_exit=0x7ffff5e98c2c, last_tb=<synthetic pointer>, + tb=0x7fffb033e7c0 <code_gen_buffer+3401619>, cpu=0x7ffff5fde1b0) at ../accel/tcg/cpu-exec.c:847 +#13 cpu_exec (cpu=cpu@entry=0x7ffff5fde1b0) at ../accel/tcg/cpu-exec.c:1006 +#14 0x00007ffff7163d54 in tcg_cpus_exec (cpu=cpu@entry=0x7ffff5fde1b0) at ../accel/tcg/tcg-accel-ops.c:68 +#15 0x00007ffff7163ea7 in mttcg_cpu_thread_fn (arg=arg@entry=0x7ffff5fde1b0) at ../accel/tcg/tcg-accel-ops-mttcg.c:96 +#16 0x00007ffff7344c31 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:556 +#17 0x00007ffff74c74eb in start_thread () +#18 0x00007ffff75649c0 in clone3 () +``` +the uboot: https://github.com/openbmc/u-boot/commit/0f245563c2cb3a6b4f1206db4f1a9f0325406094 + +we should remove the hash check, otherwise, the boot will stop at uboot-cli +``` +diff --git a/common/image-fit.c b/common/image-fit.c +index 3c8667f93d..c655b297e5 100644 +--- a/common/image-fit.c ++++ b/common/image-fit.c +@@ -1193,7 +1193,7 @@ static int fit_image_check_hash(const void *fit, int noffset, const void *data, + return -1; + } else if (memcmp(value, fit_value, value_len) != 0) { + *err_msgp = "Bad hash value"; +- return -1; ++ return 0; + } + + return 0; +``` diff --git a/results/classifier/105/mistranslation/1127 b/results/classifier/105/mistranslation/1127 new file mode 100644 index 000000000..c6287fac5 --- /dev/null +++ b/results/classifier/105/mistranslation/1127 @@ -0,0 +1,142 @@ +mistranslation: 0.922 +graphic: 0.897 +other: 0.860 +device: 0.805 +semantic: 0.791 +vnc: 0.784 +boot: 0.726 +network: 0.720 +KVM: 0.686 +socket: 0.648 +assembly: 0.584 +instruction: 0.576 + +Various problems with running SunOS 4.1.4 +Description of problem: +Yes, I know, SunOS 4.1.4 is ancient, but I happened to find an original Solaris 1.1.2/SunOS 4.1.4 installation CD, and nostalgia got the better of me. + +It used to be possible to run SunOS 4.1.4 in QEMU 5.0.0, but starting with 6.0.0, whenever you try to boot, you see the following whenever SunOS tries to access a SCSI disk: + +``` +ok boot disk +Boot device: /iommu/sbus/espdma@f,400000/esp@f,800000/sd@3,0 File and args: +root on /iommu@f,e0000000/sbus@f,e0001000/espdma@f,400000/esp@f,800000/sd@3,0:a fstype 4.2 +Boot: vmunix +Size: 1548288+463688+225704 bytes +SuperSPARC: PAC ENABLED +SunOS Release 4.1.4 (GENERIC) #2: Fri Oct 14 11:09:47 PDT 1994 +Copyright (c) 1983-1993, Sun Microsystems, Inc. +cpu = SUNW,SPARCstation-20 +mod0 = TI,TMS390Z50 (mid = 8) +mem = 523836K (0x1ff8f000) +avail mem = 510947328 +cpu0 at Mbus 0x8 0x240000 +entering uniprocessor mode +Ethernet address = 52:54:0:12:34:56 +espdma0 at SBus slot f 0x400000 +esp0 at SBus slot f 0x800000 pri 4 (onboard) +esp0: data transfer overrun + State=DATA Last State=DATA_DONE + Latched stat=0x11<XZERO,IO> intr=0x10<BUS> fifo 0x0 + last msg out: EXTENDED; last msg in: COMMAND COMPLETE + DMA csr=0xa4240030<FLSH,INTEN> + addr=fff00034 last=fff00010 last_count=24 + Cmd dump for Target 3 Lun 0: + cdb=[ 0x12 0x0 0x0 0x0 0x24 0x0 ] + pkt_state 0xf<XFER,CMD,SEL,ARB> pkt_flags 0x9 pkt_statistics 0x0 + cmd_flags=0x5 cmd_timeout 0 + Mapped Dma Space: + Base = 0x10 Count = 0x24 + Transfer History: + Base = 0x10 Count = 0x24 + current phase 0x26=DATAIN stat=0x11 0x24 + current phase 0x1=CMD_START stat=0x12 0x12 + current phase 0x60=SELECT_SNDMSG stat=0x7 0x3 0x0 + current phase 0x23=SYNCHOUT stat=0x7 0x19 0xf + current phase 0xb=CMD_CMPLT stat=0x7 0x0 + current phase 0x27=STATUS stat=0x7 0x0 + current phase 0xb=CMD_CMPLT stat=0x13 + current phase 0x80=SEL_NO_ATN stat=0x0 0x3 0x0 + current phase 0x1=CMD_START stat=0x0 0x0 0x80 + current phase 0x1c=RESET stat=0x0 0x1f +``` + +This causes SunOS to ignore the disk, and later it tries to boot via ethernet instead. + +After some digging, I *think* I tracked down the problem. + +This commit seems to be what did it: + +commit 799d90d818ba38997e9f5de2163bbfc96256ac0b +Author: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> +Date: Thu Mar 4 22:10:58 2021 +0000 + + esp: transition to message out phase after SATN and stop command + + The SCSI bus should remain in the message out phase after the SATN and stop + command rather than transitioning to the command phase. A new ESPState variable + cmdbuf_cdb_offset is added which stores the offset of the CDB from the start + of cmdbuf when accumulating extended message out phase data. + + Currently any extended message out data is discarded in do_cmd() before the CDB + is processed in do_busid_cmd(). + + Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> + Reviewed-by: Laurent Vivier <laurent@vivier.eu> + Message-Id: <20210304221103.6369-38-mark.cave-ayland@ilande.co.uk> + +I determined this by rummaging through the changes to the esp.c driver between 5.0.0 and 6.0.0 until I stumbled across this one. I can make the problem go away with this simple change: + +``` +--- esp.c.orig 2022-04-19 12:10:27.000000000 -0700 ++++ esp.c 2022-07-25 19:57:06.602665000 -0700 +@@ -433,7 +433,7 @@ + trace_esp_handle_satn_stop(fifo8_num_used(&s->cmdfifo)); + s->do_cmd = 1; + s->cmdfifo_cdb_offset = 1; +- s->rregs[ESP_RSTAT] = STAT_MO; ++ s->rregs[ESP_RSTAT] = STAT_TC | STAT_CD /*STAT_MO*/; + s->rregs[ESP_RINTR] |= INTR_BS | INTR_FC; + s->rregs[ESP_RSEQ] = SEQ_MO; + esp_raise_irq(s); +``` + +NOTE: I am not sure if this is a proper fix, as I don't know enough about SCSI or the esp controller. All I know is putting this back the way it was makes SunOS happy again. Unfortunately it may also break something else, so somebody more knowledgeable than I should investigate further. + +If you're worried that reproducing this will be difficult, don't be. I prepared detailed instructions, scripts and all the images you should need to create a virtual SunOS disk and install the OS on it. This includes the OpenProm images and installation ISO. + +You can find everything here (consult readme.txt for details): + +http://people.freebsd.org/~wpaul/sunos-qemu + +The quick install option is very simple. Once you finish writing the OS to the disk and try to boot off it the first time, you should encounter the error above. + +But wait, there's more. + +SunOS 4 has this quirk where it only works with CD-ROM drives that report a block size of 512 bytes, instead of the default of 2048. Now, I realize that just recently, there was a change committed that allows the guest to change the block size with the MODE SELECT command. However this doesn't seem to be good enough for SunOS (I tried it, it still hates the drive). Note that scsi-disk.c hard codes the block size for CD-ROMs to 2058 in scsi_cd_realize(). What would be really nice is if was possible to override this from the command line, and that addresses the problem quite nicely. + +At the same URL above, I also provided a small patch to scsi-disk.c which implements this feature. This allows the user to set the initial block size with logical_block_size=512 when specifying the device parameters. The qemu_sparc5.sh and qemu_sparc20.sh scripts show an example of this. + +One more thing: I wanted to simulate a SPARCstation 20, but I found that SunOS 4 would panic when I tried to boot it with this configuration, even if I used the correct SS20 OpenProm image. The problem here has to do with the SUNW,DBRIe device. QEMU doesn't simulate this device, but it creates dummy resources for it, including a PROM space. The problem is that this space is empty. This causes the OpenProm to create a node with an empty "name" property, which is a condition the SunOS kernel doesn't expect. The result is that the kernel tries to dereference a NULL pointer and panics. (The OpenProm code itself seems to let it slide.) + +To work around this, I patched the sun4m.c code to create the SUNW,DBRIe device such that its PROM space can actually be populated with an FCode image, and I created a simple one with a valid name property so that the kernel doesn't panic. SunOS complains later that it can't find the audio device because it's not actually implemented, but at least it doesn't crash. + +I don't know how this would actually be addressed in QEMU proper since the existing FCode images that QEMU uses come from OpenBios. + +Finally, one thing I haven't figured out is that using the -smp flag with SunOS 4 never seems to work. The OpenProms and the SunOS kernel only ever seem to detect one CPU. I am not that broken up about this though, because SunOS 4 never really did SMP very well to begin with. +Steps to reproduce: +Download all the files at: + +http://people.freebsd.org/~wpaul/sunos-qemu + +You can download just: + +http://people.freebsd.org/~wpaul/sunos-qemu/sunos-qemu.tar.gz + +if you want everything in one shot. + +Read the readme.txt file. This will walk you through trying to create a bootable SunOS system. You should apply the CD-ROM patch to scsi-disk.c and use the qemu_sparc5.sh script initially. This should allow you to install the miniroot from the CD image onto the virtual hard drive, but it will fail booting due to the esp controller problem. The qemu_sparc20.sh script will only boot successfully if you apply the sun4m.c patch and copy QEMU,dbri.bin to the QEMU firmware directory. +Additional information: +I'm not planning to provide a pull request for any of this. As I said, I'm not sure if my fixes are necessarily correct (especially the esp.c one). I'm satisfied that they work for me, but I want to leave it to the appropriate maintainers do decide how to best deal with these things. + +I would be happy to answer questions and test candidate fixes though. diff --git a/results/classifier/105/mistranslation/113 b/results/classifier/105/mistranslation/113 new file mode 100644 index 000000000..4ee037485 --- /dev/null +++ b/results/classifier/105/mistranslation/113 @@ -0,0 +1,14 @@ +mistranslation: 0.840 +graphic: 0.331 +semantic: 0.237 +vnc: 0.190 +device: 0.175 +other: 0.096 +instruction: 0.076 +network: 0.067 +KVM: 0.050 +socket: 0.041 +boot: 0.027 +assembly: 0.021 + +missing manpage for bridge.conf diff --git a/results/classifier/105/mistranslation/1151986 b/results/classifier/105/mistranslation/1151986 new file mode 100644 index 000000000..5abc0042a --- /dev/null +++ b/results/classifier/105/mistranslation/1151986 @@ -0,0 +1,314 @@ +mistranslation: 0.835 +device: 0.825 +vnc: 0.823 +graphic: 0.818 +KVM: 0.804 +other: 0.802 +semantic: 0.800 +assembly: 0.795 +instruction: 0.786 +network: 0.784 +socket: 0.781 +boot: 0.767 + +buffer overflow after block-stream via QMP + +When a block-stream is initiated via QMP and the QMP socket is closed on client side before the job is finished, QEMU crashes with a buffer overflow. + +Afterwards I cannot boot from the last active image anymore. + +I was able to reproduce this with qemu-kvm and qemu-system-x86_64 on two different machines. + +Version: +QEMU emulator version 1.2.0 (qemu-kvm-1.2.0), Copyright (c) 2003-2008 Fabrice Bellard + +I started QEMU with the following script: + +qemu-kvm \ + -monitor vc \ + -m 512 \ + -hda "$1" \ + -net nic,vlan=0 \ + -net user,vlan=0 \ + -localtime \ + -smp 2 \ + -qmp tcp:localhost:4444,server,nowait + + +Backtrace: + +Formatting '/home/helge/images/vm01.2013-03-07_11:30:13.qcow2', fmt=qcow2 size=10485760000 backing_file='/home/helge/images/vm01.qcow2' backing_fmt='qcow2' encryption=off cluster_size=65536 lazy_refcounts=off +*** buffer overflow detected ***: qemu-kvm terminated +======= Backtrace: ========= +/usr/lib/libc.so.6(__fortify_fail+0x37)[0x7f054e91a8c7] +/usr/lib/libc.so.6(+0xfc9a0)[0x7f054e9189a0] +/usr/lib/libc.so.6(+0xfe837)[0x7f054e91a837] +qemu-kvm(+0xdb0dc)[0x7f055220b0dc] +qemu-kvm(+0x15f581)[0x7f055228f581] +qemu-kvm(main+0xf93)[0x7f05521a3e93] +/usr/lib/libc.so.6(__libc_start_main+0xf5)[0x7f054e83da15] +qemu-kvm(+0x77e8d)[0x7f05521a7e8d] +======= Memory map: ======== +7f051bdff000-7f051be00000 rw-p 00000000 00:00 0 +7f051be00000-7f053be00000 rw-p 00000000 00:00 0 +7f053be00000-7f053c000000 rw-p 00000000 00:00 0 +7f053c000000-7f053c021000 rw-p 00000000 00:00 0 +7f053c021000-7f0540000000 ---p 00000000 00:00 0 +7f05421e2000-7f05421f7000 r-xp 00000000 08:12 1175478 /usr/lib/libgcc_s.so.1 +7f05421f7000-7f05423f6000 ---p 00015000 08:12 1175478 /usr/lib/libgcc_s.so.1 +7f05423f6000-7f05423f7000 rw-p 00014000 08:12 1175478 /usr/lib/libgcc_s.so.1 +7f05423f7000-7f05423f8000 ---p 00000000 00:00 0 +7f05423f8000-7f0542bf8000 rw-p 00000000 00:00 0 [stack:27848] +7f0542bf8000-7f0542bfd000 r-xp 00000000 08:12 1198566 /usr/lib/libXfixes.so.3.1.0 +7f0542bfd000-7f0542dfd000 ---p 00005000 08:12 1198566 /usr/lib/libXfixes.so.3.1.0 +7f0542dfd000-7f0542dfe000 r--p 00005000 08:12 1198566 /usr/lib/libXfixes.so.3.1.0 +7f0542dfe000-7f0542dff000 rw-p 00006000 08:12 1198566 /usr/lib/libXfixes.so.3.1.0 +7f0542dff000-7f0542e00000 rw-p 00000000 00:00 0 +7f0542e00000-7f0543e00000 rw-p 00000000 00:00 0 +7f0543e00000-7f0544000000 rw-p 00000000 00:00 0 +7f0544000000-7f0544139000 rw-p 00000000 00:00 0 +7f0544139000-7f0548000000 ---p 00000000 00:00 0 +7f0548014000-7f054801e000 r-xp 00000000 08:12 1198746 /usr/lib/libXrender.so.1.3.0 +7f054801e000-7f054821d000 ---p 0000a000 08:12 1198746 /usr/lib/libXrender.so.1.3.0 +7f054821d000-7f054821e000 r--p 00009000 08:12 1198746 /usr/lib/libXrender.so.1.3.0 +7f054821e000-7f054821f000 rw-p 0000a000 08:12 1198746 /usr/lib/libXrender.so.1.3.0 +7f054821f000-7f0548228000 r-xp 00000000 08:12 1199189 /usr/lib/libXcursor.so.1.0.2 +7f0548228000-7f0548427000 ---p 00009000 08:12 1199189 /usr/lib/libXcursor.so.1.0.2 +7f0548427000-7f0548428000 r--p 00008000 08:12 1199189 /usr/lib/libXcursor.so.1.0.2 +7f0548428000-7f0548429000 rw-p 00009000 08:12 1199189 /usr/lib/libXcursor.so.1.0.2 +7f0548429000-7f0548721000 r--p 00000000 08:12 1175421 /usr/lib/locale/locale-archive +7f0548721000-7f0548733000 r-xp 00000000 08:12 1198126 /usr/lib/libXext.so.6.4.0 +7f0548733000-7f0548932000 ---p 00012000 08:12 1198126 /usr/lib/libXext.so.6.4.0 +7f0548932000-7f0548933000 r--p 00011000 08:12 1198126 /usr/lib/libXext.so.6.4.0 +7f0548933000-7f0548934000 rw-p 00012000 08:12 1198126 /usr/lib/libXext.so.6.4.0 +7f054895d000-7f05489c0000 rw-p 00000000 00:00 0 +7f054895d000-7f05489c0000 rw-p 00000000 00:00 0 [118/1982] +7f05489d3000-7f0548aed000 rw-s 00000000 00:04 69697543 /SYSV00000000 (deleted) +7f0548aed000-7f0548aee000 ---p 00000000 00:00 0 +7f0548aee000-7f05492ee000 rw-p 00000000 00:00 0 [stack:27612] +7f05492ee000-7f05492ef000 ---p 00000000 00:00 0 +7f05492ef000-7f0549aef000 rw-p 00000000 00:00 0 [stack:27611] +7f0549cef000-7f0549cf0000 rw-p 00000000 00:00 0 +7f0549cf0000-7f0549cf1000 ---p 00000000 00:00 0 +7f0549cf1000-7f054a4f1000 rw-p 00000000 00:00 0 [stack:27858] +7f054a4f1000-7f054a4fd000 r-xp 00000000 08:12 1175139 /usr/lib/libnss_files-2.17.so +7f054a4fd000-7f054a6fc000 ---p 0000c000 08:12 1175139 /usr/lib/libnss_files-2.17.so +7f054a6fc000-7f054a6fd000 r--p 0000b000 08:12 1175139 /usr/lib/libnss_files-2.17.so +7f054a6fd000-7f054a6fe000 rw-p 0000c000 08:12 1175139 /usr/lib/libnss_files-2.17.so +7f054a6fe000-7f054a704000 rw-p 00000000 00:00 0 +7f054a704000-7f054a719000 r-xp 00000000 08:12 1175108 /usr/lib/libnsl-2.17.so +7f054a719000-7f054a918000 ---p 00015000 08:12 1175108 /usr/lib/libnsl-2.17.so +7f054a918000-7f054a919000 r--p 00014000 08:12 1175108 /usr/lib/libnsl-2.17.so +7f054a919000-7f054a91a000 rw-p 00015000 08:12 1175108 /usr/lib/libnsl-2.17.so +7f054a91a000-7f054a91d000 rw-p 00000000 00:00 0 +7f054a91d000-7f054a923000 r-xp 00000000 08:12 1203255 /usr/lib/libogg.so.0.8.0 +7f054a923000-7f054ab22000 ---p 00006000 08:12 1203255 /usr/lib/libogg.so.0.8.0 +7f054ab22000-7f054ab23000 rw-p 00005000 08:12 1203255 /usr/lib/libogg.so.0.8.0 +7f054ab23000-7f054ab4f000 r-xp 00000000 08:12 1203266 /usr/lib/libvorbis.so.0.4.6 +7f054ab4f000-7f054ad4e000 ---p 0002c000 08:12 1203266 /usr/lib/libvorbis.so.0.4.6 +7f054ad4e000-7f054ad4f000 r--p 0002b000 08:12 1203266 /usr/lib/libvorbis.so.0.4.6 +7f054ad4f000-7f054ad50000 rw-p 0002c000 08:12 1203266 /usr/lib/libvorbis.so.0.4.6 +7f054ad50000-7f054b003000 r-xp 00000000 08:12 1203269 /usr/lib/libvorbisenc.so.2.0.9 +7f054b003000-7f054b202000 ---p 002b3000 08:12 1203269 /usr/lib/libvorbisenc.so.2.0.9 +7f054b202000-7f054b21e000 r--p 002b2000 08:12 1203269 /usr/lib/libvorbisenc.so.2.0.9 +7f054b21e000-7f054b21f000 rw-p 002ce000 08:12 1203269 /usr/lib/libvorbisenc.so.2.0.9 +7f054b21f000-7f054b269000 r-xp 00000000 08:12 1203337 /usr/lib/libFLAC.so.8.2.0 +7f054b269000-7f054b468000 ---p 0004a000 08:12 1203337 /usr/lib/libFLAC.so.8.2.0 +7f054b468000-7f054b46a000 rw-p 00049000 08:12 1203337 /usr/lib/libFLAC.so.8.2.0 +7f054b46a000-7f054b46f000 r-xp 00000000 08:12 1196541 /usr/lib/libXdmcp.so.6.0.0 +7f054b46f000-7f054b66e000 ---p 00005000 08:12 1196541 /usr/lib/libXdmcp.so.6.0.0 +7f054b66e000-7f054b66f000 r--p 00004000 08:12 1196541 /usr/lib/libXdmcp.so.6.0.0 +7f054b66f000-7f054b670000 rw-p 00005000 08:12 1196541 /usr/lib/libXdmcp.so.6.0.0 +7f054b670000-7f054b672000 r-xp 00000000 08:12 1196554 /usr/lib/libXau.so.6.0.0 +7f054b672000-7f054b872000 ---p 00002000 08:12 1196554 /usr/lib/libXau.so.6.0.0 +7f054b872000-7f054b873000 r--p 00002000 08:12 1196554 /usr/lib/libXau.so.6.0.0 +7f054b873000-7f054b874000 rw-p 00003000 08:12 1196554 /usr/lib/libXau.so.6.0.0 +7f054b874000-7f054b879000 r-xp 00000000 08:12 1203313 /usr/lib/libasyncns.so.0.3.1 +7f054b879000-7f054ba78000 ---p 00005000 08:12 1203313 /usr/lib/libasyncns.so.0.3.1 +7f054ba78000-7f054ba79000 r--p 00004000 08:12 1203313 /usr/lib/libasyncns.so.0.3.1 +7f054ba79000-7f054ba7a000 rw-p 00005000 08:12 1203313 /usr/lib/libasyncns.so.0.3.1 +7f054ba7a000-7f054bad9000 r-xp 00000000 08:12 1203348 /usr/lib/libsndfile.so.1.0.25 +7f054bad9000-7f054bcd9000 ---p 0005f000 08:12 1203348 /usr/lib/libsndfile.so.1.0.25 +7f054bcd9000-7f054bcdb000 r--p 0005f000 08:12 1203348 /usr/lib/libsndfile.so.1.0.25 +7f054bcdb000-7f054bcdc000 rw-p 00061000 08:12 1203348 /usr/lib/libsndfile.so.1.0.25 +7f054bcdc000-7f054bce0000 rw-p 00000000 00:00 0 +7f054bce0000-7f054bcfe000 r-xp 00000000 08:12 1216246 /usr/lib/libxcb.so.1.1.0 +7f054bcfe000-7f054befd000 ---p 0001e000 08:12 1216246 /usr/lib/libxcb.so.1.1.0 +7f054befd000-7f054befe000 r--p 0001d000 08:12 1216246 /usr/lib/libxcb.so.1.1.0 +7f054befe000-7f054beff000 rw-p 0001e000 08:12 1216246 /usr/lib/libxcb.so.1.1.0 +7f054beff000-7f054bf6c000 r-xp 00000000 08:12 1182009 /usr/lib/libgmp.so.10.1.1 +7f054bf6c000-7f054c16b000 ---p 0006d000 08:12 1182009 /usr/lib/libgmp.so.10.1.1 +7f054c16b000-7f054c16c000 r--p 0006c000 08:12 1182009 /usr/lib/libgmp.so.10.1.1 +7f054c16c000-7f054c175000 rw-p 0006d000 08:12 1182009 /usr/lib/libgmp.so.10.1.1 +7f054c175000-7f054c187000 r-xp 00000000 08:12 1195339 /usr/lib/libhogweed.so.2.3 +7f054c187000-7f054c386000 ---p 00012000 08:12 1195339 /usr/lib/libhogweed.so.2.3 +7f054c386000-7f054c387000 r--p 00011000 08:12 1195339 /usr/lib/libhogweed.so.2.3 +7f054c387000-7f054c388000 rw-p 00012000 08:12 1195339 /usr/lib/libhogweed.so.2.3 +7f054c388000-7f054c3b1000 r-xp 00000000 08:12 1195342 /usr/lib/libnettle.so.4.5 +7f054c3b1000-7f054c5b1000 ---p 00029000 08:12 1195342 /usr/lib/libnettle.so.4.5 +7f054c5b1000-7f054c5b2000 r--p 00029000 08:12 1195342 /usr/lib/libnettle.so.4.5 +7f054c5b2000-7f054c5b3000 rw-p 0002a000 08:12 1195342 /usr/lib/libnettle.so.4.5 +7f054c5b3000-7f054c5c5000 r-xp 00000000 08:12 1195333 /usr/lib/libtasn1.so.6.1.1 +7f054c5c5000-7f054c7c4000 ---p 00012000 08:12 1195333 /usr/lib/libtasn1.so.6.1.1 +7f054c7c4000-7f054c7c5000 r--p 00011000 08:12 1195333 /usr/lib/libtasn1.so.6.1.1 +7f054c7c5000-7f054c7c6000 rw-p 00012000 08:12 1195333 /usr/lib/libtasn1.so.6.1.1 +7f054c7c6000-7f054c7d9000 r-xp 00000000 08:12 1195353 /usr/lib/libp11-kit.so.0.0.0 +7f054c7d9000-7f054c9d8000 ---p 00013000 08:12 1195353 /usr/lib/libp11-kit.so.0.0.0 +7f054c9d8000-7f054c9d9000 r--p 00012000 08:12 1195353 /usr/lib/libp11-kit.so.0.0.0 +7f054c9d9000-7f054c9da000 rw-p 00013000 08:12 1195353 /usr/lib/libp11-kit.so.0.0.0 +7f054c9da000-7f054c9ed000 r-xp 00000000 08:12 1175130 /usr/lib/libresolv-2.17.so +7f054c9ed000-7f054cbed000 ---p 00013000 08:12 1175130 /usr/lib/libresolv-2.17.so +7f054cbed000-7f054cbee000 r--p 00013000 08:12 1175130 /usr/lib/libresolv-2.17.so +7f054cbee000-7f054cbef000 rw-p 00014000 08:12 1175130 /usr/lib/libresolv-2.17.so +7f054cbef000-7f054cbf1000 rw-p 00000000 00:00 0 +7f054cbf1000-7f054cbf9000 r-xp 00000000 08:12 1175116 /usr/lib/libcrypt-2.17.so +7f054cbf9000-7f054cdf8000 ---p 00008000 08:12 1175116 /usr/lib/libcrypt-2.17.so +7f054cdf8000-7f054cdf9000 r--p 00007000 08:12 1175116 /usr/lib/libcrypt-2.17.so +7f054cdf9000-7f054cdfa000 rw-p 00008000 08:12 1175116 /usr/lib/libcrypt-2.17.so +7f054cdfa000-7f054ce28000 rw-p 00000000 00:00 0 +7f054ce28000-7f054ce6c000 r-xp 00000000 08:12 1193776 /usr/lib/libdbus-1.so.3.7.2 +7f054ce6c000-7f054d06c000 ---p 00044000 08:12 1193776 /usr/lib/libdbus-1.so.3.7.2 +7f054d06c000-7f054d06d000 r--p 00044000 08:12 1193776 /usr/lib/libdbus-1.so.3.7.2 +7f054d06d000-7f054d06e000 rw-p 00045000 08:12 1193776 /usr/lib/libdbus-1.so.3.7.2 +7f054d06e000-7f054d0d4000 r-xp 00000000 08:12 792323 /usr/lib/pulseaudio/libpulsecommon-3.0.so +7f054d0d4000-7f054d2d3000 ---p 00066000 08:12 792323 /usr/lib/pulseaudio/libpulsecommon-3.0.so +7f054d2d3000-7f054d2d4000 r--p 00065000 08:12 792323 /usr/lib/pulseaudio/libpulsecommon-3.0.so +7f054d0d4000-7f054d2d3000 ---p 00066000 08:12 792323 /usr/lib/pulseaudio/libpulsecommon-3.0.so +7f054d2d3000-7f054d2d4000 r--p 00065000 08:12 792323 /usr/lib/pulseaudio/libpulsecommon-3.0.so +7f054d2d4000-7f054d2d6000 rw-p 00066000 08:12 792323 /usr/lib/pulseaudio/libpulsecommon-3.0.so +7f054d2d6000-7f054d2df000 r-xp 00000000 08:12 1184982 /usr/lib/libjson.so.0.1.0 +7f054d2df000-7f054d4de000 ---p 00009000 08:12 1184982 /usr/lib/libjson.so.0.1.0 +7f054d4de000-7f054d4df000 r--p 00008000 08:12 1184982 /usr/lib/libjson.so.0.1.0 +7f054d4df000-7f054d4e0000 rw-p 00009000 08:12 1184982 /usr/lib/libjson.so.0.1.0 +7f054d4e0000-7f054d6c0000 r-xp 00000000 08:12 1216755 /usr/lib/libcrypto.so.1.0.0 +7f054d6c0000-7f054d8c0000 ---p 001e0000 08:12 1216755 /usr/lib/libcrypto.so.1.0.0 +7f054d8c0000-7f054d8db000 r--p 001e0000 08:12 1216755 /usr/lib/libcrypto.so.1.0.0 +7f054d8db000-7f054d8e6000 rw-p 001fb000 08:12 1216755 /usr/lib/libcrypto.so.1.0.0 +7f054d8e6000-7f054d8ea000 rw-p 00000000 00:00 0 +7f054d8ea000-7f054d94c000 r-xp 00000000 08:12 1216754 /usr/lib/libssl.so.1.0.0 +7f054d94c000-7f054db4b000 ---p 00062000 08:12 1216754 /usr/lib/libssl.so.1.0.0 +7f054db4b000-7f054db4f000 r--p 00061000 08:12 1216754 /usr/lib/libssl.so.1.0.0 +7f054db4f000-7f054db56000 rw-p 00065000 08:12 1216754 /usr/lib/libssl.so.1.0.0 +7f054db56000-7f054db7d000 r-xp 00000000 08:12 1192299 /usr/lib/libssh2.so.1.0.1 +7f054db7d000-7f054dd7d000 ---p 00027000 08:12 1192299 /usr/lib/libssh2.so.1.0.1 +7f054dd7d000-7f054dd7e000 r--p 00027000 08:12 1192299 /usr/lib/libssh2.so.1.0.1 +7f054dd7e000-7f054dd7f000 rw-p 00028000 08:12 1192299 /usr/lib/libssh2.so.1.0.1 +7f054dd7f000-7f054dd80000 rw-p 00000000 00:00 0 +7f054dd80000-7f054dd83000 r-xp 00000000 08:12 1175118 /usr/lib/libdl-2.17.so +7f054dd83000-7f054df82000 ---p 00003000 08:12 1175118 /usr/lib/libdl-2.17.so +7f054df82000-7f054df83000 r--p 00002000 08:12 1175118 /usr/lib/libdl-2.17.so +7f054df83000-7f054df84000 rw-p 00003000 08:12 1175118 /usr/lib/libdl-2.17.so +7f054df84000-7f054df87000 r-xp 00000000 08:12 1195020 /usr/lib/libplds4.so +7f054df87000-7f054e186000 ---p 00003000 08:12 1195020 /usr/lib/libplds4.so +7f054e186000-7f054e187000 r--p 00002000 08:12 1195020 /usr/lib/libplds4.so +7f054e187000-7f054e188000 rw-p 00003000 08:12 1195020 /usr/lib/libplds4.so +7f054e188000-7f054e18c000 r-xp 00000000 08:12 1195021 /usr/lib/libplc4.so +7f054e18c000-7f054e38b000 ---p 00004000 08:12 1195021 /usr/lib/libplc4.so +7f054e38b000-7f054e38c000 r--p 00003000 08:12 1195021 /usr/lib/libplc4.so +7f054e38c000-7f054e38d000 rw-p 00004000 08:12 1195021 /usr/lib/libplc4.so +7f054e38d000-7f054e38e000 rw-p 00000000 00:00 0 +7f054e38e000-7f054e3b3000 r-xp 00000000 08:12 1195095 /usr/lib/libnssutil3.so +7f054e3b3000-7f054e5b2000 ---p 00025000 08:12 1195095 /usr/lib/libnssutil3.so +7f054e5b2000-7f054e5b8000 r--p 00024000 08:12 1195095 /usr/lib/libnssutil3.so +7f054e5b8000-7f054e5b9000 rw-p 0002a000 08:12 1195095 /usr/lib/libnssutil3.so +7f054e5b9000-7f054e61a000 r-xp 00000000 08:12 1183254 /usr/lib/libpcre.so.1.2.0 +7f054e61a000-7f054e81a000 ---p 00061000 08:12 1183254 /usr/lib/libpcre.so.1.2.0 +7f054e81a000-7f054e81b000 r--p 00061000 08:12 1183254 /usr/lib/libpcre.so.1.2.0 +7f054e81b000-7f054e81c000 rw-p 00062000 08:12 1183254 /usr/lib/libpcre.so.1.2.0 +7f054e81c000-7f054e9c0000 r-xp 00000000 08:12 1175073 /usr/lib/libc-2.17.so +7f054e9c0000-7f054ebbf000 ---p 001a4000 08:12 1175073 /usr/lib/libc-2.17.so +7f054ebbf000-7f054ebc3000 r--p 001a3000 08:12 1175073 /usr/lib/libc-2.17.so +7f054ebc3000-7f054ebc5000 rw-p 001a7000 08:12 1175073 /usr/lib/libc-2.17.so +7f054ebc5000-7f054ebca000 rw-p 00000000 00:00 0 +7f054ebca000-7f054ebdf000 r-xp 00000000 08:12 1181365 /usr/lib/libz.so.1.2.7 +7f054ebdf000-7f054edde000 ---p 00015000 08:12 1181365 /usr/lib/libz.so.1.2.7 +7f054edde000-7f054eddf000 r--p 00014000 08:12 1181365 /usr/lib/libz.so.1.2.7 +7f054eddf000-7f054ede0000 rw-p 00015000 08:12 1181365 /usr/lib/libz.so.1.2.7 +7f054ede0000-7f054eedd000 r-xp 00000000 08:12 1175074 /usr/lib/libm-2.17.so +7f054eedd000-7f054f0dc000 ---p 000fd000 08:12 1175074 /usr/lib/libm-2.17.so +7f054f0dc000-7f054f0dd000 r--p 000fc000 08:12 1175074 /usr/lib/libm-2.17.so +7f054f0dd000-7f054f0de000 rw-p 000fd000 08:12 1175074 /usr/lib/libm-2.17.so +7f054f0de000-7f054f211000 r-xp 00000000 08:12 1197495 /usr/lib/libX11.so.6.3.0 +7f054f211000-7f054f411000 ---p 00133000 08:12 1197495 /usr/lib/libX11.so.6.3.0 +7f054f411000-7f054f412000 r--p 00133000 08:12 1197495 /usr/lib/libX11.so.6.3.0 +7f054f412000-7f054f417000 rw-p 00134000 08:12 1197495 /usr/lib/libX11.so.6.3.0 +7f054f417000-7f054f47f000 r-xp 00000000 08:12 1207484 /usr/lib/libSDL-1.2.so.0.11.4 +7f054f47f000-7f054f67f000 ---p 00068000 08:12 1207484 /usr/lib/libSDL-1.2.so.0.11.4 +7f054f67f000-7f054f680000 r--p 00068000 08:12 1207484 /usr/lib/libSDL-1.2.so.0.11.4 +7f054f680000-7f054f681000 rw-p 00069000 08:12 1207484 /usr/lib/libSDL-1.2.so.0.11.4 +7f054f681000-7f054f6af000 rw-p 00000000 00:00 0 +7f054f6af000-7f054f7b1000 r-xp 00000000 08:12 1200422 /usr/lib/libgnutls.so.28.16.1 +7f054f7b1000-7f054f9b1000 ---p 00102000 08:12 1200422 /usr/lib/libgnutls.so.28.16.1 +7f054f9b1000-7f054f9b9000 r--p 00102000 08:12 1200422 /usr/lib/libgnutls.so.28.16.1 +7f054f9b9000-7f054f9bb000 rw-p 0010a000 08:12 1200422 /usr/lib/libgnutls.so.28.16.1 + +On Thu, Mar 07, 2013 at 11:02:07AM -0000, Helge Rausch wrote: +> When a block-stream is initiated via QMP and the QMP socket is closed on +> client side before the job is finished, QEMU crashes with a buffer +> overflow, somewhere at the end of the streaming process. +> +> Without QMP I can stream via the HMP without problems. After crashing, I +> cannot boot from the active image anymore. +> +> I was able to reproduce this with qemu-kvm and qemu-system-x86_64 on two +> different machines. +> +> Version: +> QEMU emulator version 1.2.0 (qemu-kvm-1.2.0), Copyright (c) 2003-2008 Fabrice Bellard + +I cannot reproduce this with qemu-system-x86-1.2.2-6.fc18.x86_64. + +> I started QEMU with the following script: +> +> qemu-kvm \ +> -monitor vc \ +> -m 512 \ +> -hda "$1" \ +> -net nic,vlan=0 \ +> -net user,vlan=0 \ +> -localtime \ +> -smp 2 \ +> -qmp tcp:localhost:4444,server,nowait + +I used your command-line and the following QMP commands: + +$ QMP/qmp-shell localhost:4444 +(QEMU) blockdev-snapshot-sync device=ide0-hd0 snapshot-file=test2.qcow2 +(QEMU) block-stream ide0-hd0 +(QEMU) query-block-jobs +...output shows the job running... +(QEMU) Ctrl+D + +The block job completes successfully and I get no crash. + +Please try qemu.git/master to see if the bug is still there for you: + +$ git clone git://git.qemu-project.org/qemu.git +$ cd qemu +$ ./configure --target-list=x86_64-softmmu +$ make +$ x86_64-softmmu/qemu-system-x86_64-softmmu -enable-kvm ... + +Stefan + + +I cannot reproduce it anymore on master. One option we now have without building it ourselves is using 1.4.0 from Ubuntu's raring derivate. Would you consider that stable enough for production use (the qemu package, not raring)? + +On Thu, Mar 07, 2013 at 06:14:27PM -0000, Helge Rausch wrote: +> I cannot reproduce it anymore on master. One option we now have without +> building it ourselves is using 1.4.0 from Ubuntu's raring derivate. +> Would you consider that stable enough for production use (the qemu +> package, not raring)? + +QEMU 1.4.0 is a stable release, it is intended for production use. + +I can't speak for Ubuntu packaging of QEMU 1.4.0, perhaps check the bug +tracker to see if there are known issues with the package. + +Stefan + + +Alright. Thank you! + +1.4.0 is the intended stable release for Ubuntu raring. + diff --git a/results/classifier/105/mistranslation/1153 b/results/classifier/105/mistranslation/1153 new file mode 100644 index 000000000..ab0483d1e --- /dev/null +++ b/results/classifier/105/mistranslation/1153 @@ -0,0 +1,14 @@ +mistranslation: 0.950 +device: 0.688 +graphic: 0.329 +semantic: 0.247 +network: 0.154 +other: 0.111 +vnc: 0.101 +boot: 0.091 +assembly: 0.038 +instruction: 0.030 +socket: 0.029 +KVM: 0.010 + +arm: wrong syndrome reported for FP and SIMD traps to AArch32 Hyp diff --git a/results/classifier/105/mistranslation/1161 b/results/classifier/105/mistranslation/1161 new file mode 100644 index 000000000..45afa1b49 --- /dev/null +++ b/results/classifier/105/mistranslation/1161 @@ -0,0 +1,14 @@ +mistranslation: 0.652 +device: 0.455 +vnc: 0.365 +graphic: 0.359 +boot: 0.289 +network: 0.204 +instruction: 0.149 +semantic: 0.052 +other: 0.043 +socket: 0.028 +assembly: 0.012 +KVM: 0.008 + +revise docs/interop/virtio-balloon-stats.rst diff --git a/results/classifier/105/mistranslation/1169 b/results/classifier/105/mistranslation/1169 new file mode 100644 index 000000000..da4601157 --- /dev/null +++ b/results/classifier/105/mistranslation/1169 @@ -0,0 +1,16 @@ +mistranslation: 0.771 +semantic: 0.669 +device: 0.655 +other: 0.576 +graphic: 0.355 +network: 0.348 +boot: 0.258 +instruction: 0.236 +vnc: 0.210 +socket: 0.205 +KVM: 0.154 +assembly: 0.067 + +rename snapshot by qemu-img +Additional information: +I have no idea to rename a snapshot which created by `qemu-img snapshot -c`, I think it is a useful function diff --git a/results/classifier/105/mistranslation/1172 b/results/classifier/105/mistranslation/1172 new file mode 100644 index 000000000..701f7cba1 --- /dev/null +++ b/results/classifier/105/mistranslation/1172 @@ -0,0 +1,72 @@ +mistranslation: 0.636 +device: 0.579 +socket: 0.569 +semantic: 0.495 +vnc: 0.441 +graphic: 0.435 +network: 0.417 +assembly: 0.401 +other: 0.363 +instruction: 0.355 +boot: 0.269 +KVM: 0.138 + +Make pixman an optional dependency +Additional information: +Only these files use pixman functions (excluding tests, of course): +``` +meson.build +contrib/vhost-user-gpu/vhost-user-gpu.c +contrib/vhost-user-gpu/meson.build +chardev/meson.build +include/ui/spice-display.h +include/ui/sdl2.h +include/ui/gtk.h +include/ui/qemu-pixman.h +include/ui/console.h +include/hw/display/xlnx_dp.h +include/hw/virtio/virtio-gpu.h +include/hw/virtio/virtio-gpu-pixman.h +hw/display/vga.c +hw/display/ramfb.c +hw/display/vhost-user-gpu.c +hw/display/virtio-gpu-gl.c +hw/display/virtio-gpu-udmabuf.c +hw/display/xenfb.c +hw/display/ati_2d.c +hw/display/meson.build +hw/display/vmware_vga.c +hw/display/qxl-render.c +hw/display/xlnx_dp.c +hw/display/bochs-display.c +hw/display/sm501.c +hw/display/virtio-gpu.c +hw/vfio/display.c +hw/s390x/meson.build +ui/cocoa.m +ui/console-gl.c +ui/vnc.c +ui/qemu-pixman.c +ui/gtk.c +ui/console.c +ui/trace-events +ui/meson.build +ui/dbus-listener.c +ui/vnc-enc-tight.c +ui/vnc.h +ui/spice-display.c +ui/dbus-display1.xml +ui/sdl2-2d.c +``` + +This code in `meson.build` always require **pixman** for building system emulators: +```meson +pixman = not_found +if have_system or have_tools + pixman = dependency('pixman-1', required: have_system, version:'>=0.21.8', + method: 'pkg-config', kwargs: static_kwargs) +endif +``` +https://gitlab.com/qemu-project/qemu/-/blob/master/meson.build#L520 + +Most of the code could work without it. diff --git a/results/classifier/105/mistranslation/1178 b/results/classifier/105/mistranslation/1178 new file mode 100644 index 000000000..75f5ad83f --- /dev/null +++ b/results/classifier/105/mistranslation/1178 @@ -0,0 +1,14 @@ +mistranslation: 0.938 +instruction: 0.789 +device: 0.714 +graphic: 0.533 +semantic: 0.478 +network: 0.383 +other: 0.331 +boot: 0.278 +assembly: 0.162 +vnc: 0.096 +KVM: 0.069 +socket: 0.062 + +is that riscv64 `feq.s` only should consider the lowest 32-bits. diff --git a/results/classifier/105/mistranslation/1178107 b/results/classifier/105/mistranslation/1178107 new file mode 100644 index 000000000..1788e1920 --- /dev/null +++ b/results/classifier/105/mistranslation/1178107 @@ -0,0 +1,37 @@ +mistranslation: 0.742 +other: 0.545 +device: 0.533 +graphic: 0.511 +semantic: 0.413 +instruction: 0.363 +socket: 0.253 +boot: 0.211 +vnc: 0.199 +network: 0.164 +assembly: 0.033 +KVM: 0.030 + +qemu-system-*.exe -cpu ? (or -M ?) exit silently + +For example, 'qemu-system-arm -cpu ?' on Linux host give me available cpu list: + +Available CPUs: + arm1026 + arm1136 + arm1136-r2 + ... + +But on Windows host, I got nothing: + +C:\opt\qemu-1.5.0-rc0-win64>qemu-system-arm -cpu ? + +C:\opt\qemu-1.5.0-rc0-win64>echo %ERRORLEVEL% +0 + +Can you still reproduce this problem with the latest version of QEMU? + +This usually means that mingw(?) has been configured such that stdout/stderr from a program goes to a text file in the current working directory rather than to the console. + + +OK, so this is not a bug, but a feature of MiNGW (or SDL? ... now that you've mentioned it, I remember there was something similar in libSDL on Windows), thus let's close this ticket. + diff --git a/results/classifier/105/mistranslation/1179664 b/results/classifier/105/mistranslation/1179664 new file mode 100644 index 000000000..2842cc88d --- /dev/null +++ b/results/classifier/105/mistranslation/1179664 @@ -0,0 +1,64 @@ +mistranslation: 0.651 +socket: 0.625 +device: 0.624 +instruction: 0.521 +semantic: 0.496 +vnc: 0.401 +network: 0.352 +boot: 0.335 +other: 0.280 +graphic: 0.178 +assembly: 0.124 +KVM: 0.098 + +migration.c:293: undefined reference to `__sync_val_compare_and_swap_4' + +latest git qemu error i get on compiling with mingw + + LINK i386-softmmu/qemu-system-i386w.exe +../migration.o: In function `migrate_finish_set_state': +C:\MinGW\msys\1.0\home\therock247uk\qemu/migration.c:293: undefined reference to + `__sync_val_compare_and_swap_4' +C:\MinGW\msys\1.0\home\therock247uk\qemu/migration.c:293: undefined reference to + `__sync_val_compare_and_swap_4' +C:\MinGW\msys\1.0\home\therock247uk\qemu/migration.c:293: undefined reference to + `__sync_val_compare_and_swap_4' +collect2.exe: error: ld returned 1 exit status +make[1]: *** [qemu-system-i386w.exe] Error 1 +make: *** [subdir-i386-softmmu] Error 2 + +On Mon, May 13, 2013 at 08:46:27PM -0000, therock247uk wrote: +> Public bug reported: +> +> latest git qemu error i get on compiling with mingw +> +> LINK i386-softmmu/qemu-system-i386w.exe +> ../migration.o: In function `migrate_finish_set_state': +> C:\MinGW\msys\1.0\home\therock247uk\qemu/migration.c:293: undefined reference to +> `__sync_val_compare_and_swap_4' +> C:\MinGW\msys\1.0\home\therock247uk\qemu/migration.c:293: undefined reference to +> `__sync_val_compare_and_swap_4' +> C:\MinGW\msys\1.0\home\therock247uk\qemu/migration.c:293: undefined reference to +> `__sync_val_compare_and_swap_4' +> collect2.exe: error: ld returned 1 exit status +> make[1]: *** [qemu-system-i386w.exe] Error 1 +> make: *** [subdir-i386-softmmu] Error 2 + +Please post your gcc version: + + $ gcc --version + + +therock247uk@dell-PC ~ +$ gcc --version +gcc.exe (GCC) 4.7.2 +Copyright (C) 2012 Free Software Foundation, Inc. +This is free software; see the source for copying conditions. There is NO +warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + + +therock247uk@dell-PC ~ +$ + +I assume this had been fixed by this commit here: http://git.qemu.org/?p=qemu.git;a=commitdiff;h=1405b6290fa2143e02dce - so I'm closing this ticket now. If you still hit the problem with the latest version of QEMU, please feel free to open this ticket again. + diff --git a/results/classifier/105/mistranslation/1179731 b/results/classifier/105/mistranslation/1179731 new file mode 100644 index 000000000..4e0f890be --- /dev/null +++ b/results/classifier/105/mistranslation/1179731 @@ -0,0 +1,59 @@ +mistranslation: 0.903 +network: 0.890 +instruction: 0.819 +KVM: 0.800 +other: 0.788 +graphic: 0.770 +device: 0.767 +semantic: 0.750 +socket: 0.691 +vnc: 0.656 +boot: 0.499 +assembly: 0.387 + +is networking broken on windows hosts? + +just wondering as i just compiled the latest git and qemu goes into none responding mode when i try to do any networking stuff on guests (both linux and windows) + +On Tue, May 14, 2013 at 12:02:24AM -0000, therock247uk wrote: +> just wondering as i just compiled the latest git and qemu goes into none +> responding mode when i try to do any networking stuff on guests (both +> linux and windows) + +Works for me on qemu.git/master on Linux: + + $ git rev-parse HEAD + b087143b4d010451208264b7c841436aafe1cbb1 + $ x86_64-softmmu/qemu-system-x86_64 -m 1024 -enable-kvm -cpu host \ + -drive if=virtio,cache=none,file=test.img + +Please include more information, like the QEMU command-line and commit +ID. + +Stefan + + +latest git as of yesterday compiled under mingw using qemu-system-i386 -localtime -m 512 windows.img when ever it connects to the internet qemu hangs. + +trying other network adapters does not help either i tried the model=rtl8139 and the xp guest says limited or no connectivty. + +tried the patch did not work though still hangs/crashes has issues + +On 05/16/2013 10:59 AM, Paolo Bonzini wrote: +> Il 16/05/2013 07:52, TeLeMan ha scritto: +>> The patch is working on 134a03e0b3d34b01b68107104c525c3bff1211d4 and +>> is not working from cbff4b342b000a7642125dbdabf61113e05eee44. +> +> Thanks. +> +> Fabien or Stefan, can you take a look? +> + +Unfortunately I don't have time to investigate these days. + +-- +Fabien Chouteau + + +Looking at http://lists.gnu.org/archive/html/qemu-devel/2013-05/msg02268.html it seems this has been fixed with commits 8db165b36ef893ac69af045 and 3cb8c205e36531a07dff1d84 ==> setting status to "Fix released" + diff --git a/results/classifier/105/mistranslation/1180777 b/results/classifier/105/mistranslation/1180777 new file mode 100644 index 000000000..89fdd6933 --- /dev/null +++ b/results/classifier/105/mistranslation/1180777 @@ -0,0 +1,1329 @@ +mistranslation: 0.866 +semantic: 0.856 +instruction: 0.855 +network: 0.847 +device: 0.828 +other: 0.825 +assembly: 0.819 +vnc: 0.770 +boot: 0.746 +graphic: 0.739 +KVM: 0.700 +socket: 0.650 + +RDP traffic freeze on quiet network + +Hi, + +I recently started using KVM over VirtualBox for my Office needs. I setup a Windows 7 VM on KVM and started using it through remote desktop. + +What happens is that, after some hours of usage, the remote desktop connection freezes. I thought it was a remmina bug, as the it was enough to kill and restart it to successfully connect again to the VM. + +However, today I've switched to a different RDP client (2X Client chromium app) and the freeze just happened again! + +Some information: +- the host and the VM are completely idle when the freeze occurs +- I've tried sniffing the network packets toward the RDP port during the freeze and found that the client is sending packets but no packet is sent back + + +Could this be a KVM issue? How can I further debug this one (I expect the freeze to happen again...)? + +ProblemType: Bug +DistroRelease: Ubuntu 12.04 +Package: kvm 1:84+dfsg-0ubuntu16+1.0+noroms+0ubuntu14.8 +ProcVersionSignature: Ubuntu 3.2.0-41.66-generic 3.2.42 +Uname: Linux 3.2.0-41-generic x86_64 +ApportVersion: 2.0.1-0ubuntu17.2 +Architecture: amd64 +Date: Thu May 16 14:12:40 2013 +MachineType: Hewlett-Packard HP ProBook 4520s +MarkForUpload: True +ProcEnviron: + TERM=xterm + PATH=(custom, no user) + LANG=en_US.UTF-8 + SHELL=/bin/bash +ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-41-generic root=UUID=D2E20BC3E20BAAB5 loop=/hostname/disks/root.disk ro quiet splash vt.handoff=7 +SourcePackage: qemu-kvm +UpgradeStatus: No upgrade log present (probably fresh install) +dmi.bios.date: 08/26/2010 +dmi.bios.vendor: Hewlett-Packard +dmi.bios.version: 68AZZ Ver. F.0A +dmi.board.name: 1411 +dmi.board.vendor: Hewlett-Packard +dmi.board.version: KBC Version 57.30 +dmi.chassis.type: 10 +dmi.chassis.vendor: Hewlett-Packard +dmi.modalias: dmi:bvnHewlett-Packard:bvr68AZZVer.F.0A:bd08/26/2010:svnHewlett-Packard:pnHPProBook4520s:pvr:rvnHewlett-Packard:rn1411:rvrKBCVersion57.30:cvnHewlett-Packard:ct10:cvr: +dmi.product.name: HP ProBook 4520s +dmi.sys.vendor: Hewlett-Packard + + + +Thanks for reporting this bug. Could you please give us more +information on the VM host and the client? What do you mean +by 'kvm over virtualbox'? How exactly did you set it up? +Is the remote desktop running on a windows machine? + +My guess is that the answer lies in 'kvm on virtualbox', and +how that is exporting a display to the client. + +Marking this incomplete, please feel free to re-mark it new +after replying. Marking low priority as, IF I understand right, +the VM continues to run, making this annoying but with no risk of +data loss. + + status: incomplete + importance: low + + +Hi Serge, + +Thanks for the reply. + + +What I meant is that I started using KVM for my virtualization needs, while I was previously using VirtualBox. Sorry for not being clear on this point. + + +Yes the VM continues to run, however it is pretty annoying and can potentially imply that for me Win 7 on KVM is not usable in practice (think about hangs during customer presentations... ). + + +Thanks. + + + + +Could you show the exact remmina command you were using to connect to the VM? + +If you do 'gvncviewer localhost:0' (from the same machine on which kvm is running), what do you see? + +Hi Serge, + +I'm invoking remmina from the Unity shell, not from the terminal. + +As regard your question: I'm connecting to the VM via RDP, not VNC (it is +much faster). + + +On 5 June 2013 00:07, Serge Hallyn <email address hidden> wrote: + +> Could you show the exact remmina command you were using to connect to +> the VM? +> +> If you do 'gvncviewer localhost:0' (from the same machine on which kvm +> is running), what do you see? +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1180777 +> +> Title: +> Windows 7 VM freeze on Ubuntu 12.04 KVM +> +> Status in “qemu-kvm” package in Ubuntu: +> New +> +> Bug description: +> Hi, +> +> I recently started using KVM over VirtualBox for my Office needs. I +> setup a Windows 7 VM on KVM and started using it through remote +> desktop. +> +> What happens is that, after some hours of usage, the remote desktop +> connection freezes. I thought it was a remmina bug, as the it was +> enough to kill and restart it to successfully connect again to the VM. +> +> However, today I've switched to a different RDP client (2X Client +> chromium app) and the freeze just happened again! +> +> Some information: +> - the host and the VM are completely idle when the freeze occurs +> - I've tried sniffing the network packets toward the RDP port during the +> freeze and found that the client is sending packets but no packet is sent +> back +> +> +> Could this be a KVM issue? How can I further debug this one (I expect +> the freeze to happen again...)? +> +> ProblemType: Bug +> DistroRelease: Ubuntu 12.04 +> Package: kvm 1:84+dfsg-0ubuntu16+1.0+noroms+0ubuntu14.8 +> ProcVersionSignature: Ubuntu 3.2.0-41.66-generic 3.2.42 +> Uname: Linux 3.2.0-41-generic x86_64 +> ApportVersion: 2.0.1-0ubuntu17.2 +> Architecture: amd64 +> Date: Thu May 16 14:12:40 2013 +> MachineType: Hewlett-Packard HP ProBook 4520s +> MarkForUpload: True +> ProcEnviron: +> TERM=xterm +> PATH=(custom, no user) +> LANG=en_US.UTF-8 +> SHELL=/bin/bash +> ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-41-generic +> root=UUID=D2E20BC3E20BAAB5 loop=/hostname/disks/root.disk ro quiet splash +> vt.handoff=7 +> SourcePackage: qemu-kvm +> UpgradeStatus: No upgrade log present (probably fresh install) +> dmi.bios.date: 08/26/2010 +> dmi.bios.vendor: Hewlett-Packard +> dmi.bios.version: 68AZZ Ver. F.0A +> dmi.board.name: 1411 +> dmi.board.vendor: Hewlett-Packard +> dmi.board.version: KBC Version 57.30 +> dmi.chassis.type: 10 +> dmi.chassis.vendor: Hewlett-Packard +> dmi.modalias: +> dmi:bvnHewlett-Packard:bvr68AZZVer.F.0A:bd08/26/2010:svnHewlett-Packard:pnHPProBook4520s:pvr:rvnHewlett-Packard:rn1411:rvrKBCVersion57.30:cvnHewlett-Packard:ct10:cvr: +> dmi.product.name: HP ProBook 4520s +> dmi.sys.vendor: Hewlett-Packard +> +> To manage notifications about this bug go to: +> +> https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/1180777/+subscriptions +> + + +Quoting f3a97 (<email address hidden>): +> Hi Serge, +> +> I'm invoking remmina from the Unity shell, not from the terminal. + +Could you please tell me, perhaps with some screenshots, exactly what +boxes you fill in how to start the connection? + +> As regard your question: I'm connecting to the VM via RDP, not VNC (it is +> much faster). + +IIUC RDP connects to the guest itself over the guest's network. vnc wlil +connect to the kvm process. So if the problem has to do with the +guest's networking hanging, then connecting over vnc might let you +analyze the guest state despite guest network being down. + +When the RDP connection hangs, can you simply start a new one +immediately? + + +Hi Serge, + +Please find attached the remmina configuration screenshots. + +Yes, when the RDP connection hangs I simply close the RDP client and start +a new one immediately and it works correctly. + +As I mentioned, please consider that this happens also with a completely +different RDP client, so it probably has nothing to do with remmina itself. + +Thank you! + + +On 5 June 2013 14:30, Serge Hallyn <email address hidden> wrote: + +> Quoting f3a97 (<email address hidden>): +> > Hi Serge, +> > +> > I'm invoking remmina from the Unity shell, not from the terminal. +> +> Could you please tell me, perhaps with some screenshots, exactly what +> boxes you fill in how to start the connection? +> +> > As regard your question: I'm connecting to the VM via RDP, not VNC (it is +> > much faster). +> +> IIUC RDP connects to the guest itself over the guest's network. vnc wlil +> connect to the kvm process. So if the problem has to do with the +> guest's networking hanging, then connecting over vnc might let you +> analyze the guest state despite guest network being down. +> +> When the RDP connection hangs, can you simply start a new one +> immediately? +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1180777 +> +> Title: +> Windows 7 VM freeze on Ubuntu 12.04 KVM +> +> Status in “qemu-kvm” package in Ubuntu: +> New +> +> Bug description: +> Hi, +> +> I recently started using KVM over VirtualBox for my Office needs. I +> setup a Windows 7 VM on KVM and started using it through remote +> desktop. +> +> What happens is that, after some hours of usage, the remote desktop +> connection freezes. I thought it was a remmina bug, as the it was +> enough to kill and restart it to successfully connect again to the VM. +> +> However, today I've switched to a different RDP client (2X Client +> chromium app) and the freeze just happened again! +> +> Some information: +> - the host and the VM are completely idle when the freeze occurs +> - I've tried sniffing the network packets toward the RDP port during the +> freeze and found that the client is sending packets but no packet is sent +> back +> +> +> Could this be a KVM issue? How can I further debug this one (I expect +> the freeze to happen again...)? +> +> ProblemType: Bug +> DistroRelease: Ubuntu 12.04 +> Package: kvm 1:84+dfsg-0ubuntu16+1.0+noroms+0ubuntu14.8 +> ProcVersionSignature: Ubuntu 3.2.0-41.66-generic 3.2.42 +> Uname: Linux 3.2.0-41-generic x86_64 +> ApportVersion: 2.0.1-0ubuntu17.2 +> Architecture: amd64 +> Date: Thu May 16 14:12:40 2013 +> MachineType: Hewlett-Packard HP ProBook 4520s +> MarkForUpload: True +> ProcEnviron: +> TERM=xterm +> PATH=(custom, no user) +> LANG=en_US.UTF-8 +> SHELL=/bin/bash +> ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-41-generic +> root=UUID=D2E20BC3E20BAAB5 loop=/hostname/disks/root.disk ro quiet splash +> vt.handoff=7 +> SourcePackage: qemu-kvm +> UpgradeStatus: No upgrade log present (probably fresh install) +> dmi.bios.date: 08/26/2010 +> dmi.bios.vendor: Hewlett-Packard +> dmi.bios.version: 68AZZ Ver. F.0A +> dmi.board.name: 1411 +> dmi.board.vendor: Hewlett-Packard +> dmi.board.version: KBC Version 57.30 +> dmi.chassis.type: 10 +> dmi.chassis.vendor: Hewlett-Packard +> dmi.modalias: +> dmi:bvnHewlett-Packard:bvr68AZZVer.F.0A:bd08/26/2010:svnHewlett-Packard:pnHPProBook4520s:pvr:rvnHewlett-Packard:rn1411:rvrKBCVersion57.30:cvnHewlett-Packard:ct10:cvr: +> dmi.product.name: HP ProBook 4520s +> dmi.sys.vendor: Hewlett-Packard +> +> To manage notifications about this bug go to: +> +> https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/1180777/+subscriptions +> + + +It just happened again. + +This time I have recorded some new information. + +netstat shows a costant, non zero Send-Q: + +@ubuntu:~/WORKS/Programs/apache-jmeter-2.9/bin$ date ; netstat -atn | grep +3389 +Wed Jun 5 15:23:24 CEST 2013 +tcp 0 7301 192.168.122.1:59458 192.168.122.116:3389 + ESTABLISHED +@ubuntu:~/WORKS/Programs/apache-jmeter-2.9/bin$ date ; netstat -atn | grep +3389 +Wed Jun 5 15:23:27 CEST 2013 +tcp 0 7301 192.168.122.1:59458 192.168.122.116:3389 + ESTABLISHED +@ubuntu:~/WORKS/Programs/apache-jmeter-2.9/bin$ date ; netstat -atn | grep +3389 +Wed Jun 5 15:23:47 CEST 2013 +tcp 0 7301 192.168.122.1:59458 192.168.122.116:3389 + ESTABLISHED +@ubuntu:~/WORKS/Programs/apache-jmeter-2.9/bin$ date ; netstat -atn | grep +3389 +Wed Jun 5 15:24:34 CEST 2013 +tcp 0 7301 192.168.122.1:59458 192.168.122.116:3389 + ESTABLISHED + +Sniffing that connection with tcpdump, I can see that no packets flows back +from the VM (port 3389) back to the client: + +15:22:03.402659 IP 192.168.122.1.59458 > 192.168.122.116.3389: Flags [P.], +seq 2389102186:2389102247, ack 1393955760, win 1968, options [nop,nop,TS +val 4537984 ecr 1648164], length 61 +15:22:03.402676 IP 192.168.122.1.59458 > 192.168.122.116.3389: Flags [P.], +seq 0:61, ack 1, win 1968, options [nop,nop,TS val 4537984 ecr 1648164], +length 61 + +--- 30 seconds here --- +15:24:03.722660 IP 192.168.122.1.59458 > 192.168.122.116.3389: Flags [P.], +seq 0:61, ack 1, win 1968, options [nop,nop,TS val 4568064 ecr 1648164], +length 61 +15:24:03.722675 IP 192.168.122.1.59458 > 192.168.122.116.3389: Flags [P.], +seq 0:61, ack 1, win 1968, options [nop,nop,TS val 4568064 ecr 1648164], +length 61 + + +Looks like a network issue? + + +On 5 June 2013 15:17, Stefano Doni <email address hidden> wrote: + +> Hi Serge, +> +> Please find attached the remmina configuration screenshots. +> +> Yes, when the RDP connection hangs I simply close the RDP client and start +> a new one immediately and it works correctly. +> +> As I mentioned, please consider that this happens also with a completely +> different RDP client, so it probably has nothing to do with remmina itself. +> +> Thank you! +> +> +> On 5 June 2013 14:30, Serge Hallyn <email address hidden> wrote: +> +>> Quoting f3a97 (<email address hidden>): +>> > Hi Serge, +>> > +>> > I'm invoking remmina from the Unity shell, not from the terminal. +>> +>> Could you please tell me, perhaps with some screenshots, exactly what +>> boxes you fill in how to start the connection? +>> +>> > As regard your question: I'm connecting to the VM via RDP, not VNC (it +>> is +>> > much faster). +>> +>> IIUC RDP connects to the guest itself over the guest's network. vnc wlil +>> connect to the kvm process. So if the problem has to do with the +>> guest's networking hanging, then connecting over vnc might let you +>> analyze the guest state despite guest network being down. +>> +>> When the RDP connection hangs, can you simply start a new one +>> immediately? +>> +>> -- +>> You received this bug notification because you are subscribed to the bug +>> report. +>> https://bugs.launchpad.net/bugs/1180777 +>> +>> Title: +>> Windows 7 VM freeze on Ubuntu 12.04 KVM +>> +>> Status in “qemu-kvm” package in Ubuntu: +>> New +>> +>> Bug description: +>> Hi, +>> +>> I recently started using KVM over VirtualBox for my Office needs. I +>> setup a Windows 7 VM on KVM and started using it through remote +>> desktop. +>> +>> What happens is that, after some hours of usage, the remote desktop +>> connection freezes. I thought it was a remmina bug, as the it was +>> enough to kill and restart it to successfully connect again to the VM. +>> +>> However, today I've switched to a different RDP client (2X Client +>> chromium app) and the freeze just happened again! +>> +>> Some information: +>> - the host and the VM are completely idle when the freeze occurs +>> - I've tried sniffing the network packets toward the RDP port during +>> the freeze and found that the client is sending packets but no packet is +>> sent back +>> +>> +>> Could this be a KVM issue? How can I further debug this one (I expect +>> the freeze to happen again...)? +>> +>> ProblemType: Bug +>> DistroRelease: Ubuntu 12.04 +>> Package: kvm 1:84+dfsg-0ubuntu16+1.0+noroms+0ubuntu14.8 +>> ProcVersionSignature: Ubuntu 3.2.0-41.66-generic 3.2.42 +>> Uname: Linux 3.2.0-41-generic x86_64 +>> ApportVersion: 2.0.1-0ubuntu17.2 +>> Architecture: amd64 +>> Date: Thu May 16 14:12:40 2013 +>> MachineType: Hewlett-Packard HP ProBook 4520s +>> MarkForUpload: True +>> ProcEnviron: +>> TERM=xterm +>> PATH=(custom, no user) +>> LANG=en_US.UTF-8 +>> SHELL=/bin/bash +>> ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-41-generic +>> root=UUID=D2E20BC3E20BAAB5 loop=/hostname/disks/root.disk ro quiet splash +>> vt.handoff=7 +>> SourcePackage: qemu-kvm +>> UpgradeStatus: No upgrade log present (probably fresh install) +>> dmi.bios.date: 08/26/2010 +>> dmi.bios.vendor: Hewlett-Packard +>> dmi.bios.version: 68AZZ Ver. F.0A +>> dmi.board.name: 1411 +>> dmi.board.vendor: Hewlett-Packard +>> dmi.board.version: KBC Version 57.30 +>> dmi.chassis.type: 10 +>> dmi.chassis.vendor: Hewlett-Packard +>> dmi.modalias: +>> dmi:bvnHewlett-Packard:bvr68AZZVer.F.0A:bd08/26/2010:svnHewlett-Packard:pnHPProBook4520s:pvr:rvnHewlett-Packard:rn1411:rvrKBCVersion57.30:cvnHewlett-Packard:ct10:cvr: +>> dmi.product.name: HP ProBook 4520s +>> dmi.sys.vendor: Hewlett-Packard +>> +>> To manage notifications about this bug go to: +>> +>> https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/1180777/+subscriptions +>> +> +> + + +Confirmed in raring. + +Actually no, in my case after I had started up IE and left it sitting, the desktop logged me out, which made windows change its network settings so that RDP was not allowed. I had to log back in over spicy before I could reconnect over RDP. + +In fact that did not suffice (this is raring, not precise) - windows needed to reboot to reset the model=rtl8139 nic (over tap device). + +Could you tell me which network device type you are using? + +It looks like I should set up a precise host on which to test. + +Hi Serge, + +Thanks for that. + +Please find attached my VM complete xml configuration file (virsh dumpxml). + + + +On 12 June 2013 21:21, Serge Hallyn <email address hidden> wrote: + +> In fact that did not suffice (this is raring, not precise) - windows +> needed to reboot to reset the model=rtl8139 nic (over tap device). +> +> Could you tell me which network device type you are using? +> +> It looks like I should set up a precise host on which to test. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1180777 +> +> Title: +> Windows 7 VM freeze on Ubuntu 12.04 KVM +> +> Status in “qemu-kvm” package in Ubuntu: +> Confirmed +> +> Bug description: +> Hi, +> +> I recently started using KVM over VirtualBox for my Office needs. I +> setup a Windows 7 VM on KVM and started using it through remote +> desktop. +> +> What happens is that, after some hours of usage, the remote desktop +> connection freezes. I thought it was a remmina bug, as the it was +> enough to kill and restart it to successfully connect again to the VM. +> +> However, today I've switched to a different RDP client (2X Client +> chromium app) and the freeze just happened again! +> +> Some information: +> - the host and the VM are completely idle when the freeze occurs +> - I've tried sniffing the network packets toward the RDP port during the +> freeze and found that the client is sending packets but no packet is sent +> back +> +> +> Could this be a KVM issue? How can I further debug this one (I expect +> the freeze to happen again...)? +> +> ProblemType: Bug +> DistroRelease: Ubuntu 12.04 +> Package: kvm 1:84+dfsg-0ubuntu16+1.0+noroms+0ubuntu14.8 +> ProcVersionSignature: Ubuntu 3.2.0-41.66-generic 3.2.42 +> Uname: Linux 3.2.0-41-generic x86_64 +> ApportVersion: 2.0.1-0ubuntu17.2 +> Architecture: amd64 +> Date: Thu May 16 14:12:40 2013 +> MachineType: Hewlett-Packard HP ProBook 4520s +> MarkForUpload: True +> ProcEnviron: +> TERM=xterm +> PATH=(custom, no user) +> LANG=en_US.UTF-8 +> SHELL=/bin/bash +> ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-41-generic +> root=UUID=D2E20BC3E20BAAB5 loop=/hostname/disks/root.disk ro quiet splash +> vt.handoff=7 +> SourcePackage: qemu-kvm +> UpgradeStatus: No upgrade log present (probably fresh install) +> dmi.bios.date: 08/26/2010 +> dmi.bios.vendor: Hewlett-Packard +> dmi.bios.version: 68AZZ Ver. F.0A +> dmi.board.name: 1411 +> dmi.board.vendor: Hewlett-Packard +> dmi.board.version: KBC Version 57.30 +> dmi.chassis.type: 10 +> dmi.chassis.vendor: Hewlett-Packard +> dmi.modalias: +> dmi:bvnHewlett-Packard:bvr68AZZVer.F.0A:bd08/26/2010:svnHewlett-Packard:pnHPProBook4520s:pvr:rvnHewlett-Packard:rn1411:rvrKBCVersion57.30:cvnHewlett-Packard:ct10:cvr: +> dmi.product.name: HP ProBook 4520s +> dmi.sys.vendor: Hewlett-Packard +> +> To manage notifications about this bug go to: +> +> https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/1180777/+subscriptions +> + + +Hi, + +(You probably knkow this, but to explain my request, the RDP connection goes over the VM's virtual network card to talk directly to the VM. Provided you have only a single VM running, 'gvncviewer localhost:0' (or the equivalent with ssh port forwarding if you can't run X on the host) talks to the kvm process.) + +Could you please start the VM, run RDP until it hangs, then connect with vnc and use the windows network admin commands to see what windows thinks is going on? I.e. does it think it is still connected to a network? If not, can you simply reconnect, or do you have to restart the driver, or do you have to restart the VM altogether? + +I'm pretty sure htis is a bug in the qemu nic emulation, but am not sure where to begin diagnosing. + +Hi Serge, + +I performed the experiment you suggested: + +1) Connected with RDP client +2) Worked until it hanged +3) Successfully connected to the VM via virt-manager (RDP client still +freezed) +4) Verified that Windows is still connected to the network +5) Successfully pinged my host IP from within the VM (ping 192.168.122.1) + + +So it doesn't seem to be a network disconnect issue. + + +Can you think of anything else? + + + +Thanks! + + + +On 27 June 2013 16:12, Serge Hallyn <email address hidden> wrote: + +> Hi, +> +> (You probably knkow this, but to explain my request, the RDP connection +> goes over the VM's virtual network card to talk directly to the VM. +> Provided you have only a single VM running, 'gvncviewer localhost:0' (or +> the equivalent with ssh port forwarding if you can't run X on the host) +> talks to the kvm process.) +> +> Could you please start the VM, run RDP until it hangs, then connect with +> vnc and use the windows network admin commands to see what windows +> thinks is going on? I.e. does it think it is still connected to a +> network? If not, can you simply reconnect, or do you have to restart +> the driver, or do you have to restart the VM altogether? +> +> I'm pretty sure htis is a bug in the qemu nic emulation, but am not sure +> where to begin diagnosing. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1180777 +> +> Title: +> Windows 7 VM freeze on Ubuntu 12.04 KVM +> +> Status in “qemu-kvm” package in Ubuntu: +> Confirmed +> +> Bug description: +> Hi, +> +> I recently started using KVM over VirtualBox for my Office needs. I +> setup a Windows 7 VM on KVM and started using it through remote +> desktop. +> +> What happens is that, after some hours of usage, the remote desktop +> connection freezes. I thought it was a remmina bug, as the it was +> enough to kill and restart it to successfully connect again to the VM. +> +> However, today I've switched to a different RDP client (2X Client +> chromium app) and the freeze just happened again! +> +> Some information: +> - the host and the VM are completely idle when the freeze occurs +> - I've tried sniffing the network packets toward the RDP port during the +> freeze and found that the client is sending packets but no packet is sent +> back +> +> +> Could this be a KVM issue? How can I further debug this one (I expect +> the freeze to happen again...)? +> +> ProblemType: Bug +> DistroRelease: Ubuntu 12.04 +> Package: kvm 1:84+dfsg-0ubuntu16+1.0+noroms+0ubuntu14.8 +> ProcVersionSignature: Ubuntu 3.2.0-41.66-generic 3.2.42 +> Uname: Linux 3.2.0-41-generic x86_64 +> ApportVersion: 2.0.1-0ubuntu17.2 +> Architecture: amd64 +> Date: Thu May 16 14:12:40 2013 +> MachineType: Hewlett-Packard HP ProBook 4520s +> MarkForUpload: True +> ProcEnviron: +> TERM=xterm +> PATH=(custom, no user) +> LANG=en_US.UTF-8 +> SHELL=/bin/bash +> ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-41-generic +> root=UUID=D2E20BC3E20BAAB5 loop=/hostname/disks/root.disk ro quiet splash +> vt.handoff=7 +> SourcePackage: qemu-kvm +> UpgradeStatus: No upgrade log present (probably fresh install) +> dmi.bios.date: 08/26/2010 +> dmi.bios.vendor: Hewlett-Packard +> dmi.bios.version: 68AZZ Ver. F.0A +> dmi.board.name: 1411 +> dmi.board.vendor: Hewlett-Packard +> dmi.board.version: KBC Version 57.30 +> dmi.chassis.type: 10 +> dmi.chassis.vendor: Hewlett-Packard +> dmi.modalias: +> dmi:bvnHewlett-Packard:bvr68AZZVer.F.0A:bd08/26/2010:svnHewlett-Packard:pnHPProBook4520s:pvr:rvnHewlett-Packard:rn1411:rvrKBCVersion57.30:cvnHewlett-Packard:ct10:cvr: +> dmi.product.name: HP ProBook 4520s +> dmi.sys.vendor: Hewlett-Packard +> +> To manage notifications about this bug go to: +> +> https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/1180777/+subscriptions +> + + +Quoting f3a97 (<email address hidden>): +> Hi Serge, +> +> I performed the experiment you suggested: +> +> 1) Connected with RDP client +> 2) Worked until it hanged +> 3) Successfully connected to the VM via virt-manager (RDP client still +> freezed) +> 4) Verified that Windows is still connected to the network +> 5) Successfully pinged my host IP from within the VM (ping 192.168.122.1) + +Thanks! So just to be sure, after this did you check whether the RDP +client worked again? If not, were you able to re-connect with a new +RDP client? If so, then can you also re-connect with a new RDP client +without first connecting via VNC and pinging the host from the guest? +(This should tell us whether the problem is the RDP server in windows, +or the network connection at some layer going stale until we ping). + + +Hi Serge, + +In order to reconnect, I have simply restarted another RDP client without +any further step required (no need to use VNC and ping, it was just a test +to check network connectivity). + + +On 24 July 2013 15:16, Serge Hallyn <email address hidden> wrote: + +> Quoting f3a97 (<email address hidden>): +> > Hi Serge, +> > +> > I performed the experiment you suggested: +> > +> > 1) Connected with RDP client +> > 2) Worked until it hanged +> > 3) Successfully connected to the VM via virt-manager (RDP client still +> > freezed) +> > 4) Verified that Windows is still connected to the network +> > 5) Successfully pinged my host IP from within the VM (ping 192.168.122.1) +> +> Thanks! So just to be sure, after this did you check whether the RDP +> client worked again? If not, were you able to re-connect with a new +> RDP client? If so, then can you also re-connect with a new RDP client +> without first connecting via VNC and pinging the host from the guest? +> (This should tell us whether the problem is the RDP server in windows, +> or the network connection at some layer going stale until we ping). +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1180777 +> +> Title: +> Windows 7 VM freeze on Ubuntu 12.04 KVM +> +> Status in “qemu-kvm” package in Ubuntu: +> Confirmed +> +> Bug description: +> Hi, +> +> I have recently setup a Windows 7 VM on KVM and started using it +> through remote desktop. +> +> What happens is that, after some hours of usage, the remote desktop +> connection freezes. I thought it was a remmina bug, as the it was +> enough to kill and restart it to successfully connect again to the VM. +> +> However, today I've switched to a different RDP client (2X Client +> chromium app) and the freeze just happened again! +> +> Some information: +> - the host and the VM are completely idle when the freeze occurs +> - I've tried sniffing the network packets toward the RDP port during the +> freeze and found that the client is sending packets but no packet is sent +> back +> +> Could this be a KVM issue? How can I further debug this one (I expect +> the freeze to happen again...)? +> +> ProblemType: Bug +> DistroRelease: Ubuntu 12.04 +> Package: kvm 1:84+dfsg-0ubuntu16+1.0+noroms+0ubuntu14.8 +> ProcVersionSignature: Ubuntu 3.2.0-41.66-generic 3.2.42 +> Uname: Linux 3.2.0-41-generic x86_64 +> ApportVersion: 2.0.1-0ubuntu17.2 +> Architecture: amd64 +> Date: Thu May 16 14:12:40 2013 +> MachineType: Hewlett-Packard HP ProBook 4520s +> MarkForUpload: True +> ProcEnviron: +> TERM=xterm +> PATH=(custom, no user) +> LANG=en_US.UTF-8 +> SHELL=/bin/bash +> ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-41-generic +> root=UUID=D2E20BC3E20BAAB5 loop=/hostname/disks/root.disk ro quiet splash +> vt.handoff=7 +> SourcePackage: qemu-kvm +> UpgradeStatus: No upgrade log present (probably fresh install) +> dmi.bios.date: 08/26/2010 +> dmi.bios.vendor: Hewlett-Packard +> dmi.bios.version: 68AZZ Ver. F.0A +> dmi.board.name: 1411 +> dmi.board.vendor: Hewlett-Packard +> dmi.board.version: KBC Version 57.30 +> dmi.chassis.type: 10 +> dmi.chassis.vendor: Hewlett-Packard +> dmi.modalias: +> dmi:bvnHewlett-Packard:bvr68AZZVer.F.0A:bd08/26/2010:svnHewlett-Packard:pnHPProBook4520s:pvr:rvnHewlett-Packard:rn1411:rvrKBCVersion57.30:cvnHewlett-Packard:ct10:cvr: +> dmi.product.name: HP ProBook 4520s +> dmi.sys.vendor: Hewlett-Packard +> +> To manage notifications about this bug go to: +> +> https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/1180777/+subscriptions +> + + +Hi, + +I reported the #1212051 (https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/1212051) bug with Windows XP, but reading this case i think it could be the same issue. + +I connect via RDP to my windows XP VM and after a while it seems to freeze, then, I connect via VNC an without doing anything the communications are restored between the VM and the outside world. So i can connect again with RDP. + +Even more, if i leave an open connection with VNC (minimized because is more slow than RDP), connecting via RDP has no trouble and no problem of freeze (lost of communications) occurs. + +f3a97, Could you do this test and tell if you have the same experience than i?, If so, my bug is the same of this. +Thanks. + + +Hi Hector, + + +My network configuration is different than yours - it is not bridged. +Perhaps this might help to diagnose the issue? + + +I'm now trying to sniff network traffic generated by the VM and see what +happens during RDP hangs: does it still poll outside servers (i.e. google +drive) or will become disconnected? + + +I'll report the results, stay tuned. + + +On 19 August 2013 00:42, Hector Perez <email address hidden> wrote: + +> Hi, +> +> I reported the #1212051 (https://bugs.launchpad.net/ubuntu/+source/qemu- +> kvm/+bug/1212051) bug with Windows XP, but reading this case i think it +> could be the same issue. +> +> I connect via RDP to my windows XP VM and after a while it seems to +> freeze, then, I connect via VNC an without doing anything the +> communications are restored between the VM and the outside world. So i +> can connect again with RDP. +> +> Even more, if i leave an open connection with VNC (minimized because is +> more slow than RDP), connecting via RDP has no trouble and no problem of +> freeze (lost of communications) occurs. +> +> f3a97, Could you do this test and tell if you have the same experience +> than i?, If so, my bug is the same of this. +> Thanks. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1180777 +> +> Title: +> Windows 7 VM freeze on Ubuntu 12.04 KVM +> +> Status in QEMU: +> New +> Status in “qemu-kvm” package in Ubuntu: +> Confirmed +> +> Bug description: +> Hi, +> +> I have recently setup a Windows 7 VM on KVM and started using it +> through remote desktop. +> +> What happens is that, after some hours of usage, the remote desktop +> connection freezes. I thought it was a remmina bug, as the it was +> enough to kill and restart it to successfully connect again to the VM. +> +> However, today I've switched to a different RDP client (2X Client +> chromium app) and the freeze just happened again! +> +> Some information: +> - the host and the VM are completely idle when the freeze occurs +> - I've tried sniffing the network packets toward the RDP port during the +> freeze and found that the client is sending packets but no packet is sent +> back +> +> Could this be a KVM issue? How can I further debug this one (I expect +> the freeze to happen again...)? +> +> ProblemType: Bug +> DistroRelease: Ubuntu 12.04 +> Package: kvm 1:84+dfsg-0ubuntu16+1.0+noroms+0ubuntu14.8 +> ProcVersionSignature: Ubuntu 3.2.0-41.66-generic 3.2.42 +> Uname: Linux 3.2.0-41-generic x86_64 +> ApportVersion: 2.0.1-0ubuntu17.2 +> Architecture: amd64 +> Date: Thu May 16 14:12:40 2013 +> MachineType: Hewlett-Packard HP ProBook 4520s +> MarkForUpload: True +> ProcEnviron: +> TERM=xterm +> PATH=(custom, no user) +> LANG=en_US.UTF-8 +> SHELL=/bin/bash +> ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-41-generic +> root=UUID=D2E20BC3E20BAAB5 loop=/hostname/disks/root.disk ro quiet splash +> vt.handoff=7 +> SourcePackage: qemu-kvm +> UpgradeStatus: No upgrade log present (probably fresh install) +> dmi.bios.date: 08/26/2010 +> dmi.bios.vendor: Hewlett-Packard +> dmi.bios.version: 68AZZ Ver. F.0A +> dmi.board.name: 1411 +> dmi.board.vendor: Hewlett-Packard +> dmi.board.version: KBC Version 57.30 +> dmi.chassis.type: 10 +> dmi.chassis.vendor: Hewlett-Packard +> dmi.modalias: +> dmi:bvnHewlett-Packard:bvr68AZZVer.F.0A:bd08/26/2010:svnHewlett-Packard:pnHPProBook4520s:pvr:rvnHewlett-Packard:rn1411:rvrKBCVersion57.30:cvnHewlett-Packard:ct10:cvr: +> dmi.product.name: HP ProBook 4520s +> dmi.sys.vendor: Hewlett-Packard +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1180777/+subscriptions +> + + +Hi, + +Eventually I've been able to reproduce the hang. + +Just to recap the experiment: I have recorded network traffic during RDP +connection hangs. The result is that the VM has do not experience total +network loss: network traffic continues to flow (tcpdump from the host on +ports other than 3389). + + + + + + +On 5 September 2013 15:22, Stefano Doni <email address hidden> wrote: + +> Hi Hector, +> +> +> My network configuration is different than yours - it is not bridged. +> Perhaps this might help to diagnose the issue? +> +> +> I'm now trying to sniff network traffic generated by the VM and see what +> happens during RDP hangs: does it still poll outside servers (i.e. google +> drive) or will become disconnected? +> +> +> I'll report the results, stay tuned. +> +> +> On 19 August 2013 00:42, Hector Perez <email address hidden> wrote: +> +>> Hi, +>> +>> I reported the #1212051 (https://bugs.launchpad.net/ubuntu/+source/qemu- +>> kvm/+bug/1212051<https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/1212051>) +>> bug with Windows XP, but reading this case i think it +>> could be the same issue. +>> +>> I connect via RDP to my windows XP VM and after a while it seems to +>> freeze, then, I connect via VNC an without doing anything the +>> communications are restored between the VM and the outside world. So i +>> can connect again with RDP. +>> +>> Even more, if i leave an open connection with VNC (minimized because is +>> more slow than RDP), connecting via RDP has no trouble and no problem of +>> freeze (lost of communications) occurs. +>> +>> f3a97, Could you do this test and tell if you have the same experience +>> than i?, If so, my bug is the same of this. +>> Thanks. +>> +>> -- +>> You received this bug notification because you are subscribed to the bug +>> report. +>> https://bugs.launchpad.net/bugs/1180777 +>> +>> Title: +>> Windows 7 VM freeze on Ubuntu 12.04 KVM +>> +>> Status in QEMU: +>> New +>> Status in “qemu-kvm” package in Ubuntu: +>> Confirmed +>> +>> Bug description: +>> Hi, +>> +>> I have recently setup a Windows 7 VM on KVM and started using it +>> through remote desktop. +>> +>> What happens is that, after some hours of usage, the remote desktop +>> connection freezes. I thought it was a remmina bug, as the it was +>> enough to kill and restart it to successfully connect again to the VM. +>> +>> However, today I've switched to a different RDP client (2X Client +>> chromium app) and the freeze just happened again! +>> +>> Some information: +>> - the host and the VM are completely idle when the freeze occurs +>> - I've tried sniffing the network packets toward the RDP port during +>> the freeze and found that the client is sending packets but no packet is +>> sent back +>> +>> Could this be a KVM issue? How can I further debug this one (I expect +>> the freeze to happen again...)? +>> +>> ProblemType: Bug +>> DistroRelease: Ubuntu 12.04 +>> Package: kvm 1:84+dfsg-0ubuntu16+1.0+noroms+0ubuntu14.8 +>> ProcVersionSignature: Ubuntu 3.2.0-41.66-generic 3.2.42 +>> Uname: Linux 3.2.0-41-generic x86_64 +>> ApportVersion: 2.0.1-0ubuntu17.2 +>> Architecture: amd64 +>> Date: Thu May 16 14:12:40 2013 +>> MachineType: Hewlett-Packard HP ProBook 4520s +>> MarkForUpload: True +>> ProcEnviron: +>> TERM=xterm +>> PATH=(custom, no user) +>> LANG=en_US.UTF-8 +>> SHELL=/bin/bash +>> ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-41-generic +>> root=UUID=D2E20BC3E20BAAB5 loop=/hostname/disks/root.disk ro quiet splash +>> vt.handoff=7 +>> SourcePackage: qemu-kvm +>> UpgradeStatus: No upgrade log present (probably fresh install) +>> dmi.bios.date: 08/26/2010 +>> dmi.bios.vendor: Hewlett-Packard +>> dmi.bios.version: 68AZZ Ver. F.0A +>> dmi.board.name: 1411 +>> dmi.board.vendor: Hewlett-Packard +>> dmi.board.version: KBC Version 57.30 +>> dmi.chassis.type: 10 +>> dmi.chassis.vendor: Hewlett-Packard +>> dmi.modalias: +>> dmi:bvnHewlett-Packard:bvr68AZZVer.F.0A:bd08/26/2010:svnHewlett-Packard:pnHPProBook4520s:pvr:rvnHewlett-Packard:rn1411:rvrKBCVersion57.30:cvnHewlett-Packard:ct10:cvr: +>> dmi.product.name: HP ProBook 4520s +>> dmi.sys.vendor: Hewlett-Packard +>> +>> To manage notifications about this bug go to: +>> https://bugs.launchpad.net/qemu/+bug/1180777/+subscriptions +>> +> +> + + +I also see these EXACT symptoms, using kvm (VM managed through livirt virsh) on Debian x64 host, guest is Windows 8, RedHat VirtIo network driver. + +rgds + +Hi f3a97, did you tried to connect via VNC when the freeze situation occurs? + +This method works as a a workaround to defreeze my windows VM. + +Since a couple of weeks ago, we started to reboot the VM diary. With this way, the problem occurs very less. We have counted only twice in this period. + +I added a rtl8139c netcard to the VM and connected through it by RDP - no more freezes. + +It looks like kvm does not play well with virtio network cards and RDP. + +Red Hat virtio net windows driver version: 62.65.104.6500, 6/19/2013 + +I left the RH adapter on the VM, I just connect via RDP through the rtl8139c network card. + + + + + +Thanks for the tip Dumitrescu, + +I'll rive it a try AMD report here che result. + +Regards + Il 29/set/2013 14:50 "Vasile Dumitrescu" <email address hidden> ha +scritto: + +> I added a rtl8139c netcard to the VM and connected through it by RDP - +> no more freezes. +> +> It looks like kvm does not play well with virtio network cards and RDP. +> +> Red Hat virtio net windows driver version: 62.65.104.6500, 6/19/2013 +> +> I left the RH adapter on the VM, I just connect via RDP through the +> rtl8139c network card. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1180777 +> +> Title: +> RDP traffic freeze on quiet network +> +> Status in QEMU: +> New +> Status in “qemu-kvm” package in Ubuntu: +> Confirmed +> Status in Debian GNU/Linux: +> New +> +> Bug description: +> To summarize what I think has been found so far, +> +> 1. The main symptom is that RDP connections hang after some time +> 2. This bug affects qemu 1.0 .. 1.6.5 +> 3. This bug affects at least windows xp and windows 7 guests +> 4. Keeping another network connection open, such as vnc, prevents the +> RDP connection from hanging. +> +> ======================================== +> Hi, +> +> I have recently setup a Windows 7 VM on KVM and started using it +> through remote desktop. +> +> What happens is that, after some hours of usage, the remote desktop +> connection freezes. I thought it was a remmina bug, as the it was +> enough to kill and restart it to successfully connect again to the VM. +> +> However, today I've switched to a different RDP client (2X Client +> chromium app) and the freeze just happened again! +> +> Some information: +> - the host and the VM are completely idle when the freeze occurs +> - I've tried sniffing the network packets toward the RDP port during the +> freeze and found that the client is sending packets but no packet is sent +> back +> +> Could this be a KVM issue? How can I further debug this one (I expect +> the freeze to happen again...)? +> +> ProblemType: Bug +> DistroRelease: Ubuntu 12.04 +> Package: kvm 1:84+dfsg-0ubuntu16+1.0+noroms+0ubuntu14.8 +> ProcVersionSignature: Ubuntu 3.2.0-41.66-generic 3.2.42 +> Uname: Linux 3.2.0-41-generic x86_64 +> ApportVersion: 2.0.1-0ubuntu17.2 +> Architecture: amd64 +> Date: Thu May 16 14:12:40 2013 +> MachineType: Hewlett-Packard HP ProBook 4520s +> MarkForUpload: True +> ProcEnviron: +> TERM=xterm +> PATH=(custom, no user) +> LANG=en_US.UTF-8 +> SHELL=/bin/bash +> ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-41-generic +> root=UUID=D2E20BC3E20BAAB5 loop=/hostname/disks/root.disk ro quiet splash +> vt.handoff=7 +> SourcePackage: qemu-kvm +> UpgradeStatus: No upgrade log present (probably fresh install) +> dmi.bios.date: 08/26/2010 +> dmi.bios.vendor: Hewlett-Packard +> dmi.bios.version: 68AZZ Ver. F.0A +> dmi.board.name: 1411 +> dmi.board.vendor: Hewlett-Packard +> dmi.board.version: KBC Version 57.30 +> dmi.chassis.type: 10 +> dmi.chassis.vendor: Hewlett-Packard +> dmi.modalias: +> dmi:bvnHewlett-Packard:bvr68AZZVer.F.0A:bd08/26/2010:svnHewlett-Packard:pnHPProBook4520s:pvr:rvnHewlett-Packard:rn1411:rvrKBCVersion57.30:cvnHewlett-Packard:ct10:cvr: +> dmi.product.name: HP ProBook 4520s +> dmi.sys.vendor: Hewlett-Packard +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1180777/+subscriptions +> + + +Quoting Vasile Dumitrescu (<email address hidden>): +> I added a rtl8139c netcard to the VM and connected through it by RDP - +> no more freezes. +> +> It looks like kvm does not play well with virtio network cards and RDP. +> +> Red Hat virtio net windows driver version: 62.65.104.6500, 6/19/2013 + +This makes me wonder if the bug may not actually be in the virtio net driver. +The source for that is at +https://github.com/YanVugenfirer/kvm-guest-drivers-windows . +Something like commit 9b1b81a731f722efa8df24429649b527a17bf433 might +be relevant (assuming the git HEAD has this fixed, which I've not +tested). + + +Hi, + +I've double checked my conf, I can confirm I'm not using virtio but +standard Win 7 drivers. (please see my VM conf that I posted some time ago). + +So it's not definitely a virtio-specific issue. + + +On 3 October 2013 16:31, Serge Hallyn <email address hidden> wrote: + +> Quoting Vasile Dumitrescu (<email address hidden>): +> > I added a rtl8139c netcard to the VM and connected through it by RDP - +> > no more freezes. +> > +> > It looks like kvm does not play well with virtio network cards and RDP. +> > +> > Red Hat virtio net windows driver version: 62.65.104.6500, 6/19/2013 +> +> This makes me wonder if the bug may not actually be in the virtio net +> driver. +> The source for that is at +> https://github.com/YanVugenfirer/kvm-guest-drivers-windows . +> Something like commit 9b1b81a731f722efa8df24429649b527a17bf433 might +> be relevant (assuming the git HEAD has this fixed, which I've not +> tested). +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1180777 +> +> Title: +> RDP traffic freeze on quiet network +> +> Status in QEMU: +> New +> Status in “qemu-kvm” package in Ubuntu: +> Confirmed +> Status in Debian GNU/Linux: +> New +> +> Bug description: +> To summarize what I think has been found so far, +> +> 1. The main symptom is that RDP connections hang after some time +> 2. This bug affects qemu 1.0 .. 1.6.5 +> 3. This bug affects at least windows xp and windows 7 guests +> 4. Keeping another network connection open, such as vnc, prevents the +> RDP connection from hanging. +> +> ======================================== +> Hi, +> +> I have recently setup a Windows 7 VM on KVM and started using it +> through remote desktop. +> +> What happens is that, after some hours of usage, the remote desktop +> connection freezes. I thought it was a remmina bug, as the it was +> enough to kill and restart it to successfully connect again to the VM. +> +> However, today I've switched to a different RDP client (2X Client +> chromium app) and the freeze just happened again! +> +> Some information: +> - the host and the VM are completely idle when the freeze occurs +> - I've tried sniffing the network packets toward the RDP port during the +> freeze and found that the client is sending packets but no packet is sent +> back +> +> Could this be a KVM issue? How can I further debug this one (I expect +> the freeze to happen again...)? +> +> ProblemType: Bug +> DistroRelease: Ubuntu 12.04 +> Package: kvm 1:84+dfsg-0ubuntu16+1.0+noroms+0ubuntu14.8 +> ProcVersionSignature: Ubuntu 3.2.0-41.66-generic 3.2.42 +> Uname: Linux 3.2.0-41-generic x86_64 +> ApportVersion: 2.0.1-0ubuntu17.2 +> Architecture: amd64 +> Date: Thu May 16 14:12:40 2013 +> MachineType: Hewlett-Packard HP ProBook 4520s +> MarkForUpload: True +> ProcEnviron: +> TERM=xterm +> PATH=(custom, no user) +> LANG=en_US.UTF-8 +> SHELL=/bin/bash +> ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-41-generic +> root=UUID=D2E20BC3E20BAAB5 loop=/hostname/disks/root.disk ro quiet splash +> vt.handoff=7 +> SourcePackage: qemu-kvm +> UpgradeStatus: No upgrade log present (probably fresh install) +> dmi.bios.date: 08/26/2010 +> dmi.bios.vendor: Hewlett-Packard +> dmi.bios.version: 68AZZ Ver. F.0A +> dmi.board.name: 1411 +> dmi.board.vendor: Hewlett-Packard +> dmi.board.version: KBC Version 57.30 +> dmi.chassis.type: 10 +> dmi.chassis.vendor: Hewlett-Packard +> dmi.modalias: +> dmi:bvnHewlett-Packard:bvr68AZZVer.F.0A:bd08/26/2010:svnHewlett-Packard:pnHPProBook4520s:pvr:rvnHewlett-Packard:rn1411:rvrKBCVersion57.30:cvnHewlett-Packard:ct10:cvr: +> dmi.product.name: HP ProBook 4520s +> dmi.sys.vendor: Hewlett-Packard +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1180777/+subscriptions +> + + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + +[Expired for qemu-kvm (Ubuntu) because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1182 b/results/classifier/105/mistranslation/1182 new file mode 100644 index 000000000..205609ed3 --- /dev/null +++ b/results/classifier/105/mistranslation/1182 @@ -0,0 +1,82 @@ +mistranslation: 0.778 +other: 0.706 +graphic: 0.704 +KVM: 0.693 +vnc: 0.683 +instruction: 0.671 +device: 0.664 +semantic: 0.640 +assembly: 0.596 +socket: 0.580 +network: 0.559 +boot: 0.538 + +Hotplug device(device_add) immediately after starting a virtual machine triggers deadlock. +Description of problem: +Sometimes, hotplug device(device_add) immediately after starting a virtual machine triggers deadlock. + +Related commits: [7bed8995](https://gitlab.com/qemu-project/qemu/-/commit/7bed89958bfbf40df9ca681cefbdca63abdde39d) +Steps to reproduce: +1. start a virtual machine + +2. hotplug some device immediately(24 virtio-blk device etc.) + +3. repert step 1 and step 2 for several times, as I tried, deadlock will happen within 100 times. +Additional information: +I found similar problem [Issues 650](https://gitlab.com/qemu-project/qemu/-/issues/650)，but problem seems different. + +When qemu_main_loop deal with qmp_device_add command which will add a bottom half structure to qemu_aio_context's bh_list. + +At the same time, UEFI loader writing something to pflash device, address_space_write function get rcu_read_lock and poll aio request. + +Then, it will get the bottom half structure added by qemu_main_loop and go to qmp_device_add function. qmp_device_add function call drain_call_rcu function which will wait for all readers exit. Then it caused a deadlock. + + + +dead lock thread stack + +``` +#0 0x0000ffffb11e8ee4 in syscall () from target:/usr/lib64/libc.so.6 +#1 0x0000aaaadab2ce80 in qemu_futex_wait (val=<optimized out>, f=<optimized out>) at /Images/jdx/code/qemu/include/qemu/futex.h:29 +#2 qemu_event_wait (ev=ev@entry=0xffff87bfd890) at ../util/qemu-thread-posix.c:429 +#3 0x0000aaaadab35ed0 in drain_call_rcu () at ../util/rcu.c:347 +#4 0x0000aaaada55fa94 in qmp_device_add (qdict=<optimized out>, ret_data=<optimized out>, errp=<optimized out>) at ../softmmu/qdev-monitor.c:866 +#5 0x0000aaaadab1f01c in do_qmp_dispatch_bh (opaque=0xffffaf987ec8) at ../qapi/qmp-dispatch.c:128 +#6 0x0000aaaadab3d1b4 in aio_bh_call (bh=0xffff382d8190) at ../util/async.c:150 +#7 aio_bh_poll (ctx=ctx@entry=0xaaaaf8836ac0) at ../util/async.c:178 +#8 0x0000aaaadab29010 in aio_poll (ctx=ctx@entry=0xaaaaf8836ac0, blocking=blocking@entry=true) at ../util/aio-posix.c:712 +#9 0x0000aaaadaa060e8 in bdrv_poll_co (s=0xffff87bfda58) at /Images/jdx/code/qemu/block/block-gen.h:44 +#10 0x0000aaaadaa07134 in blk_pwrite (blk=0xaaaaf8b82400, offset=offset@entry=197120, bytes=bytes@entry=512, buf=0xffff87c30200, flags=flags@entry=0) at block/block-gen.c:685 +#11 0x0000aaaada35c330 in pflash_update (pfl=pfl@entry=0xaaaaf8b474f0, offset=197120, offset@entry=197124, size=size@entry=4) at ../hw/block/pflash_cfi01.c:395 +#12 0x0000aaaada35e1f8 in pflash_write (be=0, width=4, value=299045890, offset=197124, pfl=0xaaaaf8b474f0) at ../hw/block/pflash_cfi01.c:523 +#13 pflash_mem_write_with_attrs (opaque=0xaaaaf8b474f0, addr=197124, value=299045890, len=4, attrs=...) at ../hw/block/pflash_cfi01.c:682 +#14 0x0000aaaada918cbc in access_with_adjusted_size (addr=addr@entry=197124, value=value@entry=0xffff87bfdbf8, size=4, access_size_min=<optimized out>, access_size_max=<optimized out>, + access_fn=access_fn@entry=0xaaaada91b260 <memory_region_write_with_attrs_accessor>, mr=0xaaaaf8b478b0, attrs=...) at ../softmmu/memory.c:554 +#15 0x0000aaaada91cfc4 in memory_region_dispatch_write (mr=mr@entry=0xaaaaf8b478b0, addr=197124, data=<optimized out>, op=MO_32, attrs=attrs@entry=...) at ../softmmu/memory.c:1520 +#16 0x0000aaaada9245ec in flatview_write_continue (fv=fv@entry=0xffff38492110, addr=addr@entry=67305988, attrs=attrs@entry=..., ptr=ptr@entry=0xffffb1e13028, len=len@entry=4, addr1=<optimized out>, l=<optimized out>, + mr=0xaaaaf8b478b0) at /Images/jdx/code/qemu/include/qemu/host-utils.h:166 +#17 0x0000aaaada924844 in flatview_write (fv=0xffff38492110, addr=addr@entry=67305988, attrs=attrs@entry=..., buf=buf@entry=0xffffb1e13028, len=len@entry=4) at ../softmmu/physmem.c:2867 +#18 0x0000aaaada92825c in address_space_write (len=4, buf=0xffffb1e13028, attrs=..., addr=67305988, as=0xaaaadb4a4670 <address_space_memory>) at ../softmmu/physmem.c:2963 +#19 address_space_rw (as=0xaaaadb4a4670 <address_space_memory>, addr=67305988, attrs=attrs@entry=..., buf=buf@entry=0xffffb1e13028, len=4, is_write=<optimized out>) at ../softmmu/physmem.c:2973 +#20 0x0000aaaada9c7754 in kvm_cpu_exec (cpu=cpu@entry=0xaaaaf8c80530) at ../accel/kvm/kvm-all.c:2954 +#21 0x0000aaaada9c8adc in kvm_vcpu_thread_fn (arg=arg@entry=0xaaaaf8c80530) at ../accel/kvm/kvm-accel-ops.c:49 +#22 0x0000aaaadab2ba98 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:504 +#23 0x0000ffffb118718c in ?? () from target:/usr/lib64/libc.so.6 +#24 0x0000ffffb11ed15c in ?? () from target:/usr/lib64/libc.so.6 + +``` + +call_rcu_thread stack +``` +Thread 2 (Thread 0xffffb0196900 (LWP 1018210) "qemu-system-aar"): +#0 0x0000ffffb11e8ee4 in syscall () from target:/usr/lib64/libc.so.6 +#1 0x0000aaaadab2ce80 in qemu_futex_wait (val=<optimized out>, f=<optimized out>) at /Images/jdx/code/qemu/include/qemu/futex.h:29 +#2 qemu_event_wait (ev=ev@entry=0xaaaadb4c3bb8 <rcu_gp_event>) at ../util/qemu-thread-posix.c:429 +#3 0x0000aaaadab35ce8 in wait_for_readers () at ../util/rcu.c:138 +#4 synchronize_rcu () at ../util/rcu.c:174 +#5 0x0000aaaadab36160 in call_rcu_thread (opaque=opaque@entry=0x0) at ../util/rcu.c:268 +#6 0x0000aaaadab2ba98 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:504 +#7 0x0000ffffb118718c in ?? () from target:/usr/lib64/libc.so.6 +#8 0x0000ffffb11ed15c in ?? () from target:/usr/lib64/libc.so.6 + +``` diff --git a/results/classifier/105/mistranslation/1192065 b/results/classifier/105/mistranslation/1192065 new file mode 100644 index 000000000..2144a63e2 --- /dev/null +++ b/results/classifier/105/mistranslation/1192065 @@ -0,0 +1,22 @@ +mistranslation: 0.848 +graphic: 0.760 +device: 0.732 +other: 0.722 +instruction: 0.680 +semantic: 0.667 +boot: 0.489 +vnc: 0.469 +network: 0.462 +socket: 0.441 +assembly: 0.359 +KVM: 0.306 + +qemu release memory to system + +Qemu pre-allocates the maximum balloon amount which is inconvinient if all of the memory is used up and some other system needs to be added memory resource + +eg:- I have 4GB RAM with 4 virtual systems to be run. +I want each of them to start with 1GB RAM with maximum 2GB possible. This is not achievable since qemu pre-allocates the maximum balloon amount which is 2GBx4 systems . So to start all 4 systems the system needs 8GB RAM rather than 4GB RAM to start with although I have told initial balloon amount to be 1GB. + +Looking through old bug tickets... I think you should rather use hotpluggable memory here for the guests instead - or use a big swap partition on the host. Anyway, this is not a bug, so closing this ticket now. + diff --git a/results/classifier/105/mistranslation/1195882 b/results/classifier/105/mistranslation/1195882 new file mode 100644 index 000000000..73dcdeaed --- /dev/null +++ b/results/classifier/105/mistranslation/1195882 @@ -0,0 +1,154 @@ +mistranslation: 0.880 +other: 0.836 +vnc: 0.833 +semantic: 0.830 +device: 0.826 +instruction: 0.824 +graphic: 0.824 +assembly: 0.817 +network: 0.811 +boot: 0.804 +KVM: 0.795 +socket: 0.788 + +Make fails on Centos - can't find autoreconf + + [root@H002 qemu-1.4.2]# make +\ GEN i386-softmmu/config-devices.mak + GEN x86_64-softmmu/config-devices.mak + GEN alpha-softmmu/config-devices.mak + GEN arm-softmmu/config-devices.mak + GEN cris-softmmu/config-devices.mak + GEN lm32-softmmu/config-devices.mak + +( .... ) + +GEN unicore32-linux-user/config-devices.mak + GEN s390x-linux-user/config-devices.mak + GEN config-all-devices.mak + GEN config-host.h +(cd /opt/qemu/qemu-1.4.2/pixman; autoreconf -v --install) +/bin/sh: autoreconf: command not found +make: *** [/opt/qemu/qemu-1.4.2/pixman/configure] Error 127 + +***************** + +Exact same error for 1.5.1 build +So, qemu not supported on anything but Ubuntu? + +autoreconf is part of the autoconf package. Do you have that installed? + +As far as I know, autoreconf does not exist in the red hat/fedora/centos world. + +Can't find a yum, rpm. or other distro for it on the above os. + +Am I missing something obvious hrte? + +Thanks.... + + +Sent from a mobile device. + +-------- Original message -------- +From: Iggy <email address hidden> +Date: +To: <email address hidden> +Subject: [Bug 1195882] Re: Make fails on Centos - can't find autoreconf + +autoreconf is part of the autoconf package. Do you have that installed? + +-- +You received this bug notification because you are subscribed to the bug +report. +https://bugs.launchpad.net/bugs/1195882 + +Title: + Make fails on Centos - can't find autoreconf + +Status in QEMU: + New + +Bug description: + [root@H002 qemu-1.4.2]# make + \ GEN i386-softmmu/config-devices.mak + GEN x86_64-softmmu/config-devices.mak + GEN alpha-softmmu/config-devices.mak + GEN arm-softmmu/config-devices.mak + GEN cris-softmmu/config-devices.mak + GEN lm32-softmmu/config-devices.mak + + ( .... ) + + GEN unicore32-linux-user/config-devices.mak + GEN s390x-linux-user/config-devices.mak + GEN config-all-devices.mak + GEN config-host.h + (cd /opt/qemu/qemu-1.4.2/pixman; autoreconf -v --install) + /bin/sh: autoreconf: command not found + make: *** [/opt/qemu/qemu-1.4.2/pixman/configure] Error 127 + + ***************** + + Exact same error for 1.5.1 build + So, qemu not supported on anything but Ubuntu? + +To manage notifications about this bug go to: +https://bugs.launchpad.net/qemu/+bug/1195882/+subscriptions + + +> As far as I know, autoreconf does not exist in the red hat/fedora/centos world. +> +> Can't find a yum, rpm. or other distro for it on the above os. + +You aren't looking very hard; on my RHEL 6.4 box (which has the same +packages as what you can install in CentOS), I see: + +$ rpm -qf `which autoreconf` +autoconf-2.63-5.1.el6.noarch + + +On Friday 28 June 2013 18:20:29 you wrote: +> autoreconf is part of the autoconf package. Do you have that installed? +> +Hi, + +Thanks for the response. + +You're right, it was the lack of autoconf. Actually, on CentOS/RH, you need +to check for + +autoconf +automake (includes autoconf?) +libtools + +Seems to be building happily now. Sorry for the newbie question. + +/T. + + +On Saturday 29 June 2013 00:12:17 you wrote: +> > As far as I know, autoreconf does not exist in the red +> > hat/fedora/centos world. +> > +> > Can't find a yum, rpm. or other distro for it on the above os. +> +> You aren't looking very hard; on my RHEL 6.4 box (which has the same +> packages as what you can install in CentOS), I see: +> +> $ rpm -qf `which autoreconf` +> autoconf-2.63-5.1.el6.noarch +> +You're right. Also installed automake which supplies an 'aclocal' +executable that's not in the autoconf distro, and libtool to fix a 'possibly +undefined macro AC_LIBTOOL' issue. + +Seems to be happily compiling/linking now. + +My apologies for the pseudo-bug report. + +BTW, thank you for your assistance. + +/Todd + + + diff --git a/results/classifier/105/mistranslation/1196145 b/results/classifier/105/mistranslation/1196145 new file mode 100644 index 000000000..9575bc797 --- /dev/null +++ b/results/classifier/105/mistranslation/1196145 @@ -0,0 +1,38 @@ +mistranslation: 0.974 +semantic: 0.898 +instruction: 0.847 +other: 0.845 +device: 0.804 +graphic: 0.786 +network: 0.662 +socket: 0.631 +vnc: 0.550 +boot: 0.454 +assembly: 0.454 +KVM: 0.330 + +usb-host: hostaddr=0XX is parsed as octal number + +when doing + +device_add usb-host,hostaddr=010 + +taking 010 in the format of both lsusb or udev, qemu parses an octal number and assumes hostaddr=8. +(i used a 2.0 device on the ehci.0 bus) +at least to me that is confusing. + +also: + +when adding a non-existent usb device (bogus hostaddr), the following is created according to 'usb info': + + Device 1.0, Port 1, Speed 1.5 Mb/s, Product USB Host Device + +in usb_qdev_init(): +usb_claim_port is called but usb_device_init does not report an error and thus usb_release_port is not called. + +ps: when using host-libusb.c and tested on 1.5.1.tgz + +Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1216368 b/results/classifier/105/mistranslation/1216368 new file mode 100644 index 000000000..22a7c7daa --- /dev/null +++ b/results/classifier/105/mistranslation/1216368 @@ -0,0 +1,52 @@ +mistranslation: 0.888 +semantic: 0.815 +graphic: 0.705 +device: 0.702 +instruction: 0.692 +other: 0.691 +socket: 0.666 +vnc: 0.487 +boot: 0.449 +assembly: 0.423 +network: 0.391 +KVM: 0.293 + +unsupported screen resolution crashes sdl-qemu + +if the (windows) guest sets a screen resolution that the SDL backend does not support, +qemu does an exit(1). +with this fix, the the resolution is still wrong (only part of the desktop is displayed), +but qemu keeps running and the guest can auto-revert the video mode: + +ui/sdl.c:do_sdl_resize() + SDL_Surface * tmp_screen; + tmp_screen = SDL_SetVideoMode(width, height, bpp, flags); + if (!tmp_screen) { +// fprintf(stderr, "Could not open SDL display (%dx%dx%d): %s\n", width, +// height, bpp, SDL_GetError()); +// exit(1); + } else { + real_screen = tmp_screen; + } + +Sorry, a little confusion what's the problem you want to solve? + +its in the first sentence. let me rephrase: the (windows) guest can select some screen resolution which SDL cannot +provide. what happens is that qemu quits without giving the quest a chance to shut down. thats like having a monitor +that crashes windows when it doesnt support the video mode. + +Yes, it is a bug. It should go back to the previous setting if the new screen resolution falied. +I will send a patch later. + +Thanks. + +Patch posted: + +http://patchwork.ozlabs.org/patch/270084/ + +this patch does solve the problem + +Patch has been included here a while ago already: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=898ae2846de4dcb1 +... so this ticket could now be marked as fixed. + diff --git a/results/classifier/105/mistranslation/1217339 b/results/classifier/105/mistranslation/1217339 new file mode 100644 index 000000000..3b70982a1 --- /dev/null +++ b/results/classifier/105/mistranslation/1217339 @@ -0,0 +1,83 @@ +mistranslation: 0.549 +other: 0.534 +graphic: 0.516 +semantic: 0.493 +device: 0.481 +assembly: 0.443 +network: 0.441 +instruction: 0.441 +socket: 0.415 +vnc: 0.383 +KVM: 0.373 +boot: 0.366 + +SIGQUIT to send ACPI-shutdown to Guest + +When qemu receives SIGQUIT, it should first try to run system_powerdown (giving the guest an ACPI signal to begin the shutdown process), before ending the whole qemu process. + +At this point there is no way to do a graceful shutdown if you do not have access to the monitor and you do not use any wrapper like libvirt. + +If, for some reason SIGQUIT would not be accepted as the signal, take any free to use signal, like SIGUSR1. There should be a way to get ACPI shutdown sent to the guest. + +On 08/27/13 14:29, Lasse wrote: +> Public bug reported: +> +> When qemu receives SIGQUIT, it should first try to run system_powerdown +> (giving the guest an ACPI signal to begin the shutdown process), before +> ending the whole qemu process. + +I strongly disagree. SIGQUIT is an interactive debugging signal. It is +there so that the user running qemu can trigger a core dump from the +terminal, when he/she notices a problem. + +http://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html#index-SIGQUIT-2854 + +> At this point there is no way to do a graceful shutdown if you do not +> have access to the monitor and you do not use any wrapper like libvirt. +> +> If, for some reason SIGQUIT would not be accepted as the signal, take +> any free to use signal, like SIGUSR1. There should be a way to get ACPI +> shutdown sent to the guest. + +What's wrong with SIGINT / SIGTERM? Those signals are there to request a +clean shutdown (from the terminal and from an unrelated process, +respectively). + +As far as I can see, both SIGINT and SIGTERM end up in +qemu_system_shutdown_request() on POSIX: + +termsig_handler() [os-posix.c] + qemu_system_killed() [vl.c] + qemu_system_shutdown_request() + +Laszlo + + + +Here is a short patch making Qemu to properly power off the guest when receiving a SIGHUP signal. + +I do not think that the way SIGTERM is handled should be modified as it is needed to ask Qemu to forcefully close an unresponsive guest without having to SIGKILL Qemu itself. Regarding SIGINT this is mostly a matter of user expectation (Ctrl-C result), in doubt I keep the original behavior. + +On the other side, SIGHUP has a much flexible definition making it a good candidate for the job. + +IMHO I think such feature is really useful as it allows to cleanly close all running VM without having to involve Qemu monitor in any way: + +1. Send SIGHUP to all Qemu processes so the guests power off cleanly. +2. After a few time send SIGTERM to the remaining Qemu processes to forcefully close stuck guests. +3. After a few time send SIGKILL to the remaining Qemu processes to forcefully close stuck Qemu hypervisor processes. + +I find this more convenient than having to fiddle with Qemu monitor to implement step 1 as it must currently be done. + +Please do not add patches to the bugtracker. Post them to the mailing list instead. See http://wiki.qemu-project.org/Contribute/SubmitAPatch for information how to contribute a patch. + +(and I am also not sure whether SIGHUP is the right signal for this job - the original request was also about SIGQUIT instead) + +Sorry Thomas, I was not aware of this page. I checked the CODING_STYLE file present in Qemu source before submitting this, maybe it could be useful to include this URL there. + +Meanwhile, for reference the discussion continues there: +https://lists.nongnu.org/archive/html/qemu-devel/2017-03/msg03039.html + +Regards. + +The discussion noted in comment#4 petered out in March 2017. Closing this ticket as "Invalid" (only because LP does not let me use the "Won't Fix" resolution -- the report / feature request may very well have had merit, but apparently a good enough design could not be found). + diff --git a/results/classifier/105/mistranslation/1238 b/results/classifier/105/mistranslation/1238 new file mode 100644 index 000000000..f95139f73 --- /dev/null +++ b/results/classifier/105/mistranslation/1238 @@ -0,0 +1,132 @@ +mistranslation: 0.662 +other: 0.636 +KVM: 0.624 +vnc: 0.600 +semantic: 0.578 +instruction: 0.568 +device: 0.562 +assembly: 0.558 +graphic: 0.550 +socket: 0.550 +network: 0.532 +boot: 0.489 + +qemu-mipsn32el and qemu-mipsn32 problems with coreutils-9*, fadvise64 or fallocate related? +Description of problem: +- Recently about 15 of the ca. 250 packages in our system set fail during `make install`. A typical error is +> `/usr/bin/install: error deallocating '/var/tmp/portage/sys-apps/groff-1.22.4/image/usr/bin/troff': Invalid argument` +- Given the timing and the involved binaries (most of the times `install`, but also `cp`), I suspect this was triggered by coreutils-9 +- The problem seems to only occur on ext4 (our release engineering box), but not on btrfs (my home development box) +- The problem seems to be limited to n32 (both big and little endian) + +Here's a run with strace functionality enabled: + +``` +dilfridge-mips64el-n32 /var/tmp/portage/sys-apps/groff-1.22.4/work/groff-1.22.4 # /usr/bin/qemu-mipsn32el -strace /usr/bin/install troff '/var/tmp/portage/sys-apps/groff-1.22.4/image/usr/bin' +3216 brk(NULL) = 0x40032000 +3216 mmap(NULL,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x3f7ba000 +3216 uname(0x3fffebb0) = 0 +3216 access("/etc/ld.so.preload",R_OK) = -1 errno=2 (No such file or directory) +3216 openat(AT_FDCWD,"/etc/ld.so.cache",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +3216 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe280) = 0 +3216 mmap(NULL,11294,PROT_READ,MAP_PRIVATE,3,0) = 0x3f7b7000 +3216 close(3) = 0 +3216 openat(AT_FDCWD,"/lib32/libacl.so.1",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +3216 read(3,0x3fffe4c4,512) = 512 +3216 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe220) = 0 +3216 mmap(NULL,197008,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x3f786000 +3216 mmap(0x3f790000,131472,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0) = 0x3f790000 +3216 munmap(0x3f786000,40960) = 0 +3216 munmap(0x3f7b1000,20880) = 0 +3216 mprotect(0x3f797000,98304,PROT_NONE) = 0 +3216 mmap(0x3f7af000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0xf000) = 0x3f7af000 +3216 close(3) = 0 +3216 openat(AT_FDCWD,"/lib32/libattr.so.1",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +3216 read(3,0x3fffe4b4,512) = 512 +3216 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe210) = 0 +3216 mmap(NULL,196864,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x3f75f000 +3216 mmap(0x3f760000,131328,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0) = 0x3f760000 +3216 munmap(0x3f75f000,4096) = 0 +3216 munmap(0x3f781000,57600) = 0 +3216 mprotect(0x3f764000,110592,PROT_NONE) = 0 +3216 mmap(0x3f77f000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0xf000) = 0x3f77f000 +3216 close(3) = 0 +3216 openat(AT_FDCWD,"/lib32/libc.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +3216 read(3,0x3fffe4a4,512) = 512 +3216 pread64(3,1073734640,32,34504,1065377824,0) = 32 +3216 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe200) = 0 +3216 mmap(NULL,2056864,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x3f569000 +3216 mmap(0x3f570000,1991328,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0) = 0x3f570000 +3216 munmap(0x3f569000,28672) = 0 +3216 munmap(0x3f757000,33440) = 0 +3216 mprotect(0x3f73c000,61440,PROT_NONE) = 0 +3216 mmap(0x3f74b000,28672,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x1cb000) = 0x3f74b000 +3216 mmap(0x3f752000,17056,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x3f752000 +3216 close(3) = 0 +3216 mmap(NULL,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x3f569000 +3216 set_thread_area(0x3f570580) = 0 +3216 set_tid_address(1062637704,1065348616,1065377824,0,-1,0) = 3216 +3216 set_robust_list(1062637712,12,1065377824,0,-1,0) = -1 errno=89 (Function not implemented) +3216 Unknown syscall 6331 +3216 mprotect(0x3f74b000,16384,PROT_READ) = 0 +3216 mprotect(0x3f77f000,4096,PROT_READ) = 0 +3216 mprotect(0x3f7af000,4096,PROT_READ) = 0 +3216 mprotect(0x4002e000,4096,PROT_READ) = 0 +3216 mprotect(0x3f7fc000,8192,PROT_READ) = 0 +3216 getrlimit(3,1073737152,1064664656,1062638996,1064337736,1064664656) = 0 +3216 munmap(0x3f7b7000,11294) = 0 +3216 getrandom(1064649956,4,1,1064337736,2130640639,1077952576) = 4 +3216 brk(NULL) = 0x40032000 +3216 brk(0x40053000) = 0x40053000 +3216 brk(0x40054000) = 0x40054000 +3216 openat(AT_FDCWD,"/usr/lib/locale/locale-archive",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +3216 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffed58) = 0 +3216 mmap(NULL,2097152,PROT_READ,MAP_PRIVATE,3,0) = 0x3f369000 +3216 close(3) = 0 +3216 geteuid() = 0 +3216 umask(0) = 18 +3216 openat(AT_FDCWD,"/var/tmp/portage/sys-apps/groff-1.22.4/image/usr/bin",O_RDONLY|O_DIRECTORY|O_LARGEFILE|O_PATH) = 3 +3216 statx(AT_FDCWD,"troff",AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe998) = 0 +3216 statx(3,"troff",AT_NO_AUTOMOUNT|AT_SYMLINK_NOFOLLOW,STATX_BASIC_STATS,0x3fffe998) = 0 +3216 unlinkat(3,"troff",0) = 0 +3216 openat(AT_FDCWD,"troff",O_RDONLY|O_LARGEFILE) = 4 +3216 statx(4,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe998) = 0 +3216 openat(3,"troff",O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE,0600) = 5 +3216 ioctl(5,FICLONE,4) = -1 errno=122 (Operation not supported) +3216 statx(5,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe998) = 0 +3216 lseek(4,0,SEEK_DATA) = 0 +3216 fadvise64(4,0,0,2,1664557525,0) = -1 errno=22 (Invalid argument) +3216 lseek(4,0,SEEK_HOLE) = 716800 +3216 lseek(4,0,SEEK_SET) = 0 +3216 mmap(NULL,139264,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x3f347000 +3216 read(4,0x3f348000,131072) = 131072 +3216 write(5,0x3f348000,122880) = 122880 +3216 read(4,0x3f348000,131072) = 131072 +3216 lseek(5,12288,SEEK_CUR) = 135168 +3216 fallocate(5,FALLOC_FL_KEEP_SIZE|FALLOC_FL_PUNCH_HOLE,122880,4290510848) = -1 errno=22 (Invalid argument) +3216 openat(AT_FDCWD,"/usr/share/locale/locale.alias",O_RDONLY|O_CLOEXEC) = 6 +3216 statx(6,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe2c8) = 0 +3216 read(6,0x400333a0,4096) = 2998 +3216 read(6,0x400333a0,4096) = 0 +3216 close(6) = 0 +3216 openat(AT_FDCWD,"/usr/share/locale/C.UTF-8/LC_MESSAGES/coreutils.mo",O_RDONLY) = -1 errno=2 (No such file or directory) +3216 openat(AT_FDCWD,"/usr/share/locale/C.utf8/LC_MESSAGES/coreutils.mo",O_RDONLY) = -1 errno=2 (No such file or directory) +3216 openat(AT_FDCWD,"/usr/share/locale/C/LC_MESSAGES/coreutils.mo",O_RDONLY) = -1 errno=2 (No such file or directory) +3216 write(2,0x3fffc888,18)/usr/bin/install: = 18 +3216 write(2,0x3fffc8b8,79)error deallocating '/var/tmp/portage/sys-apps/groff-1.22.4/image/usr/bin/troff' = 79 +3216 openat(AT_FDCWD,"/usr/share/locale/C.UTF-8/LC_MESSAGES/libc.mo",O_RDONLY) = -1 errno=2 (No such file or directory) +3216 openat(AT_FDCWD,"/usr/share/locale/C.utf8/LC_MESSAGES/libc.mo",O_RDONLY) = -1 errno=2 (No such file or directory) +3216 openat(AT_FDCWD,"/usr/share/locale/C/LC_MESSAGES/libc.mo",O_RDONLY) = -1 errno=2 (No such file or directory) +3216 write(2,0x3fffc428,18): Invalid argument = 18 +3216 write(2,0x3fffc858,1) + = 1 +3216 close(5) = 0 +3216 close(4) = 0 +3216 munmap(0x3f347000,139264) = 0 +3216 lseek(0,0,SEEK_CUR) = -1 errno=29 (Illegal seek) +3216 close(0) = 0 +3216 close(1) = 0 +3216 close(2)dilfridge-mips64el-n32 /var/tmp/portage/sys-apps/groff-1.22.4/work/groff-1.22.4 # +``` + +More information and debugging on request. Any advice is appreciated. diff --git a/results/classifier/105/mistranslation/1245724 b/results/classifier/105/mistranslation/1245724 new file mode 100644 index 000000000..3c96ef930 --- /dev/null +++ b/results/classifier/105/mistranslation/1245724 @@ -0,0 +1,84 @@ +mistranslation: 0.885 +semantic: 0.864 +other: 0.856 +KVM: 0.826 +device: 0.750 +instruction: 0.742 +graphic: 0.725 +network: 0.690 +assembly: 0.676 +vnc: 0.660 +socket: 0.609 +boot: 0.507 + +libfdt.a git compilation fail + +I don't know the commit tags but I checked out dtc on the 28 of october at 20:27 in the tree of qemu (also git checkout out tonight). The compilation fail at line 234 in qemu/dtc/Makefile so I inserted that line: + +@$ /usr/bin/strace -o /usr/src/qemu_build/error.log.txt /usr/bin/ar $@ + +into the makefile at position 234 to see what is the exact problem but the strace log is inconclusive. + +for the error: /usr/bin/ar: deux operations différentes spécifiées + +liberal translation is: two different operation specified. + +the distribution is arch linux with binutils 2.23.2, gcc 4.8.2 and kernel kvm-3.12.0-rc5 from git. + + + +Which version of make are you using? Recently, a bug with make 4.0 has been discovered, please see this thread for a description and a work-around: + +http://<email address hidden>/msg198719.html + + +I am indeed using make v4.0. Thanks you very much for the email thread, I will try to compile qemu again. + +Alain + +-----Message d'origine----- +De : <email address hidden> [mailto:<email address hidden>] De la part de thh +Envoyé : 29 octobre 2013 04:32 +À : <email address hidden> +Objet : [Bug 1245724] Re: libfdt.a git compilation fail + +Which version of make are you using? Recently, a bug with make 4.0 has been discovered, please see this thread for a description and a work- +around: + +http://<email address hidden>/msg198719.html + +-- +You received this bug notification because you are subscribed to the bug report. +https://bugs.launchpad.net/bugs/1245724 + +Title: + libfdt.a git compilation fail + +Status in QEMU: + New + +Bug description: + I don't know the commit tags but I checked out dtc on the 28 of + october at 20:27 in the tree of qemu (also git checkout out tonight). + The compilation fail at line 234 in qemu/dtc/Makefile so I inserted + that line: + + @$ /usr/bin/strace -o /usr/src/qemu_build/error.log.txt /usr/bin/ar $@ + + into the makefile at position 234 to see what is the exact problem but + the strace log is inconclusive. + + for the error: /usr/bin/ar: deux operations différentes spécifiées + + liberal translation is: two different operation specified. + + the distribution is arch linux with binutils 2.23.2, gcc 4.8.2 and + kernel kvm-3.12.0-rc5 from git. + +To manage notifications about this bug go to: +https://bugs.launchpad.net/qemu/+bug/1245724/+subscriptions + + + +This should be working fine again with recent versions of QEMU, so I'm closing the bug. If you still have problems, feel free to open it again. + diff --git a/results/classifier/105/mistranslation/1248 b/results/classifier/105/mistranslation/1248 new file mode 100644 index 000000000..76104ae04 --- /dev/null +++ b/results/classifier/105/mistranslation/1248 @@ -0,0 +1,24 @@ +mistranslation: 0.840 +graphic: 0.837 +instruction: 0.755 +assembly: 0.721 +device: 0.705 +semantic: 0.542 +socket: 0.500 +vnc: 0.496 +network: 0.472 +boot: 0.417 +other: 0.336 +KVM: 0.212 + +s390x: glibc widestring algorithms broken +Description of problem: +Several wide-string functions from glibc are broken und qemu user emulation. +Affected are at least: `wcsbrk()`, `wcsspn()` and `wcscspn()`. All of these are implemented in optimized assembler in glibc. + +Unfortunately I don't have access to the real hardware to check the behavior there. But it would probably been detected by now. +Also I don't know which instructions exactly don't work, as I don't have any knowledge about s390x assembler. +Steps to reproduce: +1. Compile the test program above +2. Run the program +3. Output is `0`, should be `1`. diff --git a/results/classifier/105/mistranslation/1249 b/results/classifier/105/mistranslation/1249 new file mode 100644 index 000000000..d9bc1f2b9 --- /dev/null +++ b/results/classifier/105/mistranslation/1249 @@ -0,0 +1,14 @@ +mistranslation: 0.996 +semantic: 0.691 +device: 0.662 +graphic: 0.613 +network: 0.163 +instruction: 0.121 +boot: 0.097 +vnc: 0.075 +other: 0.074 +KVM: 0.050 +socket: 0.024 +assembly: 0.020 + +qemu-edid Division By Zero -- by misuse of the option "-d" diff --git a/results/classifier/105/mistranslation/1257 b/results/classifier/105/mistranslation/1257 new file mode 100644 index 000000000..df3e2392f --- /dev/null +++ b/results/classifier/105/mistranslation/1257 @@ -0,0 +1,16 @@ +mistranslation: 0.891 +semantic: 0.814 +device: 0.776 +other: 0.749 +socket: 0.558 +instruction: 0.409 +graphic: 0.383 +vnc: 0.376 +assembly: 0.287 +boot: 0.280 +network: 0.177 +KVM: 0.100 + +Windows guest agent shutdown requires user response to complete +Additional information: +The shutdown operation triggered by the Windows Guest Agent should prevent the system from waiting for a user response concerning unsaved work of open desktop applications. Instead, applications and services should be closed as gracefully as possible automatically, in advance of the power down event on the emulated hardware. diff --git a/results/classifier/105/mistranslation/1276879 b/results/classifier/105/mistranslation/1276879 new file mode 100644 index 000000000..e513457dd --- /dev/null +++ b/results/classifier/105/mistranslation/1276879 @@ -0,0 +1,144 @@ +mistranslation: 0.821 +semantic: 0.771 +other: 0.770 +instruction: 0.751 +assembly: 0.738 +device: 0.723 +graphic: 0.721 +KVM: 0.696 +vnc: 0.664 +network: 0.605 +boot: 0.599 +socket: 0.582 + +lots of dma command 10, 14 not supported + +Trying to install NeXTSTEP 3.3 onto a 2GB file with QEMU 1.7.0. +In the terminal that started QEMU, there are a lot of + dma: command 10 not supported +and + dma: command 14 not supported +messages. When the installation of NeXTSTEP gets to +'preparing disk for nextstep installation', there are a lot +of messages that ATA command c5 failed and other info. +The result is a failed installation. + +Is this a bug in QEMU? Is there a workaround, e.g. by +disabling DMA altogether? + +thank you + +Getting the same result in QEMU 1.6.2. NeXT setup is reporting +'interrupt timeout, cmd: 0xc5', ATA command c5 failed, +resetting drives. +This repeats until it gives up. + + +On 02/06/14 02:14, tyler knosis wrote: +> Public bug reported: +> +> Trying to install NeXTSTEP 3.3 onto a 2GB file with QEMU 1.7.0. +> In the terminal that started QEMU, there are a lot of +> dma: command 10 not supported +> and +> dma: command 14 not supported +> messages. + +These correspond to + + CMD_CYCLIC_PRIORITY + +and + + CMD_CYCLIC_PRIORITY | CMD_BLOCK_CONTROLLER + +in write_cont() [hw/dma/i8257.c]. They are not supported (see +CMD_NOT_SUPPORTED in the same file). + +> When the installation of NeXTSTEP gets to +> 'preparing disk for nextstep installation', there are a lot +> of messages that ATA command c5 failed and other info. +> The result is a failed installation. + +0xC5 is WIN_MULTWRITE ("write sectors using multiple mode"), and it +seems to hook into DMA. + +> Is this a bug in QEMU? + +Probably not, it's more likely "incomplete" DMA emulation ("lack of +support"). + +> Is there a workaround, e.g. by +> disabling DMA altogether? + +It's worth a try I guess, if you can figure out a way how to do that. +FWIW, ide_identify() appears to report unconditional support for: +- single word dma0-2 +- mdma0-2 +- udma5 + +(I have no clue about IDE or DMA btw.) + +Laszlo + + +p.s. I tried Bochs 2.6.2, and it is not stuck at the same place. Did qemu take the bochs bios +and change anything regarding the IDE drives? + + +Successfully installed NextStep in bochs, but not qemu. + +Having same problem with OpenStep 4.2 in qemu. + + +http://lists.nongnu.org/archive/html/qemu-devel/2014-02/msg00889.html + +So, Zoltan pointed to two patches. I applied the first (v8-06-10-i8259-fix.....), +but the second patches a file that is not in version 1.7.0. + +With the one patch, I am now able to get past the step where it crapped out +before. The dma messages are still there, but it seems that they can be ignored. +NextStep can now install its basic system onto a file. + +Thank you for the help so far. + +Now, I get to the point when NeXTStep want me to click on something to configure +the new system, but QEMU is not grabbing the mouse. After this step, it will install +the remainder of the system + apps. + +I have a USB mouse on a x86_64 linux machine, and QEMU 1.7.0. This is the +command line I used: +qemu-system-x86_64 -hda x.img -fda f.img -cdrom cd.img + +I have tried ctl-alt (both sides of the keyboard) to no avail. + + +The other patch is for KVM. Here's a way to build a patched kvm module (I did not test it): +http://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/#sec_0_kvm_kmod_build + +A click in the window should be enough to grab the mouse. If it's not working it may be that NeXTSTEP is using a different driver than what QEMU emulates. Since NeXTSTEP is quite old you may have better luck with a serial mouse emulation such as msmouse or make sure a PS/2 mouse driver is selected in NeXTSTEP (it may not autodetect it). + + +No luck with msmouse. NextStep assumes a PS/2 mouse, I believe, +which is what QEMU emulates by default. In bochs, the mouse does +work in NextStep. Do you know if bochs emulates the PS/2 mouse +by default? + + +I don't know about Bochs but here's another page with resources on running OPENSTEP on a VM: +http://www.zebpedersen.co.uk/?p=126 +The VMWare drivers (both svga and mouse) should work with QEMU too but I don't know if they are compatible with NeXTSTEP. +Now I remember there was some problem with mouse emulation with the PS/2 or serial driver also on VMWare which made the mouse pointer jump around and then freeze. This may also happen with QEMU but it was never debugged AFAIK. + +thank you. Will keep at it. + + +Mouse not working in WinXP with QEMU either. +But it is working with bochs (same disk image). + + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/128 b/results/classifier/105/mistranslation/128 new file mode 100644 index 000000000..0d19a74a1 --- /dev/null +++ b/results/classifier/105/mistranslation/128 @@ -0,0 +1,14 @@ +mistranslation: 0.686 +graphic: 0.673 +device: 0.645 +vnc: 0.516 +network: 0.499 +semantic: 0.483 +other: 0.464 +socket: 0.448 +boot: 0.320 +KVM: 0.309 +assembly: 0.270 +instruction: 0.251 + +man page is missing suboptions for "-display" diff --git a/results/classifier/105/mistranslation/1284874 b/results/classifier/105/mistranslation/1284874 new file mode 100644 index 000000000..1beca47a7 --- /dev/null +++ b/results/classifier/105/mistranslation/1284874 @@ -0,0 +1,139 @@ +mistranslation: 0.878 +KVM: 0.871 +graphic: 0.856 +vnc: 0.850 +device: 0.847 +network: 0.840 +instruction: 0.838 +socket: 0.832 +assembly: 0.828 +boot: 0.823 +semantic: 0.821 +other: 0.778 + +Guest hangs during option rom loading with certain cards + +With a Broadcom Corporation NetXtreme II BCM57810 10 Gigabit Ethernet card, device assignment does not work. The guest hangs during option rom execution. Moreover, if an attempt is made to quit qemu when the guest is in the hung state, the card gets into an inoperable state. Only a powercycle then, restores the card back into working order, just unloading/loading the driver does not help. + +Qemu version - 1.6.2 or current master +Distribution - FC19 +Kernel Version - 3.12.9-201.fc19.x86_64 + +Details of the card - + # ethtool -i p2p2 +driver: bnx2x +version: 1.78.17-0 +firmware-version: bc 7.8.22 +bus-info: 0000:08:00.1 +supports-statistics: yes +supports-test: yes +supports-eeprom-access: yes +supports-register-dump: yes +supports-priv-flags: yes + +The output of lspci when the card is broken - +03:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM57810 10 Gigabit Ethernet (rev ff) (prog-if ff) + !!! Unknown header type 7f + Kernel driver in use: bnx2x +00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff +10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff +20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff +30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff + +I will post if I get a chance to try out a newer than 7.8.22 for the option rom and see if this issue is fixed. However it appears we need to have a unified approach to automatically avoid loading the rom based on certain criteria. Manually, looking out for fixes to firmware and hard coding decisions based on those is neither desirable nor easy to maintain. + +Based on the trace in the attachment, the sequence of config space accesses leading up to the hang - + +vfio: vfio_pci_write_config(0000:03:00.0, @0x78, 0x1, len=0x4) +vfio: vfio_pci_write_config(0000:03:00.0, @0x80, 0x9430, len=0x4) +vfio: vfio_pci_write_config(0000:03:00.0, @0x78, 0xa30c, len=0x4) +vfio: vfio_pci_write_config(0000:03:00.0, @0x80, 0x7fffffff, len=0x4) +vfio: vfio_pci_write_config(0000:03:00.0, @0x78, 0xa5dc, len=0x4) +vfio: vfio_pci_write_config(0000:03:00.0, @0x80, 0x0, len=0x4) +vfio: vfio_pci_write_config(0000:03:00.0, @0x78, 0xa2ec, len=0x4) +vfio: vfio_pci_write_config(0000:03:00.0, @0x80, 0x3, len=0x4) +vfio: vfio_pci_read_config(0000:03:00.0, @0x98, len=0x4) 200 +vfio: vfio_pci_write_config(0000:03:00.0, @0x78, 0xa408, len=0x4) +vfio: vfio_pci_read_config(0000:03:00.0, @0x80, len=0x4) 8 + +vfio: vfio_pci_write_config(0000:03:00.0, @0x78, 0x86420, len=0x4) +vfio: vfio_pci_write_config(0000:03:00.0, @0x80, 0x4, len=0x4) +vfio: vfio_pci_write_config(0000:03:00.0, @0x78, 0x86420, len=0x4) +vfio: vfio_pci_read_config(0000:03:00.0, @0x80, len=0x4) 8 + +The last 4 writes co-relate to the point where the guest hangs because they get repeated forever + +Comments from Alex Williamson : +> The sequence leading up to this is quite short. We do standard PCI BAR +> sizing and setup, read the ROM, then do: +> +> vfio: vfio_pci_write_config(0000:03:00.0, @0x78, 0x1, len=0x4) +> vfio: vfio_pci_write_config(0000:03:00.0, @0x80, 0x9430, len=0x4) +> vfio: vfio_pci_write_config(0000:03:00.0, @0x78, 0xa30c, len=0x4) +> vfio: vfio_pci_write_config(0000:03:00.0, @0x80, 0x7fffffff, len=0x4) +> vfio: vfio_pci_write_config(0000:03:00.0, @0x78, 0xa5dc, len=0x4) +> vfio: vfio_pci_write_config(0000:03:00.0, @0x80, 0x0, len=0x4) +> vfio: vfio_pci_write_config(0000:03:00.0, @0x78, 0xa2ec, len=0x4) +> vfio: vfio_pci_write_config(0000:03:00.0, @0x80, 0x3, len=0x4) +> vfio: vfio_pci_read_config(0000:03:00.0, @0x98, len=0x4) 200 +> vfio: vfio_pci_write_config(0000:03:00.0, @0x78, 0xa408, len=0x4) +> vfio: vfio_pci_read_config(0000:03:00.0, @0x80, len=0x4) 8 +> +> vfio: vfio_pci_write_config(0000:03:00.0, @0x78, 0x86420, len=0x4) +> vfio: vfio_pci_write_config(0000:03:00.0, @0x80, 0x4, len=0x4) +> vfio: vfio_pci_write_config(0000:03:00.0, @0x78, 0x86420, len=0x4) +> vfio: vfio_pci_read_config(0000:03:00.0, @0x80, len=0x4) 8 +> +> The last 4 operations are repeated forever. + +Based on the Linux driver we can see that 0x86420 is MCP_REG_MCPR_NVM_SW_ARB which arbitrates software locking of the nvram on the device. A write of 4 seems to indicate that we want to lock port 1 for nvram access. A successful lock would set bit 2 (0x4). The value 0x8 is read back, so the lock was not successful and the ROM repeats this forever. + +Perhaps there's a problem with how the port number is selected? It seems suspicious that we're using port 1 here. + + +The vfio code has logic that checks if a FLR is possible and attempts it before and after device assignment. Replacing the FLR with a bus reset succeeds past the stuck option rom loading phase and we are able to boot into the guest successfully which means that the first initialization (by the hardware) changes something in the nvram that needs to be reset back to default by a hard (bus) reset. + +We could add an ugly hack to vfio to do a bus reset for this specific card, but it should be noted that FLR if supported, should be able to take care of this condition. + +Note that it's really the FLR that's messing up the config space if it's attempted after the sequence of events leading upto the hang. + +It's easy to reproduce this using setpci writes to the card followed by a FLR in the following manner - + +#!/bin/bash +setpci -v -s 03:00.0 4.w=2 +setpci -v -s 03:00.0 4.w +setpci -v -s 03:00.0 4.w=103 +setpci -v -s 03:00.0 4.w +setpci -v -s 03:00.0 78.l=1 +setpci -v -s 03:00.0 78.l +setpci -v -s 03:00.0 80.l=9430 +setpci -v -s 03:00.0 80.l +setpci -v -s 03:00.0 78.l=a30c +setpci -v -s 03:00.0 78.l +setpci -v -s 03:00.0 80.l=7fffffff +setpci -v -s 03:00.0 80.l +setpci -v -s 03:00.0 78.l=a5dc +setpci -v -s 03:00.0 78.l +setpci -v -s 03:00.0 80.l=0 +setpci -v -s 03:00.0 80.l +setpci -v -s 03:00.0 78.l=a2ec +setpci -v -s 03:00.0 78.l +setpci -v -s 03:00.0 80.l=3 +setpci -v -s 03:00.0 80.l +setpci -v -s 03:00.0 78.l=a408 +setpci -v -s 03:00.0 78.l +setpci -v -s 03:00.0 78.l=86420 +setpci -v -s 03:00.0 78.l +setpci -v -s 03:00.0 80.l=4 +setpci -v -s 03:00.0 80.l + +echo 1 > reset #flr then completely corrupts the config space + + +It has been suggested to blacklist loading of rom for this card (and for any other similar card that exhibit such issues) by default, a patch has been posted upstream and is going several iterations based on reviews. The most uptodate series is +[PATCH 0/2 v3] vfio: blacklist loading of unstable roms. A v4 will be posted soon. + + +Patch seems to have been included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=4b9430294ed406a00f045d + diff --git a/results/classifier/105/mistranslation/1285363 b/results/classifier/105/mistranslation/1285363 new file mode 100644 index 000000000..8b8bd4d95 --- /dev/null +++ b/results/classifier/105/mistranslation/1285363 @@ -0,0 +1,135 @@ +mistranslation: 0.838 +device: 0.783 +instruction: 0.773 +other: 0.773 +semantic: 0.752 +assembly: 0.742 +vnc: 0.735 +graphic: 0.733 +boot: 0.727 +network: 0.726 +socket: 0.721 +KVM: 0.708 + +qemu-aarch64-static segfaults + +I've found a couple conditions that causes qemu-user-static to core dump fairly reliably - same with upstream git - while a binary built from suse's aarch64-1.6 branch seems to consistently work fine. + +Testing suggests they are resolved by the sigprocmask wrapper patches included in suse's tree. + + 1) dh_fixperms is a script that commonly runs at the end of a package build. + Its basically doing a `find | xargs chmod`. + 2) debootstrap --second-stage + This is used to configure an arm64 chroot that was built using + debootstrap on a non-native host. It is basically invoking a bunch of + shell scripts (postinst, etc). When it blows up, the stack consistently + looks like this: + +Core was generated by `/usr/bin/qemu-aarch64-static /bin/sh -e +/debootstrap/debootstrap --second-stage'. +Program terminated with signal SIGSEGV, Segmentation fault. +#0 0x0000000060058e55 in memcpy (__len=8, __src=0x7fff62ae34e0, +__dest=0x400082c330) at +/usr/include/x86_64-linux-gnu/bits/string3.h:51 +51 return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest)); +(gdb) bt +#0 0x0000000060058e55 in memcpy (__len=8, __src=0x7fff62ae34e0, +__dest=0x400082c330) at +/usr/include/x86_64-linux-gnu/bits/string3.h:51 +#1 stq_p (v=274886476624, ptr=0x400082c330) at +/mnt/qemu.upstream/include/qemu/bswap.h:280 +#2 stq_le_p (v=274886476624, ptr=0x400082c330) at +/mnt/qemu.upstream/include/qemu/bswap.h:315 +#3 target_setup_sigframe (set=0x7fff62ae3530, env=0x62d9c678, +sf=0x400082b0d0) at /mnt/qemu.upstream/linux-user/signal.c:1167 +#4 target_setup_frame (usig=usig@entry=17, ka=ka@entry=0x604ec1e0 +<sigact_table+512>, info=info@entry=0x0, set=set@entry=0x7fff62ae3530, +env=env@entry=0x62d9c678) + at /mnt/qemu.upstream/linux-user/signal.c:1286 +#5 0x0000000060059f46 in setup_frame (env=0x62d9c678, +set=0x7fff62ae3530, ka=0x604ec1e0 <sigact_table+512>, sig=17) at +/mnt/qemu.upstream/linux-user/signal.c:1322 +#6 process_pending_signals (cpu_env=cpu_env@entry=0x62d9c678) at +/mnt/qemu.upstream/linux-user/signal.c:5747 +#7 0x0000000060056e60 in cpu_loop (env=env@entry=0x62d9c678) at +/mnt/qemu.upstream/linux-user/main.c:1082 +#8 0x0000000060005079 in main (argc=<optimized out>, argv=<optimized +out>, envp=<optimized out>) at +/mnt/qemu.upstream/linux-user/main.c:4374 + + + +The attachment "qemu.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team. + +[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.] + +I'm a little nervous about the do_sigprocmask in linux-user/signal.c for all arches. With the comment + +/* Force set state of SIGSEGV, may be best for some apps, maybe not so good +++ * This is not required for qemu to work + +Doing this conditionally for arm64 would be more comforting... + +I'll go ahead and run some tests with it tomorrow on amd64. + +Dann, + +can you confirm that you can reproduce this with the upstream git head (or the qemu-2.0~git package)? + +I'm building a candidate package with a modified version of the patchset (to only change behavior for aarch64 targets) in ppa:serge-hallyn/virt. + +On Thu, Feb 27, 2014 at 3:34 PM, Serge Hallyn +<email address hidden> wrote: +> Dann, +> +> can you confirm that you can reproduce this with the upstream git head +> (or the qemu-2.0~git package)? + +I just reverified with upstream git head @ +9fbee91a131a05e443d7108d7fbdf3ca91020290. +Note that this appears to only be reproducible on systems with > 1 CPU +(easy to reproduce on 4). + + +@Serge: I can confirm that this is fixed in 1.7.0+dfsg-3ubuntu5sig1 from your ppa. + +Doing this only for aarch64 targets seems like a bad idea to me -- this isn't an aarch64 specific issue. QEMU needs SIGSEGV to go to its own handler (so we can unprotect pages we've marked as read-only in order to catch guest writes to them so we can throw away invalidated translated code), and that's true for all targets. It probably just happens more often on the aarch64 target than others you've tested because aarch64 has a signal-return trampoline on the stack frame, so we'll often see that page get translated and thrown away again. (Other targets with a trampoline include sparc, cris, openrisc and ppc.) + +PS: the comment "this is not required for qemu to work" just means that QEMU will work fine whether we tell the guest a lie about what's going on with SIGSEGV in one way (saying "it's blocked") or the other (saying "it's not blocked"). + + +Quoting Peter Maydell (<email address hidden>): +> Doing this only for aarch64 targets seems like a bad idea to me -- this +> isn't an aarch64 specific issue. QEMU needs SIGSEGV to go to its own +> handler (so we can unprotect pages we've marked as read-only in order to +> catch guest writes to them so we can throw away invalidated translated +> code), and that's true for all targets. It probably just happens more +> often on the aarch64 target than others you've tested because aarch64 +> has a signal-return trampoline on the stack frame, so we'll often see +> that page get translated and thrown away again. (Other targets with a +> trampoline include sparc, cris, openrisc and ppc.) + +I see. I've just pushed the customized patch to the archive. We can +switch to the original patchset though. But, I'd also like to see what +ends up hitting upstream. + + +This bug was fixed in the package qemu - 1.7.0+dfsg-3ubuntu5 + +--------------- +qemu (1.7.0+dfsg-3ubuntu5) trusty; urgency=medium + + [ dann frazier ] + * Add patches from the susematz tree to avoid intermittent segfaults: + - ubuntu/signal-added-a-wrapper-for-sigprocmask-function.patch + - ubuntu/signal-sigsegv-protection-on-do_sigprocmask.patch + - ubuntu/Don-t-block-SIGSEGV-at-more-places.patch + + [ Serge Hallyn ] + * Modify do_sigprocmask to only change behavior for aarch64. + (LP: #1285363) + -- Serge Hallyn <email address hidden> Thu, 06 Mar 2014 16:15:50 -0600 + +We've now overhauled the signal handling code in upstream QEMU, and it has its own implementation of the basic idea in the patch from comment 1 (which is "don't let the guest block SIGSEGV"). + + diff --git a/results/classifier/105/mistranslation/1287195 b/results/classifier/105/mistranslation/1287195 new file mode 100644 index 000000000..ab6e3d0f2 --- /dev/null +++ b/results/classifier/105/mistranslation/1287195 @@ -0,0 +1,24 @@ +mistranslation: 0.851 +device: 0.792 +instruction: 0.759 +socket: 0.671 +vnc: 0.658 +network: 0.632 +boot: 0.512 +other: 0.489 +graphic: 0.419 +semantic: 0.389 +KVM: 0.176 +assembly: 0.061 + +validate_guest_space incorrectly enabled on AArch64 + +When running linux-user targetting AArch64, validate_guest_space() in elfload.c reserves space in the guest address space for the ARM commpage. Since there is no commpage on AArch64, this function should be disable on that target. + +Thanks for the bug report -- I've just submitted this patch which should fix this: + http://patchwork.ozlabs.org/patch/328565/ + + +Fix will be in 2.0. + + diff --git a/results/classifier/105/mistranslation/1298442 b/results/classifier/105/mistranslation/1298442 new file mode 100644 index 000000000..0c548453f --- /dev/null +++ b/results/classifier/105/mistranslation/1298442 @@ -0,0 +1,32 @@ +mistranslation: 0.774 +instruction: 0.728 +device: 0.669 +semantic: 0.573 +network: 0.543 +graphic: 0.453 +socket: 0.416 +assembly: 0.347 +vnc: 0.324 +other: 0.308 +boot: 0.285 +KVM: 0.167 + +build problem in qemu-2.0.0-rc0 No rule to make target `trace/generated-events.h' + +With qemu-2.0.0-rc0 on CentOS release 5.7 (Final) I get + +make: *** No rule to make target `trace/generated-events.h', needed by `Makefile'. Stop. + +On Thu, Mar 27, 2014 at 02:58:32PM -0000, Mark Wood-Patrick wrote: +> Public bug reported: +> +> With qemu-2.0.0-rc0 on CentOS release 5.7 (Final) I get +> +> make: *** No rule to make target `trace/generated-events.h', needed by +> `Makefile'. Stop. + +Please try "make distclean" and then ./configure and make again. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/130 b/results/classifier/105/mistranslation/130 new file mode 100644 index 000000000..086c02e46 --- /dev/null +++ b/results/classifier/105/mistranslation/130 @@ -0,0 +1,14 @@ +mistranslation: 0.997 +device: 0.753 +other: 0.670 +network: 0.510 +graphic: 0.437 +semantic: 0.431 +boot: 0.236 +vnc: 0.147 +socket: 0.143 +instruction: 0.103 +assembly: 0.074 +KVM: 0.026 + +QEmu translation is incorrect when using REX in combination with LAHF/SAHF diff --git a/results/classifier/105/mistranslation/1300863 b/results/classifier/105/mistranslation/1300863 new file mode 100644 index 000000000..d4aaf2e14 --- /dev/null +++ b/results/classifier/105/mistranslation/1300863 @@ -0,0 +1,23 @@ +mistranslation: 0.948 +device: 0.895 +boot: 0.877 +graphic: 0.782 +semantic: 0.724 +network: 0.672 +instruction: 0.648 +vnc: 0.563 +socket: 0.538 +other: 0.479 +assembly: 0.136 +KVM: 0.028 + +Qemu does not show all files on floppy or hard drive (MS DOS 6.22 guest) + +My host system is a raspberry pi model B 512MB. To start qemu I typed into lxterminal: + +qemu-system-i386 -hda qemu.img -Fda Dos622-1.img -boot a + +Qemu version 1.7.0+dfsg-3 installed as package. The DOS disks were downloaded from winworldpc.com and if I mount them under Linux I see all the files, but on qemu I see the first 3 files only. The hard drive image I am using is a 30MB flat image created using bximage. + +Seems like you are using the QEMU from your Linux distribution. If you want to have support for that version, you should use the bug tracker from your distro instead. Otherwise, can you please try again with the latest version from http://wiki.qemu-project.org/Download to see whether the bug is already fixed there? Thanks! + diff --git a/results/classifier/105/mistranslation/1305402 b/results/classifier/105/mistranslation/1305402 new file mode 100644 index 000000000..643e60df1 --- /dev/null +++ b/results/classifier/105/mistranslation/1305402 @@ -0,0 +1,112 @@ +mistranslation: 0.883 +KVM: 0.865 +other: 0.861 +network: 0.852 +graphic: 0.840 +vnc: 0.821 +instruction: 0.816 +semantic: 0.813 +assembly: 0.795 +socket: 0.794 +device: 0.789 +boot: 0.744 + +libvirt fails to start VirtualMachines + +I've created several kvm based machines with the 'trusty' designation using virtual machine manager. They have operated well over the last 4 days without issue. I did an apt-get upgrade, and qemu was in the list of updates. + +After upgrading, I am unable to start any of the provisioned virtual machines with the following error output + +virsh # start node2 +error: Failed to start domain node2 +error: internal error: process exited while connecting to monitor: qemu-system-x86_64: -machine trusty,accel=kvm,usb=off: Unsupported machine type +Use -machine help to list supported machines! + + +virsh # start node3 +error: Failed to start domain node3 +error: internal error: process exited while connecting to monitor: qemu-system-x86_64: -machine trusty,accel=kvm,usb=off: Unsupported machine type +Use -machine help to list supported machines! + + + +$ dpkg -l | grep kvm +ii qemu-kvm 2.0.0~rc1+dfsg-0ubuntu3 amd64 QEMU Full virtualization on x86 hardware (transitional package) + +Log snippet from vm 'media' that was verified working, and fails to start after the upgrade. + +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm-spice -name media -S -machine trusty,accel=kvm,usb=off -m 1548 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 60b20f7b-6d20-bcb3-f4fc-808a9b2fe0d0 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/media.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot menu=off,strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/libvirt/images/media.img,if=none,id=drive-virtio-disk0,format=raw -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/home/charles/iso/ubuntu-desktop-12.04.4-amd64.iso,if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=26 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:a0:69:d9,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -vnc 127.0.0.1:1 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 +char device redirected to /dev/pts/13 (label charserial0) +qemu: terminating on signal 15 from pid 31688 +2014-04-10 03:36:54.593+0000: shutting down +2014-04-10 03:59:25.487+0000: starting up +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm-spice -name media -S -machine trusty,accel=kvm,usb=off -m 1548 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 60b20f7b-6d20-bcb3-f4fc-808a9b2fe0d0 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/media.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot menu=off,strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/libvirt/images/media.img,if=none,id=drive-virtio-disk0,format=raw -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/home/charles/iso/ubuntu-desktop-12.04.4-amd64.iso,if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=25 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:a0:69:d9,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -vnc 127.0.0.1:0 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 +qemu-system-x86_64: -machine trusty,accel=kvm,usb=off: Unsupported machine type +Use -machine help to list supported machines! +2014-04-10 03:59:25.696+0000: shutting down + +After some additional investigating it looks like the XML format for the trusty machine has changed. I created a new VM and got it to boot off my MAAS cluster, The immediate change I see is: + +new: + <type arch='x86_64' machine='pc-i440fx-trusty'>hvm</type> + +old: + <type arch='x86_64' machine='trusty'>hvm</type> + +None of the old XML machines were updated with this new machine flag. + +Thanks for reporting this bug. We briefly had a 'trusty' machine type, with a corresponding libvirt patch to handle it. When we renamed the trusty machine type we dropped the libvirt patch to handle it. + +We should either re-introduce the libvirt patch to handle the trusty machine type for those who have stale VM definitions, or mention this in the release notes. In either case we should keep this bug open to guide others who run into this problem. + +This has just happened to me. For some reason, all my machines had machine='pc-i440fx-wily'. +After an update in yakkety, they stopped working. + +$ qemu-system-x86_64 -enable-kvm -machine help | grep wily + +So I updated the machine xml to a supported machine as Charles suggested, and they work again. + +Here's the note for my future self about how to do the update: + +$ virsh dumpxml $machine-name > /tmp/machine.xml +Edit the xml. +$ virsh define /tmp/machine.xml + +Machine type changes may be related to: + +https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1626070 + +There's a PPA in the bug with a fix for at least the wily machine type. + +On Thu, Sep 22, 2016 at 6:05 PM, Leo Arias <email address hidden> wrote: + +> This has just happened to me. For some reason, all my machines had +> machine='pc-i440fx-wily'. +> After an update in yakkety, they stopped working. +> +> $ qemu-system-x86_64 -enable-kvm -machine help | grep wily +> +> So I updated the machine xml to a supported machine as Charles +> suggested, and they work again. +> +> Here's the note for my future self about how to do the update: +> +> $ virsh dumpxml $machine-name > /tmp/machine.xml +> Edit the xml. +> $ virsh define /tmp/machine.xml +> +> -- +> You received this bug notification because you are subscribed to qemu in +> Ubuntu. +> https://bugs.launchpad.net/bugs/1305402 +> +> Title: +> libvirt fails to start VirtualMachines +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1305402/+subscriptions +> + + +Yeah I'm pretty sure this is a dupe of bug 1626070. + diff --git a/results/classifier/105/mistranslation/1307 b/results/classifier/105/mistranslation/1307 new file mode 100644 index 000000000..5992891ce --- /dev/null +++ b/results/classifier/105/mistranslation/1307 @@ -0,0 +1,85 @@ +mistranslation: 0.297 +KVM: 0.226 +vnc: 0.193 +other: 0.169 +graphic: 0.168 +device: 0.161 +semantic: 0.160 +assembly: 0.157 +instruction: 0.156 +network: 0.150 +socket: 0.148 +boot: 0.147 + +query-named-block-nodes, without flat=true, is massively slow as number of block nodes increases +Description of problem: +The query-named-block-nodes command is insanely slow with deep backing chains when the flat=true arg is NOT given. + +``` +qemu-img create demo0.qcow2 1g +j=0 +for i in `seq 1 199` +do + qemu-img create -f qcow2 -o backing_file=demo$j.qcow2 -o backing_fmt=qcow2 demo$i.qcow2 + j=$i +done +``` + +Now configure libvirt with + +``` + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' discard='unmap'/> + <source file='/var/lib/libvirt/images/demo199.qcow2'/> + <target dev='vdb' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x07' slot='0x00' function='0x0'/> + </disk> +``` + +This results in `-blockdev` args + +``` +-blockdev '{"driver":"file","filename":"/var/lib/libvirt/images/demo0.qcow2","node-name":"libvirt-201-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-201-format","read-only":true,"discard":"unmap","driver":"qcow2","file":"libvirt-201-storage","backing":null}' \ +-blockdev '{"driver":"file","filename":"/var/lib/libvirt/images/demo1.qcow2","node-name":"libvirt-200-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-200-format","read-only":true,"discard":"unmap","driver":"qcow2","file":"libvirt-200-storage","backing":"libvirt-201-format"}' \ +-blockdev '{"driver":"file","filename":"/var/lib/libvirt/images/demo2.qcow2","node-name":"libvirt-199-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-199-format","read-only":true,"discard":"unmap","driver":"qcow2","file":"libvirt-199-storage","backing":"libvirt-200-format"}' \ +...snip... +-blockdev '{"driver":"file","filename":"/var/lib/libvirt/images/demo197.qcow2","node-name":"libvirt-4-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-4-format","read-only":true,"discard":"unmap","driver":"qcow2","file":"libvirt-4-storage","backing":"libvirt-5-format"}' \ +-blockdev '{"driver":"file","filename":"/var/lib/libvirt/images/demo198.qcow2","node-name":"libvirt-3-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-3-format","read-only":true,"discard":"unmap","driver":"qcow2","file":"libvirt-3-storage","backing":"libvirt-4-format"}' \ +-blockdev '{"driver":"file","filename":"/var/lib/libvirt/images/demo199.qcow2","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"discard":"unmap","driver":"qcow2","file":"libvirt-1-storage","backing":"libvirt-3-format"}' \ +-device '{"driver":"virtio-blk-pci","bus":"pci.7","addr":"0x0","drive":"libvirt-1-format","id":"virtio-disk1"}' \ +``` + +Now stop libvirt + +``` +systemctl stop libvirtd +``` + +And speak directly to QMP + +``` +$ time socat UNIX:/var/lib/libvirt/qemu/domain-158-fedora38/monitor.sock - > /dev/null +{ "execute": "qmp_capabilities", "arguments": { "enable": ["oob"] } } +{ "execute": "query-named-block-nodes"} +{ "execute": "quit" } + +real 2m19.276s +user 0m0.006s +sys 0m0.014s +``` + +If we save the 'query-named-block-nodes' output instead of sending it to /dev/null, we get a 86 MB file for the QMP response. This will break all known client apps since they limit QMP reply size. + +It appears to have a combinatorial expansion of block nodes in the output. + +Blocking the main event loop for 2 minutes is obviously not good either. + +If we use '"flat": true' parameter to query-named-block-nodes, the command completes in just 15 seconds, and produces a large, but more manageable 2.7 MB + +Since the non-flat query-named-block-nodes output is so incredibly non-scalable, I think we should deprecate non-flat mode, and eventually make flat the mandatory option. diff --git a/results/classifier/105/mistranslation/1311614 b/results/classifier/105/mistranslation/1311614 new file mode 100644 index 000000000..fbf42b571 --- /dev/null +++ b/results/classifier/105/mistranslation/1311614 @@ -0,0 +1,135 @@ +mistranslation: 0.906 +device: 0.901 +instruction: 0.862 +vnc: 0.832 +other: 0.827 +network: 0.805 +semantic: 0.797 +assembly: 0.796 +graphic: 0.789 +socket: 0.770 +KVM: 0.743 +boot: 0.682 + +qemu-arm segfaults with gcc 4.9.0 + +I have an ARM chroot that working with qemu-arm emulation + +[root@filzbach fedya]# cat /proc/sys/fs/binfmt_misc/arm +enabled +interpreter /usr/bin/qemu-arm-binfmt +flags: P +offset 0 +magic 7f454c4601010100000000000000000002002800 +mask ffffffffffffff00fffffffffffffffffeffffff + + +In chroot installed gcc dependencies with 4.9.0 version + +sudo rpm --root /home/fedya/root/ -qa | grep 4.9.0 + +libgcc1-4.9.0_2014.04-1-omv2013.0.armv7hl +libgomp1-4.9.0_2014.04-1-omv2013.0.armv7hl +libstdc++6-4.9.0_2014.04-1-omv2013.0.armv7hl +gcc-4.9.0_2014.04-1-omv2013.0.armv7hl +gcc-cpp-4.9.0_2014.04-1-omv2013.0.armv7hl +libstdc++-devel-4.9.0_2014.04-1-omv2013.0.armv7hl +gcc-c++-4.9.0_2014.04-1-omv2013.0.armv7hl + + +When i try to run "rpm" , "rpmbuild", "rpm2cpio"command i always see qemu segfault message + + +example: + +[root@filzbach /]# uname -a +Linux filzbach.lindev.ch 3.13.6-nrjQL-desktop-70omv #1 SMP PREEMPT Wed Mar 12 21:40:00 UTC 2014 armv7l armv7l armv7l GNU/Linux + +[root@filzbach /]# rpm +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + + +Segfault became apparent only after gcc upgrade from 4.8.3 to 4.9.0. + +When i downgrade it to 4.8.3 all working fine again. +It looks like a qemu bug with gcc. + + +P.S. +I tried to rebuild qemu with gcc 4.9.0 +I tried to build qemu from git sources, from fedora sources, from suse sources etc. + +And of course i rebuilt rpm package with latest gcc 4.9.0 +Btw all working fine on a real hardware. + +Bump + +A backtrace of where the crash is in QEMU might be interesting. + +Do you have any howto to produce backtrace? + +I debugged it originally but did only suggest a temporary workaround... +The crash, not really in qemu, looks like this: + +--%<-- +Remote debugging using localhost:1235 +Reading symbols from +/home/fedya/openmandriva/home/fedya/root/lib/ld-linux-armhf.so.3...Reading +symbols from +/home2/fedya/openmandriva/home/fedya/root/usr/lib/debug/lib/ld-2.19.so.debug...done. +done. +Loaded symbols for /home/fedya/openmandriva/home/fedya/root/lib/ld-linux-armhf.so.3 +0xf67dfd00 in _start () + from /home/fedya/openmandriva/home/fedya/root/lib/ld-linux-armhf.so.3 +(gdb) c +Continuing. + +Program received signal SIGSEGV, Segmentation fault. +memset () at ../ports/sysdeps/arm/memset.S:53 +53 sfi_breg r3, \ +(gdb) bt +#0 memset () at ../ports/sysdeps/arm/memset.S:53 +#1 0xf650b5da in __pthread_getaffinity_new (th=th@entry=4123619328, cpusetsize=4, + cpuset=0xf008) at ../nptl/sysdeps/unix/sysv/linux/pthread_getaffinity.c:41 +#2 0xf60ca6d8 in gomp_init_num_threads () at +../../../libgomp/config/linux/proc.c:93 +#3 0xf60c28b2 in initialize_env () at ../../../libgomp/env.c:1187 +#4 0xf67ea514 in call_init (env=<optimized out>, argv=<optimized out>, + argc=<optimized out>, l=<optimized out>) at dl-init.c:76 +#5 _dl_init (main_map=0xf67fe908, argc=1, argv=0xf6ffecf4, env=0xf6ffecfc) + at dl-init.c:124 +#6 0xf67dfd32 in _dl_start_user () + from /home/fedya/openmandriva/home/fedya/root/lib/ld-linux-armhf.so.3 +Backtrace stopped: previous frame identical to this frame (corrupt stack?) +(gdb) q +A debugging session is active. + + Inferior 1 [Remote target] will be killed. + +Quit anyway? (y or n) y +--%<-- + +My suggestion was to report problems upstream ofcourse, and +a temporary quick fix would be to replace libgomp from the one +from gcc 4.8x or replace the body of gomp_init_num_threads +from gcc-4.9.0/libgomp/config/linux/proc.c with the one from +gcc-4.8.2/libgomp/config/linux/proc.c + +I believe gcc 4.9 is too smart, and some stub is missing somewhere, +e.g. in the arm chroot checking /proc/cpuinfo shows x86_64 cpus. + + +Hmm, getaffinity? Can you try applying this qemu patch: +https://patches.linaro.org/30259/ + +and see if it resolves the problem? + + +Will do! +Thanks + +Fixed, thanks + +Fixed by commit be3bd286bc06 back in 2014. + + diff --git a/results/classifier/105/mistranslation/1318091 b/results/classifier/105/mistranslation/1318091 new file mode 100644 index 000000000..6581c5ec5 --- /dev/null +++ b/results/classifier/105/mistranslation/1318091 @@ -0,0 +1,68 @@ +mistranslation: 0.921 +other: 0.894 +semantic: 0.893 +instruction: 0.857 +assembly: 0.857 +graphic: 0.845 +device: 0.844 +vnc: 0.826 +network: 0.806 +KVM: 0.789 +socket: 0.788 +boot: 0.774 + +Perfctr MSRs not available to Guest OS on AMD Phenom II + +The AMD Phenom(tm) II X4 965 Processor (family 16, model 4, stepping 3) has the 4 architecturally supported perf counters at MSRs. The selectors are c001000-c001003, and the counters are c001004-c001007. I've verified that the MSRs are there and working by manually setting the MSRs with msr-tools to count cycles. + +The processor does not support the extended perfctr or the perfctr_nb. These are in cpuid leaf 8000_0001. Qemu also sees that these cpuid flags are not set, when I try launching with -cpu host,perfctr_core,check. However, this flag is only for the extended perfctr MSRs, which also happen to map the original four counters at c0010200. + +When I run a Guest OS, that OS is unable to use the perf counter registers from c001000-7. rdmsr and wrmsr complete, but the results are always 0. By contrast, a wrmsr to one of the c0010200 registers causes a general protection fault (as it should, since those aren't supported). + +Kernel: 3.14.0-gentoo +Qemu: 2.0.0 (gentoo) and also with 2.0.50 (commit 06b4f00d5) +Qemu command: qemu-system-x86_64 -enable-kvm -cpu host -smp 8 -m 1024 -nographic -monitor /dev/pts/4 mnt/hdd.img +cat /proc/cpuinfo: +processor : 3 +vendor_id : AuthenticAMD +cpu family : 16 +model : 4 +model name : AMD Phenom(tm) II X4 965 Processor +stepping : 3 +cpu MHz : 800.000 +cache size : 512 KB +physical id : 0 +siblings : 4 +core id : 3 +cpu cores : 4 +apicid : 3 +initial apicid : 3 +fpu : yes +fpu_exception : yes +cpuid level : 5 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt hw_pstate npt lbrv svm_lock nrip_save +bogomips : 6803.79 +TLB size : 1024 4K pages +clflush size : 64 +cache_alignment : 64 +address sizes : 48 bits physical, 48 bits virtual +power management: ts ttp tm stc 100mhzsteps hwpstate + +thanks. + +i don't understand this in detail, but since the last update of qemu i can't start my virtual win7 machine. i use gnome-boxes 3.24. qemu 2.8 works, 2.9 leads to this: +Preformatted text(gnome-boxes:4301): Boxes-WARNING **: machine.vala:611: Failed to start win7: Unable to start domain: the CPU is incompatible with host CPU: Host CPU does not provide required features: monitor, rdtscp, svm + +i ask, because i also use an phenom 2 x4 and if this is the bug i don't need to opan a new one. + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +Hi - + +I don't have the hardware readily available anymore, so I can't test it. Might as well close the bug. + +Regarding Oliver's question, it doesn't sound like the same issue I had. I do recall that processor and qemu not supporting rdtscp (which is fine), so that problem might be some qemu startup script requesting features that aren't available. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1318474 b/results/classifier/105/mistranslation/1318474 new file mode 100644 index 000000000..5e3787ac2 --- /dev/null +++ b/results/classifier/105/mistranslation/1318474 @@ -0,0 +1,33 @@ +mistranslation: 0.865 +instruction: 0.771 +device: 0.751 +graphic: 0.656 +other: 0.569 +vnc: 0.545 +boot: 0.528 +semantic: 0.503 +network: 0.469 +socket: 0.465 +assembly: 0.400 +KVM: 0.326 + +QEMU update causes Windows reactivation + +After updating QEMU the guest OS's detect new hardware. As a result any Windows OS sees it as a significant change in hardware and require a reactivation. + +Host OS: Ubuntu 14.04 64-bit + +Guest OS's: +Windows Server 2003 R2 Enterprise +Windows Server 2008 R2 Enterprise +Windows Server 2008 R2 Web +Windows Server 2008 R2 Data Center + +QEMU version: 2.0.0 + +How did you start QEMU with the new version here? You might need to specify the correct machine type with the new version to avoid that the guest sees different hardware (e.g. with the "-machine pc-i440fx-2.0" option). + +[Expired for QEMU because there has been no activity for 60 days.] + +When updating QEMU use specific machine type and this will keep "old" HW. + diff --git a/results/classifier/105/mistranslation/1320360 b/results/classifier/105/mistranslation/1320360 new file mode 100644 index 000000000..3ef3ed14b --- /dev/null +++ b/results/classifier/105/mistranslation/1320360 @@ -0,0 +1,508 @@ +mistranslation: 0.917 +graphic: 0.890 +assembly: 0.884 +semantic: 0.868 +socket: 0.864 +instruction: 0.855 +device: 0.851 +boot: 0.836 +other: 0.822 +network: 0.822 +KVM: 0.784 +vnc: 0.762 + +usb passthrough not working anymore + +Hi, + +I'm using qemu 2.0.0 with opensuse 13.1 x84_64 bit as host and window7 as guest. Til qemu version 1.6.2 USB passthrough works perfectly, but starting with qemu 2.0.0 passthrough stop working. I can still add the usb device but when I start the guest following message appears: + +"unable to execute QEMU command 'device_add': 'usb-host' is not a valid device model name" + +Then the guest will not start. + +I try it with different usb devices (iphone, stick, hdd), always the same error. + +Are there any news / hints about this ? + +Regards + +Martin + +Be sure to add the -usb option. What is your command line? + +See also http://git.qemu.org/?p=qemu.git;a=blob;f=docs/usb2.txt;h=c7a445afcd55fe1f12033d529d668a1306d5a9f4;hb=HEAD#l111 + +Hi, + +From qemu-1.7 release version, the old usb-host(host-linux.c) had been removed, +re-implemented by libusbx. So you should build qemu with --enable-libusb, then +you can use usb pass-through capacity. + +BTW, Gerd, should we enable libusb by default now? Thanks. + + +Best regards, +-Gonglei + +> -----Original Message----- +> From: <email address hidden> +> [mailto:<email address hidden>] On +> Behalf Of Martin R?h +> Sent: Saturday, May 17, 2014 3:35 AM +> To: <email address hidden> +> Subject: [Qemu-devel] [Bug 1320360] [NEW] usb passthrough not working +> anymore +> +> Public bug reported: +> +> Hi, +> +> I'm using qemu 2.0.0 with opensuse 13.1 x84_64 bit as host and window7 +> as guest. Til qemu version 1.6.2 USB passthrough works perfectly, but +> starting with qemu 2.0.0 passthrough stop working. I can still add the +> usb device but when I start the guest following message appears: +> +> "unable to execute QEMU command 'device_add': 'usb-host' is not a valid +> device model name" +> +> Then the guest will not start. +> +> I try it with different usb devices (iphone, stick, hdd), always the +> same error. +> +> Are there any news / hints about this ? +> +> Regards +> +> 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/1320360 +> +> Title: +> usb passthrough not working anymore +> +> Status in QEMU: +> New +> +> Bug description: +> Hi, +> +> I'm using qemu 2.0.0 with opensuse 13.1 x84_64 bit as host and window7 +> as guest. Til qemu version 1.6.2 USB passthrough works perfectly, but +> starting with qemu 2.0.0 passthrough stop working. I can still add the +> usb device but when I start the guest following message appears: +> +> "unable to execute QEMU command 'device_add': 'usb-host' is not a +> valid device model name" +> +> Then the guest will not start. +> +> I try it with different usb devices (iphone, stick, hdd), always the +> same error. +> +> Are there any news / hints about this ? +> +> Regards +> +> Martin +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1320360/+subscriptions + + + +The command line is + +/usr/bin/qemu-system-x86_64 -machine accel=kvm -name win8 -S -machine +pc-i440fx-2.0,accel=kvm,usb=off -cpu Nehalem -m 2048 -realtime mlock=off +-smp 2,sockets=2,cores=1,threads=1 -uuid +424ca5ec-2fb4-4d1c-84c4-25b92d468b8e -no-user-config -nodefaults +-chardev +socket,id=charmonitor,path=/var/lib/libvirt/qemu/win8.monitor,server,nowait +-mon chardev=charmonitor,id=monitor,mode=control -rtc +base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=discard +-no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global +PIIX4_PM.disable_s4=1 -boot strict=on -device +ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x4.0x7 -device +ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x4 +-device +ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x4.0x1 +-device +ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x4.0x2 +-device ahci,id=ahci0,bus=pci.0,addr=0x7 -drive +file=/opt/emu/win8.raw,if=none,id=drive-virtio-disk0,format=raw -device +virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=2 +-netdev tap,fd=22,id=hostnet0,vhost=on,vhostfd=23 -device +virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:44:d1:dc,bus=pci.0,addr=0x3 +-chardev pty,id=charserial0 -device +isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 +-vnc 127.0.0.1:0 -device VGA,id=video0,bus=pci.0,addr=0x2 -device +intel-hda,id=sound0,bus=pci.0,addr=0x8 -device +hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device +virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 + +Am 17.05.2014 01:15, schrieb Lekensteyn: +> Be sure to add the -usb option. What is your command line? +> +> See also +> http://git.qemu.org/?p=qemu.git;a=blob;f=docs/usb2.txt;h=c7a445afcd55fe1f12033d529d668a1306d5a9f4;hb=HEAD#l111 +> + + + +Hi, + +as far as I can see from the rpm specs of the opensuse rpm package the +--enable-libusb is set . + +Regards + +Martin + +Am 18.05.2014 06:52, schrieb Gonglei (Arei): +> Hi, +> +> From qemu-1.7 release version, the old usb-host(host-linux.c) had been removed, +> re-implemented by libusbx. So you should build qemu with --enable-libusb, then +> you can use usb pass-through capacity. +> +> BTW, Gerd, should we enable libusb by default now? Thanks. +> +> +> Best regards, +> -Gonglei +> +>> -----Original Message----- +>> From: <email address hidden> +>> [mailto:<email address hidden>] On +>> Behalf Of Martin R?h +>> Sent: Saturday, May 17, 2014 3:35 AM +>> To: <email address hidden> +>> Subject: [Qemu-devel] [Bug 1320360] [NEW] usb passthrough not working +>> anymore +>> +>> Public bug reported: +>> +>> Hi, +>> +>> I'm using qemu 2.0.0 with opensuse 13.1 x84_64 bit as host and window7 +>> as guest. Til qemu version 1.6.2 USB passthrough works perfectly, but +>> starting with qemu 2.0.0 passthrough stop working. I can still add the +>> usb device but when I start the guest following message appears: +>> +>> "unable to execute QEMU command 'device_add': 'usb-host' is not a valid +>> device model name" +>> +>> Then the guest will not start. +>> +>> I try it with different usb devices (iphone, stick, hdd), always the +>> same error. +>> +>> Are there any news / hints about this ? +>> +>> Regards +>> +>> 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/1320360 +>> +>> Title: +>> usb passthrough not working anymore +>> +>> Status in QEMU: +>> New +>> +>> Bug description: +>> Hi, +>> +>> I'm using qemu 2.0.0 with opensuse 13.1 x84_64 bit as host and window7 +>> as guest. Til qemu version 1.6.2 USB passthrough works perfectly, but +>> starting with qemu 2.0.0 passthrough stop working. I can still add the +>> usb device but when I start the guest following message appears: +>> +>> "unable to execute QEMU command 'device_add': 'usb-host' is not a +>> valid device model name" +>> +>> Then the guest will not start. +>> +>> I try it with different usb devices (iphone, stick, hdd), always the +>> same error. +>> +>> Are there any news / hints about this ? +>> +>> Regards +>> +>> Martin +>> +>> To manage notifications about this bug go to: +>> https://bugs.launchpad.net/qemu/+bug/1320360/+subscriptions +> + + + +Hi, + +if I try to start the vm by virt-manager I get this detailed error log: + +Fehler beim Starten der Domain: internal error: early end of file from +monitor: possible problem: +qemu-system-x86_64: -device usb-host,hostbus=1,hostaddr=3,id=hostdev0: +'usb-host' is not a valid device model name + + +Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 91, in +cb_wrapper + callback(asyncjob, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 127, in +tmpcb + callback(*args, **kwargs) + File "/usr/share/virt-manager/virtManager/domain.py", line 1363, in +startup + self._backend.create() + File "/usr/lib64/python2.7/site-packages/libvirt.py", line 917, in create + if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self) +libvirtError: internal error: early end of file from monitor: possible +problem: +qemu-system-x86_64: -device usb-host,hostbus=1,hostaddr=3,id=hostdev0: +'usb-host' is not a valid device model name + +Regards + +Martin + +Am 18.05.2014 06:52, schrieb Gonglei (Arei): +> Hi, +> +> From qemu-1.7 release version, the old usb-host(host-linux.c) had been removed, +> re-implemented by libusbx. So you should build qemu with --enable-libusb, then +> you can use usb pass-through capacity. +> +> BTW, Gerd, should we enable libusb by default now? Thanks. +> +> +> Best regards, +> -Gonglei +> +>> -----Original Message----- +>> From: <email address hidden> +>> [mailto:<email address hidden>] On +>> Behalf Of Martin R?h +>> Sent: Saturday, May 17, 2014 3:35 AM +>> To: <email address hidden> +>> Subject: [Qemu-devel] [Bug 1320360] [NEW] usb passthrough not working +>> anymore +>> +>> Public bug reported: +>> +>> Hi, +>> +>> I'm using qemu 2.0.0 with opensuse 13.1 x84_64 bit as host and window7 +>> as guest. Til qemu version 1.6.2 USB passthrough works perfectly, but +>> starting with qemu 2.0.0 passthrough stop working. I can still add the +>> usb device but when I start the guest following message appears: +>> +>> "unable to execute QEMU command 'device_add': 'usb-host' is not a valid +>> device model name" +>> +>> Then the guest will not start. +>> +>> I try it with different usb devices (iphone, stick, hdd), always the +>> same error. +>> +>> Are there any news / hints about this ? +>> +>> Regards +>> +>> 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/1320360 +>> +>> Title: +>> usb passthrough not working anymore +>> +>> Status in QEMU: +>> New +>> +>> Bug description: +>> Hi, +>> +>> I'm using qemu 2.0.0 with opensuse 13.1 x84_64 bit as host and window7 +>> as guest. Til qemu version 1.6.2 USB passthrough works perfectly, but +>> starting with qemu 2.0.0 passthrough stop working. I can still add the +>> usb device but when I start the guest following message appears: +>> +>> "unable to execute QEMU command 'device_add': 'usb-host' is not a +>> valid device model name" +>> +>> Then the guest will not start. +>> +>> I try it with different usb devices (iphone, stick, hdd), always the +>> same error. +>> +>> Are there any news / hints about this ? +>> +>> Regards +>> +>> Martin +>> +>> To manage notifications about this bug go to: +>> https://bugs.launchpad.net/qemu/+bug/1320360/+subscriptions +> + + + +Hi, + +> -----Original Message----- +> From: Martin Röh [mailto:<email address hidden>] +> Sent: Monday, May 19, 2014 4:40 AM +> To: Gonglei (Arei); Bug 1320360; <email address hidden> +> Cc: Gerd Hoffmann +> Subject: Re: [Qemu-devel] [Bug 1320360] [NEW] usb passthrough not working +> anymore +> +> Hi, +> +> if I try to start the vm by virt-manager I get this detailed error log: +> +> Fehler beim Starten der Domain: internal error: early end of file from +> monitor: possible problem: +> qemu-system-x86_64: -device usb-host,hostbus=1,hostaddr=3,id=hostdev0: +> 'usb-host' is not a valid device model name +> +> +> Traceback (most recent call last): +> File "/usr/share/virt-manager/virtManager/asyncjob.py", line 91, in +> cb_wrapper +> callback(asyncjob, *args, **kwargs) +> File "/usr/share/virt-manager/virtManager/asyncjob.py", line 127, in +> tmpcb +> callback(*args, **kwargs) +> File "/usr/share/virt-manager/virtManager/domain.py", line 1363, in +> startup +> self._backend.create() +> File "/usr/lib64/python2.7/site-packages/libvirt.py", line 917, in create +> if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self) +> libvirtError: internal error: early end of file from monitor: possible +> problem: +> qemu-system-x86_64: -device usb-host,hostbus=1,hostaddr=3,id=hostdev0: +> 'usb-host' is not a valid device model name +> +The above error information shows "usb-host" didn't been built in qemu-system-x86_64 +binary file. You can get the qemu-2.0.0 source files from http://wiki.qemu.org/Download +and rebuild it with '--enable-libusb' during configure. + + +Best regards, +-Gonglei + + +On So, 2014-05-18 at 22:36 +0200, Martin Röh wrote: +> Hi, +> +> as far as I can see from the rpm specs of the opensuse rpm package the +> --enable-libusb is set . + +> > BTW, Gerd, should we enable libusb by default now? Thanks. + +By default libusb will be used when found on the system. +When it isn't there qemu will be built without usb-host support. + +If you explicitly ask for libusb support (via --enable-libusb) and +libusbx isn't found configure should fail. + +cheers, + Gerd + + + + +Martin, + +The OBS Virtualization/qemu project doesn't build QEMU v2.0 with libusb support for openSUSE 13.1, because the version provided in that distro was 1.0.9, and QEMU's configure requires 1.0.13. + +Bruce + +Hi, I've done the following on my OpenSUSE 13.1 install where I'm in sore need of USB passthrough with QEMU 2.0.0 +1) zypper source-install qemu to get the sources +2) update of libusb to 1.0.18 from the hardware:/debug/OpenSUSE_Factory repo - packages are libusb-1_0-0 and libusb-1_0-devel +3) removed the version check for --enable-libusb in qemu.spec to ensure that this flag is set when building +The output of rpmbuild -bb /usr/src/packages/SPECS/qemu.spec is +error: Failed build dependencies: + libusb-devel is needed by qemu-2.0.0-240.5.x86_64 + xen-devel is needed by qemu-2.0.0-240.5.x86_64 +Any input is greatly appreciated. + +xen-devel was not an issue (that package was installed so that dependency was resolved immediately) but libusb-devel is still reported as missing, even though I have a 1.0.18 version of a libusb-1_0-devel installed. I would think it's only the package name that is different. I'm not overly familiar with the build process, therefore I'm not certain if it would be sufficient to modify the qemu.spec build spec with the library name as it is installed on my system. Thanks. + +I went ahead and modified the qemu.spec to require libusb-1_0-devel instead of libusb-devel. That seems to work as according to the build output it includes /usr/include/libusb-1.0. I apologize for needing three comments to get to this point. This is all very much a learning experience for me. + +It looks like something may be broken when building seabios. + +ASL Input: /usr/src/packages/BUILD/qemu-2.0.0/roms/seabios/builds/seabios-128k/src/fw/acpi-dsdt.dsl.i - 475 lines, 19178 bytes, 316 keywords +AML Output: /usr/src/packages/BUILD/qemu-2.0.aml - 4407 bytes, 159 named objects, 157 executable opcodes +Listing File: /usr/src/packages/BUILD/qemu-2.0.lst - 174477 bytes +Hex Dump: /usr/src/packages/BUILD/qemu-2.0.hex - 41680 bytes + +Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 246 Optimizations +Traceback (most recent call last): + File "./scripts/acpi_extract.py", line 237, in <module> + for line in fileinput.input(): + File "/usr/lib64/python2.7/fileinput.py", line 252, in next + line = self.readline() + File "/usr/lib64/python2.7/fileinput.py", line 344, in readline + self._file = open(self._filename, self._mode) +IOError: [Errno 2] No such file or directory: '/usr/src/packages/BUILD/qemu-2.0.0/roms/seabios/builds/seabios-128k/src/fw/acpi-dsdt.lst' +make[1]: *** [/usr/src/packages/BUILD/qemu-2.0.0/roms/seabios/builds/seabios-128k/src/fw/acpi-dsdt.hex] Error 1 +make[1]: Leaving directory `/usr/src/packages/BUILD/qemu-2.0.0/roms/seabios' +make: *** [build-seabios-config-seabios-128k] Error 2 +make: Leaving directory `/usr/src/packages/BUILD/qemu-2.0.0/roms' +error: Bad exit status from /var/tmp/rpm-tmp.LbOtWA (%build) + +Now I'm well and truly stuck. Is there a way to leave seabios out of the equation or can this be resolved? + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +Hi, + +the ticket can be close. All works fine with actual opensuse tumbleweed +and qemu 2.10.0 :-) + +Best regards + +Martin + +Am 03.10.2017 um 12:42 schrieb Thomas Huth: +> Triaging old bug tickets... can you still reproduce this issue with the +> latest version of QEMU? Or could we close this ticket nowadays? +> +> ** Changed in: qemu +> Status: New => Incomplete +> + + +Thanks for checking again! + diff --git a/results/classifier/105/mistranslation/1322 b/results/classifier/105/mistranslation/1322 new file mode 100644 index 000000000..31543608c --- /dev/null +++ b/results/classifier/105/mistranslation/1322 @@ -0,0 +1,14 @@ +mistranslation: 0.918 +other: 0.834 +device: 0.473 +network: 0.227 +semantic: 0.139 +graphic: 0.136 +instruction: 0.080 +assembly: 0.044 +KVM: 0.010 +boot: 0.009 +socket: 0.003 +vnc: 0.001 + +Unknown protocol 'ssh' diff --git a/results/classifier/105/mistranslation/1324112 b/results/classifier/105/mistranslation/1324112 new file mode 100644 index 000000000..87862a1ab --- /dev/null +++ b/results/classifier/105/mistranslation/1324112 @@ -0,0 +1,1061 @@ +mistranslation: 0.780 +KVM: 0.749 +other: 0.741 +vnc: 0.707 +device: 0.578 +semantic: 0.570 +graphic: 0.561 +assembly: 0.553 +instruction: 0.540 +network: 0.531 +socket: 0.496 +boot: 0.489 + +qemu parallel building error on libcacard.la + +hi, + +im building qemu with a large make -j value(9). +sometimes the build fails because of an error: +libtool: link: ar cru .libs/libcacard.a stubs/arch-query-cpu-def.o stubs/clock-warp.o stubs/cpu-get-clock.o stubs/cpu-get-icount.o stubs/dump.o stubs/fdset-add-fd.o stubs/fdset-find-fd.o stubs/fdset-get-fd.o stubs/fdset-remove-fd.o stubs/gdbstub.o stubs/get-fd.o stubs/get-vm-name.o stubs/iothread-lock.o stubs/migr-blocker.o stubs/mon-is-qmp.o stubs/mon-printf.o stubs/mon-print-filename.o stubs/mon-protocol-event.o stubs/mon-set-error.o stubs/pci-drive-hot-add.o stubs/qtest.o stubs/reset.o stubs/runstate-check.o stubs/set-fd-handler.o stubs/slirp.o stubs/sysbus.o stubs/uuid.o stubs/vm-stop.o stubs/vmstate.o stubs/cpus.o stubs/kvm.o libcacard/cac.o libcacard/event.o libcacard/vcard.o libcacard/vreader.o libcacard/vcard_emul_nss.o libcacard/vcard_emul_type.o libcacard/card_7816.o libcacard/vcardt.o util/osdep.o util/cutils.o util/qemu-timer-common.o util/error.o util/qemu-error.o util/oslib-posix.o util/qemu-thread-posix.o trace/generated-events.o trace/default.o trace/control.o trace/generated-tracers.o +ar: trace/generated-events.o: No such file or directory +make[2]: *** [libcacard.la] Error 1 + + +i see the build of generated-events.o in the log before the ar command. +because of the -j it was probably not completed yet. +the generated-events.o build command: +/usr/bin/gcc -I/home/npsdb/qemu/qemu/tcg -I/home/npsdb/qemu/qemu/tcg/i386 -I/home/npsdb/qemu/qemu/linux-headers -I/home/npsdb/qemu/build/linux_x86_64/linux-headers -I. -I/home/npsdb/qemu/qemu -I/home/npsdb/jenkins/qemu/qemu/include -I/home/npsdb/qemu/qemu/libcacard -Itrace -Itrace -fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -I/usr/include/libpng12 -I/usr/include/nss3 -I/usr/include/nspr4 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/home/npsdb/qemu/qemu/tests -I qga/qapi-generated -MMD -MP -MT trace/generated-events.o -MF trace/generated-events.d -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -g -c -o trace/generated-events.o trace/generated-events.c + + +must be a race condition in the makefile because of a missing dependency. +i tried to find it but it was a little bit complicated to me. + +thanks, +tal + +On Wed, May 28, 2014 at 12:52:10PM -0000, tal zilcer wrote: +> im building qemu with a large make -j value(9). +> sometimes the build fails because of an error: +> libtool: link: ar cru .libs/libcacard.a stubs/arch-query-cpu-def.o stubs/clock-warp.o stubs/cpu-get-clock.o stubs/cpu-get-icount.o stubs/dump.o stubs/fdset-add-fd.o stubs/fdset-find-fd.o stubs/fdset-get-fd.o stubs/fdset-remove-fd.o stubs/gdbstub.o stubs/get-fd.o stubs/get-vm-name.o stubs/iothread-lock.o stubs/migr-blocker.o stubs/mon-is-qmp.o stubs/mon-printf.o stubs/mon-print-filename.o stubs/mon-protocol-event.o stubs/mon-set-error.o stubs/pci-drive-hot-add.o stubs/qtest.o stubs/reset.o stubs/runstate-check.o stubs/set-fd-handler.o stubs/slirp.o stubs/sysbus.o stubs/uuid.o stubs/vm-stop.o stubs/vmstate.o stubs/cpus.o stubs/kvm.o libcacard/cac.o libcacard/event.o libcacard/vcard.o libcacard/vreader.o libcacard/vcard_emul_nss.o libcacard/vcard_emul_type.o libcacard/card_7816.o libcacard/vcardt.o util/osdep.o util/cutils.o util/qemu-timer-common.o util/error.o util/qemu-error.o util/oslib-posix.o util/qemu-thread-posix.o trace/generated-events.o trace/default.o trace/control.o trace/generated-tracers.o +> ar: trace/generated-events.o: No such file or directory +> make[2]: *** [libcacard.la] Error 1 +> +> +> i see the build of generated-events.o in the log before the ar command. +> because of the -j it was probably not completed yet. +> the generated-events.o build command: +> /usr/bin/gcc -I/home/npsdb/qemu/qemu/tcg -I/home/npsdb/qemu/qemu/tcg/i386 -I/home/npsdb/qemu/qemu/linux-headers -I/home/npsdb/qemu/build/linux_x86_64/linux-headers -I. -I/home/npsdb/qemu/qemu -I/home/npsdb/jenkins/qemu/qemu/include -I/home/npsdb/qemu/qemu/libcacard -Itrace -Itrace -fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -I/usr/include/libpng12 -I/usr/include/nss3 -I/usr/include/nspr4 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/home/npsdb/qemu/qemu/tests -I qga/qapi-generated -MMD -MP -MT trace/generated-events.o -MF trace/generated-events.d -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -g -c -o trace/generated-events.o trace/generated-events.c +> +> +> must be a race condition in the makefile because of a missing dependency. +> i tried to find it but it was a little bit complicated to me. + +Which QEMU version are you building? + +In qemu.git/master I can see the dependency on trace/* in +libcacard/Makefile. + +Stefan + + +Version 2.0.0 + +Isn’t the libcacard Makefile run as a recursive make? +how do you keep the dependencies between two different makes(libcacard and trace)? + +-----Original Message----- +From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Stefan Hajnoczi +Sent: Wednesday, June 04, 2014 11:19 AM +To: Tal Zilcer +Subject: Re: [Qemu-devel] [Bug 1324112] [NEW] qemu parallel building error on libcacard.la + +On Wed, May 28, 2014 at 12:52:10PM -0000, tal zilcer wrote: +> im building qemu with a large make -j value(9). +> sometimes the build fails because of an error: +> libtool: link: ar cru .libs/libcacard.a stubs/arch-query-cpu-def.o stubs/clock-warp.o stubs/cpu-get-clock.o stubs/cpu-get-icount.o stubs/dump.o stubs/fdset-add-fd.o stubs/fdset-find-fd.o stubs/fdset-get-fd.o stubs/fdset-remove-fd.o stubs/gdbstub.o stubs/get-fd.o stubs/get-vm-name.o stubs/iothread-lock.o stubs/migr-blocker.o stubs/mon-is-qmp.o stubs/mon-printf.o stubs/mon-print-filename.o stubs/mon-protocol-event.o stubs/mon-set-error.o stubs/pci-drive-hot-add.o stubs/qtest.o stubs/reset.o stubs/runstate-check.o stubs/set-fd-handler.o stubs/slirp.o stubs/sysbus.o stubs/uuid.o stubs/vm-stop.o stubs/vmstate.o stubs/cpus.o stubs/kvm.o libcacard/cac.o libcacard/event.o libcacard/vcard.o libcacard/vreader.o libcacard/vcard_emul_nss.o libcacard/vcard_emul_type.o libcacard/card_7816.o libcacard/vcardt.o util/osdep.o util/cutils.o util/qemu-timer-common.o util/error.o util/qemu-error.o util/oslib-posix.o util/qemu-thread-posix.o trace/generated-events.o trace/default.o trace/control.o trace/generated-tracers.o +> ar: trace/generated-events.o: No such file or directory +> make[2]: *** [libcacard.la] Error 1 +> +> +> i see the build of generated-events.o in the log before the ar command. +> because of the -j it was probably not completed yet. +> the generated-events.o build command: +> /usr/bin/gcc -I/home/npsdb/qemu/qemu/tcg -I/home/npsdb/qemu/qemu/tcg/i386 -I/home/npsdb/qemu/qemu/linux-headers -I/home/npsdb/qemu/build/linux_x86_64/linux-headers -I. -I/home/npsdb/qemu/qemu -I/home/npsdb/jenkins/qemu/qemu/include -I/home/npsdb/qemu/qemu/libcacard -Itrace -Itrace -fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -I/usr/include/libpng12 -I/usr/include/nss3 -I/usr/include/nspr4 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/home/npsdb/qemu/qemu/tests -I qga/qapi-generated -MMD -MP -MT trace/generated-events.o -MF trace/generated-events.d -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -g -c -o trace/generated-events.o trace/generated-events.c +> +> +> must be a race condition in the makefile because of a missing dependency. +> i tried to find it but it was a little bit complicated to me. + +Which QEMU version are you building? + +In qemu.git/master I can see the dependency on trace/* in +libcacard/Makefile. + +Stefan + +-- +You received this bug notification because you are subscribed to the bug +report. +https://bugs.launchpad.net/bugs/1324112 + +Title: + qemu parallel building error on libcacard.la + +Status in QEMU: + New + +Bug description: + hi, + + im building qemu with a large make -j value(9). + sometimes the build fails because of an error: + libtool: link: ar cru .libs/libcacard.a stubs/arch-query-cpu-def.o stubs/clock-warp.o stubs/cpu-get-clock.o stubs/cpu-get-icount.o stubs/dump.o stubs/fdset-add-fd.o stubs/fdset-find-fd.o stubs/fdset-get-fd.o stubs/fdset-remove-fd.o stubs/gdbstub.o stubs/get-fd.o stubs/get-vm-name.o stubs/iothread-lock.o stubs/migr-blocker.o stubs/mon-is-qmp.o stubs/mon-printf.o stubs/mon-print-filename.o stubs/mon-protocol-event.o stubs/mon-set-error.o stubs/pci-drive-hot-add.o stubs/qtest.o stubs/reset.o stubs/runstate-check.o stubs/set-fd-handler.o stubs/slirp.o stubs/sysbus.o stubs/uuid.o stubs/vm-stop.o stubs/vmstate.o stubs/cpus.o stubs/kvm.o libcacard/cac.o libcacard/event.o libcacard/vcard.o libcacard/vreader.o libcacard/vcard_emul_nss.o libcacard/vcard_emul_type.o libcacard/card_7816.o libcacard/vcardt.o util/osdep.o util/cutils.o util/qemu-timer-common.o util/error.o util/qemu-error.o util/oslib-posix.o util/qemu-thread-posix.o trace/generated-events.o trace/default.o trace/control.o trace/generated-tracers.o + ar: trace/generated-events.o: No such file or directory + make[2]: *** [libcacard.la] Error 1 + + + i see the build of generated-events.o in the log before the ar command. + because of the -j it was probably not completed yet. + the generated-events.o build command: + /usr/bin/gcc -I/home/npsdb/qemu/qemu/tcg -I/home/npsdb/qemu/qemu/tcg/i386 -I/home/npsdb/qemu/qemu/linux-headers -I/home/npsdb/qemu/build/linux_x86_64/linux-headers -I. -I/home/npsdb/qemu/qemu -I/home/npsdb/jenkins/qemu/qemu/include -I/home/npsdb/qemu/qemu/libcacard -Itrace -Itrace -fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -I/usr/include/libpng12 -I/usr/include/nss3 -I/usr/include/nspr4 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/home/npsdb/qemu/qemu/tests -I qga/qapi-generated -MMD -MP -MT trace/generated-events.o -MF trace/generated-events.d -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -g -c -o trace/generated-events.o trace/generated-events.c + + + must be a race condition in the makefile because of a missing dependency. + i tried to find it but it was a little bit complicated to me. + + thanks, + tal + +To manage notifications about this bug go to: +https://bugs.launchpad.net/qemu/+bug/1324112/+subscriptions + + +On Wed, Jun 04, 2014 at 03:33:34AM -0000, tal zilcer wrote: +> Version 2.0.0 +> +> Isn’t the libcacard Makefile run as a recursive make? +> how do you keep the dependencies between two different makes(libcacard and trace)? + +In qemu.git/master:Makefile I see: +ifeq ($(CONFIG_SMARTCARD_NSS),y) +include $(SRC_PATH)/libcacard/Makefile +endif + +That doesn't look like recursive make to me, but maybe I'm missing +something. + +Stefan + + +I didn’t mention it but im building qemu out of the source tree(running the configure in a different directory). +I tried to find the missing dependency but no luck. +The build error keeps happening Here is the end of the log(please note that I don’t see here "CC trace/generated-events.o"):. +lt CC trace/generated-events.lo + GEN qemu-doc.html + GEN qemu.1 + GEN qemu-img.1 + CC qapi-types.o + CC qapi-visit.o + CC qga/commands.o + CPP optionrom/multiboot.asm + CPP optionrom/linuxboot.asm + CC qga/guest-agent-command-state.o + CC qga/main.o + CC qga/commands-posix.o + CPP optionrom/kvmvapic.asm + AS optionrom/multiboot.o + AS optionrom/linuxboot.o + CC qga/channel-posix.o + CC qga/qapi-generated/qga-qapi-types.o + AS optionrom/kvmvapic.o + Building optionrom/multiboot.img + Building optionrom/linuxboot.img + Building optionrom/multiboot.raw + Building optionrom/linuxboot.raw + Building optionrom/kvmvapic.img + CC qga/qapi-generated/qga-qapi-visit.o + Signing optionrom/multiboot.bin + Signing optionrom/linuxboot.bin + CC qga/qapi-generated/qga-qmp-marshal.o + CC qemu-img.o + CC qmp-marshal.o + LINK qemu-bridge-helper +install -c -m 0644 /home/talz/workspace/tools/qemu/qemu/sysconfigs/target/target-x86_64.conf "/home/talz/workspace/ /tools/qemu/install/linux_x86_64/etc/qemu" + Building optionrom/kvmvapic.raw + Signing optionrom/kvmvapic.bin + lt CC trace/generated-tracers.lo +lt LINK libcacard.la + AR libqemustub.a + CC trace/generated-tracers.o +ar: .libs/libcacard.a: Error reading trace/generated-events.o: No such file or directory +make[2]: *** [libcacard.la] Error 1 + +-----Original Message----- +From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Stefan Hajnoczi +Sent: Monday, June 09, 2014 4:38 PM +To: Tal Zilcer +Subject: Re: [Qemu-devel] [Bug 1324112] [NEW] qemu parallel building error on libcacard.la + +On Wed, Jun 04, 2014 at 03:33:34AM -0000, tal zilcer wrote: +> Version 2.0.0 +> +> Isn’t the libcacard Makefile run as a recursive make? +> how do you keep the dependencies between two different makes(libcacard and trace)? + +In qemu.git/master:Makefile I see: +ifeq ($(CONFIG_SMARTCARD_NSS),y) +include $(SRC_PATH)/libcacard/Makefile +endif + +That doesn't look like recursive make to me, but maybe I'm missing +something. + +Stefan + +-- +You received this bug notification because you are subscribed to the bug +report. +https://bugs.launchpad.net/bugs/1324112 + +Title: + qemu parallel building error on libcacard.la + +Status in QEMU: + New + +Bug description: + hi, + + im building qemu with a large make -j value(9). + sometimes the build fails because of an error: + libtool: link: ar cru .libs/libcacard.a stubs/arch-query-cpu-def.o stubs/clock-warp.o stubs/cpu-get-clock.o stubs/cpu-get-icount.o stubs/dump.o stubs/fdset-add-fd.o stubs/fdset-find-fd.o stubs/fdset-get-fd.o stubs/fdset-remove-fd.o stubs/gdbstub.o stubs/get-fd.o stubs/get-vm-name.o stubs/iothread-lock.o stubs/migr-blocker.o stubs/mon-is-qmp.o stubs/mon-printf.o stubs/mon-print-filename.o stubs/mon-protocol-event.o stubs/mon-set-error.o stubs/pci-drive-hot-add.o stubs/qtest.o stubs/reset.o stubs/runstate-check.o stubs/set-fd-handler.o stubs/slirp.o stubs/sysbus.o stubs/uuid.o stubs/vm-stop.o stubs/vmstate.o stubs/cpus.o stubs/kvm.o libcacard/cac.o libcacard/event.o libcacard/vcard.o libcacard/vreader.o libcacard/vcard_emul_nss.o libcacard/vcard_emul_type.o libcacard/card_7816.o libcacard/vcardt.o util/osdep.o util/cutils.o util/qemu-timer-common.o util/error.o util/qemu-error.o util/oslib-posix.o util/qemu-thread-posix.o trace/generated-events.o trace/default.o trace/control.o trace/generated-tracers.o + ar: trace/generated-events.o: No such file or directory + make[2]: *** [libcacard.la] Error 1 + + + i see the build of generated-events.o in the log before the ar command. + because of the -j it was probably not completed yet. + the generated-events.o build command: + /usr/bin/gcc -I/home/npsdb/qemu/qemu/tcg -I/home/npsdb/qemu/qemu/tcg/i386 -I/home/npsdb/qemu/qemu/linux-headers -I/home/npsdb/qemu/build/linux_x86_64/linux-headers -I. -I/home/npsdb/qemu/qemu -I/home/npsdb/jenkins/qemu/qemu/include -I/home/npsdb/qemu/qemu/libcacard -Itrace -Itrace -fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -I/usr/include/libpng12 -I/usr/include/nss3 -I/usr/include/nspr4 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/home/npsdb/qemu/qemu/tests -I qga/qapi-generated -MMD -MP -MT trace/generated-events.o -MF trace/generated-events.d -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -g -c -o trace/generated-events.o trace/generated-events.c + + + must be a race condition in the makefile because of a missing dependency. + i tried to find it but it was a little bit complicated to me. + + thanks, + tal + +To manage notifications about this bug go to: +https://bugs.launchpad.net/qemu/+bug/1324112/+subscriptions + + +I did some more experiments and maybe I found the issue. +I added a two prints to rules.mak: +%.o: %.c + $(call quiet-command,$(CC) $(QEMU_INCLUDES) $(QEMU_CFLAGS) $(QEMU_DGFLAGS) $(CFLAGS) $($@-cflags) -c -o $@ $<," CC $(TARGET_DIR)$@") + @echo ooooooooooooo:$@ + +%.lo: %.c + $(call quiet-command,$(LIBTOOL) --mode=compile --tag=CC $(CC) $(QEMU_INCLUDES) $(QEMU_CFLAGS) $(QEMU_DGFLAGS) $(CFLAGS) -c -o $@ $<," lt CC $@") + @echo lolololololo:$@ + +This two prints symbolize the end of the file build. +Here is the end of the log that I got for a failed build(using V=1): + + libtool: compile: /home/talz/workspace/mmmmm/EZdk-nps/tools/3rd-party-libs/ccache/ccache_output/bin/ccache /usr/bin/gcc -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/tcg -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/tcg/i386 -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/linux-headers -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/build/linux_x86_64/linux-headers -I. -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/include -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/libcacard -Itrace -Itrace -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -I/usr/include/libpng12 -I/usr/include/nss3 -I/usr/include/nspr4 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/tests -MMD -MP -MT trace/generated-tracers.lo -MF trace/generated-tracers.d -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -g -c trace/generated-tracers.c -fPIE -o trace/generated-tracers.o >/dev/null 2>&1 +lolololololo:trace/generated-tracers.lo +libtool --mode=link --tag=CC c++ -fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -I/usr/include/libpng12 -I/usr/include/nss3 -I/usr/include/nspr4 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/tests -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -g -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m64 -g -rpath /home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/install/linux_x86_64/lib -no-undefined -export-syms /home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/libcacard/libcacard.syms -o libcacard.la stubs/arch-query-cpu-def.lo stubs/clock-warp.lo stubs/cpu-get-clock.lo stubs/cpu-get-icount.lo stubs/dump.lo stubs/fdset-add-fd.lo stubs/fdset-find-fd.lo stubs/fdset-get-fd.lo stubs/fdset-remove-fd.lo stubs/gdbstub.lo stubs/get-fd.lo stubs/get-vm-name.lo stubs/iothread-lock.lo stubs/migr-blocker.lo stubs/mon-is-qmp.lo stubs/mon-printf.lo stubs/mon-print-filename.lo stubs/mon-protocol-event.lo stubs/mon-set-error.lo stubs/pci-drive-hot-add.lo stubs/qtest.lo stubs/reset.lo stubs/runstate-check.lo stubs/set-fd-handler.lo stubs/slirp.lo stubs/sysbus.lo stubs/uuid.lo stubs/vm-stop.lo stubs/vmstate.lo stubs/cpus.lo stubs/kvm.lo libcacard/cac.lo libcacard/event.lo libcacard/vcard.lo libcacard/vreader.lo libcacard/vcard_emul_nss.lo libcacard/vcard_emul_type.lo libcacard/card_7816.lo libcacard/vcardt.lo util/osdep.lo util/cutils.lo util/qemu-timer-common.lo util/error.lo util/qemu-error.lo util/oslib-posix.lo util/qemu-thread-posix.lo trace/generated-events.lo trace/default.lo trace/control.lo trace/generated-tracers.lo -Wc,-fstack-protector-all -lssl3 -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -lpthread -ldl -pthread -lgthread-2.0 -lrt -lglib-2.0 +/home/talz/workspace/mmmmm/EZdk-nps/tools/3rd-party-libs/ccache/ccache_output/bin/ccache /usr/bin/gcc -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/tcg -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/tcg/i386 -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/linux-headers -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/build/linux_x86_64/linux-headers -I. -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/include -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/libcacard -Itrace -Itrace -fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -I/usr/include/libpng12 -I/usr/include/nss3 -I/usr/include/nspr4 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/tests -I qga/qapi-generated -MMD -MP -MT trace/generated-events.o -MF trace/generated-events.d -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -g -c -o trace/generated-events.o trace/generated-events.c +/home/talz/workspace/mmmmm/EZdk-nps/tools/3rd-party-libs/ccache/ccache_output/bin/ccache /usr/bin/gcc -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/tcg -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/tcg/i386 -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/linux-headers -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/build/linux_x86_64/linux-headers -I. -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/include -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/libcacard -Itrace -Itrace -fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -I/usr/include/libpng12 -I/usr/include/nss3 -I/usr/include/nspr4 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/tests -I qga/qapi-generated -MMD -MP -MT trace/generated-tracers.o -MF trace/generated-tracers.d -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -g -c -o trace/generated-tracers.o trace/generated-tracers.c +rm -f libqemustub.a && ar rcs libqemustub.a stubs/arch-query-cpu-def.o stubs/clock-warp.o stubs/cpu-get-clock.o stubs/cpu-get-icount.o stubs/dump.o stubs/fdset-add-fd.o stubs/fdset-find-fd.o stubs/fdset-get-fd.o stubs/fdset-remove-fd.o stubs/gdbstub.o stubs/get-fd.o stubs/get-vm-name.o stubs/iothread-lock.o stubs/migr-blocker.o stubs/mon-is-qmp.o stubs/mon-printf.o stubs/mon-print-filename.o stubs/mon-protocol-event.o stubs/mon-set-error.o stubs/pci-drive-hot-add.o stubs/qtest.o stubs/reset.o stubs/runstate-check.o stubs/set-fd-handler.o stubs/slirp.o stubs/sysbus.o stubs/uuid.o stubs/vm-stop.o stubs/vmstate.o stubs/cpus.o stubs/kvm.o +libtool: link: gcc -shared stubs/.libs/arch-query-cpu-def.o stubs/.libs/clock-warp.o stubs/.libs/cpu-get-clock.o stubs/.libs/cpu-get-icount.o stubs/.libs/dump.o stubs/.libs/fdset-add-fd.o stubs/.libs/fdset-find-fd.o stubs/.libs/fdset-get-fd.o stubs/.libs/fdset-remove-fd.o stubs/.libs/gdbstub.o stubs/.libs/get-fd.o stubs/.libs/get-vm-name.o stubs/.libs/iothread-lock.o stubs/.libs/migr-blocker.o stubs/.libs/mon-is-qmp.o stubs/.libs/mon-printf.o stubs/.libs/mon-print-filename.o stubs/.libs/mon-protocol-event.o stubs/.libs/mon-set-error.o stubs/.libs/pci-drive-hot-add.o stubs/.libs/qtest.o stubs/.libs/reset.o stubs/.libs/runstate-check.o stubs/.libs/set-fd-handler.o stubs/.libs/slirp.o stubs/.libs/sysbus.o stubs/.libs/uuid.o stubs/.libs/vm-stop.o stubs/.libs/vmstate.o stubs/.libs/cpus.o stubs/.libs/kvm.o libcacard/.libs/cac.o libcacard/.libs/event.o libcacard/.libs/vcard.o libcacard/.libs/vreader.o libcacard/.libs/vcard_emul_nss.o libcacard/.libs/vcard_emul_type.o libcacard/.libs/card_7816.o libcacard/.libs/vcardt.o util/.libs/osdep.o util/.libs/cutils.o util/.libs/qemu-timer-common.o util/.libs/error.o util/.libs/qemu-error.o util/.libs/oslib-posix.o util/.libs/qemu-thread-posix.o trace/.libs/generated-events.o trace/.libs/default.o trace/.libs/control.o trace/.libs/generated-tracers.o -lssl3 -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -lpthread -ldl -lgthread-2.0 -lrt -lglib-2.0 -m64 -pthread -pthread -Wl,--warn-common -Wl,-z -Wl,relro -Wl,-z -Wl,now -m64 -fstack-protector-all -pthread -pthread -Wl,-soname -Wl,libcacard.so.0 -o .libs/libcacard.so.0.0.0 +libtool: link: (cd ".libs" && rm -f "libcacard.so.0" && ln -s "libcacard.so.0.0.0" "libcacard.so.0") +libtool: link: (cd ".libs" && rm -f "libcacard.so" && ln -s "libcacard.so.0.0.0" "libcacard.so") +libtool: link: ar cru .libs/libcacard.a stubs/arch-query-cpu-def.o stubs/clock-warp.o stubs/cpu-get-clock.o stubs/cpu-get-icount.o stubs/dump.o stubs/fdset-add-fd.o stubs/fdset-find-fd.o stubs/fdset-get-fd.o stubs/fdset-remove-fd.o stubs/gdbstub.o stubs/get-fd.o stubs/get-vm-name.o stubs/iothread-lock.o stubs/migr-blocker.o stubs/mon-is-qmp.o stubs/mon-printf.o stubs/mon-print-filename.o stubs/mon-protocol-event.o stubs/mon-set-error.o stubs/pci-drive-hot-add.o stubs/qtest.o stubs/reset.o stubs/runstate-check.o stubs/set-fd-handler.o stubs/slirp.o stubs/sysbus.o stubs/uuid.o stubs/vm-stop.o stubs/vmstate.o stubs/cpus.o stubs/kvm.o libcacard/cac.o libcacard/event.o libcacard/vcard.o libcacard/vreader.o libcacard/vcard_emul_nss.o libcacard/vcard_emul_type.o libcacard/card_7816.o libcacard/vcardt.o util/osdep.o util/cutils.o util/qemu-timer-common.o util/error.o util/qemu-error.o util/oslib-posix.o util/qemu-thread-posix.o trace/generated-events.o trace/default.o trace/control.o trace/generated-tracers.o +ar: trace/generated-tracers.o: No such file or directory +make[2]: *** [libcacard.la] Error 1 +make[2]: *** Waiting for unfinished jobs.... +ooooooooooooo:trace/generated-tracers.o +ooooooooooooo:trace/generated-events.o + + +as you can see trace/generated-tracers.o target is being built after trace/generated-tracers.la target. +Trace/generated-tracers.la is finished and after it trace/generated-tracers.o is being built. +Libcacard.la has a dependency only to .la files and not .o files. + +-----Original Message----- +From: Tal Zilcer +Sent: Tuesday, June 10, 2014 12:42 PM +To: 'Bug 1324112' +Subject: RE: [Qemu-devel] [Bug 1324112] [NEW] qemu parallel building error on libcacard.la + +I didn’t mention it but im building qemu out of the source tree(running the configure in a different directory). +I tried to find the missing dependency but no luck. +The build error keeps happening Here is the end of the log(please note that I don’t see here "CC trace/generated-events.o"):. +lt CC trace/generated-events.lo + GEN qemu-doc.html + GEN qemu.1 + GEN qemu-img.1 + CC qapi-types.o + CC qapi-visit.o + CC qga/commands.o + CPP optionrom/multiboot.asm + CPP optionrom/linuxboot.asm + CC qga/guest-agent-command-state.o + CC qga/main.o + CC qga/commands-posix.o + CPP optionrom/kvmvapic.asm + AS optionrom/multiboot.o + AS optionrom/linuxboot.o + CC qga/channel-posix.o + CC qga/qapi-generated/qga-qapi-types.o + AS optionrom/kvmvapic.o + Building optionrom/multiboot.img + Building optionrom/linuxboot.img + Building optionrom/multiboot.raw + Building optionrom/linuxboot.raw + Building optionrom/kvmvapic.img + CC qga/qapi-generated/qga-qapi-visit.o + Signing optionrom/multiboot.bin + Signing optionrom/linuxboot.bin + CC qga/qapi-generated/qga-qmp-marshal.o + CC qemu-img.o + CC qmp-marshal.o + LINK qemu-bridge-helper +install -c -m 0644 /home/talz/workspace/tools/qemu/qemu/sysconfigs/target/target-x86_64.conf "/home/talz/workspace/ /tools/qemu/install/linux_x86_64/etc/qemu" + Building optionrom/kvmvapic.raw + Signing optionrom/kvmvapic.bin + lt CC trace/generated-tracers.lo +lt LINK libcacard.la + AR libqemustub.a + CC trace/generated-tracers.o +ar: .libs/libcacard.a: Error reading trace/generated-events.o: No such file or directory +make[2]: *** [libcacard.la] Error 1 + +-----Original Message----- +From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Stefan Hajnoczi +Sent: Monday, June 09, 2014 4:38 PM +To: Tal Zilcer +Subject: Re: [Qemu-devel] [Bug 1324112] [NEW] qemu parallel building error on libcacard.la + +On Wed, Jun 04, 2014 at 03:33:34AM -0000, tal zilcer wrote: +> Version 2.0.0 +> +> Isn’t the libcacard Makefile run as a recursive make? +> how do you keep the dependencies between two different makes(libcacard and trace)? + +In qemu.git/master:Makefile I see: +ifeq ($(CONFIG_SMARTCARD_NSS),y) +include $(SRC_PATH)/libcacard/Makefile +endif + +That doesn't look like recursive make to me, but maybe I'm missing +something. + +Stefan + +-- +You received this bug notification because you are subscribed to the bug +report. +https://bugs.launchpad.net/bugs/1324112 + +Title: + qemu parallel building error on libcacard.la + +Status in QEMU: + New + +Bug description: + hi, + + im building qemu with a large make -j value(9). + sometimes the build fails because of an error: + libtool: link: ar cru .libs/libcacard.a stubs/arch-query-cpu-def.o stubs/clock-warp.o stubs/cpu-get-clock.o stubs/cpu-get-icount.o stubs/dump.o stubs/fdset-add-fd.o stubs/fdset-find-fd.o stubs/fdset-get-fd.o stubs/fdset-remove-fd.o stubs/gdbstub.o stubs/get-fd.o stubs/get-vm-name.o stubs/iothread-lock.o stubs/migr-blocker.o stubs/mon-is-qmp.o stubs/mon-printf.o stubs/mon-print-filename.o stubs/mon-protocol-event.o stubs/mon-set-error.o stubs/pci-drive-hot-add.o stubs/qtest.o stubs/reset.o stubs/runstate-check.o stubs/set-fd-handler.o stubs/slirp.o stubs/sysbus.o stubs/uuid.o stubs/vm-stop.o stubs/vmstate.o stubs/cpus.o stubs/kvm.o libcacard/cac.o libcacard/event.o libcacard/vcard.o libcacard/vreader.o libcacard/vcard_emul_nss.o libcacard/vcard_emul_type.o libcacard/card_7816.o libcacard/vcardt.o util/osdep.o util/cutils.o util/qemu-timer-common.o util/error.o util/qemu-error.o util/oslib-posix.o util/qemu-thread-posix.o trace/generated-events.o trace/default.o trace/control.o trace/generated-tracers.o + ar: trace/generated-events.o: No such file or directory + make[2]: *** [libcacard.la] Error 1 + + + i see the build of generated-events.o in the log before the ar command. + because of the -j it was probably not completed yet. + the generated-events.o build command: + /usr/bin/gcc -I/home/npsdb/qemu/qemu/tcg -I/home/npsdb/qemu/qemu/tcg/i386 -I/home/npsdb/qemu/qemu/linux-headers -I/home/npsdb/qemu/build/linux_x86_64/linux-headers -I. -I/home/npsdb/qemu/qemu -I/home/npsdb/jenkins/qemu/qemu/include -I/home/npsdb/qemu/qemu/libcacard -Itrace -Itrace -fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -I/usr/include/libpng12 -I/usr/include/nss3 -I/usr/include/nspr4 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/home/npsdb/qemu/qemu/tests -I qga/qapi-generated -MMD -MP -MT trace/generated-events.o -MF trace/generated-events.d -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -g -c -o trace/generated-events.o trace/generated-events.c + + + must be a race condition in the makefile because of a missing dependency. + i tried to find it but it was a little bit complicated to me. + + thanks, + tal + +To manage notifications about this bug go to: +https://bugs.launchpad.net/qemu/+bug/1324112/+subscriptions + + +To summarize what I think is the problem: +Libcacard.la depends on trace/generated*.la files(ibcacard.la: $(libcacard-lobj-y)) +Trace/generated*.o files depends on trace/generated*.la files($(libcacard-obj-y): | $(libcacard-lobj-y)) +Also util depends on generated-*.o files (util-obj-y += generated-events.o) +This means when libcacard.la is being build generated-*.o files can be build by the util target. +I think you should change libcacard.la dependencies to include the o files and not only the la files. + +Thanks, +tal + +-----Original Message----- +From: Tal Zilcer +Sent: Tuesday, June 10, 2014 3:46 PM +To: 'Bug 1324112' +Subject: RE: [Qemu-devel] [Bug 1324112] [NEW] qemu parallel building error on libcacard.la + +I did some more experiments and maybe I found the issue. +I added a two prints to rules.mak: +%.o: %.c + $(call quiet-command,$(CC) $(QEMU_INCLUDES) $(QEMU_CFLAGS) $(QEMU_DGFLAGS) $(CFLAGS) $($@-cflags) -c -o $@ $<," CC $(TARGET_DIR)$@") + @echo ooooooooooooo:$@ + +%.lo: %.c + $(call quiet-command,$(LIBTOOL) --mode=compile --tag=CC $(CC) $(QEMU_INCLUDES) $(QEMU_CFLAGS) $(QEMU_DGFLAGS) $(CFLAGS) -c -o $@ $<," lt CC $@") + @echo lolololololo:$@ + +This two prints symbolize the end of the file build. +Here is the end of the log that I got for a failed build(using V=1): + + libtool: compile: /home/talz/workspace/mmmmm/EZdk-nps/tools/3rd-party-libs/ccache/ccache_output/bin/ccache /usr/bin/gcc -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/tcg -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/tcg/i386 -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/linux-headers -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/build/linux_x86_64/linux-headers -I. -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/include -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/libcacard -Itrace -Itrace -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -I/usr/include/libpng12 -I/usr/include/nss3 -I/usr/include/nspr4 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/tests -MMD -MP -MT trace/generated-tracers.lo -MF trace/generated-tracers.d -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -g -c trace/generated-tracers.c -fPIE -o trace/generated-tracers.o >/dev/null 2>&1 +lolololololo:trace/generated-tracers.lo +libtool --mode=link --tag=CC c++ -fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -I/usr/include/libpng12 -I/usr/include/nss3 -I/usr/include/nspr4 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/tests -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -g -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m64 -g -rpath /home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/install/linux_x86_64/lib -no-undefined -export-syms /home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/libcacard/libcacard.syms -o libcacard.la stubs/arch-query-cpu-def.lo stubs/clock-warp.lo stubs/cpu-get-clock.lo stubs/cpu-get-icount.lo stubs/dump.lo stubs/fdset-add-fd.lo stubs/fdset-find-fd.lo stubs/fdset-get-fd.lo stubs/fdset-remove-fd.lo stubs/gdbstub.lo stubs/get-fd.lo stubs/get-vm-name.lo stubs/iothread-lock.lo stubs/migr-blocker.lo stubs/mon-is-qmp.lo stubs/mon-printf.lo stubs/mon-print-filename.lo stubs/mon-protocol-event.lo stubs/mon-set-error.lo stubs/pci-drive-hot-add.lo stubs/qtest.lo stubs/reset.lo stubs/runstate-check.lo stubs/set-fd-handler.lo stubs/slirp.lo stubs/sysbus.lo stubs/uuid.lo stubs/vm-stop.lo stubs/vmstate.lo stubs/cpus.lo stubs/kvm.lo libcacard/cac.lo libcacard/event.lo libcacard/vcard.lo libcacard/vreader.lo libcacard/vcard_emul_nss.lo libcacard/vcard_emul_type.lo libcacard/card_7816.lo libcacard/vcardt.lo util/osdep.lo util/cutils.lo util/qemu-timer-common.lo util/error.lo util/qemu-error.lo util/oslib-posix.lo util/qemu-thread-posix.lo trace/generated-events.lo trace/default.lo trace/control.lo trace/generated-tracers.lo -Wc,-fstack-protector-all -lssl3 -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -lpthread -ldl -pthread -lgthread-2.0 -lrt -lglib-2.0 +/home/talz/workspace/mmmmm/EZdk-nps/tools/3rd-party-libs/ccache/ccache_output/bin/ccache /usr/bin/gcc -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/tcg -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/tcg/i386 -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/linux-headers -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/build/linux_x86_64/linux-headers -I. -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/include -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/libcacard -Itrace -Itrace -fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -I/usr/include/libpng12 -I/usr/include/nss3 -I/usr/include/nspr4 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/tests -I qga/qapi-generated -MMD -MP -MT trace/generated-events.o -MF trace/generated-events.d -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -g -c -o trace/generated-events.o trace/generated-events.c +/home/talz/workspace/mmmmm/EZdk-nps/tools/3rd-party-libs/ccache/ccache_output/bin/ccache /usr/bin/gcc -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/tcg -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/tcg/i386 -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/linux-headers -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/build/linux_x86_64/linux-headers -I. -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/include -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/libcacard -Itrace -Itrace -fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -I/usr/include/libpng12 -I/usr/include/nss3 -I/usr/include/nspr4 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/tests -I qga/qapi-generated -MMD -MP -MT trace/generated-tracers.o -MF trace/generated-tracers.d -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -g -c -o trace/generated-tracers.o trace/generated-tracers.c +rm -f libqemustub.a && ar rcs libqemustub.a stubs/arch-query-cpu-def.o stubs/clock-warp.o stubs/cpu-get-clock.o stubs/cpu-get-icount.o stubs/dump.o stubs/fdset-add-fd.o stubs/fdset-find-fd.o stubs/fdset-get-fd.o stubs/fdset-remove-fd.o stubs/gdbstub.o stubs/get-fd.o stubs/get-vm-name.o stubs/iothread-lock.o stubs/migr-blocker.o stubs/mon-is-qmp.o stubs/mon-printf.o stubs/mon-print-filename.o stubs/mon-protocol-event.o stubs/mon-set-error.o stubs/pci-drive-hot-add.o stubs/qtest.o stubs/reset.o stubs/runstate-check.o stubs/set-fd-handler.o stubs/slirp.o stubs/sysbus.o stubs/uuid.o stubs/vm-stop.o stubs/vmstate.o stubs/cpus.o stubs/kvm.o +libtool: link: gcc -shared stubs/.libs/arch-query-cpu-def.o stubs/.libs/clock-warp.o stubs/.libs/cpu-get-clock.o stubs/.libs/cpu-get-icount.o stubs/.libs/dump.o stubs/.libs/fdset-add-fd.o stubs/.libs/fdset-find-fd.o stubs/.libs/fdset-get-fd.o stubs/.libs/fdset-remove-fd.o stubs/.libs/gdbstub.o stubs/.libs/get-fd.o stubs/.libs/get-vm-name.o stubs/.libs/iothread-lock.o stubs/.libs/migr-blocker.o stubs/.libs/mon-is-qmp.o stubs/.libs/mon-printf.o stubs/.libs/mon-print-filename.o stubs/.libs/mon-protocol-event.o stubs/.libs/mon-set-error.o stubs/.libs/pci-drive-hot-add.o stubs/.libs/qtest.o stubs/.libs/reset.o stubs/.libs/runstate-check.o stubs/.libs/set-fd-handler.o stubs/.libs/slirp.o stubs/.libs/sysbus.o stubs/.libs/uuid.o stubs/.libs/vm-stop.o stubs/.libs/vmstate.o stubs/.libs/cpus.o stubs/.libs/kvm.o libcacard/.libs/cac.o libcacard/.libs/event.o libcacard/.libs/vcard.o libcacard/.libs/vreader.o libcacard/.libs/vcard_emul_nss.o libcacard/.libs/vcard_emul_type.o libcacard/.libs/card_7816.o libcacard/.libs/vcardt.o util/.libs/osdep.o util/.libs/cutils.o util/.libs/qemu-timer-common.o util/.libs/error.o util/.libs/qemu-error.o util/.libs/oslib-posix.o util/.libs/qemu-thread-posix.o trace/.libs/generated-events.o trace/.libs/default.o trace/.libs/control.o trace/.libs/generated-tracers.o -lssl3 -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -lpthread -ldl -lgthread-2.0 -lrt -lglib-2.0 -m64 -pthread -pthread -Wl,--warn-common -Wl,-z -Wl,relro -Wl,-z -Wl,now -m64 -fstack-protector-all -pthread -pthread -Wl,-soname -Wl,libcacard.so.0 -o .libs/libcacard.so.0.0.0 +libtool: link: (cd ".libs" && rm -f "libcacard.so.0" && ln -s "libcacard.so.0.0.0" "libcacard.so.0") +libtool: link: (cd ".libs" && rm -f "libcacard.so" && ln -s "libcacard.so.0.0.0" "libcacard.so") +libtool: link: ar cru .libs/libcacard.a stubs/arch-query-cpu-def.o stubs/clock-warp.o stubs/cpu-get-clock.o stubs/cpu-get-icount.o stubs/dump.o stubs/fdset-add-fd.o stubs/fdset-find-fd.o stubs/fdset-get-fd.o stubs/fdset-remove-fd.o stubs/gdbstub.o stubs/get-fd.o stubs/get-vm-name.o stubs/iothread-lock.o stubs/migr-blocker.o stubs/mon-is-qmp.o stubs/mon-printf.o stubs/mon-print-filename.o stubs/mon-protocol-event.o stubs/mon-set-error.o stubs/pci-drive-hot-add.o stubs/qtest.o stubs/reset.o stubs/runstate-check.o stubs/set-fd-handler.o stubs/slirp.o stubs/sysbus.o stubs/uuid.o stubs/vm-stop.o stubs/vmstate.o stubs/cpus.o stubs/kvm.o libcacard/cac.o libcacard/event.o libcacard/vcard.o libcacard/vreader.o libcacard/vcard_emul_nss.o libcacard/vcard_emul_type.o libcacard/card_7816.o libcacard/vcardt.o util/osdep.o util/cutils.o util/qemu-timer-common.o util/error.o util/qemu-error.o util/oslib-posix.o util/qemu-thread-posix.o trace/generated-events.o trace/default.o trace/control.o trace/generated-tracers.o +ar: trace/generated-tracers.o: No such file or directory +make[2]: *** [libcacard.la] Error 1 +make[2]: *** Waiting for unfinished jobs.... +ooooooooooooo:trace/generated-tracers.o +ooooooooooooo:trace/generated-events.o + + +as you can see trace/generated-tracers.o target is being built after trace/generated-tracers.la target. +Trace/generated-tracers.la is finished and after it trace/generated-tracers.o is being built. +Libcacard.la has a dependency only to .la files and not .o files. + +-----Original Message----- +From: Tal Zilcer +Sent: Tuesday, June 10, 2014 12:42 PM +To: 'Bug 1324112' +Subject: RE: [Qemu-devel] [Bug 1324112] [NEW] qemu parallel building error on libcacard.la + +I didn’t mention it but im building qemu out of the source tree(running the configure in a different directory). +I tried to find the missing dependency but no luck. +The build error keeps happening Here is the end of the log(please note that I don’t see here "CC trace/generated-events.o"):. +lt CC trace/generated-events.lo + GEN qemu-doc.html + GEN qemu.1 + GEN qemu-img.1 + CC qapi-types.o + CC qapi-visit.o + CC qga/commands.o + CPP optionrom/multiboot.asm + CPP optionrom/linuxboot.asm + CC qga/guest-agent-command-state.o + CC qga/main.o + CC qga/commands-posix.o + CPP optionrom/kvmvapic.asm + AS optionrom/multiboot.o + AS optionrom/linuxboot.o + CC qga/channel-posix.o + CC qga/qapi-generated/qga-qapi-types.o + AS optionrom/kvmvapic.o + Building optionrom/multiboot.img + Building optionrom/linuxboot.img + Building optionrom/multiboot.raw + Building optionrom/linuxboot.raw + Building optionrom/kvmvapic.img + CC qga/qapi-generated/qga-qapi-visit.o + Signing optionrom/multiboot.bin + Signing optionrom/linuxboot.bin + CC qga/qapi-generated/qga-qmp-marshal.o + CC qemu-img.o + CC qmp-marshal.o + LINK qemu-bridge-helper +install -c -m 0644 /home/talz/workspace/tools/qemu/qemu/sysconfigs/target/target-x86_64.conf "/home/talz/workspace/ /tools/qemu/install/linux_x86_64/etc/qemu" + Building optionrom/kvmvapic.raw + Signing optionrom/kvmvapic.bin + lt CC trace/generated-tracers.lo +lt LINK libcacard.la + AR libqemustub.a + CC trace/generated-tracers.o +ar: .libs/libcacard.a: Error reading trace/generated-events.o: No such file or directory +make[2]: *** [libcacard.la] Error 1 + +-----Original Message----- +From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Stefan Hajnoczi +Sent: Monday, June 09, 2014 4:38 PM +To: Tal Zilcer +Subject: Re: [Qemu-devel] [Bug 1324112] [NEW] qemu parallel building error on libcacard.la + +On Wed, Jun 04, 2014 at 03:33:34AM -0000, tal zilcer wrote: +> Version 2.0.0 +> +> Isn’t the libcacard Makefile run as a recursive make? +> how do you keep the dependencies between two different makes(libcacard and trace)? + +In qemu.git/master:Makefile I see: +ifeq ($(CONFIG_SMARTCARD_NSS),y) +include $(SRC_PATH)/libcacard/Makefile +endif + +That doesn't look like recursive make to me, but maybe I'm missing +something. + +Stefan + +-- +You received this bug notification because you are subscribed to the bug +report. +https://bugs.launchpad.net/bugs/1324112 + +Title: + qemu parallel building error on libcacard.la + +Status in QEMU: + New + +Bug description: + hi, + + im building qemu with a large make -j value(9). + sometimes the build fails because of an error: + libtool: link: ar cru .libs/libcacard.a stubs/arch-query-cpu-def.o stubs/clock-warp.o stubs/cpu-get-clock.o stubs/cpu-get-icount.o stubs/dump.o stubs/fdset-add-fd.o stubs/fdset-find-fd.o stubs/fdset-get-fd.o stubs/fdset-remove-fd.o stubs/gdbstub.o stubs/get-fd.o stubs/get-vm-name.o stubs/iothread-lock.o stubs/migr-blocker.o stubs/mon-is-qmp.o stubs/mon-printf.o stubs/mon-print-filename.o stubs/mon-protocol-event.o stubs/mon-set-error.o stubs/pci-drive-hot-add.o stubs/qtest.o stubs/reset.o stubs/runstate-check.o stubs/set-fd-handler.o stubs/slirp.o stubs/sysbus.o stubs/uuid.o stubs/vm-stop.o stubs/vmstate.o stubs/cpus.o stubs/kvm.o libcacard/cac.o libcacard/event.o libcacard/vcard.o libcacard/vreader.o libcacard/vcard_emul_nss.o libcacard/vcard_emul_type.o libcacard/card_7816.o libcacard/vcardt.o util/osdep.o util/cutils.o util/qemu-timer-common.o util/error.o util/qemu-error.o util/oslib-posix.o util/qemu-thread-posix.o trace/generated-events.o trace/default.o trace/control.o trace/generated-tracers.o + ar: trace/generated-events.o: No such file or directory + make[2]: *** [libcacard.la] Error 1 + + + i see the build of generated-events.o in the log before the ar command. + because of the -j it was probably not completed yet. + the generated-events.o build command: + /usr/bin/gcc -I/home/npsdb/qemu/qemu/tcg -I/home/npsdb/qemu/qemu/tcg/i386 -I/home/npsdb/qemu/qemu/linux-headers -I/home/npsdb/qemu/build/linux_x86_64/linux-headers -I. -I/home/npsdb/qemu/qemu -I/home/npsdb/jenkins/qemu/qemu/include -I/home/npsdb/qemu/qemu/libcacard -Itrace -Itrace -fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -I/usr/include/libpng12 -I/usr/include/nss3 -I/usr/include/nspr4 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/home/npsdb/qemu/qemu/tests -I qga/qapi-generated -MMD -MP -MT trace/generated-events.o -MF trace/generated-events.d -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -g -c -o trace/generated-events.o trace/generated-events.c + + + must be a race condition in the makefile because of a missing dependency. + i tried to find it but it was a little bit complicated to me. + + thanks, + tal + +To manage notifications about this bug go to: +https://bugs.launchpad.net/qemu/+bug/1324112/+subscriptions + + +The following patch solved the issue for me: +--- a/qemu/libcacard/Makefile ++++ b/qemu/libcacard/Makefile +@@ -26,8 +26,8 @@ vscclient$(EXESUF): libcacard/vscclient.o libcacard.la + libcacard.la: LDFLAGS += -rpath $(libdir) -no-undefined \ + -export-syms $(SRC_PATH)/libcacard/libcacard.syms + libcacard.la: LIBS = $(libcacard_libs) +-libcacard.la: $(libcacard-lobj-y) +- $(call LINK,$^) ++libcacard.la: $(libcacard-obj-y) ++ $(call LINK,$(libcacard-lobj-y)) + + libcacard.pc: $(SRC_PATH)/libcacard/libcacard.pc.in + $(call quiet-command,sed -e 's|@LIBDIR@|$(libdir)|' \ + +-----Original Message----- +From: Tal Zilcer +Sent: Tuesday, June 10, 2014 6:09 PM +To: 'Bug 1324112' +Subject: RE: [Qemu-devel] [Bug 1324112] [NEW] qemu parallel building error on libcacard.la + +To summarize what I think is the problem: +Libcacard.la depends on trace/generated*.la files(ibcacard.la: $(libcacard-lobj-y)) +Trace/generated*.o files depends on trace/generated*.la files($(libcacard-obj-y): | $(libcacard-lobj-y)) +Also util depends on generated-*.o files (util-obj-y += generated-events.o) +This means when libcacard.la is being build generated-*.o files can be build by the util target. +I think you should change libcacard.la dependencies to include the o files and not only the la files. + +Thanks, +tal + +-----Original Message----- +From: Tal Zilcer +Sent: Tuesday, June 10, 2014 3:46 PM +To: 'Bug 1324112' +Subject: RE: [Qemu-devel] [Bug 1324112] [NEW] qemu parallel building error on libcacard.la + +I did some more experiments and maybe I found the issue. +I added a two prints to rules.mak: +%.o: %.c + $(call quiet-command,$(CC) $(QEMU_INCLUDES) $(QEMU_CFLAGS) $(QEMU_DGFLAGS) $(CFLAGS) $($@-cflags) -c -o $@ $<," CC $(TARGET_DIR)$@") + @echo ooooooooooooo:$@ + +%.lo: %.c + $(call quiet-command,$(LIBTOOL) --mode=compile --tag=CC $(CC) $(QEMU_INCLUDES) $(QEMU_CFLAGS) $(QEMU_DGFLAGS) $(CFLAGS) -c -o $@ $<," lt CC $@") + @echo lolololololo:$@ + +This two prints symbolize the end of the file build. +Here is the end of the log that I got for a failed build(using V=1): + + libtool: compile: /home/talz/workspace/mmmmm/EZdk-nps/tools/3rd-party-libs/ccache/ccache_output/bin/ccache /usr/bin/gcc -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/tcg -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/tcg/i386 -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/linux-headers -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/build/linux_x86_64/linux-headers -I. -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/include -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/libcacard -Itrace -Itrace -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -I/usr/include/libpng12 -I/usr/include/nss3 -I/usr/include/nspr4 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/tests -MMD -MP -MT trace/generated-tracers.lo -MF trace/generated-tracers.d -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -g -c trace/generated-tracers.c -fPIE -o trace/generated-tracers.o >/dev/null 2>&1 +lolololololo:trace/generated-tracers.lo +libtool --mode=link --tag=CC c++ -fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -I/usr/include/libpng12 -I/usr/include/nss3 -I/usr/include/nspr4 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/tests -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -g -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m64 -g -rpath /home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/install/linux_x86_64/lib -no-undefined -export-syms /home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/libcacard/libcacard.syms -o libcacard.la stubs/arch-query-cpu-def.lo stubs/clock-warp.lo stubs/cpu-get-clock.lo stubs/cpu-get-icount.lo stubs/dump.lo stubs/fdset-add-fd.lo stubs/fdset-find-fd.lo stubs/fdset-get-fd.lo stubs/fdset-remove-fd.lo stubs/gdbstub.lo stubs/get-fd.lo stubs/get-vm-name.lo stubs/iothread-lock.lo stubs/migr-blocker.lo stubs/mon-is-qmp.lo stubs/mon-printf.lo stubs/mon-print-filename.lo stubs/mon-protocol-event.lo stubs/mon-set-error.lo stubs/pci-drive-hot-add.lo stubs/qtest.lo stubs/reset.lo stubs/runstate-check.lo stubs/set-fd-handler.lo stubs/slirp.lo stubs/sysbus.lo stubs/uuid.lo stubs/vm-stop.lo stubs/vmstate.lo stubs/cpus.lo stubs/kvm.lo libcacard/cac.lo libcacard/event.lo libcacard/vcard.lo libcacard/vreader.lo libcacard/vcard_emul_nss.lo libcacard/vcard_emul_type.lo libcacard/card_7816.lo libcacard/vcardt.lo util/osdep.lo util/cutils.lo util/qemu-timer-common.lo util/error.lo util/qemu-error.lo util/oslib-posix.lo util/qemu-thread-posix.lo trace/generated-events.lo trace/default.lo trace/control.lo trace/generated-tracers.lo -Wc,-fstack-protector-all -lssl3 -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -lpthread -ldl -pthread -lgthread-2.0 -lrt -lglib-2.0 +/home/talz/workspace/mmmmm/EZdk-nps/tools/3rd-party-libs/ccache/ccache_output/bin/ccache /usr/bin/gcc -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/tcg -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/tcg/i386 -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/linux-headers -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/build/linux_x86_64/linux-headers -I. -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/include -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/libcacard -Itrace -Itrace -fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -I/usr/include/libpng12 -I/usr/include/nss3 -I/usr/include/nspr4 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/tests -I qga/qapi-generated -MMD -MP -MT trace/generated-events.o -MF trace/generated-events.d -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -g -c -o trace/generated-events.o trace/generated-events.c +/home/talz/workspace/mmmmm/EZdk-nps/tools/3rd-party-libs/ccache/ccache_output/bin/ccache /usr/bin/gcc -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/tcg -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/tcg/i386 -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/linux-headers -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/build/linux_x86_64/linux-headers -I. -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/include -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/libcacard -Itrace -Itrace -fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -I/usr/include/libpng12 -I/usr/include/nss3 -I/usr/include/nspr4 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/tests -I qga/qapi-generated -MMD -MP -MT trace/generated-tracers.o -MF trace/generated-tracers.d -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -g -c -o trace/generated-tracers.o trace/generated-tracers.c +rm -f libqemustub.a && ar rcs libqemustub.a stubs/arch-query-cpu-def.o stubs/clock-warp.o stubs/cpu-get-clock.o stubs/cpu-get-icount.o stubs/dump.o stubs/fdset-add-fd.o stubs/fdset-find-fd.o stubs/fdset-get-fd.o stubs/fdset-remove-fd.o stubs/gdbstub.o stubs/get-fd.o stubs/get-vm-name.o stubs/iothread-lock.o stubs/migr-blocker.o stubs/mon-is-qmp.o stubs/mon-printf.o stubs/mon-print-filename.o stubs/mon-protocol-event.o stubs/mon-set-error.o stubs/pci-drive-hot-add.o stubs/qtest.o stubs/reset.o stubs/runstate-check.o stubs/set-fd-handler.o stubs/slirp.o stubs/sysbus.o stubs/uuid.o stubs/vm-stop.o stubs/vmstate.o stubs/cpus.o stubs/kvm.o +libtool: link: gcc -shared stubs/.libs/arch-query-cpu-def.o stubs/.libs/clock-warp.o stubs/.libs/cpu-get-clock.o stubs/.libs/cpu-get-icount.o stubs/.libs/dump.o stubs/.libs/fdset-add-fd.o stubs/.libs/fdset-find-fd.o stubs/.libs/fdset-get-fd.o stubs/.libs/fdset-remove-fd.o stubs/.libs/gdbstub.o stubs/.libs/get-fd.o stubs/.libs/get-vm-name.o stubs/.libs/iothread-lock.o stubs/.libs/migr-blocker.o stubs/.libs/mon-is-qmp.o stubs/.libs/mon-printf.o stubs/.libs/mon-print-filename.o stubs/.libs/mon-protocol-event.o stubs/.libs/mon-set-error.o stubs/.libs/pci-drive-hot-add.o stubs/.libs/qtest.o stubs/.libs/reset.o stubs/.libs/runstate-check.o stubs/.libs/set-fd-handler.o stubs/.libs/slirp.o stubs/.libs/sysbus.o stubs/.libs/uuid.o stubs/.libs/vm-stop.o stubs/.libs/vmstate.o stubs/.libs/cpus.o stubs/.libs/kvm.o libcacard/.libs/cac.o libcacard/.libs/event.o libcacard/.libs/vcard.o libcacard/.libs/vreader.o libcacard/.libs/vcard_emul_nss.o libcacard/.libs/vcard_emul_type.o libcacard/.libs/card_7816.o libcacard/.libs/vcardt.o util/.libs/osdep.o util/.libs/cutils.o util/.libs/qemu-timer-common.o util/.libs/error.o util/.libs/qemu-error.o util/.libs/oslib-posix.o util/.libs/qemu-thread-posix.o trace/.libs/generated-events.o trace/.libs/default.o trace/.libs/control.o trace/.libs/generated-tracers.o -lssl3 -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -lpthread -ldl -lgthread-2.0 -lrt -lglib-2.0 -m64 -pthread -pthread -Wl,--warn-common -Wl,-z -Wl,relro -Wl,-z -Wl,now -m64 -fstack-protector-all -pthread -pthread -Wl,-soname -Wl,libcacard.so.0 -o .libs/libcacard.so.0.0.0 +libtool: link: (cd ".libs" && rm -f "libcacard.so.0" && ln -s "libcacard.so.0.0.0" "libcacard.so.0") +libtool: link: (cd ".libs" && rm -f "libcacard.so" && ln -s "libcacard.so.0.0.0" "libcacard.so") +libtool: link: ar cru .libs/libcacard.a stubs/arch-query-cpu-def.o stubs/clock-warp.o stubs/cpu-get-clock.o stubs/cpu-get-icount.o stubs/dump.o stubs/fdset-add-fd.o stubs/fdset-find-fd.o stubs/fdset-get-fd.o stubs/fdset-remove-fd.o stubs/gdbstub.o stubs/get-fd.o stubs/get-vm-name.o stubs/iothread-lock.o stubs/migr-blocker.o stubs/mon-is-qmp.o stubs/mon-printf.o stubs/mon-print-filename.o stubs/mon-protocol-event.o stubs/mon-set-error.o stubs/pci-drive-hot-add.o stubs/qtest.o stubs/reset.o stubs/runstate-check.o stubs/set-fd-handler.o stubs/slirp.o stubs/sysbus.o stubs/uuid.o stubs/vm-stop.o stubs/vmstate.o stubs/cpus.o stubs/kvm.o libcacard/cac.o libcacard/event.o libcacard/vcard.o libcacard/vreader.o libcacard/vcard_emul_nss.o libcacard/vcard_emul_type.o libcacard/card_7816.o libcacard/vcardt.o util/osdep.o util/cutils.o util/qemu-timer-common.o util/error.o util/qemu-error.o util/oslib-posix.o util/qemu-thread-posix.o trace/generated-events.o trace/default.o trace/control.o trace/generated-tracers.o +ar: trace/generated-tracers.o: No such file or directory +make[2]: *** [libcacard.la] Error 1 +make[2]: *** Waiting for unfinished jobs.... +ooooooooooooo:trace/generated-tracers.o +ooooooooooooo:trace/generated-events.o + + +as you can see trace/generated-tracers.o target is being built after trace/generated-tracers.la target. +Trace/generated-tracers.la is finished and after it trace/generated-tracers.o is being built. +Libcacard.la has a dependency only to .la files and not .o files. + +-----Original Message----- +From: Tal Zilcer +Sent: Tuesday, June 10, 2014 12:42 PM +To: 'Bug 1324112' +Subject: RE: [Qemu-devel] [Bug 1324112] [NEW] qemu parallel building error on libcacard.la + +I didn’t mention it but im building qemu out of the source tree(running the configure in a different directory). +I tried to find the missing dependency but no luck. +The build error keeps happening Here is the end of the log(please note that I don’t see here "CC trace/generated-events.o"):. +lt CC trace/generated-events.lo + GEN qemu-doc.html + GEN qemu.1 + GEN qemu-img.1 + CC qapi-types.o + CC qapi-visit.o + CC qga/commands.o + CPP optionrom/multiboot.asm + CPP optionrom/linuxboot.asm + CC qga/guest-agent-command-state.o + CC qga/main.o + CC qga/commands-posix.o + CPP optionrom/kvmvapic.asm + AS optionrom/multiboot.o + AS optionrom/linuxboot.o + CC qga/channel-posix.o + CC qga/qapi-generated/qga-qapi-types.o + AS optionrom/kvmvapic.o + Building optionrom/multiboot.img + Building optionrom/linuxboot.img + Building optionrom/multiboot.raw + Building optionrom/linuxboot.raw + Building optionrom/kvmvapic.img + CC qga/qapi-generated/qga-qapi-visit.o + Signing optionrom/multiboot.bin + Signing optionrom/linuxboot.bin + CC qga/qapi-generated/qga-qmp-marshal.o + CC qemu-img.o + CC qmp-marshal.o + LINK qemu-bridge-helper +install -c -m 0644 /home/talz/workspace/tools/qemu/qemu/sysconfigs/target/target-x86_64.conf "/home/talz/workspace/ /tools/qemu/install/linux_x86_64/etc/qemu" + Building optionrom/kvmvapic.raw + Signing optionrom/kvmvapic.bin + lt CC trace/generated-tracers.lo +lt LINK libcacard.la + AR libqemustub.a + CC trace/generated-tracers.o +ar: .libs/libcacard.a: Error reading trace/generated-events.o: No such file or directory +make[2]: *** [libcacard.la] Error 1 + +-----Original Message----- +From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Stefan Hajnoczi +Sent: Monday, June 09, 2014 4:38 PM +To: Tal Zilcer +Subject: Re: [Qemu-devel] [Bug 1324112] [NEW] qemu parallel building error on libcacard.la + +On Wed, Jun 04, 2014 at 03:33:34AM -0000, tal zilcer wrote: +> Version 2.0.0 +> +> Isn’t the libcacard Makefile run as a recursive make? +> how do you keep the dependencies between two different makes(libcacard and trace)? + +In qemu.git/master:Makefile I see: +ifeq ($(CONFIG_SMARTCARD_NSS),y) +include $(SRC_PATH)/libcacard/Makefile +endif + +That doesn't look like recursive make to me, but maybe I'm missing +something. + +Stefan + +-- +You received this bug notification because you are subscribed to the bug +report. +https://bugs.launchpad.net/bugs/1324112 + +Title: + qemu parallel building error on libcacard.la + +Status in QEMU: + New + +Bug description: + hi, + + im building qemu with a large make -j value(9). + sometimes the build fails because of an error: + libtool: link: ar cru .libs/libcacard.a stubs/arch-query-cpu-def.o stubs/clock-warp.o stubs/cpu-get-clock.o stubs/cpu-get-icount.o stubs/dump.o stubs/fdset-add-fd.o stubs/fdset-find-fd.o stubs/fdset-get-fd.o stubs/fdset-remove-fd.o stubs/gdbstub.o stubs/get-fd.o stubs/get-vm-name.o stubs/iothread-lock.o stubs/migr-blocker.o stubs/mon-is-qmp.o stubs/mon-printf.o stubs/mon-print-filename.o stubs/mon-protocol-event.o stubs/mon-set-error.o stubs/pci-drive-hot-add.o stubs/qtest.o stubs/reset.o stubs/runstate-check.o stubs/set-fd-handler.o stubs/slirp.o stubs/sysbus.o stubs/uuid.o stubs/vm-stop.o stubs/vmstate.o stubs/cpus.o stubs/kvm.o libcacard/cac.o libcacard/event.o libcacard/vcard.o libcacard/vreader.o libcacard/vcard_emul_nss.o libcacard/vcard_emul_type.o libcacard/card_7816.o libcacard/vcardt.o util/osdep.o util/cutils.o util/qemu-timer-common.o util/error.o util/qemu-error.o util/oslib-posix.o util/qemu-thread-posix.o trace/generated-events.o trace/default.o trace/control.o trace/generated-tracers.o + ar: trace/generated-events.o: No such file or directory + make[2]: *** [libcacard.la] Error 1 + + + i see the build of generated-events.o in the log before the ar command. + because of the -j it was probably not completed yet. + the generated-events.o build command: + /usr/bin/gcc -I/home/npsdb/qemu/qemu/tcg -I/home/npsdb/qemu/qemu/tcg/i386 -I/home/npsdb/qemu/qemu/linux-headers -I/home/npsdb/qemu/build/linux_x86_64/linux-headers -I. -I/home/npsdb/qemu/qemu -I/home/npsdb/jenkins/qemu/qemu/include -I/home/npsdb/qemu/qemu/libcacard -Itrace -Itrace -fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -I/usr/include/libpng12 -I/usr/include/nss3 -I/usr/include/nspr4 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/home/npsdb/qemu/qemu/tests -I qga/qapi-generated -MMD -MP -MT trace/generated-events.o -MF trace/generated-events.d -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -g -c -o trace/generated-events.o trace/generated-events.c + + + must be a race condition in the makefile because of a missing dependency. + i tried to find it but it was a little bit complicated to me. + + thanks, + tal + +To manage notifications about this bug go to: +https://bugs.launchpad.net/qemu/+bug/1324112/+subscriptions + + +On Tue, Jun 10, 2014 at 04:35:36PM -0000, tal zilcer wrote: +> The following patch solved the issue for me: +> --- a/qemu/libcacard/Makefile +> +++ b/qemu/libcacard/Makefile +> @@ -26,8 +26,8 @@ vscclient$(EXESUF): libcacard/vscclient.o libcacard.la +> libcacard.la: LDFLAGS += -rpath $(libdir) -no-undefined \ +> -export-syms $(SRC_PATH)/libcacard/libcacard.syms +> libcacard.la: LIBS = $(libcacard_libs) +> -libcacard.la: $(libcacard-lobj-y) +> - $(call LINK,$^) +> +libcacard.la: $(libcacard-obj-y) +> + $(call LINK,$(libcacard-lobj-y)) +> +> libcacard.pc: $(SRC_PATH)/libcacard/libcacard.pc.in +> $(call quiet-command,sed -e 's|@LIBDIR@|$(libdir)|' \ + +Peter, any thoughts on this Makefile issue? + +Stefan + +> -----Original Message----- +> From: Tal Zilcer +> Sent: Tuesday, June 10, 2014 6:09 PM +> To: 'Bug 1324112' +> Subject: RE: [Qemu-devel] [Bug 1324112] [NEW] qemu parallel building error on libcacard.la +> +> To summarize what I think is the problem: +> Libcacard.la depends on trace/generated*.la files(ibcacard.la: $(libcacard-lobj-y)) +> Trace/generated*.o files depends on trace/generated*.la files($(libcacard-obj-y): | $(libcacard-lobj-y)) +> Also util depends on generated-*.o files (util-obj-y += generated-events.o) +> This means when libcacard.la is being build generated-*.o files can be build by the util target. +> I think you should change libcacard.la dependencies to include the o files and not only the la files. +> +> Thanks, +> tal +> +> -----Original Message----- +> From: Tal Zilcer +> Sent: Tuesday, June 10, 2014 3:46 PM +> To: 'Bug 1324112' +> Subject: RE: [Qemu-devel] [Bug 1324112] [NEW] qemu parallel building error on libcacard.la +> +> I did some more experiments and maybe I found the issue. +> I added a two prints to rules.mak: +> %.o: %.c +> $(call quiet-command,$(CC) $(QEMU_INCLUDES) $(QEMU_CFLAGS) $(QEMU_DGFLAGS) $(CFLAGS) $($@-cflags) -c -o $@ $<," CC $(TARGET_DIR)$@") +> @echo ooooooooooooo:$@ +> +> %.lo: %.c +> $(call quiet-command,$(LIBTOOL) --mode=compile --tag=CC $(CC) $(QEMU_INCLUDES) $(QEMU_CFLAGS) $(QEMU_DGFLAGS) $(CFLAGS) -c -o $@ $<," lt CC $@") +> @echo lolololololo:$@ +> +> This two prints symbolize the end of the file build. +> Here is the end of the log that I got for a failed build(using V=1): +> +> libtool: compile: /home/talz/workspace/mmmmm/EZdk-nps/tools/3rd-party-libs/ccache/ccache_output/bin/ccache /usr/bin/gcc -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/tcg -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/tcg/i386 -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/linux-headers -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/build/linux_x86_64/linux-headers -I. -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/include -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/libcacard -Itrace -Itrace -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -I/usr/include/libpng12 -I/usr/include/nss3 -I/usr/include/nspr4 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/tests -MMD -MP -MT trace/generated-tracers.lo -MF trace/generated-tracers.d -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -g -c trace/generated-tracers.c -fPIE -o trace/generated-tracers.o >/dev/null 2>&1 +> lolololololo:trace/generated-tracers.lo +> libtool --mode=link --tag=CC c++ -fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -I/usr/include/libpng12 -I/usr/include/nss3 -I/usr/include/nspr4 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/tests -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -g -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m64 -g -rpath /home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/install/linux_x86_64/lib -no-undefined -export-syms /home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/libcacard/libcacard.syms -o libcacard.la stubs/arch-query-cpu-def.lo stubs/clock-warp.lo stubs/cpu-get-clock.lo stubs/cpu-get-icount.lo stubs/dump.lo stubs/fdset-add-fd.lo stubs/fdset-find-fd.lo stubs/fdset-get-fd.lo stubs/fdset-remove-fd.lo stubs/gdbstub.lo stubs/get-fd.lo stubs/get-vm-name.lo stubs/iothread-lock.lo stubs/migr-blocker.lo stubs/mon-is-qmp.lo stubs/mon-printf.lo stubs/mon-print-filename.lo stubs/mon-protocol-event.lo stubs/mon-set-error.lo stubs/pci-drive-hot-add.lo stubs/qtest.lo stubs/reset.lo stubs/runstate-check.lo stubs/set-fd-handler.lo stubs/slirp.lo stubs/sysbus.lo stubs/uuid.lo stubs/vm-stop.lo stubs/vmstate.lo stubs/cpus.lo stubs/kvm.lo libcacard/cac.lo libcacard/event.lo libcacard/vcard.lo libcacard/vreader.lo libcacard/vcard_emul_nss.lo libcacard/vcard_emul_type.lo libcacard/card_7816.lo libcacard/vcardt.lo util/osdep.lo util/cutils.lo util/qemu-timer-common.lo util/error.lo util/qemu-error.lo util/oslib-posix.lo util/qemu-thread-posix.lo trace/generated-events.lo trace/default.lo trace/control.lo trace/generated-tracers.lo -Wc,-fstack-protector-all -lssl3 -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -lpthread -ldl -pthread -lgthread-2.0 -lrt -lglib-2.0 +> /home/talz/workspace/mmmmm/EZdk-nps/tools/3rd-party-libs/ccache/ccache_output/bin/ccache /usr/bin/gcc -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/tcg -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/tcg/i386 -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/linux-headers -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/build/linux_x86_64/linux-headers -I. -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/include -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/libcacard -Itrace -Itrace -fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -I/usr/include/libpng12 -I/usr/include/nss3 -I/usr/include/nspr4 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/tests -I qga/qapi-generated -MMD -MP -MT trace/generated-events.o -MF trace/generated-events.d -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -g -c -o trace/generated-events.o trace/generated-events.c +> /home/talz/workspace/mmmmm/EZdk-nps/tools/3rd-party-libs/ccache/ccache_output/bin/ccache /usr/bin/gcc -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/tcg -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/tcg/i386 -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/linux-headers -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/build/linux_x86_64/linux-headers -I. -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/include -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/libcacard -Itrace -Itrace -fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -I/usr/include/libpng12 -I/usr/include/nss3 -I/usr/include/nspr4 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/home/talz/workspace/mmmmm/EZdk-nps/tools/qemu/qemu/tests -I qga/qapi-generated -MMD -MP -MT trace/generated-tracers.o -MF trace/generated-tracers.d -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -g -c -o trace/generated-tracers.o trace/generated-tracers.c +> rm -f libqemustub.a && ar rcs libqemustub.a stubs/arch-query-cpu-def.o stubs/clock-warp.o stubs/cpu-get-clock.o stubs/cpu-get-icount.o stubs/dump.o stubs/fdset-add-fd.o stubs/fdset-find-fd.o stubs/fdset-get-fd.o stubs/fdset-remove-fd.o stubs/gdbstub.o stubs/get-fd.o stubs/get-vm-name.o stubs/iothread-lock.o stubs/migr-blocker.o stubs/mon-is-qmp.o stubs/mon-printf.o stubs/mon-print-filename.o stubs/mon-protocol-event.o stubs/mon-set-error.o stubs/pci-drive-hot-add.o stubs/qtest.o stubs/reset.o stubs/runstate-check.o stubs/set-fd-handler.o stubs/slirp.o stubs/sysbus.o stubs/uuid.o stubs/vm-stop.o stubs/vmstate.o stubs/cpus.o stubs/kvm.o +> libtool: link: gcc -shared stubs/.libs/arch-query-cpu-def.o stubs/.libs/clock-warp.o stubs/.libs/cpu-get-clock.o stubs/.libs/cpu-get-icount.o stubs/.libs/dump.o stubs/.libs/fdset-add-fd.o stubs/.libs/fdset-find-fd.o stubs/.libs/fdset-get-fd.o stubs/.libs/fdset-remove-fd.o stubs/.libs/gdbstub.o stubs/.libs/get-fd.o stubs/.libs/get-vm-name.o stubs/.libs/iothread-lock.o stubs/.libs/migr-blocker.o stubs/.libs/mon-is-qmp.o stubs/.libs/mon-printf.o stubs/.libs/mon-print-filename.o stubs/.libs/mon-protocol-event.o stubs/.libs/mon-set-error.o stubs/.libs/pci-drive-hot-add.o stubs/.libs/qtest.o stubs/.libs/reset.o stubs/.libs/runstate-check.o stubs/.libs/set-fd-handler.o stubs/.libs/slirp.o stubs/.libs/sysbus.o stubs/.libs/uuid.o stubs/.libs/vm-stop.o stubs/.libs/vmstate.o stubs/.libs/cpus.o stubs/.libs/kvm.o libcacard/.libs/cac.o libcacard/.libs/event.o libcacard/.libs/vcard.o libcacard/.libs/vreader.o libcacard/.libs/vcard_emul_nss.o libcacard/.libs/vcard_emul_type.o libcacard/.libs/card_7816.o libcacard/.libs/vcardt.o util/.libs/osdep.o util/.libs/cutils.o util/.libs/qemu-timer-common.o util/.libs/error.o util/.libs/qemu-error.o util/.libs/oslib-posix.o util/.libs/qemu-thread-posix.o trace/.libs/generated-events.o trace/.libs/default.o trace/.libs/control.o trace/.libs/generated-tracers.o -lssl3 -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -lpthread -ldl -lgthread-2.0 -lrt -lglib-2.0 -m64 -pthread -pthread -Wl,--warn-common -Wl,-z -Wl,relro -Wl,-z -Wl,now -m64 -fstack-protector-all -pthread -pthread -Wl,-soname -Wl,libcacard.so.0 -o .libs/libcacard.so.0.0.0 +> libtool: link: (cd ".libs" && rm -f "libcacard.so.0" && ln -s "libcacard.so.0.0.0" "libcacard.so.0") +> libtool: link: (cd ".libs" && rm -f "libcacard.so" && ln -s "libcacard.so.0.0.0" "libcacard.so") +> libtool: link: ar cru .libs/libcacard.a stubs/arch-query-cpu-def.o stubs/clock-warp.o stubs/cpu-get-clock.o stubs/cpu-get-icount.o stubs/dump.o stubs/fdset-add-fd.o stubs/fdset-find-fd.o stubs/fdset-get-fd.o stubs/fdset-remove-fd.o stubs/gdbstub.o stubs/get-fd.o stubs/get-vm-name.o stubs/iothread-lock.o stubs/migr-blocker.o stubs/mon-is-qmp.o stubs/mon-printf.o stubs/mon-print-filename.o stubs/mon-protocol-event.o stubs/mon-set-error.o stubs/pci-drive-hot-add.o stubs/qtest.o stubs/reset.o stubs/runstate-check.o stubs/set-fd-handler.o stubs/slirp.o stubs/sysbus.o stubs/uuid.o stubs/vm-stop.o stubs/vmstate.o stubs/cpus.o stubs/kvm.o libcacard/cac.o libcacard/event.o libcacard/vcard.o libcacard/vreader.o libcacard/vcard_emul_nss.o libcacard/vcard_emul_type.o libcacard/card_7816.o libcacard/vcardt.o util/osdep.o util/cutils.o util/qemu-timer-common.o util/error.o util/qemu-error.o util/oslib-posix.o util/qemu-thread-posix.o trace/generated-events.o trace/default.o trace/control.o trace/generated-tracers.o +> ar: trace/generated-tracers.o: No such file or directory +> make[2]: *** [libcacard.la] Error 1 +> make[2]: *** Waiting for unfinished jobs.... +> ooooooooooooo:trace/generated-tracers.o +> ooooooooooooo:trace/generated-events.o +> +> +> as you can see trace/generated-tracers.o target is being built after trace/generated-tracers.la target. +> Trace/generated-tracers.la is finished and after it trace/generated-tracers.o is being built. +> Libcacard.la has a dependency only to .la files and not .o files. +> +> -----Original Message----- +> From: Tal Zilcer +> Sent: Tuesday, June 10, 2014 12:42 PM +> To: 'Bug 1324112' +> Subject: RE: [Qemu-devel] [Bug 1324112] [NEW] qemu parallel building error on libcacard.la +> +> I didn’t mention it but im building qemu out of the source tree(running the configure in a different directory). +> I tried to find the missing dependency but no luck. +> The build error keeps happening Here is the end of the log(please note that I don’t see here "CC trace/generated-events.o"):. +> lt CC trace/generated-events.lo +> GEN qemu-doc.html +> GEN qemu.1 +> GEN qemu-img.1 +> CC qapi-types.o +> CC qapi-visit.o +> CC qga/commands.o +> CPP optionrom/multiboot.asm +> CPP optionrom/linuxboot.asm +> CC qga/guest-agent-command-state.o +> CC qga/main.o +> CC qga/commands-posix.o +> CPP optionrom/kvmvapic.asm +> AS optionrom/multiboot.o +> AS optionrom/linuxboot.o +> CC qga/channel-posix.o +> CC qga/qapi-generated/qga-qapi-types.o +> AS optionrom/kvmvapic.o +> Building optionrom/multiboot.img +> Building optionrom/linuxboot.img +> Building optionrom/multiboot.raw +> Building optionrom/linuxboot.raw +> Building optionrom/kvmvapic.img +> CC qga/qapi-generated/qga-qapi-visit.o +> Signing optionrom/multiboot.bin +> Signing optionrom/linuxboot.bin +> CC qga/qapi-generated/qga-qmp-marshal.o +> CC qemu-img.o +> CC qmp-marshal.o +> LINK qemu-bridge-helper +> install -c -m 0644 /home/talz/workspace/tools/qemu/qemu/sysconfigs/target/target-x86_64.conf "/home/talz/workspace/ /tools/qemu/install/linux_x86_64/etc/qemu" +> Building optionrom/kvmvapic.raw +> Signing optionrom/kvmvapic.bin +> lt CC trace/generated-tracers.lo +> lt LINK libcacard.la +> AR libqemustub.a +> CC trace/generated-tracers.o +> ar: .libs/libcacard.a: Error reading trace/generated-events.o: No such file or directory +> make[2]: *** [libcacard.la] Error 1 +> +> -----Original Message----- +> From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Stefan Hajnoczi +> Sent: Monday, June 09, 2014 4:38 PM +> To: Tal Zilcer +> Subject: Re: [Qemu-devel] [Bug 1324112] [NEW] qemu parallel building error on libcacard.la +> +> On Wed, Jun 04, 2014 at 03:33:34AM -0000, tal zilcer wrote: +> > Version 2.0.0 +> > +> > Isn’t the libcacard Makefile run as a recursive make? +> > how do you keep the dependencies between two different makes(libcacard and trace)? +> +> In qemu.git/master:Makefile I see: +> ifeq ($(CONFIG_SMARTCARD_NSS),y) +> include $(SRC_PATH)/libcacard/Makefile +> endif +> +> That doesn't look like recursive make to me, but maybe I'm missing +> something. +> +> Stefan +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1324112 +> +> Title: +> qemu parallel building error on libcacard.la +> +> Status in QEMU: +> New +> +> Bug description: +> hi, +> +> im building qemu with a large make -j value(9). +> sometimes the build fails because of an error: +> libtool: link: ar cru .libs/libcacard.a stubs/arch-query-cpu-def.o stubs/clock-warp.o stubs/cpu-get-clock.o stubs/cpu-get-icount.o stubs/dump.o stubs/fdset-add-fd.o stubs/fdset-find-fd.o stubs/fdset-get-fd.o stubs/fdset-remove-fd.o stubs/gdbstub.o stubs/get-fd.o stubs/get-vm-name.o stubs/iothread-lock.o stubs/migr-blocker.o stubs/mon-is-qmp.o stubs/mon-printf.o stubs/mon-print-filename.o stubs/mon-protocol-event.o stubs/mon-set-error.o stubs/pci-drive-hot-add.o stubs/qtest.o stubs/reset.o stubs/runstate-check.o stubs/set-fd-handler.o stubs/slirp.o stubs/sysbus.o stubs/uuid.o stubs/vm-stop.o stubs/vmstate.o stubs/cpus.o stubs/kvm.o libcacard/cac.o libcacard/event.o libcacard/vcard.o libcacard/vreader.o libcacard/vcard_emul_nss.o libcacard/vcard_emul_type.o libcacard/card_7816.o libcacard/vcardt.o util/osdep.o util/cutils.o util/qemu-timer-common.o util/error.o util/qemu-error.o util/oslib-posix.o util/qemu-thread-posix.o trace/generated-events.o trace/default.o trace/control.o trace/generated-tracers.o +> ar: trace/generated-events.o: No such file or directory +> make[2]: *** [libcacard.la] Error 1 +> +> +> i see the build of generated-events.o in the log before the ar command. +> because of the -j it was probably not completed yet. +> the generated-events.o build command: +> /usr/bin/gcc -I/home/npsdb/qemu/qemu/tcg -I/home/npsdb/qemu/qemu/tcg/i386 -I/home/npsdb/qemu/qemu/linux-headers -I/home/npsdb/qemu/build/linux_x86_64/linux-headers -I. -I/home/npsdb/qemu/qemu -I/home/npsdb/jenkins/qemu/qemu/include -I/home/npsdb/qemu/qemu/libcacard -Itrace -Itrace -fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -I/usr/include/libpng12 -I/usr/include/nss3 -I/usr/include/nspr4 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/home/npsdb/qemu/qemu/tests -I qga/qapi-generated -MMD -MP -MT trace/generated-events.o -MF trace/generated-events.d -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -g -c -o trace/generated-events.o trace/generated-events.c +> +> +> must be a race condition in the makefile because of a missing dependency. +> i tried to find it but it was a little bit complicated to me. +> +> thanks, +> tal +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1324112/+subscriptions +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1324112 +> +> Title: +> qemu parallel building error on libcacard.la +> +> Status in QEMU: +> New +> +> Bug description: +> hi, +> +> im building qemu with a large make -j value(9). +> sometimes the build fails because of an error: +> libtool: link: ar cru .libs/libcacard.a stubs/arch-query-cpu-def.o stubs/clock-warp.o stubs/cpu-get-clock.o stubs/cpu-get-icount.o stubs/dump.o stubs/fdset-add-fd.o stubs/fdset-find-fd.o stubs/fdset-get-fd.o stubs/fdset-remove-fd.o stubs/gdbstub.o stubs/get-fd.o stubs/get-vm-name.o stubs/iothread-lock.o stubs/migr-blocker.o stubs/mon-is-qmp.o stubs/mon-printf.o stubs/mon-print-filename.o stubs/mon-protocol-event.o stubs/mon-set-error.o stubs/pci-drive-hot-add.o stubs/qtest.o stubs/reset.o stubs/runstate-check.o stubs/set-fd-handler.o stubs/slirp.o stubs/sysbus.o stubs/uuid.o stubs/vm-stop.o stubs/vmstate.o stubs/cpus.o stubs/kvm.o libcacard/cac.o libcacard/event.o libcacard/vcard.o libcacard/vreader.o libcacard/vcard_emul_nss.o libcacard/vcard_emul_type.o libcacard/card_7816.o libcacard/vcardt.o util/osdep.o util/cutils.o util/qemu-timer-common.o util/error.o util/qemu-error.o util/oslib-posix.o util/qemu-thread-posix.o trace/generated-events.o trace/default.o trace/control.o trace/generated-tracers.o +> ar: trace/generated-events.o: No such file or directory +> make[2]: *** [libcacard.la] Error 1 +> +> +> i see the build of generated-events.o in the log before the ar command. +> because of the -j it was probably not completed yet. +> the generated-events.o build command: +> /usr/bin/gcc -I/home/npsdb/qemu/qemu/tcg -I/home/npsdb/qemu/qemu/tcg/i386 -I/home/npsdb/qemu/qemu/linux-headers -I/home/npsdb/qemu/build/linux_x86_64/linux-headers -I. -I/home/npsdb/qemu/qemu -I/home/npsdb/jenkins/qemu/qemu/include -I/home/npsdb/qemu/qemu/libcacard -Itrace -Itrace -fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -I/usr/include/libpng12 -I/usr/include/nss3 -I/usr/include/nspr4 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/home/npsdb/qemu/qemu/tests -I qga/qapi-generated -MMD -MP -MT trace/generated-events.o -MF trace/generated-events.d -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -g -c -o trace/generated-events.o trace/generated-events.c +> +> +> must be a race condition in the makefile because of a missing dependency. +> i tried to find it but it was a little bit complicated to me. +> +> thanks, +> tal +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1324112/+subscriptions +> + + +On 9 July 2014 08:49, Stefan Hajnoczi <email address hidden> wrote: +> On Tue, Jun 10, 2014 at 04:35:36PM -0000, tal zilcer wrote: +>> The following patch solved the issue for me: +>> --- a/qemu/libcacard/Makefile +>> +++ b/qemu/libcacard/Makefile +>> @@ -26,8 +26,8 @@ vscclient$(EXESUF): libcacard/vscclient.o libcacard.la +>> libcacard.la: LDFLAGS += -rpath $(libdir) -no-undefined \ +>> -export-syms $(SRC_PATH)/libcacard/libcacard.syms +>> libcacard.la: LIBS = $(libcacard_libs) +>> -libcacard.la: $(libcacard-lobj-y) +>> - $(call LINK,$^) +>> +libcacard.la: $(libcacard-obj-y) +>> + $(call LINK,$(libcacard-lobj-y)) +>> +>> libcacard.pc: $(SRC_PATH)/libcacard/libcacard.pc.in +>> $(call quiet-command,sed -e 's|@LIBDIR@|$(libdir)|' \ +> +> Peter, any thoughts on this Makefile issue? + +Not particularly; I've never looked at the libtool stuff because +I have a strong dislike of libtool... It seems a bug worth +fixing for 2.1 if you think the fix is correct. + +-- PMM + + +Could be because of this rule: + +> # libtool will build the .o files, too +> $(libcacard-obj-y): | $(libcacard-lobj-y) + +Does removing the "|" (order deps) solve the issue? + +Fam + +On Thu, Jul 10, 2014 at 7:28 AM, Fam Zheng <email address hidden> wrote: +> +> Could be because of this rule: +> +> > # libtool will build the .o files, too +> > $(libcacard-obj-y): | $(libcacard-lobj-y) +> +> Does removing the "|" (order deps) solve the issue? + +I don't think so: +libcacard.la: $(libcacard-lobj-y) + $(call LINK,$^) + +The problem is the libcacard-obj-y target is not required by anything. + +Try this on qemu.git/master: + +$ make distclean +$ ./configure +$ make libcacard/vscclient +libcacard/vscclient.o: In function `do_command': +/home/stefanha/qemu/libcacard/vscclient.c:500: undefined reference to +`vreader_get_reader_by_id' +/home/stefanha/qemu/libcacard/vscclient.c:502: undefined reference to +`vcard_emul_force_card_insert' +/home/stefanha/qemu/libcacard/vscclient.c:503: undefined reference to +`vreader_get_name' +... + +The Makefile is broken. I suspect that putting proper dependencies in +place with fix this issue. + +Stefan + + +On Thu, Jul 10, 2014 at 9:32 AM, Stefan Hajnoczi <email address hidden> wrote: +> Try this on qemu.git/master: +> +> $ make distclean +> $ ./configure +> $ make libcacard/vscclient +> libcacard/vscclient.o: In function `do_command': +> /home/stefanha/qemu/libcacard/vscclient.c:500: undefined reference to +> `vreader_get_reader_by_id' +> /home/stefanha/qemu/libcacard/vscclient.c:502: undefined reference to +> `vcard_emul_force_card_insert' +> /home/stefanha/qemu/libcacard/vscclient.c:503: undefined reference to +> `vreader_get_name' +> ... +> +> The Makefile is broken. I suspect that putting proper dependencies in +> place with fix this issue. + +Please ignore, the libcacard Makefile is actually supposed to be +invoked as "make vscclient" from the QEMU root directory. These +errors were just caused by a %.o: %.c default make target. + +Stefan + + +Since the following commit, libcacard and vscclient no longer link +against QEMU common code: + +commit fd25c0e6dd1ed2aa932fa7ef814b32457bf270fd +Author: Michael Tokarev <email address hidden> +Date: Thu May 8 12:30:48 2014 +0400 + + libcacard: replace qemu thread primitives with glib ones + +Therefore this bug no longer exists in qemu.git/master and can be closed. + +Stefan + + diff --git a/results/classifier/105/mistranslation/1326533 b/results/classifier/105/mistranslation/1326533 new file mode 100644 index 000000000..1894f21e3 --- /dev/null +++ b/results/classifier/105/mistranslation/1326533 @@ -0,0 +1,36 @@ +mistranslation: 0.867 +device: 0.680 +instruction: 0.673 +graphic: 0.582 +semantic: 0.454 +network: 0.417 +socket: 0.325 +vnc: 0.296 +boot: 0.104 +other: 0.079 +KVM: 0.073 +assembly: 0.050 + +SDL2 UI sends a NULL to sdl_grab_start if fullscreen, which crashes + +in ui/sdl2.c: + + if (full_screen) { + gui_fullscreen = 1; + sdl_grab_start(0); + } + +Is sent, but no null checks are made in sdl_grab_start (its assumed to be an allocated pointer). So a crash happens if you start qemu -full-screen. + +It should at lease send the first [0] of the newly allocated sdl2_console through. + +Quickly looking around should look something like: + + if (full_screen) { + gui_fullscreen = 1; + sdl_grab_start(&sdl2_console[0]); + } + +The NULL pointer check has been added here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=f2335791fd0ceb2f9e3 + diff --git a/results/classifier/105/mistranslation/1331 b/results/classifier/105/mistranslation/1331 new file mode 100644 index 000000000..b1f3e891b --- /dev/null +++ b/results/classifier/105/mistranslation/1331 @@ -0,0 +1,14 @@ +mistranslation: 0.881 +device: 0.636 +graphic: 0.575 +vnc: 0.447 +semantic: 0.352 +other: 0.292 +network: 0.259 +boot: 0.116 +assembly: 0.084 +socket: 0.063 +instruction: 0.058 +KVM: 0.017 + +risc-v sstatus bug diff --git a/results/classifier/105/mistranslation/1332 b/results/classifier/105/mistranslation/1332 new file mode 100644 index 000000000..ec03d1da8 --- /dev/null +++ b/results/classifier/105/mistranslation/1332 @@ -0,0 +1,14 @@ +mistranslation: 0.838 +device: 0.796 +network: 0.694 +graphic: 0.608 +vnc: 0.442 +semantic: 0.379 +other: 0.341 +socket: 0.293 +boot: 0.200 +instruction: 0.113 +assembly: 0.066 +KVM: 0.029 + +qemu.log missing sstatus register on RISC-V diff --git a/results/classifier/105/mistranslation/1334 b/results/classifier/105/mistranslation/1334 new file mode 100644 index 000000000..e70e648d8 --- /dev/null +++ b/results/classifier/105/mistranslation/1334 @@ -0,0 +1,14 @@ +mistranslation: 0.987 +graphic: 0.895 +device: 0.754 +semantic: 0.232 +other: 0.223 +network: 0.122 +boot: 0.095 +instruction: 0.071 +assembly: 0.045 +vnc: 0.031 +socket: 0.016 +KVM: 0.004 + +qemu-img map qcow2 image,but can't get right zero area diff --git a/results/classifier/105/mistranslation/1336 b/results/classifier/105/mistranslation/1336 new file mode 100644 index 000000000..60000706e --- /dev/null +++ b/results/classifier/105/mistranslation/1336 @@ -0,0 +1,14 @@ +mistranslation: 0.986 +device: 0.769 +network: 0.711 +graphic: 0.245 +instruction: 0.239 +socket: 0.203 +vnc: 0.172 +boot: 0.164 +assembly: 0.146 +semantic: 0.136 +other: 0.116 +KVM: 0.002 + +QEMU qxl_phys2virt Unsafe Address Translation Lead to OOB Read diff --git a/results/classifier/105/mistranslation/1337 b/results/classifier/105/mistranslation/1337 new file mode 100644 index 000000000..4c75a9b07 --- /dev/null +++ b/results/classifier/105/mistranslation/1337 @@ -0,0 +1,29 @@ +mistranslation: 0.962 +instruction: 0.801 +device: 0.785 +socket: 0.784 +network: 0.679 +graphic: 0.648 +semantic: 0.637 +other: 0.554 +boot: 0.422 +vnc: 0.296 +assembly: 0.242 +KVM: 0.136 + +Incorrect warnings when using vhost without numa +Description of problem: +Part A: Misleading error message. Running the above command for any architecture fails to initialize vhost, and prints the following, incorrect advice +``` +qemu-system-mips: Failed initializing vhost-user memory map, consider using -object memory-backend-file share=on +qemu-system-mips: vhost_set_mem_table failed: Invalid argument (22) +qemu-system-mips: Error starting vhost: 22 +``` + +Since the command line already contains `-object memory-backend-file,id=mem1,mem-path=/tmp/mem,size=256M,share=on` this error message should not be printed. For x86_64, this can be resolved by adding `-numa node,memdev=mem0` to the command line. As such, I think this error message should instead guide a user to adding that argument. + +Part B: No documented configuration to run vhost-user for machines that don't support numa. +The mips malta machine does not support the `-numa` flag. It is unclear if this means that `vhost` cannot be used with this platform or if a non-numa configuration with a memory-backend-file can be used. +Steps to reproduce: +1. Run `vhost-user-vsock --socket=/tmp/vhost4.socket --uds-path=/tmp/foo` from https://github.com/rust-vmm/vhost-device. +1. Run the above QEMU command diff --git a/results/classifier/105/mistranslation/1338 b/results/classifier/105/mistranslation/1338 new file mode 100644 index 000000000..9abb8cf75 --- /dev/null +++ b/results/classifier/105/mistranslation/1338 @@ -0,0 +1,14 @@ +mistranslation: 0.908 +other: 0.902 +semantic: 0.698 +graphic: 0.673 +device: 0.488 +instruction: 0.263 +vnc: 0.074 +network: 0.070 +assembly: 0.064 +KVM: 0.063 +boot: 0.045 +socket: 0.023 + +Remove gprof diff --git a/results/classifier/105/mistranslation/1345 b/results/classifier/105/mistranslation/1345 new file mode 100644 index 000000000..cfcc567a3 --- /dev/null +++ b/results/classifier/105/mistranslation/1345 @@ -0,0 +1,14 @@ +mistranslation: 0.893 +device: 0.789 +graphic: 0.612 +network: 0.543 +semantic: 0.243 +other: 0.209 +socket: 0.151 +boot: 0.146 +instruction: 0.065 +vnc: 0.034 +assembly: 0.020 +KVM: 0.001 + +qemu-img manpage and is missing info on compression_type option diff --git a/results/classifier/105/mistranslation/1353947 b/results/classifier/105/mistranslation/1353947 new file mode 100644 index 000000000..545c1d48d --- /dev/null +++ b/results/classifier/105/mistranslation/1353947 @@ -0,0 +1,101 @@ +mistranslation: 0.901 +network: 0.897 +instruction: 0.896 +semantic: 0.872 +boot: 0.866 +assembly: 0.856 +KVM: 0.854 +device: 0.851 +other: 0.840 +vnc: 0.831 +graphic: 0.823 +socket: 0.777 + +Hypervisor with QEMU-2.0/libvirtd 1.2.2 stack when launching VM with CirrOS or Ubuntu 12.04 + +The issue observed when running an hypervisor with QEMU 2.0/libvirtd 1.2.2 +The VM network interface is attached to a PCI virtual function (SR-IOV). + +When we ran VM with guest OS CirrOS or Ubuntu 12.04 we observed an hipervisor hang shortly after the VM is loaded +We observed the same issue with Mellanox NIC and with Intel NIC + +We’ve tried few combinations of {GuestOS}X{Hypervisor} and we got the following findings: +When a hypervisor is running QEMU 1.5/libvirtd 1.1.1 - no issue observed +When a hypervisor is running QEMU 2.0/libvirtd 1.2.2 - CirrOS and Ubuntu 12.04 guest OSes caused hypervisor hang +When a hypervisor is running QEMU 2.0/libvirtd 1.2.2 - CentOS 6.4 and Ubuntu 13.10 - no issue observed + +The problematic guest OSes are with kernel versions ~3.2.y + + + +Sorry, I'm having trouble following your findings. Could you please give a new table, like +this: + +====================================================================================================================== +GuestOS | Guestkernel | HostOS | Hostkernel | qemu version | libvirt version | nic type | Pass/Fail +====================================================================================================================== +cirros | ??? | 12.04 | 3.2 | 1.0+noroms-0ubuntu13 | 0.9.8-2ubuntu17 | intel SR-IOV | F +====================================================================================================================== +cirros | ??? | 12.04 | 3.13 | 1.0+noroms-0ubuntu13 | 0.9.8-2ubuntu17 | intel SR-IOV | P +====================================================================================================================== +(...0 +====================================================================================================================== + +Ideally we could determine whether the kernel version is at all related, or whether it +is purely tied to qemu version. + + +Hi Serge, +1. Please see the table below +2. We also observed this issue with Intel NICs +=============================================================================================================================================== +GuestOS | Guestkernel | HostOS | Hostkernel | qemu version | libvirt version | nic type | Pass/Fail +=============================================================================================================================================== +Ubuntu 12.04 | 3.2.0-63-generic | Ubuntu 12.04 | 3.11.0-18-generic | 2.0.0+dfsg-2ubuntu1.1 | 1.2.2-0ubuntu13.2 | Mellanox SR-IOV | F +=============================================================================================================================================== +Ubuntu 13.10 | 3.11.0-26-generic | Ubuntu 12.04 | 3.11.0-18-generic | 2.0.0+dfsg-2ubuntu1.1 | 1.2.2-0ubuntu13.2 | Mellanox SR-IOV | P +=============================================================================================================================================== + + +Thanks, so the problem appears to be that a feature is missing from the guest's precise kernel, which was present in the saucy (13.10) kernel. + +Could you verify whether using the LTS backport kernel packages in the precies guest fixes the issue? + +(Note I don't believe this bug should be marked as affecting the QEMU project) + +This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run: + +apport-collect 1353947 + +and then change the status of the bug to 'Confirmed'. + +If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'. + +This change has been made by an automated script, maintained by the Ubuntu Kernel Team. + +Can't run apport-collect after the kernel hang + +Hello Serge, +I agree that there is probably some missing feature in the guest kernel. +However, I don't believe it is acceptable for the hyper-visor kernel to be affected from this. +Actually, this is a security issue if a VM user can crash i't Host kernel and probably some other VMs as well. + + +Sorry, when the table only had the two entries i drew some bad assumptions from that, and I also missed the fact that hangs were in the host kernel. + +To be clear, running qemu 1.5 on the same host kernel has no issues with any guest, while qemu 2.0 causes host kernel to hang (indefinately) with some guests? + +Then indeed disregard my comment #5. + +Is this 100% reproducible, every time? Would you be able to bisect qemu to figure out where the problem was introduced? + +Indeed, with qemu 1.5 we did not observed this issue at all. +Sorry, but I don't have the resources at the moment to do the bisecting. + + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for linux (Ubuntu) because there has been no activity for 60 days.] + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1358619 b/results/classifier/105/mistranslation/1358619 new file mode 100644 index 000000000..2f0b4a4d8 --- /dev/null +++ b/results/classifier/105/mistranslation/1358619 @@ -0,0 +1,118 @@ +mistranslation: 0.710 +KVM: 0.689 +device: 0.671 +vnc: 0.627 +other: 0.625 +boot: 0.573 +semantic: 0.561 +instruction: 0.509 +graphic: 0.491 +network: 0.458 +assembly: 0.430 +socket: 0.365 + +keep savevm/loadvm and migration cause snapshot crash + +--Version: qemu 2.1.0 public release +--OS: CentOS release 6.4 +--gcc: 4.4.7 + +Hi: + I found problems when doing some tests on qemu migration and savevm/loadvm. +On my experiment, a quest is migrated between two same host back and forth. +Source host would savevm after migration completed and incoming host loadvm before migration coming. + +image=./image/centos-1.qcow2 + +====Migration Part==== +qemu-system-x86_64 \ + -qmp tcp:$host_ip:4451,server,nowait \ + -drive file=$image \ + --enable-kvm \ + -monitor stdio \ + -m 8192 \ + -device virtio-net-pci,netdev=net0,mac=$mac \ + -netdev tap,id=net0,script=./qemu-ifup + +====Incoming Part==== +qemu-system-x86_64 \ + -qmp tcp:$host_ip:4451,server,nowait \ + -incoming tcp:0:4449 \ + --enable-kvm \ + -monitor stdio \ + -drive file=$image \ + -m 8192 \ + -device virtio-net-pci,netdev=net0,mac=$mac \ + -netdev tap,id=net0,script=./qemu-ifup + + +Command lines: + +host1 $: qemu-system-x86_64 ........ //migration part +host2 $: qemu-system-x86_64 ...incoming... //incoming part + +After finishing boot + +host1 (qemu) : migrate tcp:host2:4449 +host1 (qemu) : savevm s1 +host1 (qemu) : quit +host1 $: qemu-system-x86_64 ...incoming... //incoming part +host1 (qemu) : loadvm s1 + +host2 (qemu) : migrate tcp:host1:4449 +host2 (qemu) : savevm s2 +host2 (qemu) : quit +host2 $: qemu-system-x86_64 ...incoming... //incoming part +host2 (qemu) : loadvm s2 + +host1 (qemu) : migrate tcp:host2:4449 +host1 (qemu) : savevm s3 +host1 (qemu) : quit +host1 $: qemu-system-x86_64 ...incoming... //incoming part +host1 (qemu) : loadvm s3 + +I wish those operation can be success every time. +However problem happened irregularly when loadvm and error messages are not the same. + +host1 (qemu) : loadvm s3 +qcow2: Preventing invalid write on metadata (overlaps with active L1 table); image marked as corrupt. +Error -5 while activating snapshot 's3' on 'ide0-hd0' + +or + +host2 (qemu) : loadvm s2 +Error -22 while loading VM state + + +I have done some sample test on savevm/loadvm +On same host +(qemu) savevm test1 +(qemu) loadvm test1 +(qemu) savevm test2 +(qemu) loadvm test2 +(qemu) savevm test3 +(qemu) loadvm test3 +(qemu) savevm test4 +(qemu) loadvm test4 +(qemu) savevm test5 +(qemu) loadvm test5 +(qemu) savevm test6 +(qemu) loadvm test6 + +This is OK. No any problem. + + +Any idea? +I think it is related to migration. + +Hi, + Can I just check, when you do the incoming migrate, do you wait for the incoming migrate to finish before you do the loadvm, or do you do the loadvm during the incoming migrate? + +I execute incoming migration command and wait there. Then I do loadvm. After finishing loadvm, type migration command on source host to start migration. + +In fact, This action is useless for vm status before migration. I just modify some codes and then found this bug. + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/136 b/results/classifier/105/mistranslation/136 new file mode 100644 index 000000000..f271c16e0 --- /dev/null +++ b/results/classifier/105/mistranslation/136 @@ -0,0 +1,14 @@ +mistranslation: 0.788 +instruction: 0.774 +device: 0.769 +graphic: 0.753 +semantic: 0.431 +network: 0.421 +vnc: 0.204 +boot: 0.112 +socket: 0.042 +other: 0.039 +assembly: 0.030 +KVM: 0.021 + +windows qemu-img create vpc/vhdx error diff --git a/results/classifier/105/mistranslation/1367365 b/results/classifier/105/mistranslation/1367365 new file mode 100644 index 000000000..657e4de0c --- /dev/null +++ b/results/classifier/105/mistranslation/1367365 @@ -0,0 +1,40 @@ +mistranslation: 0.917 +graphic: 0.742 +device: 0.712 +network: 0.602 +semantic: 0.578 +other: 0.543 +socket: 0.528 +vnc: 0.440 +boot: 0.389 +instruction: 0.388 +KVM: 0.309 +assembly: 0.233 + +qemu-img fixed vhd issues + +qemu-img returns fixed vhd images file format to be raw. + +This happens because only the header is seeked for image signatures when getting the image format. In fact, unlike dynamic vhd images, differencing vhds don't have the footer copied in the header. + +An easy fix would be to just search the last 512B for the 'conectix' signature. + +Also, the fixed vhds created by qemu-img seem to be corrupted from Powershell POV. + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? Otherwise, can you provide some test images or a description how to create such images? + +Yes I can reproduce this issue on Windows 10 with newest version of QEMU (until 03/28/2018) + +I've posted my way of reproduce in a new bug issue: +`#1759522 windows qemu-img create vpc/vhdx error` + +Sorry for the mistaken operation (changed to confirmed), I didn't mean to change the status + + +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/107 + + diff --git a/results/classifier/105/mistranslation/1376533 b/results/classifier/105/mistranslation/1376533 new file mode 100644 index 000000000..5712afe65 --- /dev/null +++ b/results/classifier/105/mistranslation/1376533 @@ -0,0 +1,23 @@ +mistranslation: 0.621 +device: 0.527 +graphic: 0.522 +semantic: 0.412 +vnc: 0.376 +network: 0.358 +instruction: 0.297 +socket: 0.271 +KVM: 0.177 +boot: 0.162 +other: 0.103 +assembly: 0.060 + +Copyright year should be updated in vl.c + +When specifying '--version', qemu prints the version along with 'Copyright (c) 2003-2008'. + +Some users may think that it hasn't been updated since 2008, so the end year in version() in vl.c should probably be updated around the start of each new year. + +Found in the qemu-2.1.2 source tarball. + +This has been fixed a while ago already, so setting the status to "Fix released" now. + diff --git a/results/classifier/105/mistranslation/1383 b/results/classifier/105/mistranslation/1383 new file mode 100644 index 000000000..18bba0ec5 --- /dev/null +++ b/results/classifier/105/mistranslation/1383 @@ -0,0 +1,14 @@ +mistranslation: 0.952 +device: 0.806 +other: 0.601 +semantic: 0.533 +graphic: 0.400 +network: 0.284 +instruction: 0.220 +boot: 0.093 +vnc: 0.041 +assembly: 0.021 +socket: 0.016 +KVM: 0.004 + +Pentium Pro cpuid capabilities are wrong, resulting in wrong definition of athlon and others diff --git a/results/classifier/105/mistranslation/1393440 b/results/classifier/105/mistranslation/1393440 new file mode 100644 index 000000000..893935ab8 --- /dev/null +++ b/results/classifier/105/mistranslation/1393440 @@ -0,0 +1,34 @@ +mistranslation: 0.857 +device: 0.853 +network: 0.773 +socket: 0.749 +instruction: 0.691 +vnc: 0.607 +semantic: 0.591 +graphic: 0.556 +KVM: 0.336 +boot: 0.275 +assembly: 0.252 +other: 0.187 + +pcie.c:148: possible error in OR expression ? + +[qemu/hw/pci/pcie.c:148] -> [qemu/hw/pci/pcie.c:148]: (style) Same expression on both sides of '|'. + + pci_long_test_and_set_mask(dev->w1cmask + pos + PCI_EXP_DEVSTA, + PCI_EXP_DEVSTA_CED | PCI_EXP_DEVSTA_NFED | + PCI_EXP_DEVSTA_URD | PCI_EXP_DEVSTA_URD); + +I am guessing that something like + + pci_long_test_and_set_mask(dev->w1cmask + pos + PCI_EXP_DEVSTA, + PCI_EXP_DEVSTA_CED | PCI_EXP_DEVSTA_NFED | + PCI_EXP_DEVSTA_FED | PCI_EXP_DEVSTA_URD); + +was intended. + +I used static analyser cppcheck to find this bug. + +Fixed here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=8e815eeefe205155f5 + diff --git a/results/classifier/105/mistranslation/1397 b/results/classifier/105/mistranslation/1397 new file mode 100644 index 000000000..b66b4d340 --- /dev/null +++ b/results/classifier/105/mistranslation/1397 @@ -0,0 +1,14 @@ +mistranslation: 0.942 +device: 0.663 +instruction: 0.573 +network: 0.537 +graphic: 0.387 +semantic: 0.381 +other: 0.320 +assembly: 0.271 +socket: 0.252 +KVM: 0.212 +boot: 0.134 +vnc: 0.133 + +riscv: break, hbreak does not set a breakpoint on the correct address when providing symbols diff --git a/results/classifier/105/mistranslation/1402802 b/results/classifier/105/mistranslation/1402802 new file mode 100644 index 000000000..6b98f2965 --- /dev/null +++ b/results/classifier/105/mistranslation/1402802 @@ -0,0 +1,31 @@ +mistranslation: 0.886 +graphic: 0.652 +device: 0.520 +semantic: 0.472 +network: 0.446 +instruction: 0.375 +socket: 0.344 +vnc: 0.288 +other: 0.210 +boot: 0.142 +assembly: 0.091 +KVM: 0.080 + +target-tricore/translate.c:3812: possible bad expression ? + + +From a run of cppcheck, a static analysis checker, over the +source code of qemu trunk, dated 20141215, is the new error: + +[qemu/target-tricore/translate.c:3812]: (style) Expression '(X & 0x3f) == 0x6f' is always false. + +Source code is + + if (unlikely((op1 & 0x3f) == OPCM_32_BRN_JTT)) { + +Suggest code rework. + +Absolutly correct. The mask should be 0x7f. I will fix that asap. + +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=7f13420ec000ad7644b65e + diff --git a/results/classifier/105/mistranslation/1405176 b/results/classifier/105/mistranslation/1405176 new file mode 100644 index 000000000..73eabd385 --- /dev/null +++ b/results/classifier/105/mistranslation/1405176 @@ -0,0 +1,23 @@ +mistranslation: 0.738 +graphic: 0.737 +device: 0.656 +semantic: 0.438 +other: 0.414 +network: 0.398 +socket: 0.339 +instruction: 0.295 +vnc: 0.162 +boot: 0.135 +KVM: 0.094 +assembly: 0.077 + +ctrl+alt+2 not work on gtk display + +I download 2.2.0 release on http://wiki.qemu.org/Download +the monitor console does not appear in gtk display but works for sdl and vnc. +my gtk is 3.12.2 + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1407813 b/results/classifier/105/mistranslation/1407813 new file mode 100644 index 000000000..b5c2d09bd --- /dev/null +++ b/results/classifier/105/mistranslation/1407813 @@ -0,0 +1,29 @@ +mistranslation: 0.912 +instruction: 0.700 +device: 0.683 +semantic: 0.661 +vnc: 0.627 +graphic: 0.596 +network: 0.587 +other: 0.551 +socket: 0.506 +assembly: 0.211 +boot: 0.190 +KVM: 0.163 + +QEMU wrongly translates newlines on serial output + +When using "-serial stdio", QEMU shows the guest serial port's output on the tty running qemu. As it should, QEMU sets the tty to raw mode. Or almost... Strangely, it neglects to remove one output-translation bit, ONLCR (see termios(3)) enabled on the tty. And it should have removed this output translation! + +The problem is that with this ONLCR, the guest has no way of outputting a bare linefeed ('\n') - every time the guest tries to output a bare linefeed to the serial port, the host tty will translate it to \r\n which will be sent to the underlying terminal (e.g., xterm). + +In most cases, this issue doesn't cause a problem: When the guest is running a Unix-like operating system which is itself in cooked mode, the guest itself will always output \r\n, and the hosts second translation (to \r\r\n) does no harm. But in certain cases, the guest can *really* want to output just \n, and have this \n reach the terminal emulator and do what a linefeed is supposed to do without a carriage-return - namely - just go one line down in the same column. + +As an illustration of this bug, consider a guest running a Unix-like operating system running a curses-based application (e.g., "vi"). If you look at the output of "infocmp xterm", you'll notice that cud1=^J. This means that if the curses library decides to move one line down (it can happen in some cursor movement situations) it might decide to print a linefeed (\n) to move one line down. The guest's operating system will not mess with this linefeed (because the guest is in raw mode), but then qemu's tty, because it was wrongly left in ONLCR mode, will change this \n to \r\n before it reaches the terminal - causing wrong cursor movement (instead the cursor going straight down, it moves to the first column of the next line). + +I think this bug relates to: +https://bugs.launchpad.net/qemu/+bug/1715296 + +Patch has now been committed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=12fb0ac0575df83cec72ec + diff --git a/results/classifier/105/mistranslation/1414293 b/results/classifier/105/mistranslation/1414293 new file mode 100644 index 000000000..aa41e03a8 --- /dev/null +++ b/results/classifier/105/mistranslation/1414293 @@ -0,0 +1,24 @@ +mistranslation: 0.961 +instruction: 0.835 +device: 0.752 +graphic: 0.682 +socket: 0.502 +network: 0.409 +semantic: 0.400 +vnc: 0.349 +boot: 0.233 +other: 0.169 +KVM: 0.095 +assembly: 0.088 + +target-lm32/translate.c:336: bad ? : operator + +[qemu/target-lm32/translate.c:336]: (style) Same expression in both branches of ternary operator. + + int rY = (dc->format == OP_FMT_RR) ? dc->r0 : dc->r0; + +Patch has been committed: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=5db35b616b8d3a27783ec + +Released with version 2.8 + diff --git a/results/classifier/105/mistranslation/1417 b/results/classifier/105/mistranslation/1417 new file mode 100644 index 000000000..b134ceb7a --- /dev/null +++ b/results/classifier/105/mistranslation/1417 @@ -0,0 +1,18 @@ +mistranslation: 0.945 +semantic: 0.933 +device: 0.903 +instruction: 0.885 +graphic: 0.852 +socket: 0.768 +network: 0.737 +vnc: 0.699 +other: 0.584 +assembly: 0.540 +boot: 0.375 +KVM: 0.053 + +QEMU fails an assertion when hitting a breakpoint that is set on a tlb-missed 2-stage translated AArch64 memory +Description of problem: +After upgrading to QEMU v7.2.0 from v7.1.0, when hitting an instruction breakpoint on a memory address that is translated by 2 stages of translation, and is not already cached in the TLB, QEMU fails the assertion at target/arm/ptw.c:301 (`assert(fi->type != ARMFault_None);`). + +I believe this was introduced in f3639a64f602ea5c1436eb9c9b89f42028e3a4a8 (@rth7680), since in that commit the failure check for the return value of `get_phys_addr_lpae()` changed from checking for true (meaning failure) to checking for false (which actually means success). diff --git a/results/classifier/105/mistranslation/1429313 b/results/classifier/105/mistranslation/1429313 new file mode 100644 index 000000000..f97f9af8f --- /dev/null +++ b/results/classifier/105/mistranslation/1429313 @@ -0,0 +1,28 @@ +mistranslation: 0.413 +device: 0.389 +instruction: 0.383 +graphic: 0.286 +network: 0.262 +socket: 0.231 +semantic: 0.163 +vnc: 0.096 +boot: 0.087 +KVM: 0.034 +other: 0.031 +assembly: 0.029 + +qemu-user doesn't block target signals on entry to signal hanlder. + +Upon entry to a target signal handler the function process_pending_signals in linux-user/signal.c block the appropriate host signals, but signals already received and queued by Qemu are not blocked. If multiple signals arrive in quick succession this results incorrect recursion in the target signal handler. + +The attached test case my be run as: + +$ (sleep 2 ; echo) | qemu-i386 ./a.out +.................. Recursion in signal handler! +qemu: uncaught target signal 6 (Aborted) - core dumped + + + +The patches to block signals on entry to the signal handler have now been applied to master. + + diff --git a/results/classifier/105/mistranslation/143 b/results/classifier/105/mistranslation/143 new file mode 100644 index 000000000..e07f23bb3 --- /dev/null +++ b/results/classifier/105/mistranslation/143 @@ -0,0 +1,14 @@ +mistranslation: 0.953 +device: 0.813 +graphic: 0.497 +network: 0.328 +boot: 0.321 +instruction: 0.262 +semantic: 0.237 +other: 0.112 +vnc: 0.087 +assembly: 0.079 +socket: 0.026 +KVM: 0.023 + +xhci HCIVERSION register read emulation incorrectly handled diff --git a/results/classifier/105/mistranslation/1431 b/results/classifier/105/mistranslation/1431 new file mode 100644 index 000000000..90e39b7a2 --- /dev/null +++ b/results/classifier/105/mistranslation/1431 @@ -0,0 +1,63 @@ +mistranslation: 0.819 +graphic: 0.796 +device: 0.622 +KVM: 0.470 +instruction: 0.394 +socket: 0.356 +semantic: 0.338 +vnc: 0.251 +other: 0.208 +boot: 0.171 +network: 0.121 +assembly: 0.082 + +qemu spice support opengl +Steps to reproduce: +I wan to use spice support opengl, but my qemu seems not support,what can i do to support opengl for spice? + +qemu configure: +``` +./configure --target-list=x86_64-softmmu --enable-kvm --enable-debug --enable-spice --enable-numa --enable-libusb --enable-curl --enable-usb-redir --enable-libiscsi --enable-virglrenderer --enable-opengl --enable-gtk --prefix="/usr" +``` + +xml: +```xml +<domain type='kvm'> + <name>test</name> + <memory>1048576</memory> + <currentMemory>1048576</currentMemory> + <vcpu>1</vcpu> + <os> + <type arch='x86_64' machine='pc'>hvm</type> + </os> + <cpu mode='custom' match='exact' check='full'> + <topology sockets='1' dies='1' cores='1' threads='1'/> + </cpu> + <features> + <acpi/> + <apic/> + <pae/> + </features> + <clock offset='localtime'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/bin/qemu-system-x86_64</emulator> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/root/kk.img'/> + <target dev='hda' bus='ide'/> + </disk> + <input type='mouse' bus='ps2'/> + <graphics type='spice'> + <listen type='none'/> + <gl enable='yes' rendernode='/dev/dri/renderD128'/> + </graphics> + </devices> +</domain> +``` + +error report: + + diff --git a/results/classifier/105/mistranslation/1431084 b/results/classifier/105/mistranslation/1431084 new file mode 100644 index 000000000..611e43074 --- /dev/null +++ b/results/classifier/105/mistranslation/1431084 @@ -0,0 +1,28 @@ +mistranslation: 0.996 +graphic: 0.895 +other: 0.887 +semantic: 0.879 +device: 0.877 +instruction: 0.859 +vnc: 0.714 +network: 0.690 +boot: 0.638 +socket: 0.545 +KVM: 0.475 +assembly: 0.198 + +improve configure error message "ERROR: User requested feature nptl" + +Running `./configure` on Ubuntu 14.10 amd64 with Linux 3.19.1 causes the error + + ERROR: User requested feature nptl + configure was not able to find it. + Install glibc and linux kernel headers. + +Both linux kernel headers and `libglib2.0-dev` are installed in my case, so the error message definitely misses a point and is at least confusing and should either omit the hint if the recommended dependencies are already installed or - better - give one that fixes the issue. + +experienced with git commit d598911b6f5e7bf7bafb63b8e1d074729e94aca7 + +You say "Both linux kernel headers and `libglib2.0-dev` are installed", but the error message says "Install glibc and linux kernel headers". "glibc" is not "libglib". I suspect you didn't have what on Ubuntu is the "libc6-dev" package. Unfortunately it's difficult to be specific in these error messages, because different distros call their dev packages by different names. + + diff --git a/results/classifier/105/mistranslation/1433 b/results/classifier/105/mistranslation/1433 new file mode 100644 index 000000000..610b420ef --- /dev/null +++ b/results/classifier/105/mistranslation/1433 @@ -0,0 +1,170 @@ +mistranslation: 0.888 +other: 0.822 +graphic: 0.811 +vnc: 0.806 +semantic: 0.799 +instruction: 0.774 +assembly: 0.774 +socket: 0.774 +device: 0.767 +boot: 0.763 +KVM: 0.737 +network: 0.711 + +Abort in lan9118_16bit_mode_[read|write]() +Description of problem: +[read|write][w|l] are allowed but [read|write]b are not allowed when mode_16bit is enabled. +Steps to reproduce: +``` +export QEMU=/path/to/qemu-system-arm + +cat << EOF | $QEMU \ +-machine smdkc210 -monitor none -serial none \ +-display none -qtest stdio +readb 0x5000070 +EOF +``` +Additional information: +``` +==1940==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +INFO: found LLVMFuzzerCustomMutator (0x5654b8eede90). Disabling -len_control by default. +INFO: Running with entropic power schedule (0xFF, 100). +INFO: Seed: 3248453476 +INFO: Loaded 1 modules (601357 inline 8-bit counters): 601357 [0x5654bbdd8000, 0x5654bbe6ad0d), +INFO: Loaded 1 PC tables (601357 PCs): 601357 [0x5654bb4aa340,0x5654bbdd7410), +./qemu-videzzo-arm-target-videzzo-fuzz-lan9118: Running 1 inputs 1 time(s) each. +INFO: Reading pre_seed_input if any ... +INFO: Executing pre_seed_input if any ... +INFO: -max_len is not provided; libFuzzer will not generate inputs larger than 4096 bytes +Matching objects by name , *lan9118-mmio* +This process will fuzz the following MemoryRegions: + * lan9118-mmio[0] (size 100) +This process will fuzz through the following interfaces: + * clock_step, EVENT_TYPE_CLOCK_STEP, 0xffffffff +0xffffffff, 255,255 + * lan9118-mmio, EVENT_TYPE_MMIO_READ, 0x5000000 +0x100, 1,4 + * lan9118-mmio, EVENT_TYPE_MMIO_WRITE, 0x5000000 +0x100, 1,4 +INFO: A corpus is not provided, starting from an empty corpus +#2 INITED cov: 3 ft: 4 corp: 1/1b exec/s: 0 rss: 221Mb +Running: ./crash-663e5408ee573b1e9d073c796ffbaaae9bd583cb +qemu: hardware error: lan9118_read: Bad size 0x1 + +CPU #0: +R00=00000000 R01=00000000 R02=00000000 R03=00000000 +R04=00000000 R05=00000000 R06=00000000 R07=00000000 +R08=00000000 R09=00000000 R10=00000000 R11=00000000 +R12=00000000 R13=00000000 R14=00000000 R15=00000000 +PSR=400001d3 -Z-- A svc32 +s00=00000000 s01=00000000 d00=0000000000000000 +s02=00000000 s03=00000000 d01=0000000000000000 +s04=00000000 s05=00000000 d02=0000000000000000 +s06=00000000 s07=00000000 d03=0000000000000000 +s08=00000000 s09=00000000 d04=0000000000000000 +s10=00000000 s11=00000000 d05=0000000000000000 +s12=00000000 s13=00000000 d06=0000000000000000 +s14=00000000 s15=00000000 d07=0000000000000000 +s16=00000000 s17=00000000 d08=0000000000000000 +s18=00000000 s19=00000000 d09=0000000000000000 +s20=00000000 s21=00000000 d10=0000000000000000 +s22=00000000 s23=00000000 d11=0000000000000000 +s24=00000000 s25=00000000 d12=0000000000000000 +s26=00000000 s27=00000000 d13=0000000000000000 +s28=00000000 s29=00000000 d14=0000000000000000 +s30=00000000 s31=00000000 d15=0000000000000000 +s32=00000000 s33=00000000 d16=0000000000000000 +s34=00000000 s35=00000000 d17=0000000000000000 +s36=00000000 s37=00000000 d18=0000000000000000 +s38=00000000 s39=00000000 d19=0000000000000000 +s40=00000000 s41=00000000 d20=0000000000000000 +s42=00000000 s43=00000000 d21=0000000000000000 +s44=00000000 s45=00000000 d22=0000000000000000 +s46=00000000 s47=00000000 d23=0000000000000000 +s48=00000000 s49=00000000 d24=0000000000000000 +s50=00000000 s51=00000000 d25=0000000000000000 +s52=00000000 s53=00000000 d26=0000000000000000 +s54=00000000 s55=00000000 d27=0000000000000000 +s56=00000000 s57=00000000 d28=0000000000000000 +s58=00000000 s59=00000000 d29=0000000000000000 +s60=00000000 s61=00000000 d30=0000000000000000 +s62=00000000 s63=00000000 d31=0000000000000000 +FPSCR: 00000000 +CPU #1: +R00=00000000 R01=00000000 R02=00000000 R03=00000000 +R04=00000000 R05=00000000 R06=00000000 R07=00000000 +R08=00000000 R09=00000000 R10=00000000 R11=00000000 +R12=00000000 R13=00000000 R14=00000000 R15=00000000 +PSR=400001d3 -Z-- A svc32 +s00=00000000 s01=00000000 d00=0000000000000000 +s02=00000000 s03=00000000 d01=0000000000000000 +s04=00000000 s05=00000000 d02=0000000000000000 +s06=00000000 s07=00000000 d03=0000000000000000 +s08=00000000 s09=00000000 d04=0000000000000000 +s10=00000000 s11=00000000 d05=0000000000000000 +s12=00000000 s13=00000000 d06=0000000000000000 +s14=00000000 s15=00000000 d07=0000000000000000 +s16=00000000 s17=00000000 d08=0000000000000000 +s18=00000000 s19=00000000 d09=0000000000000000 +s20=00000000 s21=00000000 d10=0000000000000000 +s22=00000000 s23=00000000 d11=0000000000000000 +s24=00000000 s25=00000000 d12=0000000000000000 +s26=00000000 s27=00000000 d13=0000000000000000 +s28=00000000 s29=00000000 d14=0000000000000000 +s30=00000000 s31=00000000 d15=0000000000000000 +s32=00000000 s33=00000000 d16=0000000000000000 +s34=00000000 s35=00000000 d17=0000000000000000 +s36=00000000 s37=00000000 d18=0000000000000000 +s38=00000000 s39=00000000 d19=0000000000000000 +s40=00000000 s41=00000000 d20=0000000000000000 +s42=00000000 s43=00000000 d21=0000000000000000 +s44=00000000 s45=00000000 d22=0000000000000000 +s46=00000000 s47=00000000 d23=0000000000000000 +s48=00000000 s49=00000000 d24=0000000000000000 +s50=00000000 s51=00000000 d25=0000000000000000 +s52=00000000 s53=00000000 d26=0000000000000000 +s54=00000000 s55=00000000 d27=0000000000000000 +s56=00000000 s57=00000000 d28=0000000000000000 +s58=00000000 s59=00000000 d29=0000000000000000 +s60=00000000 s61=00000000 d30=0000000000000000 +s62=00000000 s63=00000000 d31=0000000000000000 +FPSCR: 00000000 +==1940== ERROR: libFuzzer: deadly signal + #0 0x5654b48090fe in __sanitizer_print_stack_trace /root/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:86:3 + #1 0x5654b4757d71 in fuzzer::PrintStackTrace() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:38 + #2 0x5654b4730ca6 in fuzzer::Fuzzer::CrashCallback() (.part.0) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:236:18 + #3 0x5654b4730d72 in fuzzer::Fuzzer::CrashCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:208:1 + #4 0x5654b4730d72 in fuzzer::Fuzzer::StaticCrashSignalCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:207:19 + #5 0x7fb6db17941f (/lib/x86_64-linux-gnu/libpthread.so.0+0x1441f) + #6 0x7fb6daf8b00a in __libc_signal_restore_set /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3 + #7 0x7fb6daf8b00a in raise /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:48:3 + #8 0x7fb6daf6a858 in abort /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:79:7 + #9 0x5654b483964a in __wrap_abort /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/less_crashes_wrappers.c:24:12 + #10 0x5654b6a64d84 in hw_error /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/cpus.c:128:5 + #11 0x5654b5ac50c7 in lan9118_16bit_mode_read /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/net/lan9118.c:1319:5 + #12 0x5654b7ee045b in memory_region_read_accessor /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:440:11 + #13 0x5654b7ea0761 in access_with_adjusted_size /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:554:18 + #14 0x5654b7e9db2c in memory_region_dispatch_read1 /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:1424:16 + #15 0x5654b7e9d268 in memory_region_dispatch_read /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:1457:9 + #16 0x5654b7f1946d in flatview_read_continue /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2892:23 + #17 0x5654b7f1aa78 in flatview_read /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2934:12 + #18 0x5654b7f1a538 in address_space_read_full /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2947:18 + #19 0x5654b483a7ea in address_space_read /root/videzzo/videzzo_qemu/qemu/include/exec/memory.h:2869:18 + #20 0x5654b483a7ea in qemu_readb /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1010:5 + #21 0x5654b483997e in dispatch_mmio_read /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1034:35 + #22 0x5654b8ee984f in videzzo_dispatch_event /root/videzzo/videzzo.c:1122:5 + #23 0x5654b8ee0bcb in __videzzo_execute_one_input /root/videzzo/videzzo.c:272:9 + #24 0x5654b8ee0aa0 in videzzo_execute_one_input /root/videzzo/videzzo.c:313:9 + #25 0x5654b48500fc in videzzo_qemu /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1497:12 + #26 0x5654b8eee132 in LLVMFuzzerTestOneInput /root/videzzo/videzzo.c:1891:18 + #27 0x5654b4731816 in fuzzer::Fuzzer::ExecuteCallback(unsigned char*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:594:17 + #28 0x5654b4714444 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:21 + #29 0x5654b471f3ee in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:885:19 + #30 0x5654b470b9d6 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30 + #31 0x7fb6daf6c082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 + #32 0x5654b470ba2d in _start (/root/videzzo/videzzo_qemu/out-san/qemu-videzzo-arm-target-videzzo-fuzz-lan9118+0x300da2d) + +NOTE: libFuzzer has rudimentary signal handlers. + Combine libFuzzer with AddressSanitizer or similar for better crash reports. +SUMMARY: libFuzzer: deadly signal +MS: 0 ; base unit: 0000000000000000000000000000000000000000 +0x4,0x2,0x29,0x92,0xa,0x0,0x0,0x0,0x0,0x0,0x0,0x8,0x70,0x0,0x0,0x5,0x0,0x0,0x0,0x0,0x1,0x0,0x0,0x0,0x1,0x9,0x48,0x0,0x0,0x5,0x0,0x0,0x0,0x0,0x4,0x0,0x0,0x0,0x29,0x1f,0x8e,0x23,0x0,0x0,0x0,0x0, +\x04\x02)\x92\x0a\x00\x00\x00\x00\x00\x00\x08p\x00\x00\x05\x00\x00\x00\x00\x01\x00\x00\x00\x01\x09H\x00\x00\x05\x00\x00\x00\x00\x04\x00\x00\x00)\x1f\x8e#\x00\x00\x00\x00 +``` diff --git a/results/classifier/105/mistranslation/1435101 b/results/classifier/105/mistranslation/1435101 new file mode 100644 index 000000000..3475be11c --- /dev/null +++ b/results/classifier/105/mistranslation/1435101 @@ -0,0 +1,23 @@ +mistranslation: 0.868 +graphic: 0.857 +device: 0.814 +boot: 0.810 +other: 0.728 +instruction: 0.649 +semantic: 0.560 +vnc: 0.495 +socket: 0.439 +network: 0.181 +assembly: 0.164 +KVM: 0.014 + +Windows, QEMU 2.2.50 fails to boot XP CD + +Running XP Pro SP3 host 32bit. When I launch qemu booting from CD, it fails to complete load, getting stuck at "Setup is starting Windows". It does not proceed past. I tried to disable floppy but still no go. Download older version 1.5.1-win32, 0.9.1, same problem. +qemu-system-i386w.exe -cdrom "d:\XP.ISO" -hda d:\xp.img -boot d +with -global isa-fdc.driveA=c or -no-fd-bootchk switches but no go. I see others have run into this problem as well but no real solutions. Some folks says turning off floppy works and I tried. + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1437811 b/results/classifier/105/mistranslation/1437811 new file mode 100644 index 000000000..ef07bd225 --- /dev/null +++ b/results/classifier/105/mistranslation/1437811 @@ -0,0 +1,24 @@ +mistranslation: 0.834 +instruction: 0.819 +graphic: 0.729 +device: 0.712 +socket: 0.694 +network: 0.511 +vnc: 0.348 +semantic: 0.330 +boot: 0.301 +assembly: 0.274 +KVM: 0.144 +other: 0.134 + +target-tricore/op_helper.c:2576: bad if statement + +[qemu/target-tricore/op_helper.c:2576]: (style) Expression '(X & 0x400000) == 0x1' is always false. + + if ((env->PCXI & MASK_PCXI_UL) == 1) { + /* CTYP trap */ + } + +This problem has been fixed here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=7b4b0b5795e934a9b7efb + diff --git a/results/classifier/105/mistranslation/1438144 b/results/classifier/105/mistranslation/1438144 new file mode 100644 index 000000000..b8a6d63b0 --- /dev/null +++ b/results/classifier/105/mistranslation/1438144 @@ -0,0 +1,30 @@ +mistranslation: 0.884 +device: 0.760 +semantic: 0.744 +instruction: 0.654 +network: 0.649 +graphic: 0.623 +other: 0.565 +socket: 0.557 +vnc: 0.471 +boot: 0.351 +assembly: 0.251 +KVM: 0.220 + +Page sizes are not interpreted correctly for E500/E500MC + +http://cache.freescale.com/files/32bit/doc/ref_manual/E500CORERM.pdf - see 2.12.5.2 MAS Register 1 (MAS1), p. 2-41 +http://cache.freescale.com/files/32bit/doc/ref_manual/E500MCRM.pdf - see 2.16.6.2 MAS Register 1 (MAS1), p. 2-54 + +According to these documents, variable page size for TLB1 is computed as 4K ** TSIZE. + +However, QEMU always treats it as if it was 1K << TSIZE, even if options like "-cpu e500mc" are supplied to qemu. + +This is not a bug. MMU v2 (implemented in e6500) extended the TSIZE field so that 1K << +TSIZE is correct. The extension was on the LSB side so that it works +fine as long as the low bit of the new TSIZE (which is reserved on +e500v2/mc) is zero. + + +You're absolutely right. Sorry for bothering. + diff --git a/results/classifier/105/mistranslation/1449 b/results/classifier/105/mistranslation/1449 new file mode 100644 index 000000000..244063f1c --- /dev/null +++ b/results/classifier/105/mistranslation/1449 @@ -0,0 +1,18 @@ +mistranslation: 0.941 +device: 0.715 +instruction: 0.660 +other: 0.583 +graphic: 0.491 +socket: 0.454 +network: 0.426 +semantic: 0.348 +boot: 0.310 +vnc: 0.290 +assembly: 0.125 +KVM: 0.094 + +RISCV: wrong check for vector extension ELEN value. +Description of problem: +When checking if the vector extension ELEN value is in the range [8, 64], the lower bound check uses the `vlen` field instead of the `elen` one: https://gitlab.com/qemu-project/qemu/-/blob/master/target/riscv/cpu.c#L885. +Additional information: +This is basically just a typo I found while reading the code, I do not have a real case scenario which resulted in this check to fail. diff --git a/results/classifier/105/mistranslation/1449687 b/results/classifier/105/mistranslation/1449687 new file mode 100644 index 000000000..f457d46f6 --- /dev/null +++ b/results/classifier/105/mistranslation/1449687 @@ -0,0 +1,115 @@ +mistranslation: 0.687 +semantic: 0.686 +other: 0.661 +instruction: 0.652 +assembly: 0.636 +KVM: 0.599 +boot: 0.569 +network: 0.565 +vnc: 0.558 +graphic: 0.537 +device: 0.510 +socket: 0.390 + +block migration of qcow2 VMs copies all empty space + +I'm running openstack 2012.1 'icehouse' which, ultimately, calls down into qemu-system-x86 2.0.0+dfsg-2ubuntu1.10. + +I primed the process by copying all necessary base images onto the destination host. Nonetheless, post-migration instances are much larger than the original image; the copy duplicated all the empty space that ought to have remained copy-on-write. + +It looks like there was some attempt to address this issue in the past (e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1058173 ) but perhaps I'm conflating two different issues. + +Did you paste the wrong Red Hat bugzilla link? +https://bugzilla.redhat.com/show_bug.cgi?id=1058173 + +I don't see how this BZ is related to expanded disk image files after migration. + +You're right, clearly that was a c/p fail. I can't for the life of me find the bug that I was trying to refer to :( + +I found a relevant Fedora bug here: +https://bugzilla.redhat.com/show_bug.cgi?id=817700 + +There is a patch available: https://lists.gnu.org/archive/html/qemu-devel/2016-11/msg03742.html (and those which are mentioned in the responses) + +This patch does not help us. When migrating, the same drives become thick ... + +[Expired for QEMU because there has been no activity for 60 days.] + +On the source : + +# qemu-img info VM.img +image: VM.img +file format: raw +virtual size: 20G (21474836480 bytes) +disk size: 3.4G + +On the target: + +# qemu-img info VM.img +image: VM.img +file format: raw +virtual size: 20G (21474836480 bytes) +disk size: 20G + + +I also tried with qcow2 format but it's the same bug. + +All kvm migration drop sparse disk image ! + +How can we resolve this ? +Does a workaround exist ? + +https://bugzilla.redhat.com/show_bug.cgi?id=1219541 +https://bugzilla.redhat.com/show_bug.cgi?id=1248996 +https://bugzilla.redhat.com/show_bug.cgi?id=1090093 +https://bugzilla.redhat.com/show_bug.cgi?id=817700 + +I forgot to inform my test envrionement : + +Ubuntu Xenial +qemu-kvm version 2.5 +libvirt-bin version 1.3.1 + +Can you please reproduce bugs with the latest version of QEMU, i.e. currently v2.11 ? Old versions like 2.5 are not supported by the upstream QEMU project anymore, and bugs from such old versions might have been fixed already. (Otherwise, if you're only interested in the Ubuntu binary, please open a bug against the Ubuntu QEMU package instead) + +Well, if you had a closer look at the BZs that you've quoted, especially BZ 1219541, you should have seen that this problem apparently has been solved in upstream QEMU version 2.9 or 2.10. So it's really just about the backlevel version 2.5 that you're using. I'm re-assigning this ticket to the Ubuntu package, maybe they can fix it for you. + +Status changed to 'Confirmed' because the bug affects multiple users. + +I tried with qemu 2.10 and libvirt 3.6.0: not bug, it works. + +I tried with raw and qcow2 format, both works. + +I used this repository: https://launchpad.net/~ubuntu-cloud-archive/+archive/ubuntu/pike-staging + +But it's a staging version, i didn't find a stable qemu/libvirt repository for Ubuntu Xenial with those versions + +Maybe i can use this repository : + +http://ubuntu-cloud.archive.canonical.com/ubuntu/dists/xenial-updates + +Just want to throw a comment on here too. We are also effected by this. We are in the process of switching to KVM and lose thin/sparse disks on live migration. Unfortunately we need this to work. + +We are using: +* Ubuntu Xenial +* qemu-kvm version 2.5 +* libvirt-bin version 1.3.1 +* Using local storage + +I've tried qcow2 and raw formats with files and even a thin LVM pool. We have had the same outcome every time. + +virsh migrate --live --persistent --undefinesource --copy-storage-all (and --copy-storage-inc) fails to keep the sparse file. + +I've had no luck using rsync or tar to pre-copy the disks either. + +Building libvirt (v3.10.0) and qemu (v12.11) from source solved the issue but is not practical for us to do this in our environment. Using the repository above that Anthony mentioned is a temporary fix in my opinion, it's using libvirt v3.6.0 and qemu v12.10.1 and also solves the migration bug. Ubuntu should release a patch for Xenial. It appears Bionic will include the working versions. + +Please backport qemu 2.10+ and libvirt 3.6+. Having issues with migration of thin provisioned disks without shared storage. Tried qcow/raw/lvm thin all with the same results. Can confirm that the versions from https://launchpad.net/~ubuntu-cloud-archive/+archive/ubuntu/pike-staging do fix the issues at least with qcow disks. + +The new versions are made available via the cloud-archive already on a regular base. +We backport isolated fixed that have a low regression risk for other users, but not sull versions per the SRU Policy (https://wiki.ubuntu.com/StableReleaseUpdates). + +Since it seems it was identified that the version in Bionic is good, but the new feature is huge and unlikely to be backported I'll set the tasks up that way. + +I consider it unlikely, but if there is a minor set of commits assocuated that might be backportable please speak up and set the Xenial task back to new when providing the commits needed. + diff --git a/results/classifier/105/mistranslation/1453 b/results/classifier/105/mistranslation/1453 new file mode 100644 index 000000000..a650e9db7 --- /dev/null +++ b/results/classifier/105/mistranslation/1453 @@ -0,0 +1,14 @@ +mistranslation: 0.731 +semantic: 0.580 +other: 0.547 +graphic: 0.371 +device: 0.140 +instruction: 0.126 +boot: 0.085 +KVM: 0.057 +network: 0.024 +assembly: 0.017 +vnc: 0.013 +socket: 0.010 + +Tricore: different definitions of pcxi register field diff --git a/results/classifier/105/mistranslation/146 b/results/classifier/105/mistranslation/146 new file mode 100644 index 000000000..a633daddd --- /dev/null +++ b/results/classifier/105/mistranslation/146 @@ -0,0 +1,14 @@ +mistranslation: 0.992 +device: 0.888 +semantic: 0.874 +graphic: 0.528 +network: 0.451 +boot: 0.314 +other: 0.285 +instruction: 0.231 +vnc: 0.226 +socket: 0.192 +assembly: 0.035 +KVM: 0.027 + +macOS Guest Reading USB 3.0 Bus as USB 2.0 diff --git a/results/classifier/105/mistranslation/1461 b/results/classifier/105/mistranslation/1461 new file mode 100644 index 000000000..698d38ea1 --- /dev/null +++ b/results/classifier/105/mistranslation/1461 @@ -0,0 +1,14 @@ +mistranslation: 0.878 +graphic: 0.787 +device: 0.713 +semantic: 0.647 +assembly: 0.366 +other: 0.355 +instruction: 0.240 +vnc: 0.236 +network: 0.205 +boot: 0.139 +KVM: 0.014 +socket: 0.013 + +Virgl on Upstream windows builds? diff --git a/results/classifier/105/mistranslation/1469924 b/results/classifier/105/mistranslation/1469924 new file mode 100644 index 000000000..45493c7f8 --- /dev/null +++ b/results/classifier/105/mistranslation/1469924 @@ -0,0 +1,68 @@ +mistranslation: 0.775 +other: 0.768 +device: 0.649 +KVM: 0.649 +vnc: 0.615 +boot: 0.609 +network: 0.595 +instruction: 0.574 +graphic: 0.557 +semantic: 0.528 +assembly: 0.517 +socket: 0.497 + +qemu-kvm crash when guest os is booting + +this is the command line of qemu. + + +2015-06-30 01:52:59.508+0000: starting up +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=none /usr/bin/qemu-kvm -name rhel7 -S -machine pc-i440fx-2.1,accel=kvm,usb=off -cpu SandyBridge -m 2048 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 2a3f1d8a-850d-4e37-aecd-65cbf1e4e415 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/rhel7.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot menu=on,strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device lsi,id=scsi0,bus=pci.0,addr=0x6 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 -drive file=/var/lib/libvirt/images/rhel7.qcow2,if=none,id=drive-ide0-0-0,format=qcow2 -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -drive file=/home/jemmy/Downloads/rhel-server-7.1-x86_64-dvd.iso,if=none,id=drive-ide0-0-1,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1,bootindex=2 -netdev tap,fd=23,id=hostnet0,vhost=on,vhostfd=24 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:b4:7b:bb,bus=pci.0,addr=0x8 -chardev socket,id=charserial0,host=127.0.0.1,port=4555,telnet,server,nowait -device isa-serial,chardev=charserial0,id=serial0 -chardev file,id=charserial1,path=/tmp/log.txt -device isa-serial,chardev=charserial1,id=serial1 -chardev pty,id=charconsole0 -device virtconsole,chardev=charconsole0,id=console0 -vnc 127.0.0.1:0 -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -msg timestamp=on +char device redirected to /dev/pts/2 (label charconsole0) + + +this is the error log of qemu when crash. + +id 0, group 0, virt start 0, virt end ffffffffffffffff, generation 0, delta 0 +id 1, group 1, virt start 7fbe20000000, virt end 7fbe23ffe000, generation 0, delta 7fbe20000000 +id 2, group 1, virt start 7fbe1c000000, virt end 7fbe20000000, generation 0, delta 7fbe1c000000 +((null):16237): Spice-CRITICAL **: red_memslots.c:69:validate_virt: virtual address out of range + virt=0x0+0x18 slot_id=0 group_id=1 + slot=0x0-0x0 delta=0x0 +Thread 4 (Thread 0x7fbeb3a32700 (LWP 16278)): +#0 0x00007fbec182d407 in ioctl () at /lib64/libc.so.6 +#1 0x00007fbecc80e565 in kvm_vcpu_ioctl () +#2 0x00007fbecc80e61c in kvm_cpu_exec () +#3 0x00007fbecc7fd0a2 in qemu_kvm_cpu_thread_fn () +#4 0x00007fbecb2f652a in start_thread () at /lib64/libpthread.so.0 +#5 0x00007fbec183722d in clone () at /lib64/libc.so.6 +Thread 3 (Thread 0x7fbeb15ff700 (LWP 16287)): +#0 0x00007fbecb2fe1cd in read () at /lib64/libpthread.so.0 +#1 0x00007fbec2a50499 in spice_backtrace_gstack () at /lib64/libspice-server.so.1 +#2 0x00007fbec2a57dae in spice_logv () at /lib64/libspice-server.so.1 +#3 0x00007fbec2a57f05 in spice_log () at /lib64/libspice-server.so.1 +#4 0x00007fbec2a177ff in validate_virt () at /lib64/libspice-server.so.1 +#5 0x00007fbec2a1791e in get_virt () at /lib64/libspice-server.so.1 +#6 0x00007fbec2a17fb9 in red_get_clip_rects () at /lib64/libspice-server.so.1 +#7 0x00007fbec2a1976f in red_get_drawable () at /lib64/libspice-server.so.1 +#8 0x00007fbec2a30332 in red_process_commands.constprop () at /lib64/libspice-server.so.1 +#9 0x00007fbec2a3638a in red_worker_main () at /lib64/libspice-server.so.1 +#10 0x00007fbecb2f652a in start_thread () at /lib64/libpthread.so.0 +#11 0x00007fbec183722d in clone () at /lib64/libc.so.6 +Thread 2 (Thread 0x7fbeb0bff700 (LWP 16289)): +#0 0x00007fbecb2fb590 in pthread_cond_wait@@GLIBC_2.3.2 () at /lib64/libpthread.so.0 +#1 0x00007fbecca954c9 in qemu_cond_wait () +#2 0x00007fbecca3bfe3 in vnc_worker_thread_loop () +#3 0x00007fbecca3c3c8 in vnc_worker_thread () +#4 0x00007fbecb2f652a in start_thread () at /lib64/libpthread.so.0 +#5 0x00007fbec183722d in clone () at /lib64/libc.so.6 +Thread 1 (Thread 0x7fbeccd2ca80 (LWP 16237)): +#0 0x00007fbec182bd51 in ppoll () at /lib64/libc.so.6 +#1 0x00007fbecca4d2ec in qemu_poll_ns () +#2 0x00007fbecca4ca94 in main_loop_wait () +#3 0x00007fbecc7d58dd in main () + +Which version of QEMU are you using? Does the problem still occur with the latest version of QEMU? What kind of guest and host OS are you using? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1470536 b/results/classifier/105/mistranslation/1470536 new file mode 100644 index 000000000..20d61d746 --- /dev/null +++ b/results/classifier/105/mistranslation/1470536 @@ -0,0 +1,32 @@ +mistranslation: 0.813 +graphic: 0.768 +device: 0.725 +instruction: 0.594 +semantic: 0.592 +network: 0.566 +socket: 0.441 +vnc: 0.396 +boot: 0.280 +other: 0.116 +KVM: 0.106 +assembly: 0.083 + +qemu-img incorrectly prints "qemu-img: Host floppy pass-through is deprecated" + +qemu-img incorrectly prints this warning when you use /dev/fd/<NN> to pass in file descriptors. A simple way to demonstrate this uses bash process substitution, so the following will only work if you are using bash as your shell: + +$ qemu-img info <( cat /dev/null ) +qemu-img: Host floppy pass-through is deprecated +Support for it will be removed in a future release. +qemu-img: Could not open '/dev/fd/63': Could not refresh total sector count: Illegal seek + +The root cause is a bug in block/raw-posix.c:floppy_probe_device() where it thinks anything starting with /dev/fd is a floppy drive, which is not the case here: + +http://git.qemu.org/?p=qemu.git;a=blob;f=block/raw-posix.c;h=cbe6574bf4da90a124436a40422dce3667da71e6;hb=HEAD#l2425 + +I sent a patch to qemu-devel which should fix this. + +Patch has been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=25d9747b6427de825322 +... so I am assuming it's OK to close this ticket now. + diff --git a/results/classifier/105/mistranslation/1473451 b/results/classifier/105/mistranslation/1473451 new file mode 100644 index 000000000..cb779baf5 --- /dev/null +++ b/results/classifier/105/mistranslation/1473451 @@ -0,0 +1,32 @@ +mistranslation: 0.906 +semantic: 0.764 +other: 0.750 +graphic: 0.692 +device: 0.682 +network: 0.584 +instruction: 0.577 +vnc: 0.463 +boot: 0.433 +socket: 0.394 +assembly: 0.300 +KVM: 0.199 + +Please support the native bios format for dec alpha + +Currently qemu-system-alpha -bios parameter takes an ELF image. +However HP maintains firmware updates for those systems. + +Some example rom files can be found here ftp://ftp.hp.com/pub/alphaserver/firmware/current_platforms/v7.3_release/DS20_DS20e/ + +It might allow things like using the SRM firmware. +The ARC(nt) firmware would allow to build and test windows applications for that platforms without having the relevant hardware + +QEMU does not really implement a "true" ev67. + +We cheat and implement something that is significantly faster to emulate. +E.g. doing all TLB refill within qemu, rather than in the PALcode. + +So, no, there's no chance of running true SRM or ARC firmware. + +But In that case it’s impossible to emulate or even compile Windows for Dec Alpha. + diff --git a/results/classifier/105/mistranslation/1479 b/results/classifier/105/mistranslation/1479 new file mode 100644 index 000000000..5ca87e550 --- /dev/null +++ b/results/classifier/105/mistranslation/1479 @@ -0,0 +1,14 @@ +mistranslation: 0.998 +graphic: 0.627 +other: 0.498 +device: 0.456 +network: 0.274 +boot: 0.217 +KVM: 0.204 +vnc: 0.187 +socket: 0.149 +semantic: 0.091 +assembly: 0.081 +instruction: 0.028 + +system/arm/cpu-features.html : text describing options is misrendered diff --git a/results/classifier/105/mistranslation/1480 b/results/classifier/105/mistranslation/1480 new file mode 100644 index 000000000..ba02b10ff --- /dev/null +++ b/results/classifier/105/mistranslation/1480 @@ -0,0 +1,14 @@ +mistranslation: 0.586 +semantic: 0.509 +graphic: 0.409 +instruction: 0.126 +KVM: 0.110 +other: 0.108 +boot: 0.101 +assembly: 0.050 +vnc: 0.045 +socket: 0.015 +device: 0.015 +network: 0.004 + +-cpu <whatever>,help should print the options available for that CPU type diff --git a/results/classifier/105/mistranslation/1483070 b/results/classifier/105/mistranslation/1483070 new file mode 100644 index 000000000..8134ccbbb --- /dev/null +++ b/results/classifier/105/mistranslation/1483070 @@ -0,0 +1,177 @@ +mistranslation: 0.909 +assembly: 0.865 +vnc: 0.829 +instruction: 0.828 +graphic: 0.820 +other: 0.805 +device: 0.782 +KVM: 0.781 +semantic: 0.761 +boot: 0.745 +network: 0.592 +socket: 0.569 + +VIRTIO Sequential Write IOPS limits not working + +Root Problem: +IOPS limit does not work for VIRTIO devices if the disk workload is a sequential write. + +To confirm: +IDE disk devices - the IOPS limit works fine. Disk transfer speed limit works fine. +VIRTIO disk devices - the IOPS limit works fine for random IO (write/read) and sequential read, but not for sequential write. Disk transfer speed limits work fine. + +Tested on Windows 7,10 and 2k12 (Fedora drivers used and here is the twist): +virtio-win-0.1.96 (stable) or older won't limit write IO if workload is sequential. +virtio-win-0.1.105 (latest) or newer will limit but I have had two test machines crash when under high workload using IOPS limit. + +For Linux: +The issue is also apparent, tested on Ubuntu 14.04 + +On the hypervisor (using KVM) machine I have tried with Qemu 2.1.2 (3.16.0-4-amd64 - Debian 8) and Qemu 2.3.0 (3.19.8-1-pve - Proxmox 3.4 and 4) using multiple machines but all are 64bit intel. + +Even though the latest VIRTIO guest drivers fix the problem, the guest drivers shouldn't be able to ignore the limits the host puts in place or am I missing something?? + +On Mon, Aug 10, 2015 at 12:15:25AM -0000, James Watson wrote: +> IOPS limit does not work for VIRTIO devices if the disk workload is a sequential write. +> +> To confirm: +> IDE disk devices - the IOPS limit works fine. Disk transfer speed limit works fine. +> VIRTIO disk devices - the IOPS limit works fine for random IO (write/read) and sequential read, but not for sequential write. Disk transfer speed limits work fine. +> +> Tested on Windows 7,10 and 2k12 (Fedora drivers used and here is the twist): +> virtio-win-0.1.96 (stable) or older won't limit write IO if workload is sequential. +> virtio-win-0.1.105 (latest) or newer will limit but I have had two test machines crash when under high workload using IOPS limit. +> +> For Linux: +> The issue is also apparent, tested on Ubuntu 14.04 +> +> On the hypervisor (using KVM) machine I have tried with Qemu 2.1.2 +> (3.16.0-4-amd64 - Debian 8) and Qemu 2.3.0 (3.19.8-1-pve - Proxmox 3.4 +> and 4) using multiple machines but all are 64bit intel. +> +> Even though the latest VIRTIO guest drivers fix the problem, the guest +> drivers shouldn't be able to ignore the limits the host puts in place or +> am I missing something?? + +This is probably due to I/O request merging: + +Your benchmark application may generate 32 x 4KB write requests, but +they are merged by the virtio-blk device into just 1 x 128KB write +request. + +The merging can happen inside the guest, depending on your benchmark +application and the guest kernel's I/O stack. It also happens in QEMU's +virtio-blk emulation. + +The most recent versions of QEMU merge both read and write requests. +Older versions only merged write requests. + +It would be more intuitive for request merging to happen after QEMU I/O +throttling checks. Currently QEMU's I/O queue plug/unplug isn't +advanced enough to do the request merging, so it's done earlier in the +virtio-blk emulation code. + +I've CCed Kevin Wolf, Alberto Garcia, and Peter Lieven who may have more +thoughts on this. + + + +Am 10.08.2015 um 11:59 schrieb Stefan Hajnoczi <email address hidden>: + +> On Mon, Aug 10, 2015 at 12:15:25AM -0000, James Watson wrote: +>> IOPS limit does not work for VIRTIO devices if the disk workload is a sequential write. +>> +>> To confirm: +>> IDE disk devices - the IOPS limit works fine. Disk transfer speed limit works fine. +>> VIRTIO disk devices - the IOPS limit works fine for random IO (write/read) and sequential read, but not for sequential write. Disk transfer speed limits work fine. +>> +>> Tested on Windows 7,10 and 2k12 (Fedora drivers used and here is the twist): +>> virtio-win-0.1.96 (stable) or older won't limit write IO if workload is sequential. +>> virtio-win-0.1.105 (latest) or newer will limit but I have had two test machines crash when under high workload using IOPS limit. +>> +>> For Linux: +>> The issue is also apparent, tested on Ubuntu 14.04 +>> +>> On the hypervisor (using KVM) machine I have tried with Qemu 2.1.2 +>> (3.16.0-4-amd64 - Debian 8) and Qemu 2.3.0 (3.19.8-1-pve - Proxmox 3.4 +>> and 4) using multiple machines but all are 64bit intel. +>> +>> Even though the latest VIRTIO guest drivers fix the problem, the guest +>> drivers shouldn't be able to ignore the limits the host puts in place or +>> am I missing something?? +> +> This is probably due to I/O request merging: +> +> Your benchmark application may generate 32 x 4KB write requests, but +> they are merged by the virtio-blk device into just 1 x 128KB write +> request. +> +> The merging can happen inside the guest, depending on your benchmark +> application and the guest kernel's I/O stack. It also happens in QEMU's +> virtio-blk emulation. +> +> The most recent versions of QEMU merge both read and write requests. +> Older versions only merged write requests. +> +> It would be more intuitive for request merging to happen after QEMU I/O +> throttling checks. Currently QEMU's I/O queue plug/unplug isn't +> advanced enough to do the request merging, so it's done earlier in the +> virtio-blk emulation code. +> +> I've CCed Kevin Wolf, Alberto Garcia, and Peter Lieven who may have more +> thoughts on this. + +I wouldn't consider this behavior bad. Instead of virtio-blk merging the request +the guest could have issued big IOPS right from the beginning. If you are +concerned that big I/O is harming your storage, you can define a maximum +iops_size for throttling or limit the maximum bandwidth. + +Peter + + + + +On Fri 14 Aug 2015 01:34:50 AM CEST, Peter Lieven <email address hidden> wrote: + +>>> IOPS limit does not work for VIRTIO devices if the disk workload is +>>> a sequential write. + +>> This is probably due to I/O request merging: +>> +>> Your benchmark application may generate 32 x 4KB write requests, but +>> they are merged by the virtio-blk device into just 1 x 128KB write +>> request. +>> +>> The merging can happen inside the guest, depending on your benchmark +>> application and the guest kernel's I/O stack. It also happens in +>> QEMU's virtio-blk emulation. +>> +>> The most recent versions of QEMU merge both read and write requests. +>> Older versions only merged write requests. +>> +>> It would be more intuitive for request merging to happen after QEMU +>> I/O throttling checks. Currently QEMU's I/O queue plug/unplug isn't +>> advanced enough to do the request merging, so it's done earlier in +>> the virtio-blk emulation code. + +Alternatively we could keep the original number of requests and pass it +to throttle_account(), but I'm not sure if it's a good idea. + +> I wouldn't consider this behavior bad. Instead of virtio-blk merging +> the request the guest could have issued big IOPS right from the +> beginning. If you are concerned that big I/O is harming your storage, +> you can define a maximum iops_size for throttling or limit the maximum +> bandwidth. + +That's right. The way throttling.iops-size works is that I/O requests +larger than this are accounted as if they were split into smaller +operations. So, if iops-size is 32KB, a 128KB request will be counted as +4 for the purpose of limiting the number of IOPS. + +Berto + + +Has this issue ever been fixed? If not, is there still interest in fixing it? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/14887122 b/results/classifier/105/mistranslation/14887122 new file mode 100644 index 000000000..1a87937b0 --- /dev/null +++ b/results/classifier/105/mistranslation/14887122 @@ -0,0 +1,266 @@ +mistranslation: 0.930 +semantic: 0.928 +device: 0.919 +assembly: 0.918 +socket: 0.914 +graphic: 0.910 +instruction: 0.905 +other: 0.890 +vnc: 0.871 +network: 0.855 +boot: 0.831 +KVM: 0.814 + +[BUG][RFC] CPR transfer Issues: Socket permissions and PID files + +Hello, + +While testing CPR transfer I encountered two issues. The first is that the +transfer fails when running with pidfiles due to the destination qemu process +attempting to create the pidfile while it is still locked by the source +process. The second is that the transfer fails when running with the -run-with +user=$USERID parameter. This is because the destination qemu process creates +the UNIX sockets used for the CPR transfer before dropping to the lower +permissioned user, which causes them to be owned by the original user. The +source qemu process then does not have permission to connect to it because it +is already running as the lesser permissioned user. + +Reproducing the first issue: + +Create a source and destination qemu instance associated with the same VM where +both processes have the -pidfile parameter passed on the command line. You +should see the following error on the command line of the second process: + +qemu-system-x86_64: cannot create PID file: Cannot lock pid file: Resource +temporarily unavailable + +Reproducing the second issue: + +Create a source and destination qemu instance associated with the same VM where +both processes have -run-with user=$USERID passed on the command line, where +$USERID is a different user from the one launching the processes. Then attempt +a CPR transfer using UNIX sockets for the main and cpr sockets. You should +receive the following error via QMP: +{"error": {"class": "GenericError", "desc": "Failed to connect to 'cpr.sock': +Permission denied"}} + +I provided a minimal patch that works around the second issue. + +Thank you, +Ben Chaney + +--- +include/system/os-posix.h | 4 ++++ +os-posix.c | 8 -------- +util/qemu-sockets.c | 21 +++++++++++++++++++++ +3 files changed, 25 insertions(+), 8 deletions(-) + +diff --git a/include/system/os-posix.h b/include/system/os-posix.h +index ce5b3bccf8..2a414a914a 100644 +--- a/include/system/os-posix.h ++++ b/include/system/os-posix.h +@@ -55,6 +55,10 @@ void os_setup_limits(void); +void os_setup_post(void); +int os_mlock(bool on_fault); + ++extern struct passwd *user_pwd; ++extern uid_t user_uid; ++extern gid_t user_gid; ++ +/** +* qemu_alloc_stack: +* @sz: pointer to a size_t holding the requested usable stack size +diff --git a/os-posix.c b/os-posix.c +index 52925c23d3..9369b312a0 100644 +--- a/os-posix.c ++++ b/os-posix.c +@@ -86,14 +86,6 @@ void os_set_proc_name(const char *s) +} + + +-/* +- * Must set all three of these at once. +- * Legal combinations are unset by name by uid +- */ +-static struct passwd *user_pwd; /* NULL non-NULL NULL */ +-static uid_t user_uid = (uid_t)-1; /* -1 -1 >=0 */ +-static gid_t user_gid = (gid_t)-1; /* -1 -1 >=0 */ +- +/* +* Prepare to change user ID. user_id can be one of 3 forms: +* - a username, in which case user ID will be changed to its uid, +diff --git a/util/qemu-sockets.c b/util/qemu-sockets.c +index 77477c1cd5..987977ead9 100644 +--- a/util/qemu-sockets.c ++++ b/util/qemu-sockets.c +@@ -871,6 +871,14 @@ static bool saddr_is_tight(UnixSocketAddress *saddr) +#endif +} + ++/* ++ * Must set all three of these at once. ++ * Legal combinations are unset by name by uid ++ */ ++struct passwd *user_pwd; /* NULL non-NULL NULL */ ++uid_t user_uid = (uid_t)-1; /* -1 -1 >=0 */ ++gid_t user_gid = (gid_t)-1; /* -1 -1 >=0 */ ++ +static int unix_listen_saddr(UnixSocketAddress *saddr, +int num, +Error **errp) +@@ -947,6 +955,19 @@ static int unix_listen_saddr(UnixSocketAddress *saddr, +error_setg_errno(errp, errno, "Failed to bind socket to %s", path); +goto err; +} ++ if (user_pwd) { ++ if (chown(un.sun_path, user_pwd->pw_uid, user_pwd->pw_gid) < 0) { ++ error_setg_errno(errp, errno, "Failed to change permissions on socket %s", +path); ++ goto err; ++ } ++ } ++ else if (user_uid != -1 && user_gid != -1) { ++ if (chown(un.sun_path, user_uid, user_gid) < 0) { ++ error_setg_errno(errp, errno, "Failed to change permissions on socket %s", +path); ++ goto err; ++ } ++ } ++ +if (listen(sock, num) < 0) { +error_setg_errno(errp, errno, "Failed to listen on socket"); +goto err; +-- +2.40.1 + +Thank you Ben. I appreciate you testing CPR and shaking out the bugs. +I will study these and propose patches. + +My initial reaction to the pidfile issue is that the orchestration layer must +pass a different filename when starting the destination qemu instance. When +using live update without containers, these types of resource conflicts in the +global namespaces are a known issue. + +- Steve + +On 3/14/2025 2:33 PM, Chaney, Ben wrote: +Hello, + +While testing CPR transfer I encountered two issues. The first is that the +transfer fails when running with pidfiles due to the destination qemu process +attempting to create the pidfile while it is still locked by the source +process. The second is that the transfer fails when running with the -run-with +user=$USERID parameter. This is because the destination qemu process creates +the UNIX sockets used for the CPR transfer before dropping to the lower +permissioned user, which causes them to be owned by the original user. The +source qemu process then does not have permission to connect to it because it +is already running as the lesser permissioned user. + +Reproducing the first issue: + +Create a source and destination qemu instance associated with the same VM where +both processes have the -pidfile parameter passed on the command line. You +should see the following error on the command line of the second process: + +qemu-system-x86_64: cannot create PID file: Cannot lock pid file: Resource +temporarily unavailable + +Reproducing the second issue: + +Create a source and destination qemu instance associated with the same VM where +both processes have -run-with user=$USERID passed on the command line, where +$USERID is a different user from the one launching the processes. Then attempt +a CPR transfer using UNIX sockets for the main and cpr sockets. You should +receive the following error via QMP: +{"error": {"class": "GenericError", "desc": "Failed to connect to 'cpr.sock': +Permission denied"}} + +I provided a minimal patch that works around the second issue. + +Thank you, +Ben Chaney + +--- +include/system/os-posix.h | 4 ++++ +os-posix.c | 8 -------- +util/qemu-sockets.c | 21 +++++++++++++++++++++ +3 files changed, 25 insertions(+), 8 deletions(-) + +diff --git a/include/system/os-posix.h b/include/system/os-posix.h +index ce5b3bccf8..2a414a914a 100644 +--- a/include/system/os-posix.h ++++ b/include/system/os-posix.h +@@ -55,6 +55,10 @@ void os_setup_limits(void); +void os_setup_post(void); +int os_mlock(bool on_fault); + ++extern struct passwd *user_pwd; ++extern uid_t user_uid; ++extern gid_t user_gid; ++ +/** +* qemu_alloc_stack: +* @sz: pointer to a size_t holding the requested usable stack size +diff --git a/os-posix.c b/os-posix.c +index 52925c23d3..9369b312a0 100644 +--- a/os-posix.c ++++ b/os-posix.c +@@ -86,14 +86,6 @@ void os_set_proc_name(const char *s) +} + + +-/* +- * Must set all three of these at once. +- * Legal combinations are unset by name by uid +- */ +-static struct passwd *user_pwd; /* NULL non-NULL NULL */ +-static uid_t user_uid = (uid_t)-1; /* -1 -1 >=0 */ +-static gid_t user_gid = (gid_t)-1; /* -1 -1 >=0 */ +- +/* +* Prepare to change user ID. user_id can be one of 3 forms: +* - a username, in which case user ID will be changed to its uid, +diff --git a/util/qemu-sockets.c b/util/qemu-sockets.c +index 77477c1cd5..987977ead9 100644 +--- a/util/qemu-sockets.c ++++ b/util/qemu-sockets.c +@@ -871,6 +871,14 @@ static bool saddr_is_tight(UnixSocketAddress *saddr) +#endif +} + ++/* ++ * Must set all three of these at once. ++ * Legal combinations are unset by name by uid ++ */ ++struct passwd *user_pwd; /* NULL non-NULL NULL */ ++uid_t user_uid = (uid_t)-1; /* -1 -1 >=0 */ ++gid_t user_gid = (gid_t)-1; /* -1 -1 >=0 */ ++ +static int unix_listen_saddr(UnixSocketAddress *saddr, +int num, +Error **errp) +@@ -947,6 +955,19 @@ static int unix_listen_saddr(UnixSocketAddress *saddr, +error_setg_errno(errp, errno, "Failed to bind socket to %s", path); +goto err; +} ++ if (user_pwd) { ++ if (chown(un.sun_path, user_pwd->pw_uid, user_pwd->pw_gid) < 0) { ++ error_setg_errno(errp, errno, "Failed to change permissions on socket %s", +path); ++ goto err; ++ } ++ } ++ else if (user_uid != -1 && user_gid != -1) { ++ if (chown(un.sun_path, user_uid, user_gid) < 0) { ++ error_setg_errno(errp, errno, "Failed to change permissions on socket %s", +path); ++ goto err; ++ } ++ } ++ +if (listen(sock, num) < 0) { +error_setg_errno(errp, errno, "Failed to listen on socket"); +goto err; +-- +2.40.1 + diff --git a/results/classifier/105/mistranslation/1490 b/results/classifier/105/mistranslation/1490 new file mode 100644 index 000000000..879d8aa3c --- /dev/null +++ b/results/classifier/105/mistranslation/1490 @@ -0,0 +1,74 @@ +mistranslation: 0.895 +other: 0.882 +instruction: 0.839 +graphic: 0.824 +device: 0.809 +semantic: 0.799 +KVM: 0.789 +assembly: 0.778 +network: 0.761 +boot: 0.758 +socket: 0.757 +vnc: 0.673 + +Keystrokes for F13-24 are not forwarded by an evdev input device +Description of problem: +Currently, keystrokes for F13-F24 are not forwarded by an evdev input device. +Steps to reproduce: +``` +/usr/bin/qemu-system-x86_64 \ +-name guest=win10,debug-threads=on \ +-S \ +-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-11-win10/master-key.aes"}' \ +-machine pc-q35-7.2,usb=off,vmport=off,dump-guest-core=off,memory-backend=pc.ram \ +-accel kvm \ +-cpu host,migratable=on,hv-time=on,hv-relaxed=on,hv-vapic=on,hv-spinlocks=0x1fff \ +-m 4096 \ +-object '{"qom-type":"memory-backend-ram","id":"pc.ram","size":4294967296}' \ +-overcommit mem-lock=off \ +-smp 4,sockets=1,dies=1,cores=4,threads=1 \ +-uuid ca2e9d01-6e02-4aa7-9feb-7846499f7d8a \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=33,server=on,wait=off \ +-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 strict=on \ +-device '{"driver":"pcie-root-port","port":16,"chassis":1,"id":"pci.1","bus":"pcie.0","multifunction":true,"addr":"0x2"}' \ +-device '{"driver":"pcie-root-port","port":17,"chassis":2,"id":"pci.2","bus":"pcie.0","addr":"0x2.0x1"}' \ +-device '{"driver":"pcie-root-port","port":18,"chassis":3,"id":"pci.3","bus":"pcie.0","addr":"0x2.0x2"}' \ +-device '{"driver":"pcie-root-port","port":19,"chassis":4,"id":"pci.4","bus":"pcie.0","addr":"0x2.0x3"}' \ +-device '{"driver":"pcie-root-port","port":20,"chassis":5,"id":"pci.5","bus":"pcie.0","addr":"0x2.0x4"}' \ +-device '{"driver":"pcie-root-port","port":21,"chassis":6,"id":"pci.6","bus":"pcie.0","addr":"0x2.0x5"}' \ +-device '{"driver":"pcie-root-port","port":22,"chassis":7,"id":"pci.7","bus":"pcie.0","addr":"0x2.0x6"}' \ +-device '{"driver":"pcie-root-port","port":23,"chassis":8,"id":"pci.8","bus":"pcie.0","addr":"0x2.0x7"}' \ +-device '{"driver":"pcie-root-port","port":24,"chassis":9,"id":"pci.9","bus":"pcie.0","multifunction":true,"addr":"0x3"}' \ +-device '{"driver":"pcie-root-port","port":25,"chassis":10,"id":"pci.10","bus":"pcie.0","addr":"0x3.0x1"}' \ +-device '{"driver":"pcie-root-port","port":26,"chassis":11,"id":"pci.11","bus":"pcie.0","addr":"0x3.0x2"}' \ +-device '{"driver":"pcie-root-port","port":27,"chassis":12,"id":"pci.12","bus":"pcie.0","addr":"0x3.0x3"}' \ +-device '{"driver":"pcie-root-port","port":28,"chassis":13,"id":"pci.13","bus":"pcie.0","addr":"0x3.0x4"}' \ +-device '{"driver":"pcie-root-port","port":29,"chassis":14,"id":"pci.14","bus":"pcie.0","addr":"0x3.0x5"}' \ +-device '{"driver":"qemu-xhci","id":"usb","bus":"pci.1","addr":"0x0"}' \ +-blockdev '{"driver":"file","filename":"/tmp/win10.qcow2","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2","file":"libvirt-1-storage","backing":null}' \ +-device '{"driver":"ide-hd","bus":"ide.0","drive":"libvirt-1-format","id":"sata0-0-0","bootindex":2}' \ +-object '{"qom-type":"input-linux","id":"input2","evdev":"/dev/input/by-id/usb-04d9_f50e-event-mouse"}' \ +-object '{"qom-type":"input-linux","id":"input3","evdev":"/dev/input/by-id/usb-0c45_6515-event-kbd","repeat":true,"grab_all":true,"grab-toggle":"scrolllock"}' \ +-audiodev '{"id":"audio1","driver":"spice"}' \ +-spice port=5900,addr=127.0.0.1,disable-ticketing=on,image-compression=off,seamless-migration=on \ +-device '{"driver":"qxl-vga","id":"video0","max_outputs":1,"ram_size":67108864,"vram_size":67108864,"vram64_size_mb":0,"vgamem_mb":16,"bus":"pcie.0","addr":"0x1"}' \ +-device '{"driver":"virtio-balloon-pci","id":"balloon0","bus":"pci.2","addr":"0x0"}' \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on +``` + +This is probably not a minimal example, but I didn't know how to generate one. I think the only relevant lines are these: +``` +-object '{"qom-type":"input-linux","id":"input2","evdev":"/dev/input/by-id/usb-04d9_f50e-event-mouse"}' \ +-object '{"qom-type":"input-linux","id":"input3","evdev":"/dev/input/by-id/usb-0c45_6515-event-kbd","repeat":true,"grab_all":true,"grab-toggle":"scrolllock"}' +``` diff --git a/results/classifier/105/mistranslation/1500175 b/results/classifier/105/mistranslation/1500175 new file mode 100644 index 000000000..e04c64748 --- /dev/null +++ b/results/classifier/105/mistranslation/1500175 @@ -0,0 +1,137 @@ +mistranslation: 0.860 +semantic: 0.835 +other: 0.812 +graphic: 0.779 +instruction: 0.769 +device: 0.720 +assembly: 0.694 +boot: 0.678 +vnc: 0.628 +socket: 0.595 +network: 0.588 +KVM: 0.413 + +unable to init msix vectors + +Using the latest stable (2.4.0.1) and earlier releases (at least down to 2.3.1), I am unable to run a qemu-system-arm virtualization on a Mac OS X Yosemite machine. QEMU was compiled with --enable-sdl. + +Command line: + +qemu-system-arm -device virtio-net,netdev=user.0 -drive file=pack,if=virtio,cache=writeback,discard=ignore -netdev user,id=user.0,hostfwd=tcp::3499-:22 -cdrom /opt/node-4.1.0/packer/2015-05-05-raspbian-wheezy.img -m 512M -boot once=d -vnc 0.0.0.0:87 -name packer-qemu -machine type=versatilepb -nographic + +Output: + +qemu-system-arm: -device virtio-net,netdev=user.0: unable to init msix vectors to 3 +qemu-system-arm: -drive file=pack,if=virtio,cache=writeback,discard=ignore: unable to init msix vectors to 2 +qemu: fatal: Trying to execute code outside RAM or ROM at 0x10000000 + +R00=00000000 R01=00000000 R02=00000000 R03=00000000 +R04=00000000 R05=00000000 R06=00000000 R07=00000000 +R08=00000000 R09=00000000 R10=00000000 R11=00000000 +R12=00000000 R13=00000000 R14=00000000 R15=10000000 +PSR=400001d3 -Z-- A svc32 +s00=00000000 s01=00000000 d00=0000000000000000 +s02=00000000 s03=00000000 d01=0000000000000000 +s04=00000000 s05=00000000 d02=0000000000000000 +s06=00000000 s07=00000000 d03=0000000000000000 +s08=00000000 s09=00000000 d04=0000000000000000 +s10=00000000 s11=00000000 d05=0000000000000000 +s12=00000000 s13=00000000 d06=0000000000000000 +s14=00000000 s15=00000000 d07=0000000000000000 +s16=00000000 s17=00000000 d08=0000000000000000 +s18=00000000 s19=00000000 d09=0000000000000000 +s20=00000000 s21=00000000 d10=0000000000000000 +s22=00000000 s23=00000000 d11=0000000000000000 +s24=00000000 s25=00000000 d12=0000000000000000 +s26=00000000 s27=00000000 d13=0000000000000000 +s28=00000000 s29=00000000 d14=0000000000000000 +s30=00000000 s31=00000000 d15=0000000000000000 +FPSCR: 00000000 +[1] 1322 abort qemu-system-arm -device virtio-net,netdev=user.0 -drive -netdev -cdrom -m + +The "unable to init msix vectors" message is just a warning, and is harmless -- it is expected for the ARM boards. (There's a patch around that suppresses the incorrect warning but unfortunately it didn't get into 2.4.) + +Your actual problem is that you haven't specified either a guest kernel (via -kernel) or a firmware image (via a suitable flash drive command). This means that QEMU executes zeroes (which are nop instructions) from its start at address 0 all the way to the end of RAM and then stops because we can't execute out of device registers. (This is approximately what real hardware would do if you booted it with an uninitialized ROM.) + +I suggest you provide QEMU with a suitable kernel that will work on a versatile PB board. + + +Oh right, stupid mistake then! Never mind. Thanks for pointing this out. + +No problem -- QEMU is unfortunately not as clear as it perhaps could be about what happens in this situation. + +As a sidenote: may I ask why the given command does not work? The IMG should contain a kernel that should be bootable, so there should be no need to specify an extra kernel. + +None of QEMU's ARM boards automatically boot a bios image shipped with QEMU. You must provide one explicitly, or else use the 'built in bootloader" with -kernel. (I'm not aware of any rom image that would work on QEMU versatilepb and load a kernel off a disk image, so in practice -kernel is what you want.) + + +Got it, thanks! + +> Op 29-sep.-2015, om 03:51 heeft Peter Maydell <email address hidden> het volgende geschreven: +> +> None of QEMU's ARM boards automatically boot a bios image shipped with +> QEMU. You must provide one explicitly, or else use the 'built in +> bootloader" with -kernel. (I'm not aware of any rom image that would +> work on QEMU versatilepb and load a kernel off a disk image, so in +> practice -kernel is what you want.) +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1500175 +> +> Title: +> unable to init msix vectors +> +> Status in QEMU: +> Invalid +> +> Bug description: +> Using the latest stable (2.4.0.1) and earlier releases (at least down +> to 2.2.1), I am unable to run a qemu-system-arm virtualization on a +> Mac OS X Yosemite machine. QEMU was compiled with --enable-sdl. +> +> Command line: +> +> qemu-system-arm -device virtio-net,netdev=user.0 -drive +> file=pack,if=virtio,cache=writeback,discard=ignore -netdev +> user,id=user.0,hostfwd=tcp::3499-:22 -cdrom +> /opt/node-4.1.0/packer/2015-05-05-raspbian-wheezy.img -m 512M -boot +> once=d -vnc 0.0.0.0:87 -name packer-qemu -machine type=versatilepb +> -nographic +> +> Output: +> +> qemu-system-arm: -device virtio-net,netdev=user.0: unable to init msix vectors to 3 +> qemu-system-arm: -drive file=pack,if=virtio,cache=writeback,discard=ignore: unable to init msix vectors to 2 +> qemu: fatal: Trying to execute code outside RAM or ROM at 0x10000000 +> +> R00=00000000 R01=00000000 R02=00000000 R03=00000000 +> R04=00000000 R05=00000000 R06=00000000 R07=00000000 +> R08=00000000 R09=00000000 R10=00000000 R11=00000000 +> R12=00000000 R13=00000000 R14=00000000 R15=10000000 +> PSR=400001d3 -Z-- A svc32 +> s00=00000000 s01=00000000 d00=0000000000000000 +> s02=00000000 s03=00000000 d01=0000000000000000 +> s04=00000000 s05=00000000 d02=0000000000000000 +> s06=00000000 s07=00000000 d03=0000000000000000 +> s08=00000000 s09=00000000 d04=0000000000000000 +> s10=00000000 s11=00000000 d05=0000000000000000 +> s12=00000000 s13=00000000 d06=0000000000000000 +> s14=00000000 s15=00000000 d07=0000000000000000 +> s16=00000000 s17=00000000 d08=0000000000000000 +> s18=00000000 s19=00000000 d09=0000000000000000 +> s20=00000000 s21=00000000 d10=0000000000000000 +> s22=00000000 s23=00000000 d11=0000000000000000 +> s24=00000000 s25=00000000 d12=0000000000000000 +> s26=00000000 s27=00000000 d13=0000000000000000 +> s28=00000000 s29=00000000 d14=0000000000000000 +> s30=00000000 s31=00000000 d15=0000000000000000 +> FPSCR: 00000000 +> [1] 1322 abort qemu-system-arm -device virtio-net,netdev=user.0 -drive -netdev -cdrom -m +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1500175/+subscriptions + + + diff --git a/results/classifier/105/mistranslation/1512134 b/results/classifier/105/mistranslation/1512134 new file mode 100644 index 000000000..5280cf7a2 --- /dev/null +++ b/results/classifier/105/mistranslation/1512134 @@ -0,0 +1,55 @@ +mistranslation: 0.630 +device: 0.589 +graphic: 0.586 +other: 0.576 +semantic: 0.492 +instruction: 0.456 +boot: 0.432 +socket: 0.385 +network: 0.300 +vnc: 0.254 +assembly: 0.183 +KVM: 0.074 + +Multiboot v1 memory map offset wrong + +I'm developping a multiboot kernel for multiboot v1 +My multiboot header contains the V1 magic (0x1BADB002) and the flags 0x00010243 (with enabled memory detection, and boot loader name) + + +When booted in multiboot, +Qemu gives me two pointers: +unsigned long mmap_length; +unsigned long mmap_addr; + +mmap_addr shall points to this structure: +struct multiboot_mmap_entry +{ +multiboot_uint32_t size; +multiboot_uint64_t addr; +multiboot_uint64_t len; +multiboot_uint32_t type; +} + + +According to the multiboot v1 specification, mmap_addr should not point to the start of this structure, but instead, should point to the "addr "field. + +Work-arround: +Detect if qemu is used using bootloader_name field. +If it is, do NOT apply a -4 offset to mmap_addr + +http://git.savannah.gnu.org/cgit/grub.git/tree/doc/multiboot.texi?h=multiboot + +I forgot to tell how i detected the issue: +I print all the fields, and in "type", i had the size of the next entry (and in size, i have always zero, which corresponds to the high part of addr) + +Hi, + +Have you tested your code with GRUB (Legacy) itself? Looking at code from one of my own hobby kernels, and from a hobby kernel that has largely not been written by me, both are interpreting the fields as qemu is (i.e. mmap_addr points to a multiboot_mmap_entry, and not to multiboot_mmap_entry + 4), and I know both to work just fine with GRUB. + +I considered the -4 offset to signify that the size field simply does not count itself, i.e. the size of one multiboot_mmap_entry is $size + 4. + +Max + +Tested today with GRUB 2.0. Indeed, mmap_entry points to the start of the structure, without a fancy offset. I guess we can close this ticket + diff --git a/results/classifier/105/mistranslation/1513 b/results/classifier/105/mistranslation/1513 new file mode 100644 index 000000000..91560042f --- /dev/null +++ b/results/classifier/105/mistranslation/1513 @@ -0,0 +1,14 @@ +mistranslation: 0.376 +boot: 0.228 +graphic: 0.170 +vnc: 0.169 +device: 0.129 +semantic: 0.124 +KVM: 0.087 +instruction: 0.052 +other: 0.033 +socket: 0.011 +assembly: 0.006 +network: 0.005 + +CPU flags should be better documented diff --git a/results/classifier/105/mistranslation/152 b/results/classifier/105/mistranslation/152 new file mode 100644 index 000000000..4f0463d88 --- /dev/null +++ b/results/classifier/105/mistranslation/152 @@ -0,0 +1,14 @@ +mistranslation: 0.983 +graphic: 0.775 +other: 0.559 +semantic: 0.551 +device: 0.442 +network: 0.196 +instruction: 0.193 +socket: 0.147 +assembly: 0.105 +boot: 0.101 +vnc: 0.096 +KVM: 0.026 + +qemu-img compare -m option is missing diff --git a/results/classifier/105/mistranslation/1526 b/results/classifier/105/mistranslation/1526 new file mode 100644 index 000000000..5306f5201 --- /dev/null +++ b/results/classifier/105/mistranslation/1526 @@ -0,0 +1,14 @@ +mistranslation: 0.988 +other: 0.847 +device: 0.827 +network: 0.724 +vnc: 0.488 +socket: 0.451 +boot: 0.429 +semantic: 0.389 +graphic: 0.311 +instruction: 0.221 +KVM: 0.172 +assembly: 0.071 + +hw/vfio/trace-events incorrect format diff --git a/results/classifier/105/mistranslation/1527322 b/results/classifier/105/mistranslation/1527322 new file mode 100644 index 000000000..7af71fca5 --- /dev/null +++ b/results/classifier/105/mistranslation/1527322 @@ -0,0 +1,65 @@ +mistranslation: 0.778 +other: 0.710 +device: 0.681 +graphic: 0.679 +network: 0.645 +instruction: 0.589 +socket: 0.570 +KVM: 0.562 +semantic: 0.560 +boot: 0.560 +assembly: 0.506 +vnc: 0.500 + +segfault in thread-pool.c:246:5: + +Building qemu-2.5.0 with -fsanitize=undefined shows, e.g.: + +markus@x4 linux % qemu-system-x86_64 -s -enable-kvm -net nic,vlan=0,model=virtio -net user -fsdev local,security_model=none,id=root,path=/ -device virtio-9p-pci,id=root,fsdev +=root,mount_tag=/dev/root -m 512 -smp 2 -kernel /usr/src/linux/arch/x86/boot/bzImage -nographic -append "init=/bin/zsh root=/dev/root console=ttyS0 kgdboc=ttyS0 rootflags=rw, +trans=virtio rootfstype=9p ip=dhcp earlyprintk=ttyS0" +/var/tmp/portage/app-emulation/qemu-2.5.0/work/qemu-2.5.0/exec.c:307:5: runtime error: variable length array bound evaluates to non-positive value 0 +/var/tmp/portage/app-emulation/qemu-2.5.0/work/qemu-2.5.0/hw/i386/kvm/apic.c:37:47: runtime error: left shift of 15 by 28 places cannot be represented in type 'int' +/var/tmp/portage/app-emulation/qemu-2.5.0/work/qemu-2.5.0/include/qemu/rcu.h:85:21: runtime error: member access within null pointer of type 'struct rcu_reader_data' +/var/tmp/portage/app-emulation/qemu-2.5.0/work/qemu-2.5.0/include/qemu/rcu.h:101:5: runtime error: member access within null pointer of type 'struct rcu_reader_data' +/var/tmp/portage/app-emulation/qemu-2.5.0/work/qemu-2.5.0/include/qemu/rcu.h:102:8: runtime error: member access within null pointer of type 'struct rcu_reader_data' +... +ALSA device list: + No soundcards found. +/var/tmp/portage/app-emulation/qemu-2.5.0/work/qemu-2.5.0/thread-pool.c:246:5: runtime error: member access within null pointer of type 'struct ThreadPool' +[1] 9295 segmentation fault qemu-system-x86_64 -s -enable-kvm -net nic,vlan=0,model=virtio -net user + +As you can see it segfaults when build with upcoming gcc-6, that is more aggressive when it comes to undefined behavior. +The compiler just assumes that "this" can never be NULL and optimizes accordingly. + +It also segfaults when build with gcc-4.9.4 or gcc-5.3. + +Program received signal SIGSEGV, Segmentation fault. +thread_pool_submit_aio (pool=0x0, func=0x555555820bc0 <coroutine_enter_func>, arg=0x5555579db430, cb=<optimized out>, opaque=<optimized out>) + at /var/tmp/portage/app-emulation/qemu-2.5.0/work/qemu-2.5.0/thread-pool.c:246 +246 QLIST_INSERT_HEAD(&pool->head, req, all); +(gdb) bt +#0 thread_pool_submit_aio (pool=0x0, func=0x555555820bc0 <coroutine_enter_func>, arg=0x5555579db430, cb=<optimized out>, opaque=<optimized out>) + at /var/tmp/portage/app-emulation/qemu-2.5.0/work/qemu-2.5.0/thread-pool.c:246 +#1 0x00005555559451cd in aio_bh_call (bh=<optimized out>) at /var/tmp/portage/app-emulation/qemu-2.5.0/work/qemu-2.5.0/async.c:64 +#2 aio_bh_poll (ctx=ctx@entry=0x5555561c1da0) at /var/tmp/portage/app-emulation/qemu-2.5.0/work/qemu-2.5.0/async.c:92 +#3 0x00005555559524f0 in aio_dispatch (ctx=0x5555561c1da0) at /var/tmp/portage/app-emulation/qemu-2.5.0/work/qemu-2.5.0/aio-posix.c:305 +#4 0x0000555555944f4e in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) + at /var/tmp/portage/app-emulation/qemu-2.5.0/work/qemu-2.5.0/async.c:231 +#5 0x00007ffff726ce2e in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 +#6 0x0000555555950baa in glib_pollfds_poll () at /var/tmp/portage/app-emulation/qemu-2.5.0/work/qemu-2.5.0/main-loop.c:211 +#7 os_host_main_loop_wait (timeout=<optimized out>) at /var/tmp/portage/app-emulation/qemu-2.5.0/work/qemu-2.5.0/main-loop.c:256 +#8 main_loop_wait (nonblocking=<optimized out>) at /var/tmp/portage/app-emulation/qemu-2.5.0/work/qemu-2.5.0/main-loop.c:504 +#9 0x00005555556ddf46 in main_loop () at /var/tmp/portage/app-emulation/qemu-2.5.0/work/qemu-2.5.0/vl.c:1923 +#10 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at /var/tmp/portage/app-emulation/qemu-2.5.0/work/qemu-2.5.0/vl.c:4684 +(gdb) p pool +$1 = (ThreadPool *) 0x0 + + +This issue was fixed with the following upstream commit: + +http://git.qemu.org/?p=qemu.git;a=commit;h=4b3a4f2d458ca5a7c6c16ac36a8d9ac22cc253d6 + +Shipped in QEMU 2.5.1 and 2.6. + + diff --git a/results/classifier/105/mistranslation/1528214 b/results/classifier/105/mistranslation/1528214 new file mode 100644 index 000000000..4e0654d61 --- /dev/null +++ b/results/classifier/105/mistranslation/1528214 @@ -0,0 +1,58 @@ +mistranslation: 0.907 +semantic: 0.888 +other: 0.887 +instruction: 0.864 +graphic: 0.863 +network: 0.840 +vnc: 0.837 +assembly: 0.837 +KVM: 0.829 +device: 0.826 +socket: 0.811 +boot: 0.750 + +qemu 1.7.0 vhost_net crash + +i find the crash in /var/crash +the crash content is : +<4>Pid: 6949, comm: qemu-system-x86 Not tainted 2.6.32-431.el6.x86_64 #1 Powerleader PR2530G2/SC612DI-8F +<4>RIP: 0010:[<ffffffff8118a849>] [<ffffffff8118a849>] fput+0x9/0x30 +<4>RSP: 0018:ffff88015b601d98 EFLAGS: 00010292 +<4>RAX: 0000000000000382 RBX: ffff881e46590000 RCX: 00000000000001c3 +<4>RDX: 0000000000000000 RSI: ffff881e46590130 RDI: 0000000000000000 +<4>RBP: ffff88015b601d98 R08: ffff881e46598518 R09: 0000000000000000 +<4>R10: 0000000000000000 R11: 0000000000000246 R12: ffff881e46590010 +<4>R13: 0000000000000000 R14: ffff880c29812748 R15: 0000000000000000 +<4>FS: 00007f6a74d20700(0000) GS:ffff8810b8840000(0000) knlGS:0000000000000000 +<4>CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b +<4>CR2: 0000000000000030 CR3: 0000001c544cc000 CR4: 00000000001427e0 +<4>DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +<4>DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 +<4>Process qemu-system-x86 (pid: 6949, threadinfo ffff88015b600000, task ffff880c1ed9c040) +<4>Stack: +<4> ffff88015b601e58 ffffffffa02ac3c8 ffff881e46590000 0000000000000000 +<4><d> ffff881e46590080 ffff881e46590078 ffff88015b601e38 0000000000000286 +<4><d> ffffffff00000000 0000000000000001 ffff88015b601e58 0000000000000282 +<4>Call Trace: +<4> [<ffffffffa02ac3c8>] vhost_net_ioctl+0x328/0x5d0 [vhost_net] +<4> [<ffffffff8119db42>] vfs_ioctl+0x22/0xa0 +<4> [<ffffffff8119dce4>] do_vfs_ioctl+0x84/0x580 +<4> [<ffffffff8118a7d1>] ? __fput+0x1a1/0x210 +<4> [<ffffffff8119e261>] sys_ioctl+0x81/0xa0 +<4> [<ffffffff810e1e5e>] ? __audit_syscall_exit+0x25e/0x290 +<4> [<ffffffff8100b072>] system_call_fastpath+0x16/0x1b +<4>Code: fe ff ff 31 d2 48 89 de 83 cf ff ff d0 e9 da fe ff ff 48 89 df e8 28 64 04 00 e9 bb fe ff ff 0f 1f 00 55 48 89 e5 0f 1f 44 00 00 <f0> 48 ff 4f 30 0f 94 c0 84 c0 75 0b c9 c3 66 0f 1f +84 00 00 00 +<1>RIP [<ffffffff8118a849>] fput+0x9/0x30 +<4> RSP <ffff88015b601d98> +<4>CR2: 0000000000000030 + +how the bug occure + +my envionment is centos6.5 +and libvirt version is 1.2.14 + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU and the kernel? Or could we close this ticket nowadays? ... also, since this looks like a kernel bug instead of a QEMU bug, have you tried to report it to the KVM or virtio mailing list instead? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1529 b/results/classifier/105/mistranslation/1529 new file mode 100644 index 000000000..149b974eb --- /dev/null +++ b/results/classifier/105/mistranslation/1529 @@ -0,0 +1,14 @@ +mistranslation: 0.994 +semantic: 0.726 +graphic: 0.187 +other: 0.072 +instruction: 0.049 +device: 0.028 +network: 0.019 +boot: 0.006 +KVM: 0.005 +assembly: 0.002 +socket: 0.002 +vnc: 0.002 + +Documentation refers to Windows Hypervisor Platform as wphx instead of whpx diff --git a/results/classifier/105/mistranslation/1533 b/results/classifier/105/mistranslation/1533 new file mode 100644 index 000000000..b6554c701 --- /dev/null +++ b/results/classifier/105/mistranslation/1533 @@ -0,0 +1,14 @@ +mistranslation: 0.585 +device: 0.559 +instruction: 0.506 +other: 0.474 +semantic: 0.455 +graphic: 0.357 +network: 0.331 +boot: 0.166 +socket: 0.073 +vnc: 0.056 +assembly: 0.042 +KVM: 0.025 + +qemu-i386 should not enable feature LM with named CPU models. diff --git a/results/classifier/105/mistranslation/1536487 b/results/classifier/105/mistranslation/1536487 new file mode 100644 index 000000000..69374e93f --- /dev/null +++ b/results/classifier/105/mistranslation/1536487 @@ -0,0 +1,99 @@ +mistranslation: 0.924 +device: 0.905 +other: 0.898 +instruction: 0.878 +KVM: 0.826 +semantic: 0.812 +graphic: 0.780 +assembly: 0.769 +boot: 0.679 +socket: 0.665 +network: 0.629 +vnc: 0.621 + +Unable to migrate pc-i440fx-2.4 KVM guest from QEMU 2.5.0 to QEMU 2.4.1 + +When migrating a pc-i440fc-2.4 KVM guest from QEMU 2.5.0 to QEMU 2.4.1, the target QEMU errors out: + + qemu-system-x86_64: error while loading state for instance 0x0 of device 'fw_cfg' + +This appears to be related to the addition of a DMA interface to fw_cfg last October: + + http://lists.nongnu.org/archive/html/qemu-devel/2015-10/msg04568.html + +"info qtree" on the source QEMU shows that the DMA interface for fw_cfg had been enabled: + + bus: main-system-bus + type System + ... + dev: fw_cfg_io, id "" + iobase = 1296 (0x510) + dma_iobase = 1300 (0x514) + dma_enabled = true + +Incidentally, this guest had just undergone a migration from QEMU 2.4.0 to QEMU 2.5.0, so it looks like DMA was enabled simply through the migration. + +It seems to me that the DMA interface for fw_cfg should only be enabled on pc-i440fx-2.5 machines or higher. + +Hi, +Proxmox users have reported same bug (qemu 2.5 with pc-i440fc-2.4 not migrating to qemu 2.4.1) + +https://forum.proxmox.com/threads/cant-live-migrate-after-dist-upgrade.26097/ + +I don't have verified yet, but it seem to be related. + + +http://thread.gmane.org/gmane.comp.emulators.qemu/390272/focus=391042 + +sent a patch: http://thread.gmane.org/gmane.comp.emulators.qemu/395014 + +Fix committed in e6915b5f3a874a467a9a65f7ec1d6ef8d251a51a. + +Note: Also affects Migration Xenial->Trusty (tested and ran into the same issue, that was how I found the bug) and very likely also Yakkety->Trusty. + + qemu | 2.0.0+dfsg-2ubuntu1.27 | trusty-security | source + qemu | 1:2.5+dfsg-5ubuntu10.4 | xenial-updates | source + +Subscribing server Team to look at this in the scope of the qemu packaging SRU work for Xenial. + +Migrating a VM from xenial -> trusty (or anything moving backward) is +not supported. + + +Hi Serge I agree to "created on xenial -> migrating to trusty" not being supported. +I already tended to even say "created on xenial with the Trusty machine type -> migrating to trusty" is not supported as well (at least it is failing for all combos I tried. + +But I wonder how far "anything moving backward" should go. + +Especially I found that the "created on Trusty, migrated to xenial (works), but later migrated back to trusty (fails)" seems affected by it as well. +I'd have thought that this would be supported. What is you opinion on this more specific case? + +You might ask on #virt for the opinion there, but I don't believe +migrating backward is supported in any case. t->x->t doesn't change +the fact that there is x->t. + + +> Especially I found that the "created on Trusty, migrated to xenial +> (works), but later migrated back to trusty (fails)" seems affected by +> it as well. + +The first migration of the t->x->t sequence does not really matter (if +anything it could introduce _more_ bugs!), so if x->t is not supported +then neither is t->x->t. + +The upstream QEMU project doesn't have the manpower to test and support +backwards migration. We try not to break it, and in this case there +was an easy fix and we suggest that Canonical backports it. However, +in general it's not guaranteed to work. + +The fix is commit e6915b5f3a874a467a9a65f7ec1d6ef8d251a51a. + +Serge, Paulo - thank you both! + +I already had the patch but I think it was good to discuss and list the expected behavior not only for me, but for whoever else that comes by this or a similar case. + +I backported this and tried my tests again, but this alone isn't sufficient to get the T->X->T working (which is effectively 2.0->2.5->2.0). +Wily (2.4) is already out of service, so setting this to won't fix. + +Thanks for your guidance, but that now properly known I'll set the Xenial task to won't fix for now. + diff --git a/results/classifier/105/mistranslation/154 b/results/classifier/105/mistranslation/154 new file mode 100644 index 000000000..789082fe3 --- /dev/null +++ b/results/classifier/105/mistranslation/154 @@ -0,0 +1,14 @@ +mistranslation: 0.953 +device: 0.644 +instruction: 0.558 +network: 0.541 +socket: 0.499 +boot: 0.395 +graphic: 0.362 +semantic: 0.315 +vnc: 0.196 +KVM: 0.150 +other: 0.119 +assembly: 0.045 + +readlink(2) returns incorrect size for /proc/self/exe diff --git a/results/classifier/105/mistranslation/1543 b/results/classifier/105/mistranslation/1543 new file mode 100644 index 000000000..c064fae0a --- /dev/null +++ b/results/classifier/105/mistranslation/1543 @@ -0,0 +1,14 @@ +mistranslation: 0.758 +device: 0.726 +graphic: 0.713 +instruction: 0.688 +semantic: 0.498 +network: 0.327 +assembly: 0.273 +vnc: 0.201 +boot: 0.162 +KVM: 0.098 +socket: 0.048 +other: 0.019 + +Heap-use-after-free in e1000e_receive_internal diff --git a/results/classifier/105/mistranslation/1545052 b/results/classifier/105/mistranslation/1545052 new file mode 100644 index 000000000..fa3b833b5 --- /dev/null +++ b/results/classifier/105/mistranslation/1545052 @@ -0,0 +1,101 @@ +mistranslation: 0.822 +KVM: 0.818 +other: 0.793 +graphic: 0.779 +vnc: 0.769 +instruction: 0.759 +device: 0.720 +semantic: 0.714 +socket: 0.704 +assembly: 0.672 +network: 0.669 +boot: 0.604 + +RDMA migration will hang forever if target QEMU fails to load vmstate + +Get a pair of machines with infiniband support. On one host run + +$ qemu-system-x86_64 -monitor stdio -incoming rdma:ibme:4444 -vnc :1 -m 1000 + +To start an incoming migration. + + +Now on the other host, run QEMU with an intentionally different configuration (ie different RAM size) + +$ qemu-system-x86_64 -monitor stdio -vnc :1 -m 2000 + +Now trigger a migration on this source host + +(qemu) migrate rdma:ibpair:4444 + + +You will see on the target host, that it failed to load migration: + +dest_init RDMA Device opened: kernel name mlx4_0 uverbs device name uverbs0, infiniband_verbs class device path /sys/class/infiniband_verbs/uverbs0, infiniband class device path /sys/class/infiniband/mlx4_0, transport: (2) Ethernet +qemu-system-x86_64: Length mismatch: pc.ram: 0x7d000000 in != 0x3e800000: Invalid argument +qemu-system-x86_64: error while loading state for instance 0x0 of device 'ram' + +This is to be expected, however, at this point QEMU has hung and no longer responds to the monitor + +GDB shows the target host is stuck in this callpath + +#0 0x00007ffff39141cd in write () at ../sysdeps/unix/syscall-template.S:81 +#1 0x00007ffff27fe795 in rdma_get_cm_event.part.15 () from /lib64/librdmacm.so.1 +#2 0x000055555593e445 in qemu_rdma_cleanup (rdma=0x7fff9647e010) at migration/rdma.c:2210 +#3 0x000055555593ea45 in qemu_rdma_close (opaque=0x555557796770) at migration/rdma.c:2652 +#4 0x00005555559397cc in qemu_fclose (f=f@entry=0x5555564b1450) at migration/qemu-file.c:270 +#5 0x0000555555936b88 in process_incoming_migration_co (opaque=0x5555564b1450) at migration/migration.c:361 +#6 0x0000555555a25a1a in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at util/coroutine-ucontext.c:79 +#7 0x00007fffef5b3110 in ?? () from /lib64/libc.so.6 + + + +Now, back on the source host again, you would expect to see that the migrate command failed. Instead, this QEMU is hung too. + +GDB shows the source host, migrate thread, is stuck in this callpath: + +#0 0x00007ffff391522d in read#1 0x00007ffff00efd93 in ibv_get_cq_event () at /lib64/libibverbs.so.1 +#2 0x00005555559403f2 in qemu_rdma_block_for_wrid (rdma=rdma@entry=0x7fff3d07e010, wrid_requested=wrid_requested@entry=4000, byte_len=byte_len@entry=0x7fff39de370c) at migration/rdma.c:1511 +#3 0x000055555594058a in qemu_rdma_exchange_get_response (rdma=0x7fff3d07e010, head=head@entry=0x7fff39de3780, expecting=expecting@entry=2, idx=idx@entry=0) + at migration/rdma.c:1648 +#4 0x0000555555941e71 in qemu_rdma_exchange_send (rdma=0x7fff3d07e010, head=0x7fff39de3840, data=0x0, resp=0x7fff39de3870, resp_idx=0x7fff39de3880, callback=0x0) at migration/rdma.c:1725 +#5 0x00005555559447e4 in qemu_rdma_registration_stop (f=<optimized out>, opaque=<optimized out>, flags=0, data=<optimized out>) at migration/rdma.c:3302 +#6 0x000055555593bc4b in ram_control_after_iterate (f=f@entry=0x5555564c20f0, flags=flags@entry=0) at migration/qemu-file.c:157 +#7 0x0000555555740b59 in ram_save_setup (f=0x5555564c20f0, opaque=<optimized out>) at /home/berrange/src/virt/qemu/migration/ram.c:1959 +#8 0x00005555557451c1 in qemu_savevm_state_begin (f=0x5555564c20f0, params=params@entry=0x555555f6f048 <current_migration.37991+72>) + at /home/berrange/src/virt/qemu/migration/savevm.c:919 +#9 0x00005555559381a5 in migration_thread (opaque=0x555555f6f000 <current_migration.37991>) at migration/migration.c:1633 +#10 0x00007ffff390edc5 in start_thread (arg=0x7fff39de4700) at pthread_create.c:308 + + +It should have aborted migrate and set the status to failed. + +FYI is is tested on current GIT master + +commit fc1ec1acffd29d54c0c4266d30d38b2399d42f4f +Merge: f163684 1834ed3 +Author: Peter Maydell <email address hidden> +Date: Thu Feb 11 15:09:33 2016 +0000 + + Merge remote-tracking branch 'remotes/mjt/tags/pull-trivial-patches-2016-02-11' into staging + + + +Fix series posted upstream: +0001-migration-rdma-Fix-race-on-source.patch +0002-migration-Close-file-on-failed-migration-load.patch +0003-migration-rdma-Allow-cancelling-while-waiting-for-wr.patch +0004-migration-rdma-Safely-convert-control-types.patch +0005-migration-rdma-Send-error-during-cancelling.patch + + +Patch series has apparently been merged in time for QEMU v2.10: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=9cf2bab2edca1e651eef +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=3a0f2ceaedcf70ff79b6 +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=9c98cfbe72b21d9d84b9 +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=482a33c53cbc9d2b0c47 +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=32bce196344772df8d68 +So I assume we can close this ticket now? + +Yes, we probably can - I'd still not be that sure we've got all the races in the RDMA code, but we're probably a chunk better of than we were. + diff --git a/results/classifier/105/mistranslation/156 b/results/classifier/105/mistranslation/156 new file mode 100644 index 000000000..825a43d83 --- /dev/null +++ b/results/classifier/105/mistranslation/156 @@ -0,0 +1,14 @@ +mistranslation: 0.865 +other: 0.669 +semantic: 0.609 +vnc: 0.300 +device: 0.247 +graphic: 0.195 +KVM: 0.166 +boot: 0.086 +network: 0.063 +socket: 0.032 +assembly: 0.029 +instruction: 0.020 + +-nodefaults has unclear documentation diff --git a/results/classifier/105/mistranslation/1562653 b/results/classifier/105/mistranslation/1562653 new file mode 100644 index 000000000..0cc25790f --- /dev/null +++ b/results/classifier/105/mistranslation/1562653 @@ -0,0 +1,163 @@ +mistranslation: 0.912 +KVM: 0.861 +graphic: 0.837 +device: 0.836 +other: 0.822 +vnc: 0.819 +boot: 0.793 +network: 0.777 +socket: 0.760 +assembly: 0.750 +instruction: 0.742 +semantic: 0.706 + +Ubuntu 15.10: QEMU VM hang if memory >= 1T + +1. Ubuntu 15.10 x86_64 installed on HP SuperDome X with 8CPUs and 4T memory. + +2. Create a VM, install Ubuntu 15.10, if memory >= 1T , VM hang when start. If memory < 1T, it is good. +<domain type='kvm'> + <name>u1510-1</name> + <uuid>39eefe1e-4829-4843-b892-026d143f3ec7</uuid> + <memory unit='KiB'>1073741824</memory> + <currentMemory unit='KiB'>1073741824</currentMemory> + <vcpu placement='static'>16</vcpu> + <os> + <type arch='x86_64' machine='pc-i440fx-2.3'>hvm</type> + <boot dev='hd'/> + <boot dev='cdrom'/> + </os> + <features> + <acpi/> + <apic/> + <pae/> + </features> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>restart</on_crash> + <devices> + <emulator>/usr/bin/kvm</emulator> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync'/> + <source file='/vms/images/u1510-1.img'/> + <target dev='vda' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> + </disk> + <disk type='file' device='cdrom'> + <driver name='qemu' type='raw'/> + <target dev='hdc' bus='ide'/> + <readonly/> + <address type='drive' controller='0' bus='1' target='0' unit='0'/> + </disk> + <controller type='pci' index='0' model='pci-root'/> + <controller type='ide' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> + </controller> + <controller type='usb' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> + </controller> + <interface type='bridge'> + <mac address='0c:da:41:1d:ae:f1'/> + <source bridge='vswitch0'/> + <model type='virtio'/> + <driver name='vhost'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + <input type='mouse' bus='ps2'/> + <input type='keyboard' bus='ps2'/> + <graphics type='vnc' port='-1' autoport='yes' listen='0.0.0.0'> + <listen type='address' address='0.0.0.0'/> + </graphics> + <video> + <model type='cirrus' vram='16384' heads='1'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </video> + <memballoon model='virtio'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> + </memballoon> + </devices> +</domain> + +3. The panic stack is + ... cannot show + async_page_fault+0x28 + ioread32_rep+0x38 + ata_sff_data_xfer32+0x8a + ata_pio_sector+0x93 + ata_pio_sectors+0x34 + ata_sff_hsm_move+0x226 + RIP: kthread_data+0x10 + CR2: FFFFFFFF_FFFFFFD8 + +4. Change the host os to Redhat 7.2 , the vm is good even memory >=3.8T. + +I delete cdrom and IDE controller, the vm start sucessfully. + +But when I increate memory to 1100G, vm hang at hpet_enable when start. + +The panic is page_fault when execute hpet_period = hpet_readl(HPET_PERIOD); + +It seems that ioremap_nocache does not works correctly. + +hpet_virt_address = ioremap_nocache(hpet_address, HPET_MMAP_SIZE); + +Hi, + +just to be sure, if you run + +kvm -vnc :1 -m 1.5G +kvm -vnc :1 -m 1.5G --no-hpet + +do those also crash? + +Can you please show the contents of + +/var/log/libvirt/qemu/u1510-1.log + +I mean vm hang when memory >= 1100G (1024G when enable ide cdrom) instead of 1.5G. + +If disable hpet, the vm will hang at acpi_ex_system_memory_space_handler when memory >= 1100G + +If disable kvm, vm is good when memory <= 1020G, but also hang when memory >= 1024G. + +There is no critical information in vm.log: + + +After I changed PHYS_ADDR_MASK, qemu vm can start when memory >=1024G , but kvm vm still hang. + +-# define PHYS_ADDR_MASK 0xffffffffffLL ++# define PHYS_ADDR_MASK 0xfffffffffffLL + + +The issue is sloved after change cpuid[80000008]; + +--- a/target-i386/cpu.c ++++ b/target-i386/cpu.c +@@ -2547,7 +2547,7 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count, + if (env->features[FEAT_8000_0001_EDX] & CPUID_EXT2_LM) { + /* 64 bit processor */ + /* XXX: The physical address space is limited to 42 bits in exec.c. */ +- *eax = 0x00003028; /* 48 bits virtual, 40 bits physical */ ++ *eax = 0x00003029; /* 48 bits virtual, 41 bits physical */ + } else { + if (env->features[FEAT_1_EDX] & CPUID_PSE36) { + *eax = 0x00000024; /* 36 bits physical */ + + +For cpus which have not EPT feature, should change CR3_L_MODE_RESERVED_BITS in arch/x86/include/asm/kvm_host.h: + +-#define CR3_L_MODE_RESERVED_BITS 0xFFFFFF0000000000ULL ++#define CR3_L_MODE_RESERVED_BITS 0xFFFFFE0000000000ULL + + +Can you still reproduce this problem with the latest version of upstream QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + +[Expired for qemu (Ubuntu) because there has been no activity for 60 days.] + +I only saw this because it expired now :-/ + +Anyone affected by this might want to take a look at bug 1776189 where Ubuntu added a special machine type to more easily set "host-phys-bits" which is the qemu flag to have more (usually the host has more) available (at the cost of migratability). That allows <1TB as the default bits in qemu are chosen on the base of TCG (to be able to emulate what is virtualized) and that is limited to 1TB. + diff --git a/results/classifier/105/mistranslation/1563152 b/results/classifier/105/mistranslation/1563152 new file mode 100644 index 000000000..d41b22c69 --- /dev/null +++ b/results/classifier/105/mistranslation/1563152 @@ -0,0 +1,72 @@ +mistranslation: 0.934 +semantic: 0.898 +KVM: 0.897 +graphic: 0.896 +device: 0.877 +instruction: 0.876 +vnc: 0.873 +other: 0.863 +boot: 0.857 +assembly: 0.845 +socket: 0.824 +network: 0.782 + +general protection fault running VirtualBox in KVM guest + +I'm trying to run nested VMs using qemu-kvm on the physical host and VirtualBox on the guest host: + * physical host: Ubuntu 14.04 running Linux 4.2.0, qemu-kvm 2.0.0 + * guest host: Ubuntu 16.04 beta 2 running Linux 4.2.0, VirtualBox 5.0.16 + +When I try to start up a VirtualBox VM in the guest host, I get a general protection fault (see below for dmesg output). According to https://www.virtualbox.org/ticket/14965 this is caused by a bug in QEMU/KVM: + + The problem in more detail: As written above, VirtualBox tries to + read the MSR 0x9B (IA32_SMM_MONITOR_CTL). This is an + architectural MSR which is present if CPUID.01 / ECX bit 5 or bit + 6 are set (VMX or SMX). As KVM has nested virtualization enabled + and therefore pretends to support VT-x, this MSR must be + accessible and reading from this MSR must not raise a + #GP. KVM/QEmu does not behave like real hardware in this case. + +dmesg output: + +SUPR0GipMap: fGetGipCpu=0x3 +general protection fault: 0000 [#1] SMP +Modules linked in: pci_stub vboxpci(OE) vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack xt_tcpudp bridge stp llc iptable_filter ip_tables x_tables ppdev kvm_intel kvm irqbypass snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer i2c_piix4 snd input_leds soundcore joydev 8250_fintek mac_hid serio_raw pvpanic parport_pc parport ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear crct10dif_pclmul crc32_pclmul qxl ttm drm_kms_helper syscopyarea sysfillrect aesni_intel sysimgblt fb_sys_fops aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd psmouse floppy drm pata_acpi +CPU: 0 PID: 31507 Comm: EMT Tainted: G OE 4.4.0-15-generic #31-Ubuntu +Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 +task: ffff880034c0a580 ti: ffff880002e00000 task.ti: ffff880002e00000 +RIP: 0010:[<ffffffffc067e506>] [<ffffffffc067e506>] 0xffffffffc067e506 +RSP: 0018:ffff880002e03d70 EFLAGS: 00010206 +RAX: 00000000000006f0 RBX: 00000000ffffffdb RCX: 000000000000009b +RDX: 0000000000000000 RSI: ffff880002e03d00 RDI: ffff880002e03cc8 +RBP: ffff880002e03d90 R08: 0000000000000004 R09: 00000000000006f0 +R10: 0000000049656e69 R11: 000000000f8bfbff R12: 0000000000000020 +R13: 0000000000000000 R14: ffffc9000057407c R15: ffffffffc0645260 +FS: 00007f89b8f6b700(0000) GS:ffff88007fc00000(0000) knlGS:0000000000000000 +CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +CR2: 00007f89b8d10000 CR3: 0000000035ae1000 CR4: 00000000000006f0 +Stack: + 0000000000000000 ffffffff00000000 0000000000000000 0000000000000000 + ffff880002e03db0 ffffffffc0693e93 ffffc90000574010 ffff880035aae550 + ffff880002e03e30 ffffffffc060a3e7 ffff880002e03e10 0000000000000282 +Call Trace: + [<ffffffffc060a3e7>] ? supdrvIOCtl+0x2de7/0x3250 [vboxdrv] + [<ffffffffc06035b0>] ? VBoxDrvLinuxIOCtl_5_0_16+0x150/0x250 [vboxdrv] + [<ffffffff8121e7df>] ? do_vfs_ioctl+0x29f/0x490 + [<ffffffff8106a554>] ? __do_page_fault+0x1b4/0x400 + [<ffffffff8121ea49>] ? SyS_ioctl+0x79/0x90 + [<ffffffff81821ff2>] ? entry_SYSCALL_64_fastpath+0x16/0x71 +Code: 88 e4 fc ff ff b9 3a 00 00 00 0f 32 48 c1 e2 20 89 c0 48 09 d0 48 89 05 f9 db 0e 00 0f 20 e0 b9 9b 00 00 00 48 89 05 d2 db 0e 00 <0f> 32 48 c1 e2 20 89 c0 b9 80 00 00 c0 48 09 d0 48 89 05 cb db +RIP [<ffffffffc067e506>] 0xffffffffc067e506 + RSP <ffff880002e03d70> +---[ end trace b3284b6520f49e0d ]--- + +Status changed to 'Confirmed' because the bug affects multiple users. + +The QEMU project is currently considering to move 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 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 (Ubuntu) because there has been no activity for 60 days.] + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1563887 b/results/classifier/105/mistranslation/1563887 new file mode 100644 index 000000000..f175a1a96 --- /dev/null +++ b/results/classifier/105/mistranslation/1563887 @@ -0,0 +1,912 @@ +mistranslation: 0.489 +graphic: 0.473 +device: 0.472 +other: 0.469 +assembly: 0.416 +semantic: 0.396 +boot: 0.370 +instruction: 0.356 +KVM: 0.334 +vnc: 0.285 +network: 0.202 +socket: 0.199 + +qemu-system-ppc64 freezes on starting image on ppc64le + +qemu-system-ppc64 running on Ubuntu 16.04 beta-2 fails to start an image as part of the certification process. This on an IBM ppc64le in PowerVM mode running Ubuntu 16.04 beta-2 deployed by MAAS 1.9.1. + +qemu-system-ppc64 -m 256 -display none -nographic -net nic -net user,net=10.0.0.0/8,host=10.0.0.1,hostfwd=tcp::2222-:22 -machine pseries -drive file= +xenial-server-cloudimg-ppc64el-disk1.img,if=virtio -drive file=seed.iso,if=virtio +qemu-system-ppc64: -drive file=seed.iso,if=virtio: Could not open 'seed.iso': No such file or directory +ubuntu@alpine01:~$ cd kvm +ubuntu@alpine01:~/kvm$ qemu-system-ppc64 -m 256 -display none -nographic -net nic -net user,net=10.0.0.0/8,host=10.0.0.1,hostfwd=tcp::2222-:22 -machine pseries -drive f +ile=xenial-server-cloudimg-ppc64el-disk1.img,if=virtio -drive file=seed.iso,if=virtio +WARNING: Image format was not specified for 'seed.iso' and probing guessed raw. + Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. + Specify the 'raw' format explicitly to remove the restrictions. + + +SLOF ********************************************************************** +QEMU Starting + Build Date = Jan 29 2016 18:58:37 + FW Version = buildd@ release 20151103 + Press "s" to enter Open Firmware. + +Populating /vdevice methods +Populating /vdevice/vty@71000000 +Populating /vdevice/nvram@71000001 +Populating /vdevice/l-lan@71000002 +Populating /vdevice/v-scsi@71000003 + SCSI: Looking for devices + 8200000000000000 CD-ROM : "QEMU QEMU CD-ROM 2.5+" +Populating /pci@800000020000000 + 00 1800 (D) : 1af4 1001 virtio [ block ] + 00 1000 (D) : 1af4 1001 virtio [ block ] + 00 0800 (D) : 106b 003f serial bus [ usb-ohci ] + 00 0000 (D) : 1234 1111 qemu vga +No NVRAM common partition, re-initializing... +Installing QEMU fb + + + +Scanning USB + OHCI: initializing + USB Keyboard + USB mouse +No console specified using screen & keyboard + + Welcome to Open Firmware + + Copyright (c) 2004, 2011 IBM Corporation All rights reserved. + This program and the accompanying materials are made available + under the terms of the BSD License available at + http://www.opensource.org/licenses/bsd-license.php + + +Trying to load: from: /pci@800000020000000/scsi@3 ... +E3404: Not a bootable device! +Trying to load: from: /pci@800000020000000/scsi@2 ... Successfully loaded +Linux ppc64le +#31-Ubuntu SMP F + +ProblemType: Bug +DistroRelease: Ubuntu 16.04 +Package: qemu-system-ppc 1:2.5+dfsg-5ubuntu6 +ProcVersionSignature: Ubuntu 4.4.0-16.32-generic 4.4.6 +Uname: Linux 4.4.0-16-generic ppc64le +ApportVersion: 2.20-0ubuntu3 +Architecture: ppc64el +Date: Wed Mar 30 14:10:01 2016 +KvmCmdLine: + COMMAND STAT EUID RUID PID PPID %CPU COMMAND + kvm-irqfd-clean S< 0 0 1172 2 0.0 [kvm-irqfd-clean] + qemu-nbd Ssl 0 0 13467 1 0.0 qemu-nbd -c /dev/nbd0 xenial-server-cloudimg-ppc64el-disk1.img + qemu-system-ppc Sl+ 1000 1000 18973 18896 101 qemu-system-ppc64 -m 256 -display none -nographic -net nic -net user,net=10.0.0.0/8,host=10.0.0.1,hostfwd=tcp::2222-:22 -machine pseries -drive file=xenial-server-cloudimg-ppc64el-disk1.img,if=virtio -drive file=seed.iso,if=virtio +Lsusb: Error: command ['lsusb'] failed with exit code 1: +ProcEnviron: + TERM=xterm + PATH=(custom, no user) + LANG=en_US.UTF-8 + SHELL=/bin/bash +ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinux-4.4.0-16-generic root=UUID=92d820c8-ab25-497b-9b1e-f1435992bbf3 ro +ProcLoadAvg: 1.08 0.94 0.58 2/616 19571 +ProcLocks: + 1: POSIX ADVISORY WRITE 886 00:13:381 0 EOF + 2: POSIX ADVISORY WRITE 1339 00:13:528 0 EOF + 3: FLOCK ADVISORY WRITE 1284 00:13:522 0 EOF + 4: POSIX ADVISORY WRITE 2281 00:13:563 0 EOF + 5: POSIX ADVISORY WRITE 1331 00:13:536 0 EOF +ProcSwaps: + Filename Type Size Used Priority + /swap.img file 8388544 0 -1 +ProcVersion: Linux version 4.4.0-16-generic (buildd@bos01-ppc64el-001) (gcc version 5.3.1 20160320 (Ubuntu/Linaro/IBM 5.3.1-12ubuntu4) ) #32-Ubuntu SMP Thu Mar 24 22:31:14 UTC 2016 +SourcePackage: qemu +UpgradeStatus: No upgrade log present (probably fresh install) +bootlist: + /pci@800000020000011/pci1014,034A@0/sas/disk@4068402c40 + /pci@800000020000018/ethernet@0:speed=auto,duplex=auto,csarch,000.000.000.000,,000.000.000.000,000.000.000.000,5,5,000.000.000.000,512 + /pci@800000020000018/ethernet@0,1:speed=auto,duplex=auto,csarch,000.000.000.000,,000.000.000.000,000.000.000.000,5,5,000.000.000.000,512 + /pci@800000020000018/ethernet@0,2:speed=auto,duplex=auto,csarch,000.000.000.000,,000.000.000.000,000.000.000.000,5,5,000.000.000.000,512 + /pci@800000020000018/ethernet@0,3:speed=auto,duplex=auto,csarch,000.000.000.000,,000.000.000.000,000.000.000.000,5,5,000.000.000.000,512 +cpu_cores: Number of cores present = 8 +cpu_coreson: Number of cores online = 8 +cpu_smt: SMT=8 +lscfg_vp: Error: [Errno 2] No such file or directory: 'lscfg' +lsmcode: Error: [Errno 2] No such file or directory: 'lsmcode' + + + +In Ubuntu 14.04.4 running on the same hardware, the fix was to update qemu-system-ppc from cloud-archive:kilo. This repository is only supported on trusty and contains an earlier version of qemu-system-ppc than what is available on xenial. + + + +Hi, + +looking at the information in the Description, it looks like you still have /dev/nbd0 attached to the file you're using in qemu. Just to be sure, does this still happen when you disconnect that first? + +Yes. I only mounted (a different file) to troubleshoot what was going on. The issue was happening before and after mounting. I have since unmounted it. + +Could you try this using upstream qemu? + +git clone http://git.qemu.org/git/qemu.git +cd qemu +sudo apt-get -y build-dep qemu +./configure --target-list=ppc64-softmmu +make +cd ppc64-softmmu +./qemu-system-ppc64 [...] + + +Same issue. Stopped on the exact same spot. + +Just to be sure before I mark this as affecting upstream, could you +try adding more memory, maybe -m 1024? + + + +Same issue with -m 2048 + +Failing any brighter ideas, this should be pretty bisectable to figure out what happened. Hardware availability is the main problem. Would you be able to use your system to bisect to the commit introducing the bug? + +Actually before we get to that, could you try installing the 14.04 slof package on the 16.04 system, and see whether that fixes it? + + +I have installed qemu-slof from trusty and ran again: + +qemu-slof: + Installed: 20151103+dfsg-1ubuntu1 + Candidate: 20151103+dfsg-1ubuntu1 + Version table: + *** 20151103+dfsg-1ubuntu1 500 + 500 http://ports.ubuntu.com/ubuntu-ports xenial/main ppc64el Packages + 100 /var/lib/dpkg/status + 20131015+dfsg-1ubuntu1 500 + 500 http://ports.ubuntu.com/ubuntu-ports trusty/universe ppc64el Packages +ubuntu@alpine01:~$ sudo apt-get install qemu-slof=20131015+dfsg-1ubuntu1 + +It froze on the exact same spot. + +Thanks very much for testing. + +I think I have a system I can use to try and bisect tonight/tomorrow. + + +Hm, building 2.2.0 (close to what is in the kilo cloud archive) doesn't help. + +I'll try building the package source from kilo on the xenial host and see if that succeeds. I'm having doubts. + +Indeed building the kilo package from source gives me the same hang. So something else (seabios maybe) + +Hi, + +I've redeployed my test box with 14.04 with kilo-staging archive, but i get a core dump when i try to run kvm the same way you did. + +Can you show your /etc/apt/sources.list and /etc/apt/sources.list.d, as well as output for + +uname -a +dpkg -l | egrep -e '(qemu|linux|bios)' + +Quoting Serge Hallyn (2016-04-01 11:56:29) +> Hi, +> +> I've redeployed my test box with 14.04 with kilo-staging archive, but i +> get a core dump when i try to run kvm the same way you did. + +What does `ppc64_cpu --info` report? The original bug had some output +that suggested SMT was enabled: + +> cpu_cores: Number of cores present = 8 +> cpu_coreson: Number of cores online = 8 +> cpu_smt: SMT=8 + +But AFAIK, SMT should be disabled in the host (ppc64_cpu --smt off) +and left to individual guests to enable/disable in guest mode. + +For KVM on powernv host kernel at least... original bug suggested +PowerVM mode: + +> Bug description: +> qemu-system-ppc64 running on Ubuntu 16.04 beta-2 fails to start an +> image as part of the certification process. This on an IBM ppc64le in +> PowerVM mode running Ubuntu 16.04 beta-2 deployed by MAAS 1.9.1. There +> is no error output. + +which I'm assuming didn't actually mean PowerVM instead of +powernv+KVM? Or was this actually a PowerVM partition trying to run +a KVM guest? + + + +Hm - I can boot a wily cloud image, just not a xenial one. + +This change was made by a bot. + +Result of doing qemu-system-ppc64 -m 1024 -vnc :1 -net nic -net user,net=10.0.0.0/8,host=10.0.0.1,hostfwd=tcp::2222-:22 -machine pseries -drive file=xenial-server-cloudimg-ppc64el-disk1.img,if=virtio -drive file=my-seed.img,if=virtio + + +ubuntu@alpine01:~$ ppc64_cpu --info +Core 0: 0* 1* 2* 3* 4* 5* 6* 7* +Core 1: 8* 9* 10* 11* 12* 13* 14* 15* +Core 2: 16* 17* 18* 19* 20* 21* 22* 23* +Core 3: 24* 25* 26* 27* 28* 29* 30* 31* +Core 4: 32* 33* 34* 35* 36* 37* 38* 39* +Core 5: 40* 41* 42* 43* 44* 45* 46* 47* +Core 6: 48* 49* 50* 51* 52* 53* 54* 55* +Core 7: 56* 57* 58* 59* 60* 61* 62* 63* +ubuntu@alpine01:~$ ppc64_cpu --smt off +SMT=8 +ubuntu@alpine01:~$ ppc64_cpu --info +Core 0: 0* 1* 2* 3* 4* 5* 6* 7* +Core 1: 8* 9* 10* 11* 12* 13* 14* 15* +Core 2: 16* 17* 18* 19* 20* 21* 22* 23* +Core 3: 24* 25* 26* 27* 28* 29* 30* 31* +Core 4: 32* 33* 34* 35* 36* 37* 38* 39* +Core 5: 40* 41* 42* 43* 44* 45* 46* 47* +Core 6: 48* 49* 50* 51* 52* 53* 54* 55* +Core 7: 56* 57* 58* 59* 60* 61* 62* 63* + +Still freezing at the same point: + +Trying to load: from: disk ... Successfully loaded +* finddevice /memory grub workaround * +* finddevice /memory grub workaround * +* finddevice /memory grub workaround * +Linux ppc64le +#31-Ubuntu SMP F + + +This is running on an LPAR in PowerNV mode. + +Actually the clou dimages have a 4.2 kernel. When I use a xenial beta2 iso which has 4.4.0-15-generic #31, it boots fine. I can install, and I can boot the installed image (with same kernel) just fine. + + +4.4.0-16 also works. + +Quoting Mike Rushton (2016-04-04 09:49:29) +> ubuntu@alpine01:~$ ppc64_cpu --info +> Core 0: 0* 1* 2* 3* 4* 5* 6* 7* +> Core 1: 8* 9* 10* 11* 12* 13* 14* 15* +> Core 2: 16* 17* 18* 19* 20* 21* 22* 23* +> Core 3: 24* 25* 26* 27* 28* 29* 30* 31* +> Core 4: 32* 33* 34* 35* 36* 37* 38* 39* +> Core 5: 40* 41* 42* 43* 44* 45* 46* 47* +> Core 6: 48* 49* 50* 51* 52* 53* 54* 55* +> Core 7: 56* 57* 58* 59* 60* 61* 62* 63* +> ubuntu@alpine01:~$ ppc64_cpu --smt off +> SMT=8 +> ubuntu@alpine01:~$ ppc64_cpu --info +> Core 0: 0* 1* 2* 3* 4* 5* 6* 7* +> Core 1: 8* 9* 10* 11* 12* 13* 14* 15* +> Core 2: 16* 17* 18* 19* 20* 21* 22* 23* +> Core 3: 24* 25* 26* 27* 28* 29* 30* 31* +> Core 4: 32* 33* 34* 35* 36* 37* 38* 39* +> Core 5: 40* 41* 42* 43* 44* 45* 46* 47* +> Core 6: 48* 49* 50* 51* 52* 53* 54* 55* +> Core 7: 56* 57* 58* 59* 60* 61* 62* 63* + +Yah, this is not right. + +I think the command you need is actually: + + ppc64_cpu --smt=1 + +I don't know if this is the root cause, but I would not +expect things to work in general without SMT=1 + +> +> Still freezing at the same point: +> +> Trying to load: from: disk ... Successfully loaded +> * finddevice /memory grub workaround * +> * finddevice /memory grub workaround * +> * finddevice /memory grub workaround * +> Linux ppc64le +> #31-Ubuntu SMP F +> +> +> This is running on an LPAR in PowerNV mode. +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1563887 +> +> Title: +> qemu-system-ppc64 freezes on starting image on ppc64le +> +> Status in QEMU: +> New +> Status in linux package in Ubuntu: +> Confirmed +> Status in qemu package in Ubuntu: +> Confirmed +> +> Bug description: +> qemu-system-ppc64 running on Ubuntu 16.04 beta-2 fails to start an +> image as part of the certification process. This on an IBM ppc64le in +> PowerVM mode running Ubuntu 16.04 beta-2 deployed by MAAS 1.9.1. There +> is no error output. +> +> ubuntu@alpine01:~/kvm$ qemu-system-ppc64 -m 256 -display none -nographic -net nic -net user,net=10.0.0.0/8,host=10.0.0.1,hostfwd=tcp::2222-:22 -machine pseries -drive file=xenial-server-cloudimg-ppc64el-disk1.img,if=virtio -drive file=seed.iso,if=virtio +> WARNING: Image format was not specified for 'seed.iso' and probing guessed raw. +> Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. +> Specify the 'raw' format explicitly to remove the restrictions. +> +> SLOF ********************************************************************** +> QEMU Starting +> Build Date = Jan 29 2016 18:58:37 +> FW Version = buildd@ release 20151103 +> Press "s" to enter Open Firmware. +> +> Populating /vdevice methods +> Populating /vdevice/vty@71000000 +> Populating /vdevice/nvram@71000001 +> Populating /vdevice/l-lan@71000002 +> Populating /vdevice/v-scsi@71000003 +> SCSI: Looking for devices +> 8200000000000000 CD-ROM : "QEMU QEMU CD-ROM 2.5+" +> Populating /pci@800000020000000 +> 00 1800 (D) : 1af4 1001 virtio [ block ] +> 00 1000 (D) : 1af4 1001 virtio [ block ] +> 00 0800 (D) : 106b 003f serial bus [ usb-ohci ] +> 00 0000 (D) : 1234 1111 qemu vga +> No NVRAM common partition, re-initializing... +> Installing QEMU fb +> +> Scanning USB +> OHCI: initializing +> USB Keyboard +> USB mouse +> No console specified using screen & keyboard +> +> Welcome to Open Firmware +> +> Copyright (c) 2004, 2011 IBM Corporation All rights reserved. +> This program and the accompanying materials are made available +> under the terms of the BSD License available at +> http://www.opensource.org/licenses/bsd-license.php +> +> Trying to load: from: /pci@800000020000000/scsi@3 ... +> E3404: Not a bootable device! +> Trying to load: from: /pci@800000020000000/scsi@2 ... Successfully loaded +> Linux ppc64le +> #31-Ubuntu SMP F +> +> ProblemType: Bug +> DistroRelease: Ubuntu 16.04 +> Package: qemu-system-ppc 1:2.5+dfsg-5ubuntu6 +> ProcVersionSignature: Ubuntu 4.4.0-16.32-generic 4.4.6 +> Uname: Linux 4.4.0-16-generic ppc64le +> ApportVersion: 2.20-0ubuntu3 +> Architecture: ppc64el +> Date: Wed Mar 30 14:10:01 2016 +> KvmCmdLine: +> COMMAND STAT EUID RUID PID PPID %CPU COMMAND +> kvm-irqfd-clean S< 0 0 1172 2 0.0 [kvm-irqfd-clean] +> qemu-nbd Ssl 0 0 13467 1 0.0 qemu-nbd -c /dev/nbd0 xenial-server-cloudimg-ppc64el-disk1.img +> qemu-system-ppc Sl+ 1000 1000 18973 18896 101 qemu-system-ppc64 -m 256 -display none -nographic -net nic -net user,net=10.0.0.0/8,host=10.0.0.1,hostfwd=tcp::2222-:22 -machine pseries -drive file=xenial-server-cloudimg-ppc64el-disk1.img,if=virtio -drive file=seed.iso,if=virtio +> Lsusb: Error: command ['lsusb'] failed with exit code 1: +> ProcEnviron: +> TERM=xterm +> PATH=(custom, no user) +> LANG=en_US.UTF-8 +> SHELL=/bin/bash +> ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinux-4.4.0-16-generic root=UUID=92d820c8-ab25-497b-9b1e-f1435992bbf3 ro +> ProcLoadAvg: 1.08 0.94 0.58 2/616 19571 +> ProcLocks: +> 1: POSIX ADVISORY WRITE 886 00:13:381 0 EOF +> 2: POSIX ADVISORY WRITE 1339 00:13:528 0 EOF +> 3: FLOCK ADVISORY WRITE 1284 00:13:522 0 EOF +> 4: POSIX ADVISORY WRITE 2281 00:13:563 0 EOF +> 5: POSIX ADVISORY WRITE 1331 00:13:536 0 EOF +> ProcSwaps: +> Filename Type Size Used Priority +> /swap.img file 8388544 0 -1 +> ProcVersion: Linux version 4.4.0-16-generic (buildd@bos01-ppc64el-001) (gcc version 5.3.1 20160320 (Ubuntu/Linaro/IBM 5.3.1-12ubuntu4) ) #32-Ubuntu SMP Thu Mar 24 22:31:14 UTC 2016 +> SourcePackage: qemu +> UpgradeStatus: No upgrade log present (probably fresh install) +> bootlist: +> /pci@800000020000011/pci1014,034A@0/sas/disk@4068402c40 +> /pci@800000020000018/ethernet@0:speed=auto,duplex=auto,csarch,000.000.000.000,,000.000.000.000,000.000.000.000,5,5,000.000.000.000,512 +> /pci@800000020000018/ethernet@0,1:speed=auto,duplex=auto,csarch,000.000.000.000,,000.000.000.000,000.000.000.000,5,5,000.000.000.000,512 +> /pci@800000020000018/ethernet@0,2:speed=auto,duplex=auto,csarch,000.000.000.000,,000.000.000.000,000.000.000.000,5,5,000.000.000.000,512 +> /pci@800000020000018/ethernet@0,3:speed=auto,duplex=auto,csarch,000.000.000.000,,000.000.000.000,000.000.000.000,5,5,000.000.000.000,512 +> cpu_cores: Number of cores present = 8 +> cpu_coreson: Number of cores online = 8 +> cpu_smt: SMT=8 +> lscfg_vp: Error: [Errno 2] No such file or directory: 'lscfg' +> lsmcode: Error: [Errno 2] No such file or directory: 'lsmcode' +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1563887/+subscriptions +> + + + +ubuntu@alpine01:~$ sudo ppc64_cpu --smt=1 +ubuntu@alpine01:~$ ppc64_cpu --info +Core 0: 0* 1 2 3 4 5 6 7 +Core 1: 8* 9 10 11 12 13 14 15 +Core 2: 16* 17 18 19 20 21 22 23 +Core 3: 24* 25 26 27 28 29 30 31 +Core 4: 32* 33 34 35 36 37 38 39 +Core 5: 40* 41 42 43 44 45 46 47 +Core 6: 48* 49 50 51 52 53 54 55 +Core 7: 56* 57 58 59 60 61 62 63 + +ubuntu@alpine01:~$ sudo ppc64_cpu --smt +SMT is off + + +Still freezing at the same point. + +If you can reproduce this with the ppc64 xenial iso or a rootfs +installed from that, using 4.4 kernel, please let us know. Otherwise, +I think the fix will be for cloud images to be updated with a 4.4 kernel. + + +Quoting Mike Rushton (2016-04-05 13:10:17) +> ubuntu@alpine01:~$ sudo ppc64_cpu --smt=1 +> ubuntu@alpine01:~$ ppc64_cpu --info +> Core 0: 0* 1 2 3 4 5 6 7 +> Core 1: 8* 9 10 11 12 13 14 15 +> Core 2: 16* 17 18 19 20 21 22 23 +> Core 3: 24* 25 26 27 28 29 30 31 +> Core 4: 32* 33 34 35 36 37 38 39 +> Core 5: 40* 41 42 43 44 45 46 47 +> Core 6: 48* 49 50 51 52 53 54 55 +> Core 7: 56* 57 58 59 60 61 62 63 +> +> ubuntu@alpine01:~$ sudo ppc64_cpu --smt +> SMT is off +> +> +> Still freezing at the same point. +> +> Bug description: +> qemu-system-ppc64 running on Ubuntu 16.04 beta-2 fails to start an +> image as part of the certification process. This on an IBM ppc64le in +> PowerVM mode running Ubuntu 16.04 beta-2 deployed by MAAS 1.9.1. There +> is no error output. +> +> ubuntu@alpine01:~/kvm$ qemu-system-ppc64 -m 256 -display none -nographic -net nic -net user,net=10.0.0.0/8,host=10.0.0.1,hostfwd=tcp::2222-:22 -machine pseries -drive file=xenial-server-cloudimg-ppc64el-disk1.img,if=virtio -drive file=seed.iso,if=virtio +> WARNING: Image format was not specified for 'seed.iso' and probing guessed raw. +> Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. +> Specify the 'raw' format explicitly to remove the restrictions. + +Unless things are different with Ubuntu, I don't think KVM is enabled by default. Try your command with -enable-kvm to be sure. + + + +@serge-hallyn + +ubuntu@alpine01:~/kvm$ cat /etc/issue; uname -a ; ppc64_cpu --smt +Ubuntu Xenial Xerus (development branch) \n \l + +Linux alpine01 4.4.0-17-generic #33-Ubuntu SMP Tue Mar 29 17:15:31 UTC 2016 ppc64le ppc64le ppc64le GNU/Linux +SMT is off +ubuntu@alpine01:~/kvm$ qemu-system-ppc64 -m 256 -display none -nographic -net nic -net user,net=10.0.0.0/8,host=10.0.0.1,hostfwd=tcp::2222-:22 -machine pseries -drive file=xenial-server-cloudimg-ppc64el-disk1.img,if=virtio -drive file=seed.iso,if=virtio +WARNING: Image format was not specified for 'seed.iso' and probing guessed raw. + Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. + Specify the 'raw' format explicitly to remove the restrictions. + + +SLOF ********************************************************************** +QEMU Starting + Build Date = Jan 29 2016 18:58:37 + FW Version = buildd@ release 20151103 + Press "s" to enter Open Firmware. + +Populating /vdevice methods +Populating /vdevice/vty@71000000 +Populating /vdevice/nvram@71000001 +Populating /vdevice/l-lan@71000002 +Populating /vdevice/v-scsi@71000003 + SCSI: Looking for devices + 8200000000000000 CD-ROM : "QEMU QEMU CD-ROM 2.5+" +Populating /pci@800000020000000 + 00 1800 (D) : 1af4 1001 virtio [ block ] + 00 1000 (D) : 1af4 1001 virtio [ block ] + 00 0800 (D) : 106b 003f serial bus [ usb-ohci ] + 00 0000 (D) : 1234 1111 qemu vga +No NVRAM common partition, re-initializing... +Installing QEMU fb + + + +Scanning USB + OHCI: initializing + USB Keyboard + USB mouse +No console specified using screen & keyboard + + Welcome to Open Firmware + + Copyright (c) 2004, 2011 IBM Corporation All rights reserved. + This program and the accompanying materials are made available + under the terms of the BSD License available at + http://www.opensource.org/licenses/bsd-license.php + + +Trying to load: from: /pci@800000020000000/scsi@3 ... +E3404: Not a bootable device! +Trying to load: from: /pci@800000020000000/scsi@2 ... Successfully loaded +Linux ppc64le +#31-Ubuntu SMP F + + +@mdroth + +I don't think PPC supports kvm the same way as x86: + +ubuntu@alpine01:~/kvm$ qemu-system-ppc64 -enable-kvm -m 256 -display none -nographic -net nic -net user,net=10.0.0.0/8,host=10.0.0.1,hostfwd=tcp::2222-:22 -machine pseries -drive file=xenial-server-cloudimg-ppc64el-disk1.img,if=virtio -drive file=seed.iso,if=virtio +Could not access KVM kernel module: Permission denied +failed to initialize KVM: Permission denied + + +Quoting Mike Rushton (2016-04-05 16:47:29) +> @mdroth +> +> I don't think PPC supports kvm the same way as x86: +> +> ubuntu@alpine01:~/kvm$ qemu-system-ppc64 -enable-kvm -m 256 -display none -nographic -net nic -net user,net=10.0.0.0/8,host=10.0.0.1,hostfwd=tcp::2222-:22 -machine pseries -drive file=xenial-server-cloudimg-ppc64el-disk1.img,if=virtio -drive file=seed.iso,if=virtio +> Could not access KVM kernel module: Permission denied +> failed to initialize KVM: Permission denied + +-enable-kvm should work as expected on Power machines that support +KVM. + +You seem to be running the command as a normal user. KVM generally +requires a priviledged user. + + + +Sorry, I copied the wrong thing: + +sudo qemu-system-ppc64 -enable-kvm -m 256 -display none -nographic -net nic -net user,net=10.0.0.0/8,host=10.0.0.1,hostfwd=tcp::2222-:22 -machine pseries -drive file=xenial-server-cloudimg-ppc64el-disk1.img,if=virtio -drive file=seed.iso,if=virtio +ioctl(KVM_CREATE_VM) failed: 22 Invalid argument +failed to initialize KVM: Invalid argument + +Quoting Mike Rushton (2016-04-05 17:22:24) +> Sorry, I copied the wrong thing: +> +> sudo qemu-system-ppc64 -enable-kvm -m 256 -display none -nographic -net nic -net user,net=10.0.0.0/8,host=10.0.0.1,hostfwd=tcp::2222-:22 -machine pseries -drive file=xenial-server-cloudimg-ppc64el-disk1.img,if=virtio -drive file=seed.iso,if=virtio +> ioctl(KVM_CREATE_VM) failed: 22 Invalid argument +> failed to initialize KVM: Invalid argument + +Can you post the output of this from the host? + + cat /proc/cpuinfo | grep platform + +If it reports "PowerNV" then things should be working, so the error +needs investigation. + +If it reports "pSeries", then that's not a normally supported scenario +for running KVM (since your host is already running as virtualized +pSeries partition running on top of the pHyp hypervisor rather than +KVM). You *might* have KVM support via 'PR' mode as opposed to the normal +'HV' mode, but that's generally used to do nested virtualization on top +of a KVM HV guest. To do it on top of a pHyp guest partition is probably +not something that's been actively tested. + +I'd assume you're using PowerNV host, but you mentioned "PowerVM" +earlier which is synonymous with pHyp, so it warrants confirming. + +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1563887 +> +> Title: +> qemu-system-ppc64 freezes on starting image on ppc64le +> +> Status in QEMU: +> New +> Status in linux package in Ubuntu: +> Confirmed +> Status in livecd-rootfs package in Ubuntu: +> New +> Status in qemu package in Ubuntu: +> Confirmed +> +> Bug description: +> qemu-system-ppc64 running on Ubuntu 16.04 beta-2 fails to start an +> image as part of the certification process. This on an IBM ppc64le in +> PowerVM mode running Ubuntu 16.04 beta-2 deployed by MAAS 1.9.1. There +> is no error output. +> +> ubuntu@alpine01:~/kvm$ qemu-system-ppc64 -m 256 -display none -nographic -net nic -net user,net=10.0.0.0/8,host=10.0.0.1,hostfwd=tcp::2222-:22 -machine pseries -drive file=xenial-server-cloudimg-ppc64el-disk1.img,if=virtio -drive file=seed.iso,if=virtio +> WARNING: Image format was not specified for 'seed.iso' and probing guessed raw. +> Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. +> Specify the 'raw' format explicitly to remove the restrictions. +> +> SLOF ********************************************************************** +> QEMU Starting +> Build Date = Jan 29 2016 18:58:37 +> FW Version = buildd@ release 20151103 +> Press "s" to enter Open Firmware. +> +> Populating /vdevice methods +> Populating /vdevice/vty@71000000 +> Populating /vdevice/nvram@71000001 +> Populating /vdevice/l-lan@71000002 +> Populating /vdevice/v-scsi@71000003 +> SCSI: Looking for devices +> 8200000000000000 CD-ROM : "QEMU QEMU CD-ROM 2.5+" +> Populating /pci@800000020000000 +> 00 1800 (D) : 1af4 1001 virtio [ block ] +> 00 1000 (D) : 1af4 1001 virtio [ block ] +> 00 0800 (D) : 106b 003f serial bus [ usb-ohci ] +> 00 0000 (D) : 1234 1111 qemu vga +> No NVRAM common partition, re-initializing... +> Installing QEMU fb +> +> Scanning USB +> OHCI: initializing +> USB Keyboard +> USB mouse +> No console specified using screen & keyboard +> +> Welcome to Open Firmware +> +> Copyright (c) 2004, 2011 IBM Corporation All rights reserved. +> This program and the accompanying materials are made available +> under the terms of the BSD License available at +> http://www.opensource.org/licenses/bsd-license.php +> +> Trying to load: from: /pci@800000020000000/scsi@3 ... +> E3404: Not a bootable device! +> Trying to load: from: /pci@800000020000000/scsi@2 ... Successfully loaded +> Linux ppc64le +> #31-Ubuntu SMP F +> +> ProblemType: Bug +> DistroRelease: Ubuntu 16.04 +> Package: qemu-system-ppc 1:2.5+dfsg-5ubuntu6 +> ProcVersionSignature: Ubuntu 4.4.0-16.32-generic 4.4.6 +> Uname: Linux 4.4.0-16-generic ppc64le +> ApportVersion: 2.20-0ubuntu3 +> Architecture: ppc64el +> Date: Wed Mar 30 14:10:01 2016 +> KvmCmdLine: +> COMMAND STAT EUID RUID PID PPID %CPU COMMAND +> kvm-irqfd-clean S< 0 0 1172 2 0.0 [kvm-irqfd-clean] +> qemu-nbd Ssl 0 0 13467 1 0.0 qemu-nbd -c /dev/nbd0 xenial-server-cloudimg-ppc64el-disk1.img +> qemu-system-ppc Sl+ 1000 1000 18973 18896 101 qemu-system-ppc64 -m 256 -display none -nographic -net nic -net user,net=10.0.0.0/8,host=10.0.0.1,hostfwd=tcp::2222-:22 -machine pseries -drive file=xenial-server-cloudimg-ppc64el-disk1.img,if=virtio -drive file=seed.iso,if=virtio +> Lsusb: Error: command ['lsusb'] failed with exit code 1: +> ProcEnviron: +> TERM=xterm +> PATH=(custom, no user) +> LANG=en_US.UTF-8 +> SHELL=/bin/bash +> ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinux-4.4.0-16-generic root=UUID=92d820c8-ab25-497b-9b1e-f1435992bbf3 ro +> ProcLoadAvg: 1.08 0.94 0.58 2/616 19571 +> ProcLocks: +> 1: POSIX ADVISORY WRITE 886 00:13:381 0 EOF +> 2: POSIX ADVISORY WRITE 1339 00:13:528 0 EOF +> 3: FLOCK ADVISORY WRITE 1284 00:13:522 0 EOF +> 4: POSIX ADVISORY WRITE 2281 00:13:563 0 EOF +> 5: POSIX ADVISORY WRITE 1331 00:13:536 0 EOF +> ProcSwaps: +> Filename Type Size Used Priority +> /swap.img file 8388544 0 -1 +> ProcVersion: Linux version 4.4.0-16-generic (buildd@bos01-ppc64el-001) (gcc version 5.3.1 20160320 (Ubuntu/Linaro/IBM 5.3.1-12ubuntu4) ) #32-Ubuntu SMP Thu Mar 24 22:31:14 UTC 2016 +> SourcePackage: qemu +> UpgradeStatus: No upgrade log present (probably fresh install) +> bootlist: +> /pci@800000020000011/pci1014,034A@0/sas/disk@4068402c40 +> /pci@800000020000018/ethernet@0:speed=auto,duplex=auto,csarch,000.000.000.000,,000.000.000.000,000.000.000.000,5,5,000.000.000.000,512 +> /pci@800000020000018/ethernet@0,1:speed=auto,duplex=auto,csarch,000.000.000.000,,000.000.000.000,000.000.000.000,5,5,000.000.000.000,512 +> /pci@800000020000018/ethernet@0,2:speed=auto,duplex=auto,csarch,000.000.000.000,,000.000.000.000,000.000.000.000,5,5,000.000.000.000,512 +> /pci@800000020000018/ethernet@0,3:speed=auto,duplex=auto,csarch,000.000.000.000,,000.000.000.000,000.000.000.000,5,5,000.000.000.000,512 +> cpu_cores: Number of cores present = 8 +> cpu_coreson: Number of cores online = 8 +> cpu_smt: SMT=8 +> lscfg_vp: Error: [Errno 2] No such file or directory: 'lscfg' +> lsmcode: Error: [Errno 2] No such file or directory: 'lsmcode' +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1563887/+subscriptions +> + + + +The PowerVM machine I've been using for these tests has the following output: + +ubuntu@alpine01:~/kvm$ cat /proc/cpuinfo | grep platform +platform : pSeries + + +The PowerNV server has the following output: + +ubuntu@binacle:~$ cat /etc/issue; uname -a ; ppc64_cpu --smt ; cat /proc/cpuinfo |grep platform +Ubuntu Xenial Xerus (development branch) \n \l + +Linux binacle 4.4.0-17-generic #33-Ubuntu SMP Tue Mar 29 17:15:31 UTC 2016 ppc64le ppc64le ppc64le GNU/Linux +SMT is off +platform : PowerNV + +ubuntu@binacle:~$ sudo qemu-system-ppc64 -enable-kvm -m 256 -display none -nographic -net nic -net user,net=10.0.0.0/8,host=10.0.0.1,hostfwd=tcp::2222-:22 -machine pseries -drive file=xenial-server-cloudimg-ppc64el-disk1.img,if=virtio -drive file=seed.iso,if=virtio +WARNING: Image format was not specified for 'seed.iso' and probing guessed raw. + Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. + Specify the 'raw' format explicitly to remove the restrictions. + + +SLOF ********************************************************************** +QEMU Starting + Build Date = Jan 29 2016 18:58:37 + FW Version = buildd@ release 20151103 + Press "s" to enter Open Firmware. + +Populating /vdevice methods +Populating /vdevice/vty@71000000 +Populating /vdevice/nvram@71000001 +Populating /vdevice/l-lan@71000002 +Populating /vdevice/v-scsi@71000003 + SCSI: Looking for devices + 8200000000000000 CD-ROM : "QEMU QEMU CD-ROM 2.5+" +Populating /pci@800000020000000 + 00 1800 (D) : 1af4 1001 virtio [ block ] + 00 1000 (D) : 1af4 1001 virtio [ block ] + 00 0800 (D) : 106b 003f serial bus [ usb-ohci ] + 00 0000 (D) : 1234 1111 qemu vga +No NVRAM common partition, re-initializing... +Installing QEMU fb + + + +Scanning USB + OHCI: initializing + USB Keyboard + USB mouse +No console specified using screen & keyboard + + Welcome to Open Firmware + + Copyright (c) 2004, 2011 IBM Corporation All rights reserved. + This program and the accompanying materials are made available + under the terms of the BSD License available at + http://www.opensource.org/licenses/bsd-license.php + + +Trying to load: from: /pci@800000020000000/scsi@3 ... +E3404: Not a bootable device! +Trying to load: from: /pci@800000020000000/scsi@2 ... Successfully loaded +Linux ppc64le +#32-Ubuntu SMP T + +Ok so if I'm following this right there are two issues: + +1. the bug reporter is using a powervm partition. KVM cannot be used there. This is not a KVM bug. + +2. the xenial cloud images have an outdated 4.2 kernel which doesn't boot in kvm on powernv. A workaround is to use the isos which do boot. This is a cloud-images bug. + +AFAICS there is no qemu bug here, so marking invalid for that package. + +1. the bug reporter is using a powervm partition. KVM cannot be used there. This is not a KVM bug. + +PowerVM mode is an LPAR. It is not a kvm instance trying to run an KVM within. This was also working in 14.04 without issue and is being asked of us from IBM to certify + +2. the xenial cloud images have an outdated 4.2 kernel which doesn't boot in kvm on powernv. A workaround is to use the isos which do boot. This is a cloud-images bug. + +All the Xenial daily images i've been using from MAAS deployments have been the 4.4 kernel which is still not working. + +I have also shown that this issue has the exact same results on PowerNV above. + + + +ok. so after playing some, this all comes down to needing 'usb=off' on the qemu command line. + +works: +qemu-system-ppc64 -enable-kvm -machine usb=off -device virtio-net-pci,netdev=net00 -netdev type=user,id=net00 -drive if=virtio,file=xenial-server-cloudimg-ppc64el-disk1.img,format=qcow2 -drive if=virtio,file=my-seed.img,format=raw -snapshot -m 256 -nographic + + +doesnt work: +qemu-system-ppc64 -enable-kvm virtio-net-pci,netdev=net00 -netdev type=user,id=net00 -drive if=virtio,file=xenial-server-cloudimg-ppc64el-disk1.img,format=qcow2 -drive if=virtio,file=my-seed.img,format=raw -snapshot -m 256 -nographic + + +the interesting bit of 'doesnt work' is that it *does* work, the user just thinks it doesnt because output is eaten up and doesnt go to console, but it *does* work fine. +http://paste.ubuntu.com/15660816/ + +Note, that Michael Roth's comments are probably valid. I suspect that if leftyfb ever saw this working on powerVM host, then it was through the kvm_pr module. In my experience, that works generally pretty well (buit my testing has only ever been done powerNV host). + +@leftyfb - what exactly is IBM asking to verify? Whether kvm works under powervm? Did smoser's info help? + +Here's an update. + +The Xenial kernel doesn;t like the emulated POWER7 cpu that the command line being used generates by default. + +processor : 0 +cpu : POWER7 (raw), altivec supported +clock : 1000.000000MHz +revision : 2.3 (pvr 003f 0203) + +timebase : 512000000 +platform : pSeries +model : IBM pSeries (emulated by qemu) +machine : CHRP IBM pSeries (emulated by qemu) + +We can boot a Wily image (kernel 4.2.0-35) just fine with the POWER7 cpu. + + +When booting Xenial's kernel with POWER7 cpu, it produces a stacktrace during module load: + +[ 9.885165] Loaded X.509 cert 'Build time autogenerated kernel key: 6687eed33bf99302166296c3e5cafe31ef38ad41' +[ 9.886507] zswap: loaded using pool lzo/zbud +[ 9.916000] modprobe[74]: unhandled signal 4 at 00003fffb5a4d03c nip 00003fffb5a4d03c lr 00003fffb5a25e24 code 30001 +[ 9.925819] modprobe[76]: unhandled signal 4 at 00003fff85b9d03c nip 00003fff85b9d03c lr 00003fff85b75e24 code 30001 +[ 9.928401] Key type trusted registered +[ 9.930762] modprobe[79]: unhandled signal 4 at 00003fff7d05d03c nip 00003fff7d05d03c lr 00003fff7d035e24 code 30001 +[ 9.933360] modprobe[80]: unhandled signal 4 at 00003fff8820d03c nip 00003fff8820d03c lr 00003fff881e5e24 code 30001 +[ 9.936240] modprobe[83]: unhandled signal 4 at 00003fffb4fbd03c nip 00003fffb4fbd03c lr 00003fffb4f95e24 code 30001 +[ 9.938873] modprobe[84]: unhandled signal 4 at 00003fff92d4d03c nip 00003fff92d4d03c lr 00003fff92d25e24 code 30001 +[ 9.940335] Key type encrypted registered +[ 9.940461] AppArmor: AppArmor sha1 policy hashing enabled +[ 9.941005] ima: No TPM chip found, activating TPM-bypass! +[ 9.942985] evm: HMAC attrs: 0x1 +[ 9.947081] hctosys: unable to open rtc device (rtc0) +[ 9.987867] Freeing unused kernel memory: 6144K (c000000000ea0000 - c0000000014a0000) +[ 9.991123] init[1]: unhandled signal 4 at 00003fff8edfd03c nip 00003fff8edfd03c lr 00003fff8edd5e24 code 30001 +[ 9.994581] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004 +[ 9.994581] +[ 9.994889] CPU: 0 PID: 1 Comm: init Not tainted 4.4.0-18-generic #34-Ubuntu +[ 9.995054] Call Trace: +[ 9.995216] [c00000001e4c3a50] [c000000000aed6fc] dump_stack+0xb0/0xf0 (unreliable) +[ 9.995336] [c00000001e4c3a90] [c000000000ae9930] panic+0x100/0x2c0 +[ 9.995398] [c00000001e4c3b20] [c0000000000bd554] do_exit+0xc24/0xc30 +[ 9.995443] [c00000001e4c3be0] [c0000000000bd644] do_group_exit+0x64/0x100 +[ 9.995490] [c00000001e4c3c20] [c0000000000ceaac] get_signal+0x55c/0x7b0 +[ 9.995534] [c00000001e4c3d10] [c000000000017424] do_signal+0x54/0x2b0 +[ 9.995578] [c00000001e4c3e00] [c00000000001787c] do_notify_resume+0xbc/0xd0 +[ 9.995677] [c00000001e4c3e30] [c000000000009838] ret_from_except_lite+0x64/0x68 +[ 10.011069] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004 +[ 10.011069] + + +When we use -enable-kvm, this bypasses the tcg POWER7 cpu, and uses the host cpu type (POWER8) which is why we can boot the Xenial kernel with KVM. + +We need to open a linux task to help track down that issue; also if someone is testing Xenial on POWER7 hardware, that may help determine if there is a lurking qemu tcg issue, though given that Wily kernels boot fine in tcg mode; it's more likely there's something that changed/broke in the kernels since 4.2.0-35. + +I'm marking the qemu task invalid, and will open the linux task. + + +I should also mention that the original command used will work if we specify which cpu type to use: + +qemu-system-ppc64 -m 256 \ + -cpu POWER8 \ + -display none -nographic \ + -net nic -net user,net=10.0.0.0/8,host=10.0.0.1,hostfwd=tcp::2222-:22 \ + -machine pseries \ + -drive file=xenial-server-cloudimg-ppc64el-disk1.img,if=virtio \ + -drive file=seed.iso,if=virtio + + + +Build target was changed to P8 starting with Xenial. Previously it had been a P7 target. I would expect Xenial kernel to have problems booting on a P7 model. IMO this kernel bug is invalid. + +As noted, Xenial kernel is not supporting POWER7 cpu. + +TL;DR: pass '-vga none' with -nographic, or redirect the screen somewhere! + +I ended up digging into this after it was mentioned by smoser. The bug is invalid because of a bad assumption in the QEMU inputs. smoser's workaround of usb=off removes USB as a workaround. + +The kernel, OpenFirmware, and QEMU are behaving correctly, but the original command-line hides the screen output. + +If you have both a supported* keyboard AND screen, then OpenFirmware/SLOF sets OF stdout to be the screen. +This causes the OF output of 'No console specified using screen & keyboard' + +If you are missing either a keyboard OR screen, then OF sets stdout to be hvterm (serial). +This causes the OF output of 'No console specified using hvterm' + +https://git.qemu.org/?p=SLOF.git;a=blob;f=board-qemu/slof/OF.fs;h=4e04b840d5e6ff6c39191939e1a4f70f3d169d5d;hb=HEAD#l215 + +Which devices are available depends on the QEMU commandline... +Base QEMU defaults to '-vga std'. +QEMU '-machine pseries' defaults to enabling USB. + + +Re supported keyboards: The OpenFirmware/SLOF only seems to support USB keyboards at this time (virtio keyboard not supported). + +Thanks for the Detail Robin! + diff --git a/results/classifier/105/mistranslation/1566 b/results/classifier/105/mistranslation/1566 new file mode 100644 index 000000000..25895e758 --- /dev/null +++ b/results/classifier/105/mistranslation/1566 @@ -0,0 +1,22 @@ +mistranslation: 0.809 +device: 0.793 +socket: 0.686 +vnc: 0.683 +network: 0.609 +graphic: 0.595 +instruction: 0.482 +semantic: 0.452 +boot: 0.376 +KVM: 0.149 +assembly: 0.109 +other: 0.034 + +qemo-8-0-0-rc2 error: redeclaration of 'enum fsconfig_command' +Description of problem: + +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/105/mistranslation/1568621 b/results/classifier/105/mistranslation/1568621 new file mode 100644 index 000000000..52e0594df --- /dev/null +++ b/results/classifier/105/mistranslation/1568621 @@ -0,0 +1,47 @@ +mistranslation: 0.701 +other: 0.631 +boot: 0.590 +instruction: 0.584 +vnc: 0.551 +KVM: 0.547 +device: 0.547 +assembly: 0.525 +network: 0.487 +graphic: 0.479 +semantic: 0.470 +socket: 0.436 + +input-linux misdetects Logitech keyboard as a mouse + +The new input-linux.c code misdetects my Logitech K350 keyboard as a mouse. The bug is in the input_linux_complete function. The evdev for this keyboard returns an "evtmap" with the EV_REL bit set. Full evtmap is 0x0012001F. Using a different keyboard everything works as intended, so my configuration and setup are correct otherwise. + + +Suggestion: + +I suggest adding an object property called something like "type" where the user can specify what the device type is manually. This K350 keyboard shows that "evtmap" cannot be used to reliably detect the device type. Since specifying the device type manually is not an undue burden, perhaps it should be a required option and there should be no autodetection? + + +System: + +Arch linux, using qemu-git AUR package installed 20160409. + + +Command line: + +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=none /usr/sbin/qemu-system-x86_64 -name win10,debug-threads=on -S -machine pc-i440fx-2.4,accel=kvm,usb=off,vmport=off -cpu host,kvm=off -drive file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd,if=pflash,format=raw,unit=0,readonly=on -drive file=/var/lib/libvirt/qemu/nvram/win10_VARS.fd,if=pflash,format=raw,unit=1 -m 8196 -realtime mlock=off -smp 8,sockets=1,cores=4,threads=2 -uuid 58623778-9d9d-4d30-8ec0-b37e12a30fdc -nographic -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-17-win10/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 -drive file=/var/lib/libvirt/images/ISOs/Win10_1511_English_x64.iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on -device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 -drive file=/var/lib/libvirt/images/ISOs/virtio-win-0.1.112.iso,format=raw,if=none,id=drive-ide0-1-0,readonly=on -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive file=/dev/sda,format=raw,if=none,id=drive-virtio-disk1 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x8,drive=drive-virtio-disk1,id=virtio-disk1,bootindex=1 -netdev tap,fd=26,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:70:8a:db,bus=pci.0,addr=0x3 -netdev tap,fd=28,id=hostnet1 -device rtl8139,netdev=hostnet1,id=net1,mac=d4:be:d9:56:2e:35,bus=pci.0,addr=0x9 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device vfio-pci,host=04:00.0,id=hostdev0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -object input-linux,id=kbd1,evdev=/dev/input/event19,grab_all=on -object input-linux,id=kbb2,evdev=/dev/input/event2 -msg timestamp=on + +The QEMU project is currently considering to move 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/105/mistranslation/1573 b/results/classifier/105/mistranslation/1573 new file mode 100644 index 000000000..fe2b2958a --- /dev/null +++ b/results/classifier/105/mistranslation/1573 @@ -0,0 +1,14 @@ +mistranslation: 0.808 +other: 0.688 +network: 0.380 +device: 0.256 +semantic: 0.192 +boot: 0.096 +vnc: 0.089 +graphic: 0.088 +instruction: 0.050 +socket: 0.038 +assembly: 0.033 +KVM: 0.006 + +TCP Previous segment not captured diff --git a/results/classifier/105/mistranslation/1577841 b/results/classifier/105/mistranslation/1577841 new file mode 100644 index 000000000..bc27b1e48 --- /dev/null +++ b/results/classifier/105/mistranslation/1577841 @@ -0,0 +1,30 @@ +mistranslation: 0.980 +instruction: 0.920 +device: 0.850 +socket: 0.788 +semantic: 0.752 +network: 0.711 +vnc: 0.656 +graphic: 0.523 +assembly: 0.493 +other: 0.466 +boot: 0.441 +KVM: 0.288 + +target-mips/helper.c:542: bad sizeof ? + +Recent versions of gcc say this: + +qemu/target-mips/helper.c:542:9: warning: ‘memset’ used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size] + +Source code is + + memset(env->CP0_WatchLo, 0, sizeof(*env->CP0_WatchLo)); + +Maybe better code + + memset(env->CP0_WatchLo, 0, 8 * sizeof(target_ulong)); + +Fix has been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=9d989c732b153fe15 + diff --git a/results/classifier/105/mistranslation/1579306 b/results/classifier/105/mistranslation/1579306 new file mode 100644 index 000000000..521d0573d --- /dev/null +++ b/results/classifier/105/mistranslation/1579306 @@ -0,0 +1,85 @@ +mistranslation: 0.887 +semantic: 0.868 +instruction: 0.852 +other: 0.852 +graphic: 0.849 +assembly: 0.848 +device: 0.827 +vnc: 0.765 +socket: 0.762 +KVM: 0.736 +network: 0.707 +boot: 0.702 + +usb-uas does not work in Windows (10) guest + +When I attach a "-device usb-uas" to a VM with Windows 10 10586, the device fail to start with the following error in the guest: + +"The device cannot start. (Code 10) + +{Operation Failed} +The requested operation was unsuccessful" + +If the host controller is nec-usb-xhci, there will be two of the following error on the terminal of the host as well: + +"qemu-system-x86_64: usb_uas_handle_control: unhandled control request" + +If it's usb-ehci, ich9-usb-ehci1 or ich9-usb-echi2, this will not show up on the host side, but the device stil fails with the same error on the guest side. + + + +usb-bot works fine + +Also tried to "passthrough" the SCSI layer of an actual UASP drive with scsi-block. No luck either. + +Not sure if it's relevant, but when I try completely passthrough a UASP device to the VM through usb-host, only the BOT/MSC part is exposed. This is not the case when I do the same thing to a Linux guest (btw usb-uas apparently works fine in Linux guest as well). + +I am using qemu-2.5.1. Here are the commands I used in the test cases: + +qemu-system-x86_64 -enable-kvm -cpu host -m 2G -net none -full-screen -drive file=disks/uas.qcow2,format=qcow2,cache=none,aio=native -drive file=test.img,format=raw,if=none,id=test -device nec-usb-xhci -device usb-uas -device scsi-hd,drive=test + +qemu-system-x86_64 -enable-kvm -cpu host -m 2G -net none -full-screen -drive file=disks/uas.qcow2,format=qcow2,cache=none,aio=native -drive file=test.img,format=raw,if=none,id=test -device nec-usb-xhci -device usb-bot -device scsi-hd,drive=test + +qemu-system-x86_64 -enable-kvm -cpu host -m 2G -net none -full-screen -drive file=disks/uas.qcow2,format=qcow2,cache=none,aio=native -drive file=/dev/sdc,format=raw,if=none,id=test -device nec-usb-xhci -device usb-uas -device scsi-block,drive=test + +qemu-system-x86_64 -enable-kvm -cpu host -m 2G -net none -full-screen -drive file=disks/uas.qcow2,format=qcow2,cache=none,aio=native -device nec-usb-xhci -device usb-host,hostbus=2,hostport=6 + +Also tried to "passthrough" the SCSI layer of an actual UASP drive with scsi-block. No luck either. + +Not sure if it's relevant, but when I try completely passthrough a UASP device to the VM through usb-host, only the BOT/MSC part is exposed. This is not the case when I do the same thing to a Linux guest (btw usb-uas apparently works fine in Linux guest as well). + +I am also facing this issue. + +On further probing, I found out that usb-uas in Qemu doesn't support "SET_SEL" control command due to which windows driver "uaspstor.sys" couldn't complete the enumeration. + +It is clearly mentioned in USB 3.1 specs that uasp devices should handle two new control commands - SET_SEL and SET_ISOCH_DELAY. + + + +Just echoing Tom Yan's comment; I've tried passing through what appears to be the very same device (if not, at least the same UAS-SATA bridge) to a VM in its entirety. + +I can confirm the same result - with an otherwise identical domain configuration, Linux guests correctly use the UAS driver: + +/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M + |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M +/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M + + +Whereas Windows guests fall back to BOT/MSC: + +<see attached image> + + +In both cases, QEMU is being run via libvirt, which is generating the following command line: + +/usr/bin/qemu-system-x86_64 -name guest=Win10-Edge-IE11,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-13-Win10-Edge-IE11/master-key.aes -machine pc-q35-2.7,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu host,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -m 4096 -realtime mlock=off -smp 8,sockets=1,cores=4,threads=2 -uuid 47c39707-088c-4edc-8b6a-a7856e09f43d -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-13-Win10-Edge-IE11/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 -boot strict=on -device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1e -device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x0 -device nec-usb-xhci,id=usb,bus=pci.2,addr=0x6 -device virtio-scsi-pci,id=scsi0,bus=pci.2,addr=0x3 -device virtio-serial-pci,id=virtio-serial0,bus=pci.2,addr=0x4 -drive file=/home/jack/IMG/Win10-Edge-IE11.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0,discard=unmap -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -drive if=none,id=drive-scsi0-0-0-1,readonly=on -device scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1 -netdev tap,fd=22,id=hostnet0,vhost=on,vhostfd=24 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:27:94:5d,bus=pci.2,addr=0x1 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0,bus=usb.0,port=2 -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pcie.0,addr=0x1 -device intel-hda,id=sound0,bus=pci.2,addr=0x2 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=3 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=4 -device usb-host,hostbus=4,hostaddr=4,id=hostdev0,bus=usb.0,port=1 -device virtio-balloon-pci,id=balloon0,bus=pci.2,addr=0x5 -msg timestamp=on + +I think they are two separate issues in usb-uas and usb-host respectively. I probably should not have bring in the usb-host case here but create another report for it. + +Noted, I've created https://bugs.launchpad.net/qemu/+bug/1648726 to track the issue with passing through physical UAS devices. + +The QEMU project is currently considering to move 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 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/105/mistranslation/1579327 b/results/classifier/105/mistranslation/1579327 new file mode 100644 index 000000000..6b5335105 --- /dev/null +++ b/results/classifier/105/mistranslation/1579327 @@ -0,0 +1,295 @@ +mistranslation: 0.815 +vnc: 0.706 +assembly: 0.706 +KVM: 0.704 +instruction: 0.695 +device: 0.695 +graphic: 0.668 +semantic: 0.644 +boot: 0.626 +other: 0.619 +socket: 0.566 +network: 0.504 + +emulation of vexpress-a9 vexpress-a15 in multicore mode seems to be broken + +Report based on: +https://stackoverflow.com/questions/37068688/have-you-got-issues-with-running-u-boot-for-versatile-express-a9-platform-under + +I don't see any bug reports about vexpress boards emulation here, so I decided to let you know: + +version tested: qemu 2.0.0 on 32 bit Debian GNU/Linux + +There are issues with running u-boot on qemu vexpress-a9 ( it was reported to work ok at physical multicore board ) and vexpress-a15 with parameters -smp cores=2 r 3 or 4. +So far those are two tested. I dont know ATM if any other board emulation works in multiprocessor mode + +Original post at stackoverflow: +--------------------------------------------------------------------------------------------------- +I have tried numerous releases of u-boot since vexpress-a9 was introduced in u-bot stable release. Under qemu with multicore emulation its behaving unstable - mostly crashes instantly after loading. Sometimes it loads without issues but its rare. My version of qemu is 2.0.0 on x86 32bit Debian. I would be interested to hear if you succeeded in runing it under qemu with multicore emulation ( if yes which version of qemu and u-boot ) or physical versatile express board with multiple cores. + +Example outputs are + +$ qemu-system-arm -M vexpress-a9 -nographic -kernel u-boot -smp cores=2 +U-Boot 2013.01.01-dirty (May 05 2016 - 08:27:19) + +DRAM: 128 MiB +WARNING: Caches not enabled +undefined instruction +pc : [<00000000>] lr : [<00000000>] +sp : 60000ef0 ip : 67eedfd8 fp : 00000000 +r10: 00000000 r9 : 00000000 r8 : 60000f00 +r7 : 00000000 r6 : 608146ac r5 : 60828365 r4 : 0000004d +r3 : 00000000 r2 : 00000000 r1 : 60000f80 r0 : 47cc9e10 +Flags: nzcv IRQs on FIQs on Mode USER_26 +Resetting CPU ... +resetting ... +Flash: 256 MiB +MMC: MMC: 0 +*** Warning - bad CRC, using default environment + +In: serial +Out: serial +Err: serial +Net: smc911x-0 +Warning: smc911x-0 using MAC address from net device + +Hit any key to stop autoboot: 0 +Wrong Image Format for bootm command +ERROR: can't get kernel image! +VExpress# + +This time it was loaded + +Other time it was not... + +$ qemu-system-arm -M vexpress-a9 -nographic -kernel u-boot -smp cores=2 + + +U-Boot 2013.01.01-dirty (May 05 2016 - 08:27:19) + +DRAM: 128 MiB +WARNING: Caches not enabled + + +U-Boot 2013.01.01-dirty (May 05 2016 - 08:27:19) + +DRAM: 128 MiB +WARNING: Caches not enabled +Flash: 256 MiB +MMC: MMC: 0 +*** Warning - bad CRC, using default environment + +In: serial +Out: serial +Err: serial +Net: smc911x-0 +Warning: smc911x-0 using MAC address from net device + +Hit any key to stop autoboot: 2 qemu: fatal: Trying to execute code outside RAM or ROM at 0x6f71c004 + +R00=00418937 R01=000003e8 R02=00418937 R03=00000000 +R04=00000000 R05=67eedf58 R06=67f8e000 R07=00000002 +R08=00418937 R09=0778e000 R10=6082f688 R11=00000000 +R12=67eedfd8 R13=00000000 R14=67fb82c0 R15=6f71c004 +PSR=200001db --C- A und32 +s00=00000000 s01=00000000 d00=0000000000000000 +s02=00000000 s03=00000000 d01=0000000000000000 +s04=00000000 s05=00000000 d02=0000000000000000 +s06=00000000 s07=00000000 d03=0000000000000000 +s08=00000000 s09=00000000 d04=0000000000000000 +s10=00000000 s11=00000000 d05=0000000000000000 +vs12=00000000 s13=00000000 d06=0000000000000000 +s14=00000000 s15=00000000 d07=0000000000000000 +s16=00000000 s17=00000000 d08=0000000000000000 +s18=00000000 s19=00000000 d09=0000000000000000 +s20=00000000 s21=00000000 d10=0000000000000000 +s22=00000000 s23=00000000 d11=0000000000000000 +s24=00000000 s25=00000000 d12=0000000000000000 +s26=00000000 s27=00000000 d13=0000000000000000 +s28=00000000 s29=00000000 d14=0000000000000000 +s30=00000000 s31=00000000 d15=0000000000000000 +s32=00000000 s33=00000000 d16=0000000000000000 +s34=00000000 s35=00000000 d17=0000000000000000 +s36=00000000 s37=00000000 d18=0000000000000000 +s38=00000000 s39=00000000 d19=0000000000000000 +s40=00000000 s41=00000000 d20=0000000000000000 +s42=00000000 s43=00000000 d21=0000000000000000 +s44=00000000 s45=00000000 d22=0000000000000000 +s46=00000000 s47=00000000 d23=0000000000000000 +s48=00000000 s49=00000000 d24=0000000000000000 +s50=00000000 s51=00000000 d25=0000000000000000 +s52=00000000 s53=00000000 d26=0000000000000000 +s54=00000000 s55=00000000 d27=0000000000000000 +s56=00000000 s57=00000000 d28=0000000000000000 +s58=00000000 s59=00000000 d29=0000000000000000 +s60=00000000 s61=00000000 d30=0000000000000000 +s62=00000000 s63=00000000 d31=0000000000000000 +FPSCR: 00000000 +------------------------------------------------------------------------------------------------- +end of post + +Original discussion at ( includes comments of head custodian of Das U-boot about u-boot working on physical board versatile express a9 and him having issues with runing Linux distro at qemu vexpress-a9 board emulation ): +https://stackoverflow.com/questions/37068688/have-you-got-issues-with-running-u-boot-for-versatile-express-a9-platform-under + +On 7 May 2016 at 09:08, embedded0n3 <email address hidden> wrote: +> Public bug reported: +> +> Report based on: +> https://stackoverflow.com/questions/37068688/have-you-got-issues-with-running-u-boot-for-versatile-express-a9-platform-under +> +> I don't see any bug reports about vexpress boards emulation here, so I +> decided to let you know: +> +> version tested: qemu 2.0.0 on 32 bit Debian GNU/Linux + +This version of QEMU is now five major releases old. Please can +you retry with the most recent the QEMU 2.6.0 release candidate, +or with QEMU master from git and see if your problems are still +present? + +thanks +-- PMM + + +Yes, there are still problems on qemu 2.6.0 release candidate and 2.5.1 with same version of u-boot as mentioned and with latest stable u-boot release. When qemu has parameter -smp cores=2 or 3 or 4. + +errors are: +qemu: fatal: Trying to execute code outside RAM or ROM at 0x31306c70 +That adress changes but is mostly close to that example value ("8 digits" adress) +as mentioned in previous posted bugreport + +Sometimes runing U-boot(?) hangs but I can exit qemu using keys Ctrl-a x +And that seems to be new behaviour. + +- - - - - - - - - - - - +If someone is interested how to build u-boot for further testing of this issue on his own box + + $ git clone git://git.denx.de/u-boot.git + $ cd u-boot + $ make vexpress_ca9x4_defconfig ARCH=arm CROSS_COMPILE=arm-none-eabi + $ make all_ca9x4_defconfig ARCH=arm CROSS_COMPILE=arm-none-eabi + + +Sorry, missed '-' character at the end of command obviously. It shaould be: + + $ make vexpress_ca9x4_defconfig ARCH=arm CROSS_COMPILE=arm-none-eabi- + $ make all_ca9x4_defconfig ARCH=arm CROSS_COMPILE=arm-none-eabi- + + +And if this is not clear - in all cases everything was OK when emulation was started without -smp cors=2 or 3 or 4. By OK i mean there was no + qemu: fatal: Trying to execute code outside RAM or ROM at 0xXXXXXXXX +errors and I was able to execute some comands like help and printenv and nothing happened when qemu was left open for time of 15 minutes ( sometimes in multicoe mulation mode error appeaed after about one and half minute if that time it loaded without almost instant eror message ). + +Does the u-boot binary you're running expect to work with SMP? Usually "Trying to execute code outside RAM or ROM" means "the guest binary did something badly wrong and jumped off to an invalid address", rather than being a QEMU bug. + + +Does -smp cores=4 means qemu is emulaing versatile espress a9 with 4 cores ( this is how versatile express board is designed - i mean it's a board with 4 cores cotex a9 ) and qemu without -smp parameter emalates jus single core ( unicore )? + +In case of versatile express a9 u-boot binary: + +U-boot was compilled from cofig file vexpress_ca9x4 - versatile express cortex a9 4cores + +U-boot configuration file is created to run on physical versatile a9 board. And this was confirmed by Tom Rini ( the head custodian of Das U-boot project as I see on his stackoverflow page ) to run without problems on physical 4 core versatile express a9 board ( see stackoverflow disscussion link in 1st message of this bug report ): + +Here is citation of his comment: + +>I have recently gotten confirmation that the real HW does work on current mainline U-Boot, +> but I can also replicate your failures. Interestingly, the real board is 4 cores, +> and I can (with the kernelci.org Linux kernel / device tree) run with -smp cores=2 +> but 3 and 4 result in soft lockups once userland starts. – Tom Rini 2 days ago + +So he even had more erors as he get further in linux boot process ( I stopped tests so far on just loading u-boot and waiting few minutes if it will fail suddenly, what happend ). As I said errors were quiet random, and sometimes appeard just after more than minute of inactivity, other times almost instantly after boot ). + +On 9 May 2016 at 13:47, embedded0n3 <email address hidden> wrote: +> Does -smp cores=4 means qemu is emulaing versatile espress a9 with 4 +> cores ( this is how versatile express board is designed - i mean it's a +> board with 4 cores cotex a9 ) and qemu without -smp parameter emalates +> jus single core ( unicore )? + +Yes. + +> U-boot configuration file is created to run on physical versatile a9 +> board. And this was confirmed by Tom Rini ( the head custodian of Das +> U-boot project as I see on his stackoverflow page ) to run without +> problems on physical 4 core versatile express a9 board ( see +> stackoverflow disscussion link in 1st message of this bug report ): +> +> Here is citation of his comment: +> +>>I have recently gotten confirmation that the real HW does work on current mainline U-Boot, +>> but I can also replicate your failures. Interestingly, the real board is 4 cores, +>> and I can (with the kernelci.org Linux kernel / device tree) run with -smp cores=2 +>> but 3 and 4 result in soft lockups once userland starts. – Tom Rini 2 days ago +> +> So he even had more erors as he get further in linux boot process ( I +> stopped tests so far on just loading u-boot and waiting few minutes if +> it will fail suddenly, what happend ). As I said errors were quiet +> random, and sometimes appeard just after more than minute of inactivity, +> other times almost instantly after boot ). + +The next phase is that somebody needs to debug what the u-boot code is +doing that causes it to crash (this is largely working with the guest +code, not trying to debug QEMU itself). + +thanks +-- PMM + + +I see. +I can take a look. +Could this procedure be helpfull in this case? Error message was similar but it was related to loading coreboot +http://blog.3mdeb.com/2014/08/07/debugging-coreboot-for-qemu-armv7-vexpress-a9-emulated-mainboard/ +Or there are better tools to do this job? + + +I found another typo In comment from last night about compilling u-boot. +This line + $ make all_ca9x4_defconfig ARCH=arm CROSS_COMPILE=arm-none-eabi- +should look: + $ make all ARCH=arm CROSS_COMPILE=arm-none-eabi- + + +I can confirm this bug with vexpress-a9. +I have tested with the following versions: +QEMU emulator version 2.4.1 (qemu-2.4.1-11.fc23), Copyright (c) 2003-2008 Fabrice Bellard +QEMU emulator version 2.7.0, Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers + +Here are the reproducing steps: +Get an ARM cross-compiler, and latest u-boot. +$ cd u-boot +$ make ARCH=arm CROSS_COMPILE=${CROSS_COMPILE} vexpress_ca9x4_defconfig +$ make ARCH=arm CROSS_COMPILE=${CROSS_COMPILE} + +# avoid audio errors +$ export QEMU_AUDIO_DRV=none +$ qemu-system-arm -M vexpress-a9 -m 1024 -smp 4 -nographic -kernel u-boot +U-Boot 2016.11-rc2-00090-g5ac5861-dirty (Oct 27 2016 - 14:46:54 +0300) + +DRAM: 1 GiB +WARNING: Caches not enabled +Flash: + +U-Boot 2016.11-rc2-00090-g5ac5861-dirty (Oct 27 2016 - 14:46:54 +0300) + +DRAM: 1 GiB +WARNING: Caches not enabled +Flash: + +U-Boot 2016.11-rc2-00090-g5ac5861-dirty (Oct 27 2016 - 14:46:54 +0300) + +DRAM: 1 GiB +WARNING: Caches not enabled +Flash: + +U-Boot 2016.11-rc2-00090-g5ac5861-dirty (Oct 27 2016 - 14:46:54 +0300) + +DRAM: 1 GiB +WARNING: Caches not enabled +Flash: Bad ram pointer (nil) +Aborted (core dumped) + + +I believe this is not a qemu boot since booting the kernel with -smp 4 works just fine, sorry for the noise + +Sounds like a U-Boot bug. Closing according to comment #11. + diff --git a/results/classifier/105/mistranslation/1580586 b/results/classifier/105/mistranslation/1580586 new file mode 100644 index 000000000..95bd6a22e --- /dev/null +++ b/results/classifier/105/mistranslation/1580586 @@ -0,0 +1,37 @@ +mistranslation: 0.794 +graphic: 0.785 +device: 0.669 +other: 0.652 +semantic: 0.631 +network: 0.595 +instruction: 0.588 +socket: 0.504 +vnc: 0.477 +boot: 0.412 +assembly: 0.326 +KVM: 0.161 + +Qemu WinXP SP3 second loadvm freezes Guest OS + +Using Qemu-system-i386 to run WinXP SP3 with the following command line: + +qemu-system-i386 -hda qcow2/windowsxp_32bits_dd.qcow2 -m 1024 -net user,smb=/shared -vga std -net nic,model=rtl8139 -rtc base=localtime,clock=vm -s -snapshot + +savevm works fine, and the first loadvm to the snapshot works properly, but the next ones will all freeze the guest OS. + +First I thought it was due to the clock but adding the rtc options did not fix it. + +Actually the following commands also produce the freeze : +savevm 1 +loadvm 1 +savevm 2 +loadvm 2 +Guest OS freezes. + + + +The QEMU project is currently considering to move 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 mark it as "Fix Released" if the problem has be + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1584 b/results/classifier/105/mistranslation/1584 new file mode 100644 index 000000000..fe2b2958a --- /dev/null +++ b/results/classifier/105/mistranslation/1584 @@ -0,0 +1,14 @@ +mistranslation: 0.808 +other: 0.688 +network: 0.380 +device: 0.256 +semantic: 0.192 +boot: 0.096 +vnc: 0.089 +graphic: 0.088 +instruction: 0.050 +socket: 0.038 +assembly: 0.033 +KVM: 0.006 + +TCP Previous segment not captured diff --git a/results/classifier/105/mistranslation/1586 b/results/classifier/105/mistranslation/1586 new file mode 100644 index 000000000..6d665ef02 --- /dev/null +++ b/results/classifier/105/mistranslation/1586 @@ -0,0 +1,120 @@ +mistranslation: 0.255 +graphic: 0.215 +vnc: 0.212 +device: 0.184 +assembly: 0.159 +KVM: 0.151 +instruction: 0.149 +other: 0.135 +boot: 0.129 +socket: 0.129 +semantic: 0.126 +network: 0.079 + +qemu-8.0.0-rc3 mock build test stage failures +Description of problem: +https://bugzilla.redhat.com/show_bug.cgi?id=2185288 +Following files have been attached to that report +Attached : +- The rpmuild SPEC file so far (qemu.spec.20230408.v3.txt) +- testlog.20230408.v3.txt +- build.log.20230408.v3.txt +- hw_info.log.20230408.v3.txt +- installed_pkgs.log.20230408.v3.txt +- root.log.20230408.v3.txt +- state.log.20230408.v3.txt + +A number of test failure involving allwinner-i2c and pci_expander_bridge + +``` +Summary of Failures: + + 39/817 qemu:qtest+qtest-aarch64 / qtest-aarch64/test-hmp ERROR 32.55s killed by signal 6 SIGABRT + 41/817 qemu:qtest+qtest-arm / qtest-arm/test-hmp ERROR 34.48s killed by signal 6 SIGABRT + 1/817 qemu:qtest+qtest-aarch64 / qtest-aarch64/qom-test ERROR 210.93s killed by signal 6 SIGABRT + 3/817 qemu:qtest+qtest-arm / qtest-arm/qom-test ERROR 212.50s killed by signal 6 SIGABRT + 45/817 qemu:qtest+qtest-i386 / qtest-i386/bios-tables-test ERROR 272.50s killed by signal 6 SIGABRT + 68/817 qemu:qtest+qtest-x86_64 / qtest-x86_64/bios-tables-test ERROR 286.06s killed by signal 6 SIGABRT +230/817 qemu:qtest+qtest-aarch64 / qtest-aarch64/device-introspect-test ERROR 8.92s killed by signal 6 SIGABRT +270/817 qemu:qtest+qtest-arm / qtest-arm/device-introspect-test ERROR 5.95s killed by signal 6 SIGABRT +337/817 qemu:qtest+qtest-i386 / qtest-i386/cxl-test ERROR 0.90s killed by signal 6 SIGABRT +630/817 qemu:qtest+qtest-x86_64 / qtest-x86_64/cxl-test ERROR 0.84s killed by signal 6 SIGABRT + +Ok: 737 +Expected Fail: 0 +Fail: 10 +Unexpected Pass: 0 +Skipped: 70 +Timeout: 0 + +``` + +The below includes a last line of log snippet for each failure +``` + + 39/817 qemu:qtest+qtest-aarch64 / qtest-aarch64/test-hmp ERROR 32.55s killed by signal 6 SIGABRT + /builddir/build/BUILD/qemu-8.0.0/include/hw/i2c/allwinner-i2c.h:35:AW_I2C: Object 0x7fec734903a0 is not an instance of type allwinner.i2c +Broken pipe +../tests/qtest/libqtest.c:193: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped) + + + 41/817 qemu:qtest+qtest-arm / qtest-arm/test-hmp ERROR 34.48s killed by signal 6 SIGABRT +/builddir/build/BUILD/qemu-8.0.0/include/hw/i2c/allwinner-i2c.h:35:AW_I2C: Object 0x55e683992440 is not an instance of type allwinner.i2c +Broken pipe +../tests/qtest/libqtest.c:193: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped) + + + 1/817 qemu:qtest+qtest-aarch64 / qtest-aarch64/qom-test ERROR 210.93s killed by signal 6 SIGABRT +/builddir/build/BUILD/qemu-8.0.0/include/hw/i2c/allwinner-i2c.h:35:AW_I2C: Object 0x7fbddaf123a0 is not an instance of type allwinner.i2c +Broken pipe +../tests/qtest/libqtest.c:193: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped) + + + 3/817 qemu:qtest+qtest-arm / qtest-arm/qom-test ERROR 212.50s killed by signal 6 SIGABRT +/builddir/build/BUILD/qemu-8.0.0/include/hw/i2c/allwinner-i2c.h:35:AW_I2C: Object 0x55c346ae4440 is not an instance of type allwinner.i2c +Broken pipe +../tests/qtest/libqtest.c:193: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped) + +45/817 qemu:qtest+qtest-i386 / qtest-i386/bios-tables-test ERROR 272.50s killed by signal 6 SIGABRT +../hw/pci-bridge/pci_expander_bridge.c:54:PXB_DEV: Object 0x5636d9f16fa0 is not an instance of type pxb +Broken pipe +../tests/qtest/libqtest.c:193: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped) + + +68/817 qemu:qtest+qtest-x86_64 / qtest-x86_64/bios-tables-test ERROR 286.06s killed by signal 6 SIGABRT +../hw/pci-bridge/pci_expander_bridge.c:54:PXB_DEV: Object 0x55e0736d8e20 is not an instance of type pxb +Broken pipe +../tests/qtest/libqtest.c:193: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped) + +230/817 qemu:qtest+qtest-aarch64 / qtest-aarch64/device-introspect-test ERROR 8.92s killed by signal 6 SIGABRT +/builddir/build/BUILD/qemu-8.0.0/include/hw/i2c/allwinner-i2c.h:35:AW_I2C: Object 0x55ab62324420 is not an instance of type allwinner.i2c +Broken pipe +../tests/qtest/libqtest.c:193: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped) + + +270/817 qemu:qtest+qtest-arm / qtest-arm/device-introspect-test ERROR 5.95s killed by signal 6 SIGABRT +----------------------------------- stderr ----------------------------------- +/builddir/build/BUILD/qemu-8.0.0/include/hw/i2c/allwinner-i2c.h:35:AW_I2C: Object 0x564fbf62ee90 is not an instance of type allwinner.i2c +Broken pipe +../tests/qtest/libqtest.c:193: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped) + + + +337/817 qemu:qtest+qtest-i386 / qtest-i386/cxl-test ERROR 0.90s killed by signal 6 SIGABRT +../hw/pci-bridge/pci_expander_bridge.c:54:PXB_DEV: Object 0x55c66482d5f0 is not an instance of type pxb +Broken pipe +../tests/qtest/libqtest.c:193: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped) + +630/817 qemu:qtest+qtest-x86_64 / qtest-x86_64/cxl-test ERROR 0.84s killed by signal 6 SIGABRT +../hw/pci-bridge/pci_expander_bridge.c:54:PXB_DEV: Object 0x5634e6278170 is not an instance of type pxb +Broken pipe +../tests/qtest/libqtest.c:193: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped) +``` +Steps to reproduce: +1. Populate rpmbuild folders with ```rpm -i qemu-7.2.0-7.fc39.srpm``` from https://koji.fedoraproject.org/koji/packageinfo?packageID=3685 +2. Download to ```~/rpmbuild/SOURCES/qemu-8.0.0.tar.xz``` from ```https://download.qemu.org/qemu-8.0.0-rc3.tar.xz``` +3. craft ```~/SPECS/qemu.spec``` for qemu-8.0.0-rc3 (or download attachment of bugzilla bug) +4. recreate new qemu-8.0.0 srpm ```rpmbuild -bs SPECS/qemu.spec``` +5. run ```mock -r /etc/mock/fedora-38-x86_64.cfg --rebuild ~/rpmbuild/SRPMS/qemu-8.0.0-0.fc38.src.rpm``` +Additional information: + diff --git a/results/classifier/105/mistranslation/1586229 b/results/classifier/105/mistranslation/1586229 new file mode 100644 index 000000000..e1b9e562a --- /dev/null +++ b/results/classifier/105/mistranslation/1586229 @@ -0,0 +1,43 @@ +mistranslation: 0.976 +semantic: 0.911 +graphic: 0.895 +other: 0.890 +instruction: 0.855 +device: 0.822 +boot: 0.747 +assembly: 0.701 +socket: 0.619 +network: 0.540 +vnc: 0.361 +KVM: 0.322 + +seabios hell + +getting weird annoying seabios hell and not sure how to fix it. + +ok. + +there IS a SEA-BIOS. There IS a way in. + +-I found it by mistake.(and yall need to move the BIOS key...its in the wrong place) + +I was tryng to boot Yosemite to re-install. I mashed the key too early and it wanted to boot the hard drive. + +Apparently the bios loads AFTER the hard drive wants to boot, not BEFORE it.And it will ONLY load when booting a hard disk. + +..Booting hard disk...[mash F8 here but let go and wait] +eventually will want to load the OS and clear the screen[mash F8 again] + +--Youre in! + +Its tiny, like a mini award bios but youre in! +-Change anything HERE, though...and kiss booting a cd goodbye! + +Im trying to diagnose a black screen, seems related to seabios, not the vga driver. + +-mayhaps wants to boot hard disk but in fact its not bootable as the installer hung(and often unices install bootloader late in process)? + +I cant boot the disc to reinstall to tell. But I have a few dos iso lying around...hmmm. + +Sounds like your describing problems with SeaBIOS, not with QEMU. May I suggest to report this issues to the SeaBIOS project instead? See http://seabios.org/ + diff --git a/results/classifier/105/mistranslation/159 b/results/classifier/105/mistranslation/159 new file mode 100644 index 000000000..4ae8cfa61 --- /dev/null +++ b/results/classifier/105/mistranslation/159 @@ -0,0 +1,14 @@ +mistranslation: 0.985 +graphic: 0.546 +device: 0.500 +semantic: 0.409 +network: 0.158 +other: 0.128 +instruction: 0.095 +assembly: 0.080 +socket: 0.062 +vnc: 0.060 +boot: 0.047 +KVM: 0.029 + +qemu-nbd -l and -s options don't work together diff --git a/results/classifier/105/mistranslation/1590322 b/results/classifier/105/mistranslation/1590322 new file mode 100644 index 000000000..23a7c4ee3 --- /dev/null +++ b/results/classifier/105/mistranslation/1590322 @@ -0,0 +1,28 @@ +mistranslation: 0.992 +device: 0.699 +semantic: 0.662 +other: 0.424 +graphic: 0.418 +instruction: 0.307 +network: 0.252 +vnc: 0.161 +socket: 0.080 +boot: 0.076 +assembly: 0.057 +KVM: 0.028 + +mouse_button 0 takes back to initial position + +i wrote a python script to perform some drag function in the Qemu simulator. +mouse_move x , y +mouse_button 1 +mouse_move new_x,new_y +mouse_move 0 + + +The mouse_move 0 doesn't release the mouse in the position new_x,new_y instead it takes it back to the point x,y and then releases the mouse + +Did you mean "mouse_button 0" instead of "mouse_move 0" here? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1593605 b/results/classifier/105/mistranslation/1593605 new file mode 100644 index 000000000..363391f80 --- /dev/null +++ b/results/classifier/105/mistranslation/1593605 @@ -0,0 +1,260 @@ +mistranslation: 0.469 +KVM: 0.400 +other: 0.400 +vnc: 0.388 +boot: 0.333 +device: 0.331 +instruction: 0.331 +network: 0.329 +semantic: 0.313 +assembly: 0.307 +socket: 0.300 +graphic: 0.296 + +windows2008r2 boot failed with uefi + +I want to run my win2008r2 with uefi. Hypervisor is ubuntu16.04 and my qemu command line show below: + +qemu-system-x86_64 -enable-kvm -name win2008r2 -S -machine pc-i440fx-2.5,accel=kvm,usb=off -cpu host,hv_time,hv_relaxed,hv_spinlocks=0x2000 -drive file=/usr/share/qemu/OVMF.fd,if=pflash,format=raw,unit=0,readonly=on -drive file=/var/lib/libvirt/qemu/nvram/win2008r2_VARS.fd,if=pflash,format=raw,unit=1 -m size=8388608k,slots=10,maxmem=1073741824k -realtime mlock=off -smp 8,maxcpus=96,sockets=24,cores=4,threads=1 -numa node,nodeid=0,cpus=0-7,mem=8192 -uuid 030638c5-c6aa-4f06-82f8-dd2d04fd5705 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-win2008r2/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,clock=vm,driftfix=slew -no-hpet -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device usb-ehci,id=usb1,bus=pci.0,addr=0x4 -device nec-usb-xhci,id=usb2,bus=pci.0,addr=0x5 -device lsi,id=scsi0,bus=pci.0,addr=0x6 -device virtio-scsi-pci,id=scsi1,bus=pci.0,addr=0x7 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x8 -drive file=/vms/images/win2008r2,format=qcow2,if=none,id=drive-ide0-0-0,cache=directsync -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -drive file=/vms/isos/cn_windows_server_2008_r2_standard_enterprise_datacenter_and_web_with_sp1_x64_dvd_617598.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on -device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/win2008r2.agent,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -device usb-tablet,id=input0 -vnc 0.0.0.0:0 -device VGA,id=video0,vgamem_mb=16,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0xa -msg timestamp=on + + +OVMF.fd is download from http://sourceforge.net/projects/edk2/files/OVMF/ OVMF-X64-r15214.zip. + +When I boot my domain with windows2008 iso, the kvm was caught in endless interrupt. I enable trace on my host and I got this. + + + +1. echo 1 > /sys/kernel/debug/tracing/events/kvm/enable +2. cat /sys/kernel/debug/tracing/trace_pipe +qemu-system-x86-1969 [006] .... 2093.019588: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae8e info 0 800000fd + qemu-system-x86-1969 [006] d... 2093.019590: kvm_entry: vcpu 0 + qemu-system-x86-1966 [017] .... 2093.021424: kvm_set_irq: gsi 8 level 1 source 0 + qemu-system-x86-1966 [017] .... 2093.021429: kvm_pic_set_irq: chip 1 pin 0 (edge|masked) + qemu-system-x86-1966 [017] .... 2093.021430: kvm_ioapic_set_irq: pin 8 dst 1 vec=209 (Fixed|logical|edge) (coalesced) + qemu-system-x86-1969 [006] .... 2093.021683: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae78 info 0 800000fd + qemu-system-x86-1969 [006] d... 2093.021686: kvm_entry: vcpu 0 + qemu-system-x86-1969 [006] .... 2093.022592: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae8e info 0 800000ef + qemu-system-x86-1969 [006] d... 2093.022595: kvm_entry: vcpu 0 + qemu-system-x86-1969 [006] .... 2093.022746: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae8e info 0 800000fd + qemu-system-x86-1969 [006] d... 2093.022749: kvm_entry: vcpu 0 + qemu-system-x86-1966 [017] .... 2093.023434: kvm_set_irq: gsi 8 level 1 source 0 + qemu-system-x86-1966 [017] .... 2093.023444: kvm_pic_set_irq: chip 1 pin 0 (edge|masked) + qemu-system-x86-1966 [017] .... 2093.023446: kvm_ioapic_set_irq: pin 8 dst 1 vec=209 (Fixed|logical|edge) (coalesced) + qemu-system-x86-1969 [006] .... 2093.023610: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae78 info 0 800000fd + qemu-system-x86-1969 [006] d... 2093.023612: kvm_entry: vcpu 0 + qemu-system-x86-1966 [017] .... 2093.025430: kvm_set_irq: gsi 8 level 1 source 0 + qemu-system-x86-1966 [017] .... 2093.025435: kvm_pic_set_irq: chip 1 pin 0 (edge|masked) + qemu-system-x86-1966 [017] .... 2093.025436: kvm_ioapic_set_irq: pin 8 dst 1 vec=209 (Fixed|logical|edge) (coalesced) + qemu-system-x86-1969 [006] .... 2093.025599: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae78 info 0 800000fd + qemu-system-x86-1969 [006] d... 2093.025601: kvm_entry: vcpu 0 + qemu-system-x86-1969 [006] .N.. 2093.026593: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae78 info 0 800000ef + qemu-system-x86-1969 [006] d... 2093.026596: kvm_fpu: unload + qemu-system-x86-1969 [006] .... 2093.026598: kvm_ple_window: vcpu 0: ple_window 4096 (shrink 4096) + qemu-system-x86-1969 [006] .... 2093.026599: kvm_fpu: load + qemu-system-x86-1969 [006] d... 2093.026599: kvm_entry: vcpu 0 + qemu-system-x86-1969 [006] .... 2093.026741: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae78 info 0 800000fd + qemu-system-x86-1969 [006] d... 2093.026744: kvm_entry: vcpu 0 + qemu-system-x86-1969 [006] .... 2093.026841: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae8e info 0 800000fd + qemu-system-x86-1969 [006] d... 2093.026844: kvm_entry: vcpu 0 + qemu-system-x86-1966 [017] .... 2093.027448: kvm_set_irq: gsi 8 level 1 source 0 + qemu-system-x86-1966 [017] .... 2093.027454: kvm_pic_set_irq: chip 1 pin 0 (edge|masked) + qemu-system-x86-1966 [017] .... 2093.027455: kvm_ioapic_set_irq: pin 8 dst 1 vec=209 (Fixed|logical|edge) (coalesced) + qemu-system-x86-1966 [017] .... 2093.029444: kvm_set_irq: gsi 8 level 1 source 0 + qemu-system-x86-1966 [017] .... 2093.029449: kvm_pic_set_irq: chip 1 pin 0 (edge|masked) + qemu-system-x86-1966 [017] .... 2093.029450: kvm_ioapic_set_irq: pin 8 dst 1 vec=209 (Fixed|logical|edge) (coalesced) + qemu-system-x86-1969 [006] .... 2093.029452: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae78 info 0 800000ef + qemu-system-x86-1969 [006] d... 2093.029454: kvm_entry: vcpu 0 + qemu-system-x86-1969 [006] .... 2093.029633: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae8e info 0 800000fd + qemu-system-x86-1969 [006] d... 2093.029636: kvm_entry: vcpu 0 + qemu-system-x86-1969 [006] .... 2093.030592: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae8e info 0 800000ef + qemu-system-x86-1969 [006] d... 2093.030595: kvm_entry: vcpu 0 + qemu-system-x86-1969 [006] .... 2093.030745: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae8e info 0 800000fd + qemu-system-x86-1969 [006] d... 2093.030748: kvm_entry: vcpu 0 + qemu-system-x86-1969 [006] .... 2093.030840: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae8e info 0 800000fd + qemu-system-x86-1969 [006] d... 2093.030843: kvm_entry: vcpu 0 + qemu-system-x86-1966 [017] .... 2093.031454: kvm_set_irq: gsi 8 level 1 source 0 + qemu-system-x86-1966 [017] .... 2093.031459: kvm_pic_set_irq: chip 1 pin 0 (edge|masked) + qemu-system-x86-1966 [017] .... 2093.031460: kvm_ioapic_set_irq: pin 8 dst 1 vec=209 (Fixed|logical|edge) (coalesced) + qemu-system-x86-1966 [017] .... 2093.032968: kvm_set_irq: gsi 8 level 1 source 0 + qemu-system-x86-1966 [017] .... 2093.032974: kvm_pic_set_irq: chip 1 pin 0 (edge|masked) + qemu-system-x86-1966 [017] .... 2093.032975: kvm_ioapic_set_irq: pin 8 dst 1 vec=209 (Fixed|logical|edge) (coalesced) + qemu-system-x86-1969 [006] .... 2093.033229: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae78 info 0 800000fd + qemu-system-x86-1969 [006] d... 2093.033231: kvm_entry: vcpu 0 + qemu-system-x86-1969 [006] .... 2093.034592: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae78 info 0 800000ef + qemu-system-x86-1969 [006] d... 2093.034595: kvm_entry: vcpu 0 + qemu-system-x86-1969 [006] .... 2093.034781: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae78 info 0 800000fd + qemu-system-x86-1969 [006] d... 2093.034783: kvm_entry: vcpu 0 + qemu-system-x86-1966 [017] .... 2093.034975: kvm_set_irq: gsi 8 level 1 source 0 + qemu-system-x86-1966 [017] .... 2093.034980: kvm_pic_set_irq: chip 1 pin 0 (edge|masked) + qemu-system-x86-1966 [017] .... 2093.034981: kvm_ioapic_set_irq: pin 8 dst 1 vec=209 (Fixed|logical|edge) (coalesced) + qemu-system-x86-1969 [006] .... 2093.035113: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae8e info 0 800000fd + qemu-system-x86-1969 [006] d... 2093.035116: kvm_entry: vcpu 0 + qemu-system-x86-1966 [017] .... 2093.036983: kvm_set_irq: gsi 8 level 1 source 0 + qemu-system-x86-1966 [017] .... 2093.036989: kvm_pic_set_irq: chip 1 pin 0 (edge|masked) + qemu-system-x86-1966 [017] .... 2093.036990: kvm_ioapic_set_irq: pin 8 dst 1 vec=209 (Fixed|logical|edge) (coalesced) + qemu-system-x86-1969 [006] .... 2093.037154: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae78 info 0 800000fd + qemu-system-x86-1969 [006] d... 2093.037157: kvm_entry: vcpu 0 + + + +The OVMF build you use (SVN r15214) is from Feb 2014 -- it is completely obsolete. I suggest you use the packages from https://www.kraxel.org/repos/ . + +I'm marking this as "invalid" because supporting 2+ year old OVMF builds is unthinkable. + +Thanks for your advice. I got newer version of OVMF from https://www.kraxel.org/repos/. And compile from source code(git://github.com/tianocore/edk2.git). +With these OVMF, it really works well on only 1 vcpu domain. But still failed with multi-vcpus. +The vcpu0 runnig in an endless loop, and other vcpus is halted. The stack of vcpu0 show below: +#0 0x00005571f4b10959 in address_space_update_topology_pass (as=0x5571f6b76de8, old_view=0x7f6884020690, new_view=0x7f6884022ab0, adding=true) + at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:753 +#1 0x00005571f4b10a18 in address_space_update_topology (as=0x5571f6b76de8) at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:768 +#2 0x00005571f4b10bba in memory_region_transaction_commit () at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:809 +#3 0x00005571f4b13d8b in memory_region_update_container_subregions (subregion=0x5571f6cc5140) + at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:1658 +#4 0x00005571f4b13e14 in memory_region_add_subregion_common (mr=0x5571f6a22530, offset=655360, subregion=0x5571f6cc5140) + at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:1668 +#5 0x00005571f4b13ee8 in memory_region_add_subregion_overlap (mr=0x5571f6a22530, offset=655360, subregion=0x5571f6cc5140, priority=2) + at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:1687 +#6 0x00005571f4b2c27a in vga_update_memory_access (s=0x5571f6cc4f38) at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/hw/display/vga.c:210 +#7 0x00005571f4b2cddb in vga_ioport_write (opaque=0x5571f6cc4f38, addr=975, val=8) + at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/hw/display/vga.c:538 +#8 0x00005571f4cf7072 in qxl_vga_ioport_write (opaque=0x5571f6cc4f38, addr=975, val=8) at hw/display/qxl.c:1197 +#9 0x00005571f4b03316 in portio_write (opaque=0x5571f6c72890, addr=14, data=2056, size=2) + at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/ioport.c:201 +#10 0x00005571f4b0ea9c in memory_region_write_accessor (mr=0x5571f6c72890, addr=14, value=0x7f688b73ab28, size=2, shift=0, mask=65535) + at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:444 +#11 0x00005571f4b0ebe4 in access_with_adjusted_size (addr=14, value=0x7f688b73ab28, size=2, access_size_min=1, access_size_max=4, + access=0x5571f4b0ea00 <memory_region_write_accessor>, mr=0x5571f6c72890) at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:481 +#12 0x00005571f4b11b28 in memory_region_dispatch_write (mr=0x5571f6c72890, addr=14, data=2056, size=2) + at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:1138 +#13 0x00005571f4b152ce in io_mem_write (mr=0x5571f6c72890, addr=14, val=2056, size=2) at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:1971 +#14 0x00005571f4abd56b in address_space_rw (as=0x5571f5333b80, addr=974, buf=0x7f689a390000 "\b", <incomplete sequence \307>, len=2, is_write=true) + at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/exec.c:2123 +#15 0x00005571f4b0b028 in kvm_handle_io (port=974, data=0x7f689a390000, direction=1, size=2, count=1) + at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/kvm-all.c:1616 +#16 0x00005571f4b0b5d1 in kvm_cpu_exec (cpu=0x5571f6a5d5e0) at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/kvm-all.c:1758 +#17 0x00005571f4af0bf0 in qemu_kvm_cpu_thread_fn (arg=0x5571f6a5d5e0) at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/cpus.c:898 +#18 0x00007f6899c18e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 +#19 0x00007f68963f938d in clone () from /lib/x86_64-linux-gnu/libc.so.6 +#20 0x0000000000000000 in ?? () + + +When I change qemu version from 2.1.2 to 2.6.0. The vcpu0 will return 0 qemu. +I got strace like this: +strace -p 1180 +Process 1180 attached - interrupt to quit +rt_sigtimedwait([BUS USR1], 0x7f719b5fa960, {0, 0}, 8) = -1 EAGAIN (Resource temporarily unavailable) +rt_sigpending([]) = 0 +futex(0x55669f356d60, FUTEX_WAKE_PRIVATE, 1) = 1 +ioctl(26, KVM_RUN + +The kvm tracing like this: + kvm-1180 [018] d... 63148.545821: kvm_entry: vcpu 0 + kvm-1180 [018] d... 63148.545944: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd + kvm-1180 [018] d... 63148.545948: kvm_entry: vcpu 0 + kvm-1180 [018] d... 63148.546083: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd + kvm-1180 [018] d... 63148.546085: kvm_entry: vcpu 0 + kvm-1180 [018] d... 63148.546200: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd + kvm-1180 [018] d... 63148.546202: kvm_entry: vcpu 0 + kvm-1180 [018] d... 63148.546317: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd + kvm-1180 [018] d... 63148.546320: kvm_entry: vcpu 0 + kvm-1180 [018] d... 63148.546436: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd + kvm-1180 [018] d... 63148.546439: kvm_entry: vcpu 0 + kvm-1180 [018] d... 63148.546553: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd + kvm-1180 [018] d... 63148.546556: kvm_entry: vcpu 0 + kvm-1180 [018] d... 63148.546689: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd + kvm-1180 [018] d... 63148.546691: kvm_entry: vcpu 0 + kvm-1180 [018] d... 63148.546807: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd + kvm-1180 [018] d... 63148.546810: kvm_entry: vcpu 0 + kvm-1180 [018] d... 63148.546927: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd + kvm-1180 [018] d... 63148.546930: kvm_entry: vcpu 0 + kvm-1180 [018] d... 63148.547067: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd + kvm-1180 [018] d... 63148.547070: kvm_entry: vcpu 0 + kvm-1180 [018] d... 63148.547186: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd + kvm-1180 [018] d... 63148.547189: kvm_entry: vcpu 0 + kvm-1180 [018] d... 63148.547304: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd + kvm-1180 [018] d... 63148.547307: kvm_entry: vcpu 0 + kvm-1180 [018] d... 63148.547384: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000ef + kvm-1180 [018] d... 63148.547391: kvm_entry: vcpu 0 + + +Win2k8 EFI has a bug under HyperV. This will never work without a specific hack in UEFI. I can dig in my archives to find a patch if you are really interested in. AFAIR some memory in video driver has to be marked not as boot services but differently and will stay permanently. + +Hi Denis, thank you very much. I do really be interested in it. If the patch can be found, it readlly help me. + +And I still have another question. I notice that Win2k8 cound runnig with UEFI normally on Xen and VMare. Is there any diffrence between them abount handling with video, especially on Xen enviroment？ + +Thank you very much! + +you CAN run, but you have to disable HyperV enlightments. This means that these options "hv_time,hv_relaxed,hv_spinlocks=0x2000" must NOT be set. + +I have not found exact patch, sorry. But something like the following should be done even to start thinking on running win2k8 with EFI if HyperV is enabled. Look into OvmfPkg/QemuVideoDxe/ and replace allocations of EfiBootServicesData/EfiBootServicesCode with EfiACPIMemoryNVS. + +For our case we have found that "The problem is triggered by the Windows memory manager unmapping the page #0 while Windows HAL keeps thinking it's still available and accesses it. + +The unmapping happens because the page #0 is marked by OVMF as EfiBootServicesCode. + +Reportedly the access of the page #0 by HAL only happens when the VM announces +the support for Hyper-V enlightenments; otherwise no crashes are observed." + +Thank you very much. After disabling all HyperV feature, Win2k8 can runnig with multi-vcpus in my enviroment. + +Referring to your advice, I will try to runnig Win2k8 with HyperV feature. Thank you very much. + + + +Denis, thanks a lot for the reminder and the analysis here. I knew about this issue at one point -- see https://bugzilla.redhat.com/show_bug.cgi?id=1185253 -- but by now I've completely forgotten that HyperV enlightenments and UEFI SMP Win7 don't mix. + +Also, for your analysis in comment #7 -- thanks for that too; I've never dug into it this deep. In the RHBZ I referenced above, there's a link to MSDN -- https://technet.microsoft.com/en-us/library/dn282285.aspx -- which indicates that the UEFI Win7 family was never meant to be run as HyperV guests. Those docs were enough explanation to me. + +I don't think hacking on OVMF's VBE shim would be smart at this point -- the VBE shim is already an ugly hack to trick Win7 into working. I think the best course of action here is to disable HyperV enlightenments for Win7 UEFI guests. That's what virt-manager does as well: + +https://github.com/virt-manager/virt-manager/commit/cbba1c4dd381 + +Given that this is not a QEMU issue, I'm closing the report (again). + +Actually I can provide you with the patch which makes win2k8 + UEFI working if you willing to accept it for mainstream QEMU. It was quite simple. We have prepared it but not sent. Parallels Server 6/Parallels Desktop have this hack around 3-5 years. + +I have missed you comment. Closing again. + +sorry, I meant not QEMU but UEFI above. + +... In addition to what I said above in comment #9 (which stands), the technical problem with turning the memory allocation in question into AcpiNVS type is that it would prevent *all* OSes from reusing the area. + +It would prevent the Windows 7 memory manager from deallocating page #0 (thereby saving Windows 7 HAL's buttocks), correct, but the page would also be lost for other, actually UEFI-abiding, OSes as well. That's a way too high price to pay for bug-compatibility with Windows 7. + +This is actually documented in the commit message of https://github.com/tianocore/edk2/commit/90803342b1b6 . An excerpt: + + The Int10h real-mode IVT entry is covered with a Boot Services Code page, + making that too unaccessible to the rest of edk2. (Thus UEFI guest OSes + different from the Windows 2008 family can reclaim the page. The Windows + 2008 family accesses the page at zero regardless of the allocation type.) + +This was in fact a difference between v1 and v2 of the patch. V1 used EfiReservedMemoryType, but v2 changed that, so that no other OSes would be punished. See esp. the Notes section of v2: + +http://thread.gmane.org/gmane.comp.bios.tianocore.devel/7047 +http://thread.gmane.org/gmane.comp.bios.tianocore.devel/7127 + + +I had the same problem and it took me some time to get to this bug report. + +Since this behaviour will not change in future versions of Qemu/OVMF, maybe Qemu should recognize this configuration as invalid and print error message instead of failing silently? + +@alex3kov -- I think you mean the question as + +""" +Since this behaviour will not change in future versions of Windows 7 / Windows Server 2008 R2, ... +""" + +because, again, the problem is not in OVMF but in the Windows guest. + +QEMU cannot be expected to recognize (guest OS, guest firmware, hw config) combinations that might not work. That's not QEMU's business. + +Such (automatic or semi-automatic) config tweaks belong to the management layer. If you use virt-manager or virt-install to create your guest, and select the guest OS type correctly (or let virt-manager / virt-install recognize the guest type from a signature of the installer ISO, which I believe is implemented with the help of libosinfo), then virt-manager / virt-install will automatically disable Hyper-V enlightments for you. This is what https://bugzilla.redhat.com/show_bug.cgi?id=1185253 was about, which I referenced here earlier. + +The virt-manager change is <https://github.com/virt-manager/virt-manager/commit/cbba1c4dd3815e3981d3b315bf28d1018f838702>. + +So, the answer to your question is to use libvirt and its tools (which is recommended anyway). Thanks. + +(In general, I have no idea why large groups of users keep struggling with QEMU command lines, when the interface that libvirt provides is just so much better and easier for production use. The reason I always recommend libvirt is not because I'm an RH zealot, the reason I recommend it is that libvirt adds *actual value*, even for the individual, interactive user.) + + diff --git a/results/classifier/105/mistranslation/1596870 b/results/classifier/105/mistranslation/1596870 new file mode 100644 index 000000000..8843d4c58 --- /dev/null +++ b/results/classifier/105/mistranslation/1596870 @@ -0,0 +1,26 @@ +mistranslation: 0.902 +device: 0.873 +network: 0.609 +graphic: 0.561 +semantic: 0.425 +boot: 0.392 +other: 0.370 +instruction: 0.313 +vnc: 0.306 +socket: 0.121 +assembly: 0.079 +KVM: 0.018 + +qemu-img backed over https fails on zero-length file + +When creating new disk with qemu-img backed by file accessed over HTTPS and the backing file has zero length, qemu-img fails with uninformative error: + + qemu-img: disk.qcow2: CURL: Error opening file: + +The error message should either be improved, or the operation on zero-length file should be allowed. Some other backends, as e.g. raw backend for regular files, seem to allow empty files. + +Fix has been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=a41c457881b5463b18901a849 + +Released with QEMU v2.8 + diff --git a/results/classifier/105/mistranslation/1600112 b/results/classifier/105/mistranslation/1600112 new file mode 100644 index 000000000..f042a1b59 --- /dev/null +++ b/results/classifier/105/mistranslation/1600112 @@ -0,0 +1,37 @@ +mistranslation: 0.943 +graphic: 0.824 +device: 0.664 +other: 0.622 +network: 0.614 +vnc: 0.592 +semantic: 0.502 +socket: 0.491 +instruction: 0.439 +boot: 0.346 +KVM: 0.178 +assembly: 0.149 + +Qemu GTK interface showing question marks instead of correct strings + +Qemu version: 2.6.0 + +When running Qemu system emulation (configured with GTK interface), all interface strings shows up as question marks instead of the correct translated strings. Tested on locale zh_CN.UTF-8. + +I have attached a screenshot below for better understanding. + + + +The QEMU project is currently considering to move 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/105/mistranslation/1606899 b/results/classifier/105/mistranslation/1606899 new file mode 100644 index 000000000..68b0e41f6 --- /dev/null +++ b/results/classifier/105/mistranslation/1606899 @@ -0,0 +1,251 @@ +mistranslation: 0.610 +KVM: 0.578 +other: 0.542 +vnc: 0.494 +device: 0.410 +network: 0.379 +graphic: 0.378 +boot: 0.372 +assembly: 0.366 +semantic: 0.357 +instruction: 0.350 +socket: 0.348 + +virtio-vga does not let guest poweroff properly + +I have a VM running rawhide (Fedora development) and I can't poweroff the machine when I enable virtio-vga. Reboot works correctly. Using QXL works also. The machine arrive to print the "Powering off" message (from Linux kernel) but then hangs. + +The command line is + +/usr/bin/qemu-system-x86_64 -machine accel=kvm -name rawhide -machine pc-i440fx-2.3,accel=kvm,usb=off -cpu Haswell-noTSX -m 2048 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 64216421-aec4-4ce4-aa52-aed9e4e31a1c -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/rawhide.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/home/rawhide.qcow2,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive if=none,id=drive-ide0-0-0,readonly=on -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -netdev user,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:fc:11:43,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/rawhide.org.qemu.guest_agent.0,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -chardev spicevmc,id=charchannel1,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=com.redhat.spice.0 -device usb-tablet,id=input0 -spice ipv4,addr=0.0.0.0,port=5900,disable-ticketing,image-compression=lz,seamless-migration=on,streaming-video=filter -device virtio-vga,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -msg timestamp=on + +I though was due to Virgl but disabling it does not change. + +I'm using Qemu 2.6.0 from Fedora 24. + +Does the issue persist if you remove the intel-hda device (id=sound0) and the dependent hda-duplex device (id=sound0-codec0)? + +Asking because of <http://lists.nongnu.org/archive/html/qemu-devel/2016-07/msg06283.html>. + +If it persists, then please capture a stack dump with gdb, when QEMU is hung. (Not that I'll look at it, but it will help whoever will look at it.) Thanks. + +Removed the parameters, now the command line is + +/usr/bin/qemu-system-x86_64 -machine accel=kvm -name rawhide -machine pc-i440fx-2.3,accel=kvm,usb=off -cpu Haswell-noTSX -m 2048 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 64216421-aec4-4ce4-aa52-aed9e4e31a1c -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/rawhide.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/home/rawhide.qcow2,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive if=none,id=drive-ide0-0-0,readonly=on -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -netdev user,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:fc:11:43,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/rawhide.org.qemu.guest_agent.0,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -chardev spicevmc,id=charchannel1,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=com.redhat.spice.0 -device usb-tablet,id=input0 -spice ipv4,addr=0.0.0.0,port=5900,disable-ticketing,image-compression=lz,seamless-migration=on,streaming-video=filter -device virtio-vga,bus=pci.0,addr=0x2 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -msg timestamp=on + + +Shutdown stops again. + +(gdb) thread apply all bt full + +Thread 5 (Thread 0x7fab8f1ff700 (LWP 3152)): +#0 0x00007fac23b7d32d in poll () at ../sysdeps/unix/syscall-template.S:84 +#1 0x00007fac27913a46 in g_main_context_iterate (priority=<optimized out>, n_fds=2, fds=0x5643798d6f00, timeout=<optimized out>, context=0x5643785d7760) at gmain.c:4135 + poll_func = 0x7fac27922330 <g_poll> + max_priority = 2147483647 + timeout = 2147483647 + some_ready = <optimized out> + nfds = 2 + allocated_nfds = 4 + fds = 0x5643798d6f00 +#2 0x00007fac27913a46 in g_main_context_iterate (context=0x5643785d7760, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3835 + max_priority = 2147483647 + timeout = 2147483647 + some_ready = <optimized out> + nfds = 2 + allocated_nfds = 4 + fds = 0x5643798d6f00 +#3 0x00007fac27913dd2 in g_main_loop_run (loop=0x564378645560) at gmain.c:4034 + __func__ = "g_main_loop_run" +#4 0x00007fac25820e70 in red_worker_main (arg=<optimized out>) at red-worker.c:1570 + worker = <optimized out> + __FUNCTION__ = "red_worker_main" + loop = 0x564378645560 +#5 0x00007fac23e4f5ca in start_thread (arg=0x7fab8f1ff700) at pthread_create.c:333 + __res = <optimized out> + pd = 0x7fab8f1ff700 + now = <optimized out> + unwind_buf = + {cancel_jmp_buf = {{jmp_buf = {140374817371904, 1634185351380305518, 140727220814255, 4096, 140374817371904, 140374817372608, -1586721908543748498, -1588208112698816914}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} + not_first_call = <optimized out> + pagesize_m1 = <optimized out> + sp = <optimized out> + freesize = <optimized out> +#6 0x00007fac23b88ead in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 + +Thread 4 (Thread 0x7fac10d2c700 (LWP 3150)): +#0 0x00007fac23e54bd0 in pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 +#1 0x0000564376e71d09 in qemu_cond_wait (cond=<optimized out>, mutex=<optimized out>) + at /usr/src/debug/qemu-2.6.0/util/qemu-thread-posix.c:123 + err = <optimized out> + __func__ = "qemu_cond_wait" +#2 0x0000564376b762df in qemu_kvm_cpu_thread_fn (arg=<optimized out>) at /usr/src/debug/qemu-2.6.0/cpus.c:1030 + cpu = <optimized out> + r = <optimized out> +#3 0x00007fac23e4f5ca in start_thread (arg=0x7fac10d2c700) at pthread_create.c:333 + __res = <optimized out> + pd = 0x7fac10d2c700 + now = <optimized out> + unwind_buf = + {cancel_jmp_buf = {{jmp_buf = {140376993351424, 1634185351380305518, 140727220813631, 4096, 140376993351424, 140376993352128, -1588104572869835154, -1588208112698816914}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} + not_first_call = <optimized out> + pagesize_m1 = <optimized out> + sp = <optimized out> + freesize = <optimized out> +#4 0x00007fac23b88ead in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 + +Thread 3 (Thread 0x7fac1152d700 (LWP 3149)): +#0 0x00007fac23e54bd0 in pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 +#1 0x0000564376e71d09 in qemu_cond_wait (cond=<optimized out>, mutex=<optimized out>) + at /usr/src/debug/qemu-2.6.0/util/qemu-thread-posix.c:123 + err = <optimized out> + __func__ = "qemu_cond_wait" +#2 0x0000564376b762df in qemu_kvm_cpu_thread_fn (arg=<optimized out>) at /usr/src/debug/qemu-2.6.0/cpus.c:1030 + cpu = <optimized out> + r = <optimized out> +#3 0x00007fac23e4f5ca in start_thread (arg=0x7fac1152d700) at pthread_create.c:333 + __res = <optimized out> + pd = 0x7fac1152d700 + now = <optimized out> + unwind_buf = + {cancel_jmp_buf = {{jmp_buf = {140377001744128, 1634185351380305518, 140727220813631, 4096, 140377001744128, 140377001744832, -1588107869794105746, -1588208112698816914}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} + not_first_call = <optimized out> + pagesize_m1 = <optimized out> + sp = <optimized out> + freesize = <optimized out> +#4 0x00007fac23b88ead in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 + +Thread 2 (Thread 0x7fac13b45700 (LWP 3147)): +#0 0x00007fac23b82ff9 in syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 +#1 0x0000564376e72018 in qemu_event_wait (val=<optimized out>, ev=<optimized out>) + at /usr/src/debug/qemu-2.6.0/util/qemu-thread-posix.c:292 + value = <optimized out> +#2 0x0000564376e72018 in qemu_event_wait (ev=ev@entry=0x56437786f264 <rcu_call_ready_event>) + at /usr/src/debug/qemu-2.6.0/util/qemu-thread-posix.c:399 + value = <optimized out> +#3 0x0000564376e8018e in call_rcu_thread (opaque=<optimized out>) at /usr/src/debug/qemu-2.6.0/util/rcu.c:250 + tries = 0 + n = <optimized out> + node = <optimized out> +#4 0x00007fac23e4f5ca in start_thread (arg=0x7fac13b45700) at pthread_create.c:333 + __res = <optimized out> + pd = 0x7fac13b45700 + now = <optimized out> + unwind_buf = + {cancel_jmp_buf = {{jmp_buf = {140377041688320, 1634185351380305518, 140727220814879, 4096, 140377041688320, 140377041689024, -1588102144602700178, -1588208112698816914}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} + not_first_call = <optimized out> + pagesize_m1 = <optimized out> + sp = <optimized out> + freesize = <optimized out> +#5 0x00007fac23b88ead in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 + +Thread 1 (Thread 0x7fac4116af80 (LWP 3145)): +#0 0x00007fac23b7d3f1 in __GI_ppoll (fds=0x56437863c000, nfds=27, timeout=<optimized out>, + timeout@entry=0x7ffd9c01c3f0, sigmask=sigmask@entry=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:50 + resultvar = 18446744073709551102 + sc_cancel_oldtype = 0 + tval = {tv_sec = 0, tv_nsec = 4479136} +#1 0x0000564376ddfaa9 in qemu_poll_ns (__ss=0x0, __timeout=0x7ffd9c01c3f0, __nfds=<optimized out>, __fds=<optimized out>) + at /usr/include/bits/poll2.h:77 + ts = {tv_sec = 0, tv_nsec = 29561047} +Python Exception <class 'gdb.error'> That operation is not available on integers of more than 8 bytes.: +#2 0x0000564376ddfaa9 in qemu_poll_ns (fds=<optimized out>, nfds=<optimized out>, timeout=timeout@entry=29561047) + at /usr/src/debug/qemu-2.6.0/qemu-timer.c:325 + ts = {tv_sec = 0, tv_nsec = 29561047} +Python Exception <class 'gdb.error'> That operation is not available on integers of more than 8 bytes.: +#3 0x0000564376ddf4ca in main_loop_wait (timeout=29561047) at /usr/src/debug/qemu-2.6.0/main-loop.c:252 + ret = <optimized out> + spin_counter = 0 + spin_counter = 0 + notified = false + timeout = 499 + timeout_ns = <optimized out> +#4 0x0000564376ddf4ca in main_loop_wait (nonblocking=<optimized out>) at /usr/src/debug/qemu-2.6.0/main-loop.c:506 + timeout = 499 + timeout_ns = <optimized out> +#5 0x0000564376b42e2d in main () at /usr/src/debug/qemu-2.6.0/vl.c:1934 + last_io = 0 + i = <optimized out> + snapshot = <optimized out> + linux_boot = <optimized out> + initrd_filename = <optimized out> + kernel_filename = <optimized out> + kernel_cmdline = <optimized out> + boot_order = 0x564376e9aec0 "cad" + boot_once = 0x0 + ds = <optimized out> + cyls = <optimized out> + heads = <optimized out> + secs = <optimized out> + translation = <optimized out> + hda_opts = <optimized out> + opts = <optimized out> + machine_opts = <optimized out> + icount_opts = <optimized out> + olist = <optimized out> + optind = 87 + optarg = 0x7ffd9c01f50d "timestamp=on" + loadvm = <optimized out> + cpu_model = <optimized out> + vga_model = <optimized out> + qtest_chrdev = <optimized out> + qtest_log = <optimized out> + pid_file = <optimized out> + incoming = <optimized out> + defconfig = <optimized out> + userconfig = <optimized out> + log_mask = <optimized out> + log_file = <optimized out> + trace_file = <optimized out> + maxram_size = <optimized out> + ram_slots = <optimized out> + vmstate_dump_file = <optimized out> + main_loop_err = 0x0 + err = 0x0 + __func__ = "main" +#6 0x0000564376b42e2d in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) + at /usr/src/debug/qemu-2.6.0/vl.c:4656 + i = <optimized out> + snapshot = <optimized out> + linux_boot = <optimized out> + initrd_filename = <optimized out> + kernel_filename = <optimized out> + kernel_cmdline = <optimized out> + boot_order = 0x564376e9aec0 "cad" + boot_once = 0x0 + ds = <optimized out> + cyls = <optimized out> + heads = <optimized out> + secs = <optimized out> + translation = <optimized out> + hda_opts = <optimized out> + opts = <optimized out> + machine_opts = <optimized out> + icount_opts = <optimized out> + olist = <optimized out> + optind = 87 + optarg = 0x7ffd9c01f50d "timestamp=on" + loadvm = <optimized out> + cpu_model = <optimized out> + vga_model = <optimized out> + qtest_chrdev = <optimized out> + qtest_log = <optimized out> + pid_file = <optimized out> + incoming = <optimized out> + defconfig = <optimized out> + userconfig = <optimized out> + log_mask = <optimized out> + log_file = <optimized out> + trace_file = <optimized out> + maxram_size = <optimized out> + ram_slots = <optimized out> + vmstate_dump_file = <optimized out> + main_loop_err = 0x0 + err = 0x0 + __func__ = "main" + + +Can you still reproduce this problem with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1608 b/results/classifier/105/mistranslation/1608 new file mode 100644 index 000000000..33c110966 --- /dev/null +++ b/results/classifier/105/mistranslation/1608 @@ -0,0 +1,14 @@ +mistranslation: 0.916 +instruction: 0.582 +device: 0.533 +graphic: 0.483 +boot: 0.328 +vnc: 0.291 +other: 0.280 +semantic: 0.212 +socket: 0.193 +KVM: 0.129 +network: 0.114 +assembly: 0.008 + +QEMU gives wrong MPIDR value for Arm CPU types with MT=1 diff --git a/results/classifier/105/mistranslation/1608802 b/results/classifier/105/mistranslation/1608802 new file mode 100644 index 000000000..183ed0422 --- /dev/null +++ b/results/classifier/105/mistranslation/1608802 @@ -0,0 +1,89 @@ +mistranslation: 0.708 +semantic: 0.682 +network: 0.624 +instruction: 0.594 +other: 0.559 +device: 0.546 +assembly: 0.519 +boot: 0.492 +graphic: 0.480 +socket: 0.447 +vnc: 0.436 +KVM: 0.296 + +READ_DMA (0xC8) command does not work correctly + +The QEMU PC emulation of DMA does not behave like real hardware or other virtualization software. + +From the original bug report (Benjamin David Lunt): + + Back to the READ_DMA command, it is my conclusion that the + READ_DMA command, more precisely, the BUS Master part of QEMU is + in error. The tests that people have done to see if it works, is + probably the guest finding out that DMA doesn't work and defaulting + to PIO, but since the read was successful visually to the user, the + user assumed the READ_DMA command works, where the guest actually + defaulted back to PIO transfers without notice. + + My code works on real hardware (numerous machines), Bochs, and Oracle's + Virtual Box. + + ... + + I have a small test suite, zipped and included at: + www.fysnet.net/temp/c8bug.zip + + Within this zip file is a.img. This is a freeDOS bootable + floppy. Emulate it with QEMU and then at the DOS prompt, run + c8bug.exe. + + It will say that the drive is not ready. + "Drive never became ready" + (along with a few other lines of text) + + The source for this test suite is also included. + c8bug.c is the c source code + c8bug.h is the header file + ctype.h is a quick way to get 'bit8u' type defines + timer.h is a delay routine from another project I have + (The base IO addresses are assumed and set at the top of c8bug.c) + (compiled with DJGPP for DPMI) + + q.bat is my command line for QEMU + + On all other machines and VirtualBox, the controller is ready + for me to receive the sector data. + "Drive is ready to transmit data..." + + However, in QEMU, the controller never becomes ready. + "Drive never became ready" + +The bug was reported for QEMU for Windows, but I can confirm that QEMU for Linux also shows that +behaviour, while VirtualBox works. + +Okay, I think there are two parts to this, and both the test case and qemu are +buggy, though perhaps the test case more seriously than qemu. + +The ATA spec describes DMA commands as having two phases, preparation and +transfer. During the first phase, BSY=1,DRQ=0 is required. In the second phase, +the device can use the same status (BSY=1,DRQ=0) or switch to BSY=0,DRQ=1. +I couldn't find clear information on which state the device should be in between +receiving the ATA command and enabling the bus master operation, which is what +the test case checks, but it must be one of the two. + +So the reason that the test case is buggy is that it waits for DRQ to be set, +while the spec only guarantees that either DRQ or BSY is set during the +transfer. It doesn't work on hardware that sets BSY rather than DRQ. (It also +means that the test expects the device to be in the transfer state before the +bus master is enabled.) + +The problem with qemu is that it sets _both_ bits, whereas the spec requires +that only one of them is set. Apparently most drivers don't care about this as +long as any of the bits is set, but technically it's wrong. + + +The QEMU project is currently considering to move 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 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/105/mistranslation/1610368 b/results/classifier/105/mistranslation/1610368 new file mode 100644 index 000000000..5d5b0b6c9 --- /dev/null +++ b/results/classifier/105/mistranslation/1610368 @@ -0,0 +1,107 @@ +mistranslation: 0.484 +KVM: 0.461 +vnc: 0.457 +graphic: 0.455 +semantic: 0.451 +other: 0.447 +instruction: 0.438 +network: 0.433 +assembly: 0.432 +socket: 0.428 +boot: 0.418 +device: 0.413 + +qemu-system-x86_64 read acces DENIED in apparmor + +When starting a win8.1 VM in virt-manager I see theses errors in dmesg + +[ 185.210435] audit: type=1400 audit(1470419576.704:27): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="libvirt-d694857f-577a-45d4-81d2-4f3672ae7bd4" pid=4885 comm="apparmor_parser" +[ 185.220800] audit: type=1400 audit(1470419576.716:28): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="libvirt-d694857f-577a-45d4-81d2-4f3672ae7bd4//qemu_bridge_helper" pid=4885 comm="apparmor_parser" +[ 185.356159] audit: type=1400 audit(1470419576.848:29): apparmor="DENIED" operation="open" profile="libvirt-d694857f-577a-45d4-81d2-4f3672ae7bd4" name="/run/udev/data/c189:1" pid=4912 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=123 ouid=0 +[ 185.356244] audit: type=1400 audit(1470419576.848:30): apparmor="DENIED" operation="open" profile="libvirt-d694857f-577a-45d4-81d2-4f3672ae7bd4" name="/run/udev/data/c189:129" pid=4912 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=123 ouid=0 +[ 185.356317] audit: type=1400 audit(1470419576.848:31): apparmor="DENIED" operation="open" profile="libvirt-d694857f-577a-45d4-81d2-4f3672ae7bd4" name="/run/udev/data/c189:130" pid=4912 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=123 ouid=0 +[ 185.356396] audit: type=1400 audit(1470419576.848:32): apparmor="DENIED" operation="open" profile="libvirt-d694857f-577a-45d4-81d2-4f3672ae7bd4" name="/run/udev/data/c189:131" pid=4912 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=123 ouid=0 +[ 185.356486] audit: type=1400 audit(1470419576.852:33): apparmor="DENIED" operation="open" profile="libvirt-d694857f-577a-45d4-81d2-4f3672ae7bd4" name="/run/udev/data/c189:257" pid=4912 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=123 ouid=0 +[ 185.356545] audit: type=1400 audit(1470419576.852:34): apparmor="DENIED" operation="open" profile="libvirt-d694857f-577a-45d4-81d2-4f3672ae7bd4" name="/run/udev/data/c189:0" pid=4912 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=123 ouid=0 + + +the process 4912 is : + +libvirt+ 4912 1 36 19:52 ? 00:00:51 qemu-system-x86_64 -enable-kvm -name win8.1 -S -machine pc-i440fx-2.5,accel=kvm,usb=off -cpu Broadwell-noTSX,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -m 4096 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid d694857f-577a-45d4-81d2-4f3672ae7bd4 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-win8.1/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device nec-usb-xhci,id=usb,bus=pci.0,addr=0x5 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/TEMPO/VMS/win81.qcow2,format=qcow2,if=none,id=drive-ide0-0-0 -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -netdev tap,fd=26,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:9d:db:21,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0 -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on -k fr -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vgamem_mb=16,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1 -device usb-host,hostbus=2,hostaddr=10,id=hostdev0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -msg timestamp=on + + +I have no visible problems with the VM but just wanted to signal this to developpers in case this is not normal behaviour. + +ProblemType: Bug +DistroRelease: Ubuntu 16.04 +Package: qemu-system-x86 1:2.5+dfsg-5ubuntu10.3 +ProcVersionSignature: Ubuntu 4.4.0-31.50-generic 4.4.13 +Uname: Linux 4.4.0-31-generic x86_64 +ApportVersion: 2.20.1-0ubuntu2.1 +Architecture: amd64 +CurrentDesktop: KDE +Date: Fri Aug 5 19:57:37 2016 +InstallationDate: Installed on 2016-05-14 (83 days ago) +InstallationMedia: Kubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) +ProcKernelCmdLine: BOOT_IMAGE=/@/boot/vmlinuz-4.4.0-31-generic root=UUID=54def8c1-2495-44c4-b760-f8dbc15e25b1 ro rootflags=subvol=@ quiet splash vt.handoff=7 +SourcePackage: qemu +UpgradeStatus: No upgrade log present (probably fresh install) +dmi.bios.date: 02/24/2016 +dmi.bios.vendor: Intel Corporation +dmi.bios.version: RYBDWi35.86A.0355.2016.0224.1501 +dmi.board.name: NUC5i5RYB +dmi.board.vendor: Intel Corporation +dmi.board.version: H40999-504 +dmi.chassis.type: 3 +dmi.modalias: dmi:bvnIntelCorporation:bvrRYBDWi35.86A.0355.2016.0224.1501:bd02/24/2016:svn:pn:pvr:rvnIntelCorporation:rnNUC5i5RYB:rvrH40999-504:cvn:ct3:cvr: + + + +apparmor profile + +$ cat /etc/apparmor.d/libvirt/libvirt-d694857f-577a-45d4-81d2-4f3672ae7bd4 +# +# This profile is for the domain whose UUID matches this file. +# + +#include <tunables/global> + +profile libvirt-d694857f-577a-45d4-81d2-4f3672ae7bd4 { + #include <abstractions/libvirt-qemu> + #include <libvirt/libvirt-d694857f-577a-45d4-81d2-4f3672ae7bd4.files> + +} + + + + + + + +$ cat /etc/apparmor.d/libvirt/libvirt-d694857f-577a-45d4-81d2-4f3672ae7bd4.files +# DO NOT EDIT THIS FILE DIRECTLY. IT IS MANAGED BY LIBVIRT. + "/var/log/libvirt/**/win8.1.log" w, + "/var/lib/libvirt/qemu/domain-win8.1/monitor.sock" rw, + "/var/run/libvirt/**/win8.1.pid" rwk, + "/run/libvirt/**/win8.1.pid" rwk, + "/var/run/libvirt/**/*.tunnelmigrate.dest.win8.1" rw, + "/run/libvirt/**/*.tunnelmigrate.dest.win8.1" rw, + "/TEMPO/VMS/win81.qcow2" rw, + # for qemu guest agent channel + owner "/var/lib/libvirt/qemu/channel/target/domain-win8.1/**" rw, + "/dev/bus/usb/002/010" rw, + "/dev/net/tun" rw, + + +Looking at the contents of those files, I think giving libvirt vms read access by default to all of them should be safe. + +Hi, +getting to my attention now due to the drop of upstream qemu. +This is actually a dup of bug 1552241 + +TL;DR: +- yes it is an issue +- the /run/udev/data/* blanket is considered "too open" +- a correct fix needs some serious development in virt-aa-helper +- until this is done upstream users who want to opt-in need to opt-in (to get functionality but also unsafety) by making the profile less restrictive in /etc/apparmor.d/abstractions/libvirt-qemu + diff --git a/results/classifier/105/mistranslation/1613817 b/results/classifier/105/mistranslation/1613817 new file mode 100644 index 000000000..a275fd7fb --- /dev/null +++ b/results/classifier/105/mistranslation/1613817 @@ -0,0 +1,130 @@ +mistranslation: 0.697 +instruction: 0.679 +other: 0.653 +KVM: 0.623 +graphic: 0.617 +vnc: 0.599 +device: 0.558 +semantic: 0.550 +boot: 0.543 +assembly: 0.543 +network: 0.536 +socket: 0.523 + +x86: ret, lret and iret with noncanonical IP saves wrong IP on the exception stack + +This test program: + +# compile with: gcc -nostartfiles -nostdlib +_start: .globl _start + mov %ss,%eax + push %rax + push %rsp + pushf + mov %cs,%eax + push %rax + mov $0x1234567812345678,%rax + push %rax +//qemu bug: ip=1234567812345678, should be ip=0000000000400abc: + iretq +1: + jmp 1b + +should segfault on IRET instruction because return address on stack is invalid +(it is not canonical). And it does, both on native CPU and in qemu. +But there is a difference: on native CPU, it fails before instruction is executed, +IOW: saved IP points to the failed IRET: + +# strace -i ./bad_ip_in_iret +[00007fa609805d57] execve("./bad_ip_in_iret", ["./bad_ip_in_iret"], [/* 54 vars */]) = 0 +[00000000004000e7] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} --- + ^^^^^^^^^^^^^^^^-NOTE THIS +[????????????????] +++ killed by SIGSEGV (core dumped) +++ + + +In qemu, evidently instruction succeeds, and then emulated CPU throws an exception because fetching instructions from non-canonical addresses is not allowed: + +/ # strace -i ./bad_ip_in_iret +[000000000041a790] execve("./bad_ip_in_iret", ["./bad_ip_in_iret"], [/* 5 vars */]) = 0 +[1234567812345678] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} --- + ^^^^^^^^^^^^^^^^-NOTE THIS +[????????????????] +++ killed by SIGSEGV +++ +Segmentation fault + +Thus, the emulation is not the same as real CPU. + +This is not specific to IRET, the same happens with "far return" LRET, +and with ordinary RET instructions as well. +In qemu: + +/ # strace -i ./bad_ip_in_lret +[000000000041a790] execve("./bad_ip_in_lret", ["./bad_ip_in_lret"], [/* 5 vars */]) = 0 +[1234567812345678] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} --- +[????????????????] +++ killed by SIGSEGV +++ +Segmentation fault +/ # strace -i ./bad_ip_in_ret +[000000000041a790] execve("./bad_ip_in_ret", ["./bad_ip_in_ret"], [/* 5 vars */]) = 0 +[1234567812345678] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} --- +[????????????????] +++ killed by SIGSEGV +++ +Segmentation fault + +# qemu-system-x86_64 --version +QEMU emulator version 2.6.92(qemu-2.7.0-0.1.rc2.fc26), Copyright (c) 2003-2008 Fabrice Bellard + +Running it like this: + +qemu-system-x86_64 -no-reboot -kernel "$bzImage" -initrd initramfs.cpio -append "panic=1" + +(i.e. no KVM, no unusual options) + + +The QEMU project is currently considering to move 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 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. + + +Still happens with qemu 5.1.92 + +I imagine the fix should be inserted here: + +static inline void helper_ret_protected(CPUX86State *env, int shift, + int is_iret, int addend, + uintptr_t retaddr) +{ + uint32_t new_cs, new_eflags, new_ss; + uint32_t new_es, new_ds, new_fs, new_gs; + uint32_t e1, e2, ss_e1, ss_e2; + int cpl, dpl, rpl, eflags_mask, iopl; + target_ulong ssp, sp, new_eip, new_esp, sp_mask; + +#ifdef TARGET_X86_64 + if (shift == 2) { + sp_mask = -1; + } else +#endif + { + sp_mask = get_sp_mask(env->segs[R_SS].flags); + } + sp = env->regs[R_ESP]; + ssp = env->segs[R_SS].base; + new_eflags = 0; /* avoid warning */ +#ifdef TARGET_X86_64 + if (shift == 2) { + POPQ_RA(sp, new_eip, retaddr); +if (new_eip is not canonical) raise_exception_err_ra(); <==== HERE + POPQ_RA(sp, new_cs, retaddr); + new_cs &= 0xffff; + if (is_iret) { + POPQ_RA(sp, new_eflags, retaddr); + } + } else +#endif + + + +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/125 + + diff --git a/results/classifier/105/mistranslation/1614521 b/results/classifier/105/mistranslation/1614521 new file mode 100644 index 000000000..65dd40d23 --- /dev/null +++ b/results/classifier/105/mistranslation/1614521 @@ -0,0 +1,21 @@ +mistranslation: 0.959 +other: 0.864 +device: 0.784 +socket: 0.684 +semantic: 0.670 +network: 0.651 +instruction: 0.557 +vnc: 0.455 +boot: 0.376 +graphic: 0.352 +assembly: 0.185 +KVM: 0.031 + +-display accepts "none[a-z,0-9]*" instead of 'none' + +When using the '-display' option the parameter 'none' is not the only string that causes the behaviour of 'none'. I can use '-display noneMICKEYMOUSE' and still have the none behaviour. + +Fixed in: + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=2c9498c3e44cd5574 + diff --git a/results/classifier/105/mistranslation/1614609 b/results/classifier/105/mistranslation/1614609 new file mode 100644 index 000000000..df2585449 --- /dev/null +++ b/results/classifier/105/mistranslation/1614609 @@ -0,0 +1,65 @@ +mistranslation: 0.915 +device: 0.871 +boot: 0.842 +other: 0.798 +vnc: 0.715 +network: 0.688 +socket: 0.685 +KVM: 0.637 +instruction: 0.609 +assembly: 0.531 +graphic: 0.528 +semantic: 0.270 + +alphabetical order of monitor options + +Looking for the 'continue'/'resume' option I found this order that was not quite 'alphabetical'. +It had me overlook the 'cont' option at glance. Which is just a little impractical. + +... +boot_set bootdevice -- define new values for the boot device list +change device filename [format [read-only-mode]] -- change a removable medium, optional format +chardev-add args -- add chardev +chardev-remove id -- remove chardev +client_migrate_info protocol hostname port tls-port cert-subject -- set migration information for remote display +closefd closefd name -- close a file descriptor previously passed via SCM rights +commit device|all -- commit changes to the disk images (if -snapshot is used) or backing files +cpu index -- set the default CPU +cpu-add id -- add cpu +c|cont -- resume emulation +delvm tag|id -- delete a VM snapshot from its tag or id +... + +I tested this list with 'sort' just to make sure and make a point: + +$ cat Desktop/order-orig.txt +boot_set +change +chardev-add +chardev-remove +client_migrate_info +closefd +commit +cpu +cpu-add +c|cont +delvm +$ cat Desktop/order-orig.txt | sort +boot_set +c|cont +change +chardev-add +chardev-remove +client_migrate_info +closefd +commit +cpu +cpu-add +delvm +$ + +Should be fixed by this patch: https://<email address hidden>/ + +Fix has been included here: +https://gitlab.com/qemu-project/qemu/-/commit/ff688cd2c7c3a677b71e + diff --git a/results/classifier/105/mistranslation/1615079 b/results/classifier/105/mistranslation/1615079 new file mode 100644 index 000000000..bdb664f70 --- /dev/null +++ b/results/classifier/105/mistranslation/1615079 @@ -0,0 +1,29 @@ +mistranslation: 0.934 +device: 0.788 +graphic: 0.768 +other: 0.626 +vnc: 0.418 +semantic: 0.395 +instruction: 0.236 +network: 0.232 +boot: 0.126 +socket: 0.114 +KVM: 0.047 +assembly: 0.007 + +GTK+ UI virtual consoles scrolling broken + +"In the virtual consoles, you can use Ctrl-Up, Ctrl-Down, Ctrl-PageUp and Ctrl-PageDown to move in the back log." + +the scrolling bar does not appear either + +these are broken on gtk2 and gtk3 + +VTE is required for this to work? + +if yes, the configure script should have info about the dependency + +Are you talking about serial console? Or graphical (VGA) console? Which QEMU target (x86? ... and which machine?)? How did you start QEMU? ... this bug report clearly lacks some more information... + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1625987 b/results/classifier/105/mistranslation/1625987 new file mode 100644 index 000000000..6ac27da97 --- /dev/null +++ b/results/classifier/105/mistranslation/1625987 @@ -0,0 +1,81 @@ +mistranslation: 0.928 +semantic: 0.627 +device: 0.580 +instruction: 0.488 +socket: 0.484 +graphic: 0.418 +network: 0.397 +assembly: 0.342 +boot: 0.340 +KVM: 0.333 +vnc: 0.319 +other: 0.288 + +target-arm/translate-a64.c:2028: possible coding error ? + +target-arm/translate-a64.c:2028:37: warning: ?: using integer constants in boolean context [-Wint-in-bool-context] + +Source code is + + bool iss_sf = opc == 0 ? 32 : 64; + +Maybe better code + + bool iss_sf = (opc == 0) ? 32 : 64; + +This is clearly a bug, but your suggested change won't deal with the problem, which is that we're trying to set a bool so the ? 32 : 64 construct is just wrong. + + +On 22 September 2016 at 02:53, Peter Maydell <email address hidden> wrote: +> This is clearly a bug, but your suggested change won't deal with the +> problem, which is that we're trying to set a bool so the ? 32 : 64 +> construct is just wrong. + +> Bug description: +> target-arm/translate-a64.c:2028:37: warning: ?: using integer +> constants in boolean context [-Wint-in-bool-context] +> +> Source code is +> +> bool iss_sf = opc == 0 ? 32 : 64; + +Edgar, did you want to look at a fix for this? It was introduced +in your commit aaa1f954d4 adding syndrome info for loads and stores. + +thanks +-- PMM + + +On Thu, Sep 29, 2016 at 06:40:53PM -0700, Peter Maydell wrote: +> On 22 September 2016 at 02:53, Peter Maydell <email address hidden> wrote: +> > This is clearly a bug, but your suggested change won't deal with the +> > problem, which is that we're trying to set a bool so the ? 32 : 64 +> > construct is just wrong. +> +> > Bug description: +> > target-arm/translate-a64.c:2028:37: warning: ?: using integer +> > constants in boolean context [-Wint-in-bool-context] +> > +> > Source code is +> > +> > bool iss_sf = opc == 0 ? 32 : 64; +> +> Edgar, did you want to look at a fix for this? It was introduced +> in your commit aaa1f954d4 adding syndrome info for loads and stores. + +Hi Peter, + +Yes, I've just posted a fix to the list. +It should have been: + +bool iss_sf = opc == 0 ? false : true; + +Cheers, +Edgar + + +Now fixed in master, commit 173ff58580b383a7841. + + +Released with v2.8 + diff --git a/results/classifier/105/mistranslation/1631773 b/results/classifier/105/mistranslation/1631773 new file mode 100644 index 000000000..237046cb2 --- /dev/null +++ b/results/classifier/105/mistranslation/1631773 @@ -0,0 +1,30 @@ +mistranslation: 0.928 +instruction: 0.916 +device: 0.831 +socket: 0.662 +network: 0.539 +vnc: 0.472 +semantic: 0.412 +graphic: 0.406 +assembly: 0.248 +other: 0.242 +boot: 0.222 +KVM: 0.213 + +hw/dma/pl080.c:354: possible typo ? + +hw/dma/pl080.c:354:1: warning: V578 An odd bitwise operation detected: s->conf & (0x2 | 0x2). Consider verifying it. + +Source code is + + if (s->conf & (PL080_CONF_M1 | PL080_CONF_M1)) { + +Maybe better code + + if (s->conf & (PL080_CONF_M1 | PL080_CONF_M2)) { + +Thanks for reporting the issue, patch has now been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=04bb79d1f519ae190a + +Released with version 2.8. + diff --git a/results/classifier/105/mistranslation/1648726 b/results/classifier/105/mistranslation/1648726 new file mode 100644 index 000000000..92748f7de --- /dev/null +++ b/results/classifier/105/mistranslation/1648726 @@ -0,0 +1,42 @@ +mistranslation: 0.937 +KVM: 0.893 +vnc: 0.880 +other: 0.874 +instruction: 0.871 +graphic: 0.860 +semantic: 0.845 +assembly: 0.842 +device: 0.841 +boot: 0.837 +socket: 0.835 +network: 0.817 + +[usb-host] Passthrough of UAS devices fails with Windows (10) guests + +Split off from #1579306 as this is a distinct issue. + +Physical USB storage devices that support the UAS protocol do not work correctly when passed through to Windows guests (I've only tested this with Windows 10 x64, build 1607). + +Passing through such a device results in the older BOT/MSC protocol being used: + +<See attachment win10-uas-fail.png> + +Using the same domain configuration with a Linux guest (tested with SystemRescueCD 4.8.0) works correctly: + +/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M + |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M +/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M + + +In both cases, the VM was launched via libvirt, which generated the following command line: + +/usr/bin/qemu-system-x86_64 -name guest=Win10-Edge-IE11,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-13-Win10-Edge-IE11/master-key.aes -machine pc-q35-2.7,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu host,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -m 4096 -realtime mlock=off -smp 8,sockets=1,cores=4,threads=2 -uuid 47c39707-088c-4edc-8b6a-a7856e09f43d -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-13-Win10-Edge-IE11/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 -boot strict=on -device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1e -device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x0 -device nec-usb-xhci,id=usb,bus=pci.2,addr=0x6 -device virtio-scsi-pci,id=scsi0,bus=pci.2,addr=0x3 -device virtio-serial-pci,id=virtio-serial0,bus=pci.2,addr=0x4 -drive file=/home/jack/IMG/Win10-Edge-IE11.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0,discard=unmap -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -drive if=none,id=drive-scsi0-0-0-1,readonly=on -device scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1 -netdev tap,fd=22,id=hostnet0,vhost=on,vhostfd=24 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:27:94:5d,bus=pci.2,addr=0x1 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0,bus=usb.0,port=2 -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pcie.0,addr=0x1 -device intel-hda,id=sound0,bus=pci.2,addr=0x2 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=3 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=4 -device usb-host,hostbus=4,hostaddr=4,id=hostdev0,bus=usb.0,port=1 -device virtio-balloon-pci,id=balloon0,bus=pci.2,addr=0x5 -msg timestamp=on + + + +The QEMU project is currently considering to move 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 all 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". Thank you and sorry for the +inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1650175 b/results/classifier/105/mistranslation/1650175 new file mode 100644 index 000000000..312f7bb35 --- /dev/null +++ b/results/classifier/105/mistranslation/1650175 @@ -0,0 +1,33 @@ +mistranslation: 0.694 +semantic: 0.466 +network: 0.438 +instruction: 0.385 +device: 0.354 +graphic: 0.316 +socket: 0.301 +other: 0.271 +vnc: 0.240 +assembly: 0.130 +boot: 0.102 +KVM: 0.087 + +wrong version in 2.8.0-rc03 + +When you compile qemu the version still 2.7.93 instead 2.8.0-rc03 + +build/config-host.mak:VERSION=2.7.93 + +This is intentional and is the way that QEMU release candidates are versioned. + +The versioning scheme is MAJOR.MINOR.PATCH where: + +0 >= PATCH < 90 is a stable release +PATCH = 90 is the development window for the next MINOR release +91 >= PATCH <= 99 is a release candidate for the next MINOR release + +This means 2.7.93 is release candidate 3 for 2.8. + +I suppose one reason this scheme has been used is that simple MAJOR.MINOR.PATCH version comparison algorithms will work correctly even if they do not support -rcN notation. + +Not a bug. + diff --git a/results/classifier/105/mistranslation/1654 b/results/classifier/105/mistranslation/1654 new file mode 100644 index 000000000..c34b256c9 --- /dev/null +++ b/results/classifier/105/mistranslation/1654 @@ -0,0 +1,94 @@ +mistranslation: 0.834 +vnc: 0.832 +other: 0.814 +KVM: 0.803 +instruction: 0.788 +graphic: 0.785 +device: 0.784 +socket: 0.761 +semantic: 0.703 +assembly: 0.656 +network: 0.608 +boot: 0.600 + +Memory out of bounds access vulnerability when guest accesses Block Limits information of SCSI devices +Description of problem: +When a guest uses a Linux kernel version 5.19 or higher and uses an scsi device, there will be a memory access violation, which can be clearly seen when ASAN is turned on. + +**reason：** +Linux kernel 5.19 merge commit： + +https://github.com/torvalds/linux/commit/c92a6b5d63359dd6d2ce6ea88ecd8e31dd769f6b + +The Linux kernel will first issue a header request to obtain the VPD length before obtaining the VPD information. The BUF for obtaining the VPD length is less than 8 bytes. However, QEMU regards the header for obtaining the VPD length as obtaining all VPD information, and a memory access violation occurs when writing information to BUF. + +The specific memory out of bounds information is as follows: +==12430==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! + +==12430==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: +0x7fffebc1d000; bottom 0x7f61115ee000; size: 0x009eda62f000 (682268749824) + +False positive error reports may follow + +==12430==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200024d858 at pc 0x55767513791c bp 0x7f6111fcddc0 sp 0x7f6111fcddb0 + +WRITE of size 4 at 0x60200024d858 thread T0 + + #0 0x55767513791b in stl_he_p /root/hci/qemu/qemu-5.0.0/include/qemu/bswap.h:357 + + #1 0x55767513791b in stl_be_p /root/hci/qemu/qemu-5.0.0/include/qemu/bswap.h:464 + + #2 0x55767513791b in scsi_handle_inquiry_reply hw/scsi/scsi-generic.c:173 + + #3 0x55767513791b in scsi_read_complete hw/scsi/scsi-generic.c:318 + + #4 0x55767545d7c6 in blk_aio_complete block/block-backend.c:1425 + + #5 0x557675544d79 in coroutine_trampoline util/coroutine-ucontext.c:115 + + #6 0x7f611b9f14df (/lib/x86_64-linux-gnu/libc.so.6+0x5b4df) + +0x60200024d858 is located 4 bytes to the right of 4-byte region [0x60200024d850,0x60200024d854) + +allocated by thread T0 here: + + #0 0x557674a987f2 in malloc (/sf/bin/qemu-system-x86_64+0x7827f2) + + #1 0x7f6120141d41 in g_malloc (/usr/lib/libglib256-2.0.so.0+0x61d41) + + #2 0x557675137bb4 in scsi_send_command hw/scsi/scsi-generic.c:459 + + #3 0x55767513e902 in scsi_req_enqueue hw/scsi/scsi-bus.c:836 + + #4 0x557674c5f26e in virtio_scsi_handle_cmd_req_submit /root/hci/qemu/qemu-5.0.0/hw/scsi/virtio-scsi.c:589 + + #5 0x557674c5f26e in virtio_scsi_handle_cmd_vq /root/hci/qemu/qemu-5.0.0/hw/scsi/virtio-scsi.c:634 + + #6 0x557674c61089 in virtio_scsi_data_plane_handle_cmd /root/hci/qemu/qemu-5.0.0/hw/scsi/virtio-scsi-dataplane.c:60 + + #7 0x557674c9a520 in virtio_queue_notify_aio_vq /root/hci/qemu/qemu-5.0.0/hw/virtio/virtio.c:2338 + + #8 0x55767552c7c4 in aio_dispatch_handler util/aio-posix.c:328 + +SUMMARY: AddressSanitizer: heap-buffer-overflow /root/hci/qemu/qemu-5.0.0/include/qemu/bswap.h:357 stl_he_p +Steps to reproduce: +1. QEMU Enable ASAN +2. Use a guest with a Linux kernel version greater than 5.19 and mount an scsi physical device +3. Upon startup, memory out of bounds access can be detected +Additional information: +At present, I have made some simple modifications, but I am not sure if this is the best solution and can serve as a reference. + +Make a judgment on buflen, ignore the header information issued by the Linux kernel, and write the VPD information when issuing the actual instruction to obtain VPD information. + +hw/scsi/scsi-generic.c:scsi_handle_inquiry_reply + +``` +if (r->buflen >= 12) { + stl_be_p(&r->buf[8], max_transfer); +} +if (r->buflen >= 16){ + /* Also take care of the opt xfer len. */ + stl_be_p(&r->buf[12], + MIN_NON_ZERO(max_transfer, ldl_be_p(&r->buf[12]))); +} +``` diff --git a/results/classifier/105/mistranslation/1655708 b/results/classifier/105/mistranslation/1655708 new file mode 100644 index 000000000..4ddb5226c --- /dev/null +++ b/results/classifier/105/mistranslation/1655708 @@ -0,0 +1,80 @@ +mistranslation: 0.960 +other: 0.855 +device: 0.812 +semantic: 0.811 +socket: 0.783 +vnc: 0.741 +instruction: 0.683 +graphic: 0.661 +boot: 0.654 +network: 0.587 +assembly: 0.537 +KVM: 0.520 + +target/ppc/int_helper.c:2806: strange expression ? + +target/ppc/int_helper.c:2806:25: warning: ‘*’ in boolean context, suggest ‘&&’ instead [-Wint-in-bool-context] + +Source code is + + zone_digit = (i * 2) ? b->u8[BCD_DIG_BYTE(i * 2)] >> 4 : zone_lead; + +Which I read as + + zone_digit = (i * 2) ? (b->u8[BCD_DIG_BYTE(i * 2)] >> 4) : zone_lead; + +so I think the compiler warning is for the i * 2 lhs of the ?. + +I am not sure what to suggest as a bugfix. + +On 01/11/2017 10:41 AM, dcb wrote: +> Public bug reported: +> +> target/ppc/int_helper.c:2806:25: warning: ‘*’ in boolean context, +> suggest ‘&&’ instead [-Wint-in-bool-context] +> +> Source code is +> +> zone_digit = (i * 2) ? b->u8[BCD_DIG_BYTE(i * 2)] >> 4 : +> zone_lead; + +Also, looking at BCD_DIG_BYTE(): + +#if defined(HOST_WORDS_BIGENDIAN) +#define BCD_DIG_BYTE(n) (15 - (n/2)) +#else +#define BCD_DIG_BYTE(n) (n/2) +#endif + +Oops. n is under-parenthesized, and will cause invalid expansions for +some expressions. Let's fix that as well. + + +> so I think the compiler warning is for the i * 2 lhs of the ?. + +Yes - the compiler is complaining that 'i * 2' can only be non-zero if +'i' was non-zero (given that the code occurs in a loop for i between 0 +and 16), so it is just as easy to write 'i ? ...' instead of the weirder +'(i * 2) ? ...'. + +-- +Eric Blake eblake redhat com +1-919-301-3266 +Libvirt virtualization library http://libvirt.org + + + +> so it is just as easy to write 'i ? ...' instead of the weirder +> '(i * 2) ? ...'. + +I suspect it is just possible that the i * 2 expression is a typo +for something else, perhaps i & 2 or i << 2 or i >> 2 or something else. + +I don't know the code so I am unable to offer better guidance. + + +Patch has been posted to the mailing list: +https://lists.gnu.org/archive/html/qemu-devel/2017-01/msg02008.html + +Fix had been committed here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=365206aeb3d0bb72043d + diff --git a/results/classifier/105/mistranslation/1657538 b/results/classifier/105/mistranslation/1657538 new file mode 100644 index 000000000..bd1dad8f4 --- /dev/null +++ b/results/classifier/105/mistranslation/1657538 @@ -0,0 +1,214 @@ +mistranslation: 0.771 +other: 0.716 +graphic: 0.706 +vnc: 0.688 +instruction: 0.686 +device: 0.683 +KVM: 0.664 +network: 0.662 +assembly: 0.640 +semantic: 0.633 +socket: 0.621 +boot: 0.611 + +qemu 2.7.x 2.8 softmmu dont work on BE machine + +Build on Be machine qemu 2.7.1 and 2.8 in pure softmmu (tgc) dont work on big endian hardware . +tested with ppc-softmmu,i386-softmmu,arm-softmmu same result: + +with : + ./qemu-system-i386 +Gtk-Message: Failed to load module "overlay-scrollbar" +qemu-system-i386: Trying to execute code outside RAM or ROM at 0x000a0000 +This usually means one of the following happened: + +(1) You told QEMU to execute a kernel for the wrong machine type, and it crashed on startup (eg trying to run a raspberry pi kernel on a versatilepb QEMU machine) +(2) You didn't give QEMU a kernel or BIOS filename at all, and QEMU executed a ROM full of no-op instructions until it fell off the end +(3) Your guest kernel has a bug and crashed by jumping off into nowhere + +This is almost always one of the first two, so check your command line and that you are using the right type of kernel for this machine. +If you think option (3) is likely then you can try debugging your guest with the -d debug options; in particular -d guest_errors will cause the log to include a dump of the guest register state at this point. + +Execution cannot continue; stopping here. + + +I try to add the -L option with ../pc-bios/bios.bin +and have the same result. + +note the ppc-softmmu and ppc64-softmmu work in kvm mode only emulated mode have issue. + + +tested on my hardware a Qriq P5040 and G5 4x970MP with Ubuntu Mate 16.10 +thanks +Luigi + +I can not reproduce this issue. QEMU 2.8 works fine here on a POWER8 big endian host (running RHEL7). Can you still run older versions of QEMU that used to work for you in the past, to check whether it is QEMU or whether it is Ubuntu 16.10 that is causing the trouble here? Could you please also post the full output of the "configure" run on your system? + +Something else to try: Could you please check whether you get any output when you run "qemu-system-ppc -nographic" on your system? So we can make sure that it is not related to GTK or something similar... + +Hi Thomas, +here the configure .. i made a clean one just with the target for have fastest build +will report soon the result with the nographic just the time of build + +src/qemu$ ./configure --target-list=i386-softmmu,ppc-softmmu,ppc64-softmmu +Install prefix /usr/local +BIOS directory /usr/local/share/qemu +binary directory /usr/local/bin +library directory /usr/local/lib +module directory /usr/local/lib/qemu +libexec directory /usr/local/libexec +include directory /usr/local/include +config directory /usr/local/etc +local state directory /usr/local/var +Manual directory /usr/local/share/man +ELF interp prefix /usr/gnemul/qemu-%M +Source path /home/amigaone/src/qemu +C compiler cc +Host C compiler cc +C++ compiler c++ +Objective-C compiler clang +ARFLAGS rv +CFLAGS -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g +QEMU_CFLAGS -I/usr/include/pixman-1 -Werror -DHAS_LIBSSH2_SFTP_FSYNC -pthread -I/usr/include/glib-2.0 -I/usr/lib/powerpc-linux-gnu/glib-2.0/include -D_GNU_SOURCE -I/usr/include/ncursesw -m32 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wendif-labels -Wno-shift-negative-value -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-strong -I/usr/local/include/libpng12 -I/usr/local/include/cacard -I/usr/include/nss -I/usr/include/nspr -I/usr/include/libusb-1.0 +LDFLAGS -Wl,--warn-common -m32 -g +make make +install install +python python -B +smbd /usr/sbin/smbd +module support no +host CPU ppc +host big endian yes +target list i386-softmmu ppc-softmmu ppc64-softmmu +tcg debug enabled no +gprof enabled no +sparse enabled no +strip binaries yes +profiler no +static build no +pixman system +SDL support yes (1.2.15) +GTK support yes (2.24.30) +GTK GL support no +VTE support no +TLS priority NORMAL +GNUTLS support no +GNUTLS rnd no +libgcrypt yes +libgcrypt kdf yes +nettle no +nettle kdf no +libtasn1 no +curses support yes +virgl support yes +curl support yes +mingw32 support no +Audio drivers oss +Block whitelist (rw) +Block whitelist (ro) +VirtFS support yes +VNC support yes +VNC SASL support yes +VNC JPEG support yes +VNC PNG support yes +xen support no +brlapi support yes +bluez support yes +Documentation yes +PIE no +vde support no +netmap support no +Linux AIO support yes +ATTR/XATTR support yes +Install blobs yes +KVM support yes +COLO support yes +RDMA support yes +TCG interpreter no +fdt support yes +preadv support yes +fdatasync yes +madvise yes +posix_madvise yes +libcap-ng support yes +vhost-net support yes +vhost-scsi support yes +vhost-vsock support yes +Trace backends log +spice support no +rbd support yes +xfsctl support yes +smartcard support yes +libusb yes +usb net redir yes +OpenGL support yes +OpenGL dmabufs yes +libiscsi support yes +libnfs support yes +build guest agent yes +QGA VSS support no +QGA w32 disk info no +QGA MSI support no +seccomp support yes +coroutine backend ucontext +coroutine pool yes +debug stack usage no +GlusterFS support no +Archipelago support no +gcov gcov +gcov enabled no +TPM support yes +libssh2 support yes +TPM passthrough no +QOM debugging yes +lzo support yes +snappy support yes +bzip2 support yes +NUMA host support yes +tcmalloc support no +jemalloc support no +avx2 optimization no +replication support yes + + + +i386-softmmu: +./qemu-system-i386 -nographic +qemu-system-i386: Trying to execute code outside RAM or ROM at 0x000a0000 +This usually means one of the following happened: and so and so + +./qemu-system-ppc -nographic +nothing happen ... no exit on console . + + +on 2.6.2 i have: + +qemu-system-ppc -nographic + +>> ============================================================= +>> OpenBIOS 1.1 [Apr 18 2016 08:20] +>> Configuration device id QEMU version 1 machine id 2 +>> CPUs: 1 +>> Memory: 128M +>> UUID: 00000000-0000-0000-0000-000000000000 +>> CPU type PowerPC,750 +milliseconds isn't unique. +Welcome to OpenBIOS v1.1 built on Apr 18 2016 08:20 +Trying hd:,\\:tbxi... +Trying hd:,\ppc\bootinfo.txt... +Trying hd:,%BOOT... + + +note the 2.6.2 work, before on 2.6.1 i had the same issue of 2.7 and 2.8 + +I can reproduce the same problem on 2.7.0 on a PowerPC G5 for the x86, x86_64 and ppc softmmu targets (minus the Gtk problem, since I use this ported to Cocoa). As with Luigi this seems to be a regression from 2.6.2. There is no change with -nographic. + +See also: https://bugzilla.redhat.com/show_bug.cgi?id=1332449 + +The commenter indicates several BE issues were detected. I have not yet heard from him regarding his patches or whether they were upstreamed here. + +Oh my gosh the great Cameron Kaiser :) + +Looking through old bug tickets ... can you still reproduce the issue with the latest version of QEMU (v4.2) and a more recent Linux distribution? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1657841 b/results/classifier/105/mistranslation/1657841 new file mode 100644 index 000000000..8b1d2acf6 --- /dev/null +++ b/results/classifier/105/mistranslation/1657841 @@ -0,0 +1,29 @@ +mistranslation: 0.717 +device: 0.699 +graphic: 0.685 +instruction: 0.609 +boot: 0.605 +semantic: 0.508 +vnc: 0.260 +other: 0.237 +socket: 0.202 +network: 0.159 +assembly: 0.114 +KVM: 0.001 + +QEMU Intel HAX Windows + +Hi, + +Using the latest exe's from http://qemu.weilnetz.de/w32/ + +C:\Users\therock247uk\Desktop\jan\qemu-w64-setup-20170113>qemu-system-i386 --enable-hax -m 512 -cdrom C:\Users\therock247uk\Desktop\jan\en_windows_xp_professional_with_service_pack_3_x86_cd_x14-80428.iso +HAX is working and emulator runs in fast virt mode. +Failed to allocate 20000000 memory + +The emulator seems to hang/get stuck during booting from the CD taking out --enable-hax allows it to boot. + +Which version were you exactly using? Can you still reproduce the problem with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1658634 b/results/classifier/105/mistranslation/1658634 new file mode 100644 index 000000000..25f7325c5 --- /dev/null +++ b/results/classifier/105/mistranslation/1658634 @@ -0,0 +1,413 @@ +mistranslation: 0.887 +graphic: 0.851 +network: 0.832 +other: 0.821 +semantic: 0.805 +instruction: 0.798 +assembly: 0.796 +device: 0.783 +boot: 0.753 +socket: 0.746 +KVM: 0.734 +vnc: 0.669 + +Can't get correct display with latest QEMU and OVMF BIOS + +I tried to install a Ubuntu 16.04.1 Desktop 64bits with latest QEMU and OVMF UEFI BIOS, however I can't get correct display output with default vga configuration (-vga std). However, qemu works with a couple of different configurations: +1. "-vga cirrus" + "-bios OVMF.fd": works +2. "-vga std" + non-UEFI bios: works + +The same error with QEMU 2.8.0 release. Everything works well on 2.7.0/1. + +(1) What phase of the guest do you get invalid video output in? Do you see the TianoCore splash screen? Does the grub2 menu appear? + +(2) I cannot reproduce the issue (with a different guest OS anyway); I just tried QEMU (at d1c82f7cc344) and OVMF (built from edk2 at 7cf59c854f35), with stdvga; this combo works fine. + +(3) Can you bisect QEMU from 2.7 through 2.8, using the same OVMF binary? + +(4) Side point: please *never* use "-bios OVMF.fd"; use two pflash chips instead. Libvirt (strongly recommended) will do this for you. + +Thanks. + +Splash screen and UEFI shell were displayed correctly. Grub2 menu and +Ubuntu login screen also appeared, however the display didn't seem right. I +got very blurry output. + +[image: Inline image 1] + +With QEMU 2.7.0 and the same OVMF.fd, everything works well. + +Please let me know if anything is not clear. + +Thanks, +Kai + +On Mon, Jan 23, 2017 at 4:50 AM, Laszlo Ersek (Red Hat) <email address hidden> +wrote: + +> (1) What phase of the guest do you get invalid video output in? Do you +> see the TianoCore splash screen? Does the grub2 menu appear? +> +> (2) I cannot reproduce the issue (with a different guest OS anyway); I +> just tried QEMU (at d1c82f7cc344) and OVMF (built from edk2 at +> 7cf59c854f35), with stdvga; this combo works fine. +> +> (3) Can you bisect QEMU from 2.7 through 2.8, using the same OVMF +> binary? +> +> (4) Side point: please *never* use "-bios OVMF.fd"; use two pflash chips +> instead. Libvirt (strongly recommended) will do this for you. +> +> Thanks. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1658634 +> +> Title: +> Can't get correct display with latest QEMU and OVMF BIOS +> +> Status in QEMU: +> New +> +> Bug description: +> I tried to install a Ubuntu 16.04.1 Desktop 64bits with latest QEMU and +> OVMF UEFI BIOS, however I can't get correct display output with default vga +> configuration (-vga std). However, qemu works with a couple of different +> configurations: +> 1. "-vga cirrus" + "-bios OVMF.fd": works +> 2. "-vga std" + non-UEFI bios: works +> +> The same error with QEMU 2.8.0 release. Everything works well on +> 2.7.0/1. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1658634/+subscriptions +> + + +I downloaded "ubuntu-16.04.1-desktop-amd64.iso" (MD5: 17643c29e3c4609818f26becf76d29a3), and I can reproduce the issue -- the grub2 display is corrupt. (I didn't even look further than that.) I also confirm that it works fine with the same firmware, but using QEMU 2.7. + +Here's the result of the bisection: + +cd958edb1fae85d0c7d1e1acbff82d22724e8d64 is the first bad commit +commit cd958edb1fae85d0c7d1e1acbff82d22724e8d64 +Author: Marc-André Lureau <email address hidden> +Date: Fri Aug 26 13:47:11 2016 +0400 + + console: skip same-size resize + + virtio-gpu does a set-scanout at each frame (it might be a driver + regression). qemu_console_resize() recreate a surface even if the size + didn't change, and this shows up in profiling reports because the + surface is cleared. With this patch, I get a +15-20% glmark2 + improvement. + + Signed-off-by: Marc-André Lureau <email address hidden> + Message-id: <email address hidden> + Signed-off-by: Gerd Hoffmann <email address hidden> + +If I revert this commit on top of current master -- it reverts cleanly -- then the grub2 screen displays fine again. + +For reference, this is my script: + +ISO=ubuntu-16.04.1-desktop-amd64.iso +CODE=OVMF_CODE.fd +TMPL=OVMF_VARS.fd + +cp $TMPL vars.fd + +qemu-system-x86_64 \ + -m 1024 \ + -M pc,accel=kvm \ + -device VGA \ + -drive if=pflash,readonly,format=raw,file=$CODE \ + -drive if=pflash,format=raw,file=vars.fd \ + -drive id=cdrom,if=none,readonly,format=raw,file=$ISO \ + -device virtio-scsi-pci,id=scsi0 \ + -device scsi-cd,bus=scsi0.0,drive=cdrom,bootindex=0 \ + -debugcon file:debug.log \ + -global isa-debugcon.iobase=0x402 \ + -chardev stdio,signal=off,mux=on,id=char0 \ + -mon chardev=char0,mode=readline,default \ + -serial chardev:char0 + + +Added Marc-André and Gerd to the CC list. + +Only skip surface reallocation in case the old surface was created using +qemu_alloc_display (via qemu_create_displaysurface) too, otherwise we +might end up with a DisplaySurface with the wrong backing storage. + +Cc: <email address hidden> +Cc: Marc-André Lureau <email address hidden> +Fixes: cd958edb1fae85d0c7d1e1acbff82d22724e8d64 +Signed-off-by: Gerd Hoffmann <email address hidden> +--- + ui/console.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/ui/console.c b/ui/console.c +index b9575f2..67c65b7 100644 +--- a/ui/console.c ++++ b/ui/console.c +@@ -2121,7 +2121,7 @@ void qemu_console_resize(QemuConsole *s, int width, int height) + + assert(s->console_type == GRAPHIC_CONSOLE); + +- if (s->surface && ++ if (s->surface && (surface->flags & QEMU_ALLOCATED_FLAG) && + pixman_image_get_width(s->surface->image) == width && + pixman_image_get_height(s->surface->image) == height) { + return; +-- +1.8.3.1 + + + +Hi + +On Tue, Jan 24, 2017 at 2:31 PM Gerd Hoffmann <email address hidden> +wrote: + +> Only skip surface reallocation in case the old surface was created using +> qemu_alloc_display (via qemu_create_displaysurface) too, otherwise we +> might end up with a DisplaySurface with the wrong backing storage. +> +> Cc: <email address hidden> +> Cc: Marc-André Lureau <email address hidden> +> Fixes: cd958edb1fae85d0c7d1e1acbff82d22724e8d64 +> Signed-off-by: Gerd Hoffmann <email address hidden> +> --- +> ui/console.c | 2 +- +> 1 file changed, 1 insertion(+), 1 deletion(-) +> +> diff --git a/ui/console.c b/ui/console.c +> index b9575f2..67c65b7 100644 +> --- a/ui/console.c +> +++ b/ui/console.c +> @@ -2121,7 +2121,7 @@ void qemu_console_resize(QemuConsole *s, int width, +> int height) +> +> assert(s->console_type == GRAPHIC_CONSOLE); +> +> - if (s->surface && +> + if (s->surface && (surface->flags & QEMU_ALLOCATED_FLAG) && +> pixman_image_get_width(s->surface->image) == width && +> pixman_image_get_height(s->surface->image) == height) { +> return; +> + +You are missing the 's->' ! + +with that, +Reviewed-by: Marc-André Lureau <email address hidden> + + +-- +> 1.8.3.1 +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1658634 +> +> Title: +> Can't get correct display with latest QEMU and OVMF BIOS +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1658634/+subscriptions +> +-- +Marc-André Lureau + + +> > - if (s->surface && +> > + if (s->surface && (surface->flags & QEMU_ALLOCATED_FLAG) && +> > pixman_image_get_width(s->surface->image) == width && +> > pixman_image_get_height(s->surface->image) == height) { +> > return; +> > +> +> You are missing the 's->' ! + +Good catch. /me wonders why gcc didn't throw a warning on that one. + +Fixed. + +thanks, + Gerd + + + +Only skip surface reallocation in case the old surface was created using +qemu_alloc_display (via qemu_create_displaysurface) too, otherwise we +might end up with a DisplaySurface with the wrong backing storage. + +Cc: <email address hidden> +Fixes: cd958edb1fae85d0c7d1e1acbff82d22724e8d64 +Signed-off-by: Gerd Hoffmann <email address hidden> +Reviewed-by: Marc-André Lureau <email address hidden> +--- + ui/console.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/ui/console.c b/ui/console.c +index b9575f2..d573351 100644 +--- a/ui/console.c ++++ b/ui/console.c +@@ -2121,7 +2121,7 @@ void qemu_console_resize(QemuConsole *s, int width, int height) + + assert(s->console_type == GRAPHIC_CONSOLE); + +- if (s->surface && ++ if (s->surface && (s->surface->flags & QEMU_ALLOCATED_FLAG) && + pixman_image_get_width(s->surface->image) == width && + pixman_image_get_height(s->surface->image) == height) { + return; +-- +1.8.3.1 + + + +On 01/24/17 11:37, elmarco wrote: +> Hi +> +> On Tue, Jan 24, 2017 at 2:31 PM Gerd Hoffmann <email address hidden> +> wrote: +> +>> Only skip surface reallocation in case the old surface was created using +>> qemu_alloc_display (via qemu_create_displaysurface) too, otherwise we +>> might end up with a DisplaySurface with the wrong backing storage. +>> +>> Cc: <email address hidden> +>> Cc: Marc-André Lureau <email address hidden> +>> Fixes: cd958edb1fae85d0c7d1e1acbff82d22724e8d64 +>> Signed-off-by: Gerd Hoffmann <email address hidden> +>> --- +>> ui/console.c | 2 +- +>> 1 file changed, 1 insertion(+), 1 deletion(-) +>> +>> diff --git a/ui/console.c b/ui/console.c +>> index b9575f2..67c65b7 100644 +>> --- a/ui/console.c +>> +++ b/ui/console.c +>> @@ -2121,7 +2121,7 @@ void qemu_console_resize(QemuConsole *s, int width, +>> int height) +>> +>> assert(s->console_type == GRAPHIC_CONSOLE); +>> +>> - if (s->surface && +>> + if (s->surface && (surface->flags & QEMU_ALLOCATED_FLAG) && +>> pixman_image_get_width(s->surface->image) == width && +>> pixman_image_get_height(s->surface->image) == height) { +>> return; +>> +> +> You are missing the 's->' ! +> +> with that, +> Reviewed-by: Marc-André Lureau <email address hidden> + +With that change: + +Tested-by: Laszlo Ersek <email address hidden> + +Also, + +Cc: <email address hidden> + +Thanks +Laszlo + + +> -- +>> 1.8.3.1 +>> +>> -- +>> You received this bug notification because you are subscribed to the bug +>> report. +>> https://bugs.launchpad.net/bugs/1658634 +>> +>> Title: +>> Can't get correct display with latest QEMU and OVMF BIOS +>> +>> To manage notifications about this bug go to: +>> https://bugs.launchpad.net/qemu/+bug/1658634/+subscriptions +>> + + + +On 01/24/17 12:10, Gerd Hoffmann wrote: +> Only skip surface reallocation in case the old surface was created using +> qemu_alloc_display (via qemu_create_displaysurface) too, otherwise we +> might end up with a DisplaySurface with the wrong backing storage. +> +> Cc: <email address hidden> +> Fixes: cd958edb1fae85d0c7d1e1acbff82d22724e8d64 +> Signed-off-by: Gerd Hoffmann <email address hidden> +> Reviewed-by: Marc-André Lureau <email address hidden> +> --- +> ui/console.c | 2 +- +> 1 file changed, 1 insertion(+), 1 deletion(-) +> +> diff --git a/ui/console.c b/ui/console.c +> index b9575f2..d573351 100644 +> --- a/ui/console.c +> +++ b/ui/console.c +> @@ -2121,7 +2121,7 @@ void qemu_console_resize(QemuConsole *s, int width, int height) +> +> assert(s->console_type == GRAPHIC_CONSOLE); +> +> - if (s->surface && +> + if (s->surface && (s->surface->flags & QEMU_ALLOCATED_FLAG) && +> pixman_image_get_width(s->surface->image) == width && +> pixman_image_get_height(s->surface->image) == height) { +> return; +> + +Tested-by: Laszlo Ersek <email address hidden> +Cc: <email address hidden> + +Thanks +Laszlo + + +It works well on my side with the patch. Thanks! + +Only skip surface reallocation in case the old surface was created using +qemu_alloc_display (via qemu_create_displaysurface) too, otherwise we +might end up with a DisplaySurface with the wrong backing storage. + +Cc: <email address hidden> +Fixes: cd958edb1fae85d0c7d1e1acbff82d22724e8d64 +Signed-off-by: Gerd Hoffmann <email address hidden> +Reviewed-by: Marc-André Lureau <email address hidden> +Tested-by: Laszlo Ersek <email address hidden> +Message-id: <email address hidden> +--- + ui/console.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/ui/console.c b/ui/console.c +index fe03a66..e353c85 100644 +--- a/ui/console.c ++++ b/ui/console.c +@@ -2116,7 +2116,7 @@ void qemu_console_resize(QemuConsole *s, int width, int height) + + assert(s->console_type == GRAPHIC_CONSOLE); + +- if (s->surface && ++ if (s->surface && (s->surface->flags & QEMU_ALLOCATED_FLAG) && + pixman_image_get_width(s->surface->image) == width && + pixman_image_get_height(s->surface->image) == height) { + return; +-- +1.8.3.1 + + + +Fixed in commit 3ef0c573d37b ("console: fix console resize", 2017-01-31), released in v2.9.0. + + diff --git a/results/classifier/105/mistranslation/166 b/results/classifier/105/mistranslation/166 new file mode 100644 index 000000000..46dd0c5aa --- /dev/null +++ b/results/classifier/105/mistranslation/166 @@ -0,0 +1,14 @@ +mistranslation: 0.996 +semantic: 0.899 +device: 0.600 +graphic: 0.513 +other: 0.357 +network: 0.283 +vnc: 0.068 +assembly: 0.060 +instruction: 0.031 +KVM: 0.016 +boot: 0.013 +socket: 0.008 + +qemu-bridge-helper failure but qemu not exit diff --git a/results/classifier/105/mistranslation/1660010 b/results/classifier/105/mistranslation/1660010 new file mode 100644 index 000000000..9d5f3cfd7 --- /dev/null +++ b/results/classifier/105/mistranslation/1660010 @@ -0,0 +1,56 @@ +mistranslation: 0.614 +semantic: 0.558 +device: 0.542 +socket: 0.517 +network: 0.473 +instruction: 0.448 +graphic: 0.418 +vnc: 0.394 +other: 0.364 +boot: 0.264 +assembly: 0.174 +KVM: 0.102 + +AArch64 system emulation cannot execute virt uefi in 2.7 or 2.8 + +The UEFI firmware file is retrieved from http://snapshots.linaro.org/components/kernel/linaro-edk2/latest/release/qemu64/QEMU_EFI.fd . + +The error is: +``` +TODO /var/lib/abbs/build/tmp.p2dMBBlJ0D/qemu-2.7.0/tci.c:1049: tcg_qemu_tb_exec() +/var/lib/abbs/build/tmp.p2dMBBlJ0D/qemu-2.7.0/tci.c:1049: tcg fatal error +``` + +(both 2.7.0 and 2.8.0 are tested to fail, 2.6.1 works) + + +Icenowy Zheng <email address hidden> writes: + +> Public bug reported: +> +> The UEFI firmware file is retrieved from +> http://snapshots.linaro.org/components/kernel/linaro- +> edk2/latest/release/qemu64/QEMU_EFI.fd . +> +> The error is: +> ``` +> TODO /var/lib/abbs/build/tmp.p2dMBBlJ0D/qemu-2.7.0/tci.c:1049: tcg_qemu_tb_exec() +> /var/lib/abbs/build/tmp.p2dMBBlJ0D/qemu-2.7.0/tci.c:1049: tcg fatal error +> ``` + +What is your command line and why are you running with the TCI? + +> +> (both 2.7.0 and 2.8.0 are tested to fail, 2.6.1 works) +> +> ** Affects: qemu +> Importance: Undecided +> Status: New + + +-- +Alex Bennée + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1660599 b/results/classifier/105/mistranslation/1660599 new file mode 100644 index 000000000..88b6ef22e --- /dev/null +++ b/results/classifier/105/mistranslation/1660599 @@ -0,0 +1,26 @@ +mistranslation: 0.814 +graphic: 0.789 +device: 0.705 +instruction: 0.673 +semantic: 0.624 +other: 0.473 +network: 0.414 +vnc: 0.284 +socket: 0.272 +boot: 0.194 +assembly: 0.061 +KVM: 0.019 + +v2.8.0 won't compile if g++ compiler doesn't understand "-fstack-protector-strong" + +For example, Ubuntu Trusty (LTS 14.04) uses g++ v4.8.5. +Compilation fails with a syntax error saying that the ""-fstack-protector-strong" option in g++ is unrecognized. +Instead, under Ubuntu Xenial (LTS 16.04), the g++ compiler is v5.4.0 and the compilation goes on smoothly. + +Could you provide the command you've used? +I tried `CC=gcc-4.8 ./configure --enable-stack-protector && make` in Ubuntu 14.04 and qemu v2.8.0. It didn't set `-fstack-protector-strong` flag, only `-fstack-protector-all`. + +Which version of gcc (i.e. normal C-compiler, not g++) did you use here? Can you still reproduce this issue with the latest release of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1662468 b/results/classifier/105/mistranslation/1662468 new file mode 100644 index 000000000..66b4bcd98 --- /dev/null +++ b/results/classifier/105/mistranslation/1662468 @@ -0,0 +1,73 @@ +mistranslation: 0.882 +semantic: 0.725 +graphic: 0.641 +device: 0.476 +instruction: 0.435 +socket: 0.400 +other: 0.348 +network: 0.320 +assembly: 0.288 +vnc: 0.284 +boot: 0.192 +KVM: 0.188 + +[feature request] qemu-img convert should respond to control-T like dd + +Since qemu-img convert is a long-running operation, it would be nice if it reported progress in response to control-T (SIGINFO) to show progress information, much like dd, fsck, dump, cp, etc. + +That should be simple enough to implement considering we have this behavior already on SIGUSR1. Unfortunately, I wouldn't be able to test it because Linux apparently doesn't implement SIGINFO... + +Max + + +PS: By the way, thanks for the information. I didn't know about SIGINFO at all. Well, now I have mapped Ctrl-T to SIGUSR1 in my terminal emulator so I don't have to feel quite as inferior... + +On 02/08/17 00:22, Max Reitz wrote: +> That should be simple enough to implement considering we have this +> behavior already on SIGUSR1. Unfortunately, I wouldn't be able to test +> it because Linux apparently doesn't implement SIGINFO... +> +> Max +> +> +> PS: By the way, thanks for the information. I didn't know about SIGINFO at all. Well, now I have mapped Ctrl-T to SIGUSR1 in my terminal emulator so I don't have to feel quite as inferior... +> + +By that you may have lost the following Readline action: + + transpose-chars (C-t) + Drag the character before point forward over the charac- + ter at point, moving point forward as well. If point is + at the end of the line, then this transposes the two + characters before point. Negative arguments have no + effect. + +I'm sure you've been using that all the time... ;) + +Laszlo + + +On Tue, Feb 07, 2017 at 11:22:26PM -0000, Max Reitz wrote: +> That should be simple enough to implement considering we have this +> behavior already on SIGUSR1. Unfortunately, I wouldn't be able to test +> it because Linux apparently doesn't implement SIGINFO... +> +> Max +> +> +> PS: By the way, thanks for the information. I didn't know about SIGINFO at all. Well, now I have mapped Ctrl-T to SIGUSR1 in my terminal emulator so I don't have to feel quite as inferior... + +Christophe: In case you hadn't seen what Max is referring to on the +qemu-img man page: + + -p display progress bar (compare, convert and rebase commands + only). If the -p option is not used for a command that supports + it, the progress is reported when the process receives a + "SIGUSR1" signal. + +Does this do what you want? + + +Fix has been included in v2.10.0: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=262fbae692722d5c8b + diff --git a/results/classifier/105/mistranslation/1665344 b/results/classifier/105/mistranslation/1665344 new file mode 100644 index 000000000..30c6d8ddc --- /dev/null +++ b/results/classifier/105/mistranslation/1665344 @@ -0,0 +1,26 @@ +mistranslation: 0.910 +device: 0.905 +graphic: 0.892 +network: 0.803 +socket: 0.771 +vnc: 0.741 +semantic: 0.661 +boot: 0.626 +instruction: 0.549 +other: 0.467 +KVM: 0.402 +assembly: 0.265 + +documentation error:404 not found + +In http://wiki.qemu-project.org/Outreachy_2017_MayAugust the urls + http://www.qemu-project.org/images/4/4e/Q35.pdf and http://www.qemu-project.org/images/f/f6/PCIvsPCIe.pdf on opening displays: + + + + Not Found + +The requested URL /images/4/4e/Q35.pdf was not found on this server. + +Thanks for letting us know. The links have been updated on the wiki page. + diff --git a/results/classifier/105/mistranslation/1666 b/results/classifier/105/mistranslation/1666 new file mode 100644 index 000000000..8b17423fd --- /dev/null +++ b/results/classifier/105/mistranslation/1666 @@ -0,0 +1,14 @@ +mistranslation: 0.742 +other: 0.710 +semantic: 0.559 +instruction: 0.315 +vnc: 0.258 +KVM: 0.245 +device: 0.200 +graphic: 0.200 +boot: 0.148 +socket: 0.086 +assembly: 0.064 +network: 0.063 + +About the develop environment diff --git a/results/classifier/105/mistranslation/1667 b/results/classifier/105/mistranslation/1667 new file mode 100644 index 000000000..e6cc33da4 --- /dev/null +++ b/results/classifier/105/mistranslation/1667 @@ -0,0 +1,14 @@ +mistranslation: 0.808 +graphic: 0.798 +instruction: 0.745 +device: 0.638 +semantic: 0.417 +vnc: 0.228 +network: 0.172 +other: 0.123 +boot: 0.117 +socket: 0.061 +KVM: 0.047 +assembly: 0.037 + +Tricore: missing a few TC1.6.2 instruction set diff --git a/results/classifier/105/mistranslation/1668 b/results/classifier/105/mistranslation/1668 new file mode 100644 index 000000000..99efa583f --- /dev/null +++ b/results/classifier/105/mistranslation/1668 @@ -0,0 +1,58 @@ +mistranslation: 0.948 +instruction: 0.937 +device: 0.850 +graphic: 0.825 +vnc: 0.704 +network: 0.667 +socket: 0.655 +semantic: 0.646 +boot: 0.513 +assembly: 0.450 +other: 0.441 +KVM: 0.241 + +Fedora 38 build of clang 16 fails when run under s390x emulation (both system & linux-user) +Description of problem: +Spawn a Fedora 38 container using `s390x` linux-user based emulation + +``` +$ podman run -it --platform linux/s390x fedora:latest +``` + +Install clang inside it + +``` +sh-5.2# dnf -y install clang +``` + +Try to run clang + +``` +sh-5.2# clang --version +clang version 16.0.4 (Fedora 16.0.4-1.fc38) +Target: s390x-redhat-linux-gnu +Thread model: posix +InstalledDir: /usr/bin +sh-5.2# clang --help +clang-16: error: unsupported option '--help'; did you mean '--help'? +clang-16: error: no input files +``` + +Notice the nonsense error message when requesting `--help`. With Fedora 37 build of clang 15 (compiled with gcc 12), under s390x emulation, `--help` will correctly print the help. In fact all options except for `--version` appear to be broken: + +``` +sh-5.2# echo "void foo(void) {}" > foo.c +sh-5.2# clang -c foo.c +clang-16: error: unknown argument: '-c' +``` + + +IOW, there appears to be something in the clang 16 (compiled with gcc 13) in Fedora 38 that is tripping up s390x emulation. + +It is unclear whether the trigger was from building clang 16 with a newer gcc 13, or whether something changed from clang 15 -> 16. + +Originally reported with qemu-user-static-7.2.1-1.fc38.x86_64, but I've reproduced with QEMU upstream 7.1.0 release and QEMU upstream git master (v8.0.0-394-gc2b7158455) + +This was originally reported in Fedora at + + https://bugzilla.redhat.com/show_bug.cgi?id=2209635 diff --git a/results/classifier/105/mistranslation/1668360 b/results/classifier/105/mistranslation/1668360 new file mode 100644 index 000000000..2a4873323 --- /dev/null +++ b/results/classifier/105/mistranslation/1668360 @@ -0,0 +1,20 @@ +mistranslation: 0.972 +graphic: 0.786 +device: 0.768 +KVM: 0.718 +semantic: 0.677 +network: 0.568 +vnc: 0.544 +other: 0.485 +socket: 0.465 +assembly: 0.426 +instruction: 0.333 +boot: 0.314 + +Documentation error :404 not found + +In http://wiki.qemu-project.org/Documentation/GettingStartedDevelopers the url http://www.linux-kvm.org/wiki/images/1/17/2010-forum-qmp-status-talk.pp.pdf displays a 404 NOt found error. + +Thanks for the report; the right URL is https://www.linux-kvm.org/images/1/17/2010-forum-qmp-status-talk.pp.pdf and I have updated the wiki page. + + diff --git a/results/classifier/105/mistranslation/1675108 b/results/classifier/105/mistranslation/1675108 new file mode 100644 index 000000000..b42348b00 --- /dev/null +++ b/results/classifier/105/mistranslation/1675108 @@ -0,0 +1,368 @@ +mistranslation: 0.838 +semantic: 0.788 +graphic: 0.768 +instruction: 0.767 +other: 0.758 +assembly: 0.753 +device: 0.739 +boot: 0.718 +vnc: 0.687 +KVM: 0.673 +socket: 0.660 +network: 0.611 + +Cocoa UI always crashes on startup + +Commit 8bb93c6f99a42c2e0943bc904b283cd622d302c5 ("ui/console: ensure graphic updates don't race with TCG vCPUs") causes the graphic update to run on a non-main thread, which Cocoa is not happy with. It crashes immediately after startup. + +$ i386-softmmu/qemu-system-i386 +2017-03-22 10:09:25.113 qemu-system-i386[15968:9538245] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'nextEventMatchingMask should only be called from the Main Thread!' +*** First throw call stack: +( + 0 CoreFoundation 0x00007fff91e72e7b __exceptionPreprocess + 171 + 1 libobjc.A.dylib 0x00007fffa6a5ccad objc_exception_throw + 48 + 2 AppKit 0x00007fff900953fd -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 4471 + 3 qemu-system-i386 0x0000000104f75a49 cocoa_refresh + 233 + 4 qemu-system-i386 0x0000000104e0312c process_queued_cpu_work + 140 + 5 qemu-system-i386 0x0000000104d1a73c qemu_tcg_rr_cpu_thread_fn + 284 + 6 libsystem_pthread.dylib 0x00007fffa7557aab _pthread_body + 180 + 7 libsystem_pthread.dylib 0x00007fffa75579f7 _pthread_body + 0 + 8 libsystem_pthread.dylib 0x00007fffa75571fd thread_start + 13 +) +libc++abi.dylib: terminating with uncaught exception of type NSException +Abort trap: 6 + +System: macOS 10.12.3, Xcode 8.2.1 + +On 22 March 2017 at 17:26, Brendan Shanks <email address hidden> wrote: +> Public bug reported: +> +> Commit 8bb93c6f99a42c2e0943bc904b283cd622d302c5 ("ui/console: ensure +> graphic updates don't race with TCG vCPUs") causes the graphic update to +> run on a non-main thread, which Cocoa is not happy with. It crashes +> immediately after startup. + +Oops. Alex, we can't just run UI code on random threads like this. +Any ideas? + +thanks +-- PMM + + + +Peter Maydell <email address hidden> writes: + +> On 22 March 2017 at 17:26, Brendan Shanks <email address hidden> wrote: +>> Public bug reported: +>> +>> Commit 8bb93c6f99a42c2e0943bc904b283cd622d302c5 ("ui/console: ensure +>> graphic updates don't race with TCG vCPUs") causes the graphic update to +>> run on a non-main thread, which Cocoa is not happy with. It crashes +>> immediately after startup. +> +> Oops. Alex, we can't just run UI code on random threads like this. + +Technically its not a random thread its the vCPU context (which ensures +the vCPU isn't updating while the display is being updated). But I guess +the Cocoa is limited to not being able to update from an arbitrary +thread? + +There was a patch posted yesterday to ensure the BQL is held during the +deferred work but this doesn't look like that. + +> Any ideas? + +Hmm a quick Google seems to imply Cocoa is inflexible in its +requirements. You can try this ugly but untested patch (I don't have any +Macs handy): + +modified ui/console.c +@@ -1598,8 +1598,16 @@ static void dpy_refresh(DisplayState *s) + QLIST_FOREACH(dcl, &s->listeners, next) { + if (dcl->ops->dpy_refresh) { + if (tcg_enabled()) { ++#ifdef CONFIG_COCOA ++ qemu_mutex_unlock_iothread(); ++ start_exclusive(); ++ do_safe_dpy_refresh(first_cpu, RUN_ON_CPU_HOST_PTR(dcl)); ++ end_exclusive(); ++ qemu_mutex_lock_iothread(); ++#else + async_safe_run_on_cpu(first_cpu, do_safe_dpy_refresh, + RUN_ON_CPU_HOST_PTR(dcl)); ++#endif + } else { + dcl->ops->dpy_refresh(dcl); + } + + +Other than that I guess we need to bring forward the plans to "fixed the dirty tracking +races in display adapters" + +> +> thanks +> -- PMM + + +-- +Alex Bennée + + +On 23 March 2017 at 11:13, Alex Bennée <email address hidden> wrote: +> Technically its not a random thread its the vCPU context (which ensures +> the vCPU isn't updating while the display is being updated). But I guess +> the Cocoa is limited to not being able to update from an arbitrary +> thread? + +Yes. It's very common for windowing libraries to mandate that you +do all windowing operations from one specific thread. + +thanks +-- PMM + + + +Peter Maydell <email address hidden> writes: + +> On 23 March 2017 at 11:13, Alex Bennée <email address hidden> wrote: +>> Technically its not a random thread its the vCPU context (which ensures +>> the vCPU isn't updating while the display is being updated). But I guess +>> the Cocoa is limited to not being able to update from an arbitrary +>> thread? +> +> Yes. It's very common for windowing libraries to mandate that you +> do all windowing operations from one specific thread. + +Fair enough. Well let me know if that works OK on MacOS and I'll fold it +in to the other console patches. In fact I might as well do the +start/end_exclusive dance for all OSes and it will achieve the same thing. + +-- +Alex Bennée + + + +On Mar 23, 2017, at 7:35 AM, <email address hidden> wrote: + +> Message: 15 +> Date: Thu, 23 Mar 2017 11:13:02 +0000 +> From: Alex Benn?e <email address hidden> +> To: Peter Maydell <email address hidden> +> Cc: Bug 1675108 <email address hidden>, QEMU Developers +> <email address hidden>, Gerd Hoffmann <email address hidden> +> Subject: Re: [Qemu-devel] [Bug 1675108] [NEW] Cocoa UI always crashes +> on startup +> Message-ID: <email address hidden> +> Content-Type: text/plain; charset=utf-8 +> +> +> Peter Maydell <email address hidden> writes: +> +>> On 22 March 2017 at 17:26, Brendan Shanks <email address hidden> wrote: +>>> Public bug reported: +>>> +>>> Commit 8bb93c6f99a42c2e0943bc904b283cd622d302c5 ("ui/console: ensure +>>> graphic updates don't race with TCG vCPUs") causes the graphic update to +>>> run on a non-main thread, which Cocoa is not happy with. It crashes +>>> immediately after startup. +>> +>> Oops. Alex, we can't just run UI code on random threads like this. +> +> Technically its not a random thread its the vCPU context (which ensures +> the vCPU isn't updating while the display is being updated). But I guess +> the Cocoa is limited to not being able to update from an arbitrary +> thread? +> +> There was a patch posted yesterday to ensure the BQL is held during the +> deferred work but this doesn't look like that. +> +>> Any ideas? +> +> Hmm a quick Google seems to imply Cocoa is inflexible in its +> requirements. You can try this ugly but untested patch (I don't have any +> Macs handy): +> +> modified ui/console.c +> @@ -1598,8 +1598,16 @@ static void dpy_refresh(DisplayState *s) +> QLIST_FOREACH(dcl, &s->listeners, next) { +> if (dcl->ops->dpy_refresh) { +> if (tcg_enabled()) { +> +#ifdef CONFIG_COCOA +> + qemu_mutex_unlock_iothread(); +> + start_exclusive(); +> + do_safe_dpy_refresh(first_cpu, RUN_ON_CPU_HOST_PTR(dcl)); +> + end_exclusive(); +> + qemu_mutex_lock_iothread(); +> +#else +> async_safe_run_on_cpu(first_cpu, do_safe_dpy_refresh, +> RUN_ON_CPU_HOST_PTR(dcl)); +> +#endif +> } else { +> dcl->ops->dpy_refresh(dcl); +> } +> +> +> Other than that I guess we need to bring forward the plans to "fixed the dirty tracking +> races in display adapters" +> +>> +>> thanks +>> -- PMM +> +> +> -- +> Alex Benn?e + +Your patch does work. I tested it on Mac OS 10.6.8 using qemu-sytem-ppc. + +Has anyone checked on the GTK front-end yet to see if it is having similar problems? + +Tested on 10.12.3, it doesn't crash immediately (like before) but crashes reliably once I send some keyboard input to qemu: + +$ i386-softmmu/qemu-system-i386 +** +ERROR:/Users/pip/no_backup/qemu/translate-common.c:34:tcg_handle_interrupt: assertion failed: (qemu_mutex_iothread_locked()) +Abort trap: 6 + + + +Thread 0 Crashed:: Dispatch queue: com.apple.main-thread +0 libsystem_kernel.dylib 0x00007fffa746edd6 __pthread_kill + 10 +1 libsystem_pthread.dylib 0x00007fffa755a787 pthread_kill + 90 +2 libsystem_c.dylib 0x00007fffa73d4420 abort + 129 +3 libglib-2.0.0.dylib 0x00000001076aec86 g_assertion_message + 388 +4 libglib-2.0.0.dylib 0x00000001076aece4 g_assertion_message_expr + 94 +5 qemu-system-i386 0x00000001066bb1ec tcg_handle_interrupt + 156 (translate-common.c:50) +6 qemu-system-i386 0x0000000106740dfc pic_irq_request + 156 (pc.c:187) +7 qemu-system-i386 0x000000010673e5e4 gsi_handler + 36 (pc.c:115) +8 qemu-system-i386 0x000000010685e97a kbd_update_kbd_irq + 138 (pckbd.c:180) +9 qemu-system-i386 0x000000010694164a qemu_input_event_send_impl + 938 (input.c:328) +10 qemu-system-i386 0x000000010694188f qemu_input_event_send_key + 239 (input.c:359) +11 qemu-system-i386 0x0000000106946a00 cocoa_refresh + 272 (cocoa.m:1402) +12 qemu-system-i386 0x000000010693f6a8 gui_update + 104 (console.c:1603) + + +The keyboard input issue looks the same as #1675549, and that's on Linux/SDL. So not specific to this fix or Cocoa. + + +Brendan Shanks <email address hidden> writes: + +> Tested on 10.12.3, it doesn't crash immediately (like before) but +> crashes reliably once I send some keyboard input to qemu: +> +> $ i386-softmmu/qemu-system-i386 +> ** +> ERROR:/Users/pip/no_backup/qemu/translate-common.c:34:tcg_handle_interrupt: assertion failed: (qemu_mutex_iothread_locked()) +> Abort trap: 6 + +Can you test with the suggested patch I posted yesterday? If we keep the +update under BQL this shouldn't fail. + +> +> +> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread +> 0 libsystem_kernel.dylib 0x00007fffa746edd6 __pthread_kill + 10 +> 1 libsystem_pthread.dylib 0x00007fffa755a787 pthread_kill + 90 +> 2 libsystem_c.dylib 0x00007fffa73d4420 abort + 129 +> 3 libglib-2.0.0.dylib 0x00000001076aec86 g_assertion_message + 388 +> 4 libglib-2.0.0.dylib 0x00000001076aece4 g_assertion_message_expr + 94 +> 5 qemu-system-i386 0x00000001066bb1ec tcg_handle_interrupt + 156 (translate-common.c:50) +> 6 qemu-system-i386 0x0000000106740dfc pic_irq_request + 156 (pc.c:187) +> 7 qemu-system-i386 0x000000010673e5e4 gsi_handler + 36 (pc.c:115) +> 8 qemu-system-i386 0x000000010685e97a kbd_update_kbd_irq + 138 (pckbd.c:180) +> 9 qemu-system-i386 0x000000010694164a qemu_input_event_send_impl + 938 (input.c:328) +> 10 qemu-system-i386 0x000000010694188f qemu_input_event_send_key + 239 (input.c:359) +> 11 qemu-system-i386 0x0000000106946a00 cocoa_refresh + 272 (cocoa.m:1402) +> 12 qemu-system-i386 0x000000010693f6a8 gui_update + 104 (console.c:1603) + + +-- +Alex Bennée + + +On Do, 2017-03-23 at 11:31 +0000, Alex Bennée wrote: +> Peter Maydell <email address hidden> writes: +> +> > On 23 March 2017 at 11:13, Alex Bennée <email address hidden> wrote: +> >> Technically its not a random thread its the vCPU context (which ensures +> >> the vCPU isn't updating while the display is being updated). But I guess +> >> the Cocoa is limited to not being able to update from an arbitrary +> >> thread? +> > +> > Yes. It's very common for windowing libraries to mandate that you +> > do all windowing operations from one specific thread. +> +> Fair enough. Well let me know if that works OK on MacOS and I'll fold it +> in to the other console patches. In fact I might as well do the +> start/end_exclusive dance for all OSes and it will achieve the same thing. + +Where do we stand with this one? + +cheers, + Gerd + + + + +Gerd Hoffmann <email address hidden> writes: + +> On Do, 2017-03-23 at 11:31 +0000, Alex Bennée wrote: +>> Peter Maydell <email address hidden> writes: +>> +>> > On 23 March 2017 at 11:13, Alex Bennée <email address hidden> wrote: +>> >> Technically its not a random thread its the vCPU context (which ensures +>> >> the vCPU isn't updating while the display is being updated). But I guess +>> >> the Cocoa is limited to not being able to update from an arbitrary +>> >> thread? +>> > +>> > Yes. It's very common for windowing libraries to mandate that you +>> > do all windowing operations from one specific thread. +>> +>> Fair enough. Well let me know if that works OK on MacOS and I'll fold it +>> in to the other console patches. In fact I might as well do the +>> start/end_exclusive dance for all OSes and it will achieve the same thing. +> +> Where do we stand with this one? + +I've got two patches in my tree at the moment. I was holding off posting +the series to see if I could make more progress with the record/replay +bug. I'll post the series tomorrow morning but if you want to grab them +ahead of that see: + + https://github.com/stsquad/qemu/commit/6c0ddfc5752f311b4c5a2956de25821cc2cd3fd6 + https://github.com/stsquad/qemu/commit/15d2b05a20879017f20370b71d5d144947b693fe + +-- +Alex Bennée + + +On 27 March 2017 at 16:18, Alex Bennée <email address hidden> wrote: +> I've got two patches in my tree at the moment. I was holding off posting +> the series to see if I could make more progress with the record/replay +> bug. + +rc candidates are cut on Tuesdays, so it's better in general not +to sit on a fix for rc bugs if it causes them to miss going into +the next rc tag. + +thanks +-- PMM + + +I just did a quick test on 10.12.3 with those two patches and didn't get any crashes + + +Brendan Shanks <email address hidden> writes: + +> I just did a quick test on 10.12.3 with those two patches and didn't get +> any crashes + +Awesome. I'm rolling the series now. I assume will pickup the patches in +due course. + +-- +Alex Bennée + + +Fixed in -rc2, closing. + diff --git a/results/classifier/105/mistranslation/1683084 b/results/classifier/105/mistranslation/1683084 new file mode 100644 index 000000000..e0e73af5c --- /dev/null +++ b/results/classifier/105/mistranslation/1683084 @@ -0,0 +1,29 @@ +mistranslation: 0.802 +graphic: 0.648 +other: 0.460 +semantic: 0.360 +network: 0.349 +device: 0.342 +vnc: 0.227 +socket: 0.160 +instruction: 0.089 +boot: 0.073 +KVM: 0.062 +assembly: 0.037 + +DNS server not working in QEMU usermode networking + +Nslookup is returning "unknown host". +I try to ping 10.0.2.3 and it fails. Pinging 10.0.2.2 and 10.0.2.15 works correctly. +Downloading files via wget using a static IP works well. + +Results of qemu monitor command "info network" included as an attachment. + +This bug was reported as a question on stack overflow: http://stackoverflow.com/questions/43308310/dns-server-not-working-in-qemu-usermode-networking. + +This bug exists on 2.8.0 and 2.9-rc3. + + + +User error, this is not a bug + diff --git a/results/classifier/105/mistranslation/1686980 b/results/classifier/105/mistranslation/1686980 new file mode 100644 index 000000000..b688fc0db --- /dev/null +++ b/results/classifier/105/mistranslation/1686980 @@ -0,0 +1,101 @@ +mistranslation: 0.731 +other: 0.701 +vnc: 0.637 +KVM: 0.616 +semantic: 0.598 +assembly: 0.517 +graphic: 0.511 +device: 0.510 +instruction: 0.496 +socket: 0.449 +network: 0.437 +boot: 0.431 + +qemu is very slow when adding 16,384 virtio-scsi drives + +qemu runs very slowly when adding many virtio-scsi drives. I have attached a small reproducer shell script which demonstrates this. + +Using perf shows the following stack trace taking all the time: + + 72.42% 71.15% qemu-system-x86 qemu-system-x86_64 [.] drive_get + | + --72.32%--drive_get + | + --1.24%--__irqentry_text_start + | + --1.22%--smp_apic_timer_interrupt + | + --1.00%--local_apic_timer_interrupt + | + --1.00%--hrtimer_interrupt + | + --0.83%--__hrtimer_run_queues + | + --0.64%--tick_sched_timer + + 21.70% 21.34% qemu-system-x86 qemu-system-x86_64 [.] blk_legacy_dinfo + | + ---blk_legacy_dinfo + + 3.65% 3.59% qemu-system-x86 qemu-system-x86_64 [.] blk_next + | + ---blk_next + + + +The first place where it ages an insane amount of time is simply processing -drive options. The stack trace I see is this + +(gdb) bt +#0 0x00005583b596719a in drive_get (type=type@entry=IF_NONE, bus=bus@entry=0, unit=unit@entry=2313) at blockdev.c:223 +#1 0x00005583b59679bd in drive_new (all_opts=0x5583b890e080, block_default_type=<optimized out>) at blockdev.c:996 +#2 0x00005583b5971641 in drive_init_func (opaque=<optimized out>, opts=<optimized out>, errp=<optimized out>) + at vl.c:1154 +#3 0x00005583b5c1149a in qemu_opts_foreach (list=<optimized out>, func=0x5583b5971630 <drive_init_func>, opaque=0x5583b9980030, errp=0x0) at util/qemu-option.c:1114 +#4 0x00005583b5830d30 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4499 + + +We're iterating over every -drive option. Now because we're using if=none, and thus unit==0, line 996 of blockdev.c looks calling drive_get() until we find a matching drive, in order to identify the unit number. So we have a loop over every drive, calling drive_new which loops over every drive calling drive_get which loops over every drive. So about O(N*N*N) + +I instrumented drive_new to time how long 1000 creations took with current code: + +1000 drive_new() in 0 secs +1000 drive_new() in 2 secs +1000 drive_new() in 18 secs +1000 drive_new() in 61 secs + +As a quick hack you can just disable the drive_get() calls when if=none. They're mostly just used to fill in default unit_id, but that's not really required for if=none. That said, if no id= parameter is set, then the code does expect unit_id to be valid, so not sure how to fully fix that. + +Anyway, with this hack applied it is much faster, but there is still some kind of N*N complexity going on, because drive_new() gets slower & slower as each drive is created - just not nearly as badly as before. + +1000 drive_new() in 0 secs +1000 drive_new() in 0 secs +1000 drive_new() in 0 secs +1000 drive_new() in 1 secs +1000 drive_new() in 1 secs +1000 drive_new() in 1 secs +1000 drive_new() in 2 secs +1000 drive_new() in 2 secs +1000 drive_new() in 2 secs +1000 drive_new() in 4 secs +1000 drive_new() in 4 secs +1000 drive_new() in 6 secs +1000 drive_new() in 8 secs +1000 drive_new() in 8 secs + + +I added further instrumentation and got this profile of where the remaining time goes + +1000x drive_new 18.347secs +-> 1000x blockdev_init 18.328secs + -> 1000x monitor_add_blk 4.515secs + -> 1000x blk_by_name 1.545secs + -> 1000x bdrv_find_node 2.968secs + -> 1000x blk_new_open 13.786secs + -> 1000x bdrv_open 13.783secs + +These numbers are all increasing as we process more & more -drive args, so there's some O(N) factor in blk_by_name, bdrv_find_node and bdrv_open + +Is this faster nowadays if you use the new -blockdev parameter instead of -drive? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1692 b/results/classifier/105/mistranslation/1692 new file mode 100644 index 000000000..877f88181 --- /dev/null +++ b/results/classifier/105/mistranslation/1692 @@ -0,0 +1,115 @@ +mistranslation: 0.923 +other: 0.837 +graphic: 0.834 +instruction: 0.810 +KVM: 0.792 +device: 0.783 +semantic: 0.780 +boot: 0.756 +socket: 0.735 +assembly: 0.706 +network: 0.706 +vnc: 0.617 + +Got "Assertion `bus->irq_count[i] == 0` failed" when running fuzzing +Description of problem: +When running the fuzzer on ac97, it always stops with "Assertion `bus->irq_count[i] == 0` failed". +Steps to reproduce: +Run `./qemu-fuzz-x86_64 --fuzz-target=generic-fuzz-ac97` +Additional information: +The logs triggered by the crash report are: +``` +==2330108==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +[I 0.000000] OPENED +INFO: libFuzzer ignores flags that start with '--' +INFO: Running with entropic power schedule (0xFF, 100). +INFO: Seed: 1879893091 +INFO: Loaded 1 modules (358762 inline 8-bit counters): 358762 [0x55bec313a1a0, 0x55bec3191b0a), +INFO: Loaded 1 PC tables (358762 PCs): 358762 [0x55bec3191b10,0x55bec370b1b0), +./qemu-fuzz-x86_64: Running 1 inputs 1 time(s) each. +Running: ./crash-55e7a160b7c66d5b41718e22c7620a29e9f568f1 +Starting x86_64 with Arguments: -display none -machine accel=qtest, -m 512M -machine q35 -nodefaults -device ac97,audiodev=snd0 -audiodev none,id=snd0 -nodefaults -qtest /dev/null +Matching objects by name ac97* +This process will try to fuzz the following MemoryRegions: + * bus master[0] (size 0xffffffffffffffff) + * ac97-nabm[0] (size 0x100) + * bus master container[0] (size 0xffffffffffffffff) + * ac97-nam[0] (size 0x400) +[R +0.033680] outl 0xcf8 0x80000800 +[S +0.033714] [R +0.033729] inw 0xcfc +[S +0.033750] [R +0.033766] outl 0xcf8 0x80000810 +[S +0.033781] [R +0.033792] outl 0xcfc 0xffffffff +[S +0.033816] [R +0.033827] outl 0xcf8 0x80000810 +[S +0.033841] [R +0.033852] inl 0xcfc +[S +0.033866] [R +0.033879] outl 0xcf8 0x80000810 +[S +0.033894] [R +0.033904] outl 0xcfc 0xc001 +[S +0.033920] [R +0.033935] outl 0xcf8 0x80000814 +[S +0.033952] [R +0.033967] outl 0xcfc 0xffffffff +[S +0.033984] [R +0.033994] outl 0xcf8 0x80000814 +[S +0.034008] [R +0.034017] inl 0xcfc +[S +0.034031] [R +0.034043] outl 0xcf8 0x80000814 +[S +0.034057] [R +0.034067] outl 0xcfc 0xc401 +[S +0.034085] [R +0.034096] outl 0xcf8 0x80000804 +[S +0.034110] [R +0.034120] inw 0xcfc +[S +0.034133] [R +0.034145] outl 0xcf8 0x80000804 +[S +0.034159] [R +0.034170] outw 0xcfc 0x7 +[S +0.035259] [R +0.035272] outl 0xcf8 0x80000804 +[S +0.035285] [R +0.035291] inw 0xcfc +[S +0.035300] [I +0.035389] CLOSED +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outl 0xcf8 0x80000805 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outl 0xcfc 0x5050505 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outw 0xc40b 0x6f0d +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x0 0x8 0x2a256c5a2c008425 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] clock_step +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outl 0xcf8 0x80000805 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outl 0xcfc 0x8468920 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] clock_step +qemu-fuzz-x86_64: ../../../../hw/pci/pci.c:435: void pcibus_reset(BusState *): Assertion `bus->irq_count[i] == 0' failed. +==2330108== ERROR: libFuzzer: deadly signal + #0 0x55bebf2624de in __sanitizer_print_stack_trace ../../llvm-project-15.0.0.src/compiler-rt/lib/asan/asan_stack.cpp:87:3 + #1 0x55bebf1a4b31 in fuzzer::PrintStackTrace() ../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:38 + #2 0x55bebf17f406 in fuzzer::Fuzzer::CrashCallback() (.part.0) ../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:233:18 + #3 0x55bebf17f4cd in fuzzer::Fuzzer::CrashCallback() ../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:205:1 + #4 0x55bebf17f4cd in fuzzer::Fuzzer::StaticCrashSignalCallback() ../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:204:19 + #5 0x7fae9f8a441f (/lib/x86_64-linux-gnu/libpthread.so.0+0x1441f) (BuildId: 7b4536f41cdaa5888408e82d0836e33dcf436466) + #6 0x7fae9f69800a in __libc_signal_restore_set /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3 + #7 0x7fae9f69800a in raise /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:48:3 + #8 0x7fae9f677858 in abort /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:79:7 + #9 0x7fae9f677728 in __assert_fail_base /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:92:3 + #10 0x7fae9f688fd5 in __assert_fail /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:101:3 + #11 0x55bebfab33a7 in pcibus_reset ../hw/pci/pci.c:435:9 + #12 0x55bec0c75ae3 in resettable_phase_hold ../hw/core/resettable.c + #13 0x55bec0c6e543 in device_reset_child_foreach ../hw/core/qdev.c:276:9 + #14 0x55bec0c757c5 in resettable_phase_hold ../hw/core/resettable.c:173:5 + #15 0x55bec0c5c421 in bus_reset_child_foreach ../hw/core/bus.c:97:13 + #16 0x55bec0c757c5 in resettable_phase_hold ../hw/core/resettable.c:173:5 + #17 0x55bec0c73729 in resettable_assert_reset ../hw/core/resettable.c:60:5 + #18 0x55bec0c7336a in resettable_reset ../hw/core/resettable.c:45:5 + #19 0x55bec0c7309a in qemu_devices_reset ../hw/core/reset.c:84:9 + #20 0x55bec02d95bb in pc_machine_reset ../hw/i386/pc.c:1901:5 + #21 0x55bebff4ede6 in qemu_system_reset ../softmmu/runstate.c:451:9 + #22 0x55bec0c49684 in fuzz_reset ../tests/qtest/fuzz/fuzz.c:56:5 + #23 0x55bec0c55641 in generic_fuzz ../tests/qtest/fuzz/generic_fuzz.c:676:5 + #24 0x55bec0c4a0f7 in LLVMFuzzerTestOneInput ../tests/qtest/fuzz/fuzz.c:158:5 + #25 0x55bebf17fc88 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) .. /../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:612:15 + #26 0x55bebf1630a4 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) ../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:324:21 + #27 0x55bebf16fa8a in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) ../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:860:19 + #28 0x55bebf15a856 in main ../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30 + #29 0x7fae9f679082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 + #30 0x55bebf15a8dd in _start (../qemu-fuzz-x86_64+0x1e938dd) + +NOTE: libFuzzer has rudimentary signal handlers. + Combine libFuzzer with AddressSanitizer or similar for better crash reports. +SUMMARY: libFuzzer: deadly signal + +``` + +After some manual checks, I find out that the instruction `outl 0xcf8 0x80000805` and `outl 0xcfc 0x8468920` will set irq_count[5] to -1 while the pcibus_reset() doesn't set it back to 0 so it will fail the assertion. diff --git a/results/classifier/105/mistranslation/1694 b/results/classifier/105/mistranslation/1694 new file mode 100644 index 000000000..4c6bca741 --- /dev/null +++ b/results/classifier/105/mistranslation/1694 @@ -0,0 +1,14 @@ +mistranslation: 0.939 +instruction: 0.670 +device: 0.647 +graphic: 0.499 +semantic: 0.300 +vnc: 0.270 +other: 0.205 +assembly: 0.197 +boot: 0.145 +socket: 0.087 +network: 0.075 +KVM: 0.011 + +cpu-x86-uarch-abi.py is missing "xsave" cpuid for x86-64-v3 && x86-64-v4 diff --git a/results/classifier/105/mistranslation/1696746 b/results/classifier/105/mistranslation/1696746 new file mode 100644 index 000000000..d2f614cc6 --- /dev/null +++ b/results/classifier/105/mistranslation/1696746 @@ -0,0 +1,37 @@ +mistranslation: 0.818 +network: 0.803 +socket: 0.698 +device: 0.672 +graphic: 0.648 +instruction: 0.569 +semantic: 0.569 +other: 0.323 +assembly: 0.204 +boot: 0.197 +vnc: 0.195 +KVM: 0.066 + +netdev user,restrict=on prevents forwarded ports from being accessed from other systems + +I've got a guest only network and I'm wanting to access SSH on one of the guests externally. +I'm using -netdev user,id=usernet0,hostfwd=tcp::2222-:22,restrict=yes -device virtio-net-pci,netdev=usernet0 +to forward 2222 to 22 in the guest. + +The docs state: +restrict=on|off + + If this option is enabled, the guest will be isolated, i.e. it will not be able to contact the host and no guest IP packets will be routed over the host to the outside. This option does not affect any explicitly set forwarding rules. + + +However, with restrict=on, the forwarded port is only accessible from the host. Other systems receive no data. + +This was tested with qemu 2.8. Changelog for 2.9 doesn't mention any (relevant) user networking changes, so that should also fail. + +slirp (i.e. user networking) has been moved to a separate project... does this problem still persist with the latest version of QEMU? If so, could you please report it to the libslirp project instead: + +https://gitlab.freedesktop.org/slirp/libslirp/-/issues + +Thanks! + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1699 b/results/classifier/105/mistranslation/1699 new file mode 100644 index 000000000..24d7c1185 --- /dev/null +++ b/results/classifier/105/mistranslation/1699 @@ -0,0 +1,14 @@ +mistranslation: 0.977 +instruction: 0.928 +semantic: 0.618 +graphic: 0.486 +other: 0.440 +device: 0.360 +boot: 0.244 +vnc: 0.224 +KVM: 0.103 +network: 0.071 +socket: 0.051 +assembly: 0.034 + +Tricore: Call instruction wrong diff --git a/results/classifier/105/mistranslation/1700 b/results/classifier/105/mistranslation/1700 new file mode 100644 index 000000000..95366e933 --- /dev/null +++ b/results/classifier/105/mistranslation/1700 @@ -0,0 +1,14 @@ +mistranslation: 0.902 +device: 0.867 +instruction: 0.762 +graphic: 0.374 +socket: 0.310 +network: 0.299 +semantic: 0.282 +boot: 0.228 +other: 0.175 +vnc: 0.089 +assembly: 0.058 +KVM: 0.005 + +TriCore: helper_ret() is not correctly restoring PSW diff --git a/results/classifier/105/mistranslation/1706 b/results/classifier/105/mistranslation/1706 new file mode 100644 index 000000000..a6d0cdc2e --- /dev/null +++ b/results/classifier/105/mistranslation/1706 @@ -0,0 +1,22 @@ +mistranslation: 0.906 +device: 0.847 +other: 0.710 +network: 0.707 +socket: 0.673 +vnc: 0.671 +instruction: 0.624 +semantic: 0.560 +graphic: 0.534 +boot: 0.431 +KVM: 0.256 +assembly: 0.173 + +Allow TCG plugins to read registers +Additional information: +- `include/qemu/plugin.h` +- `include/qemu/qemu-plugin.h` + +PANDA implemented this already but it is not a very clean solution: +- https://github.com/panda-re/qemu/commit/b97c5a56edd0ba3b5f6ab16bf531ac1f7abaac04 (mentioned in QPP patch series: https://lore.kernel.org/qemu-devel/20221213213757.4123265-1-fasano@mit.edu/) + +I personally think the flag for the TB translation and execution callbacks makes more sense diff --git a/results/classifier/105/mistranslation/1707274 b/results/classifier/105/mistranslation/1707274 new file mode 100644 index 000000000..6eee4f9cd --- /dev/null +++ b/results/classifier/105/mistranslation/1707274 @@ -0,0 +1,24 @@ +mistranslation: 0.728 +instruction: 0.631 +device: 0.611 +assembly: 0.607 +boot: 0.599 +vnc: 0.594 +other: 0.592 +graphic: 0.590 +KVM: 0.582 +network: 0.567 +semantic: 0.563 +socket: 0.554 + +Segfaults inside QEMU + +I'm running a server with QEMU emulator version 2.9.0. Although i gave the machine plenty RAM it begins segfaulting some processes after some hours which ends in a complete crash. +This is the commandline from libvirt: + +/usr/bin/qemu-system-x86_64-nameguest=server,debug-threads=on-S-objectsecret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-2-server/master-key.aes-machinepc-i440fx-2.9,accel=kvm,usb=off,dump-guest-core=off-cpuhost-m8192-realtimemlock=off-smp4,sockets=4,cores=1,threads=1-uuid5329bfd3-b947-473b-9880-d95b4ca78f28-no-user-config-nodefaults-chardevsocket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-2-server/monitor.sock,server,nowait-monchardev=charmonitor,id=monitor,mode=control-rtcbase=utc,driftfix=slew-globalkvm-pit.lost_tick_policy=delay-no-hpet-no-shutdown-globalPIIX4_PM.disable_s3=1-globalPIIX4_PM.disable_s4=1-bootstrict=on-deviceich9-usb-ehci1,id=usb,bus=pci.0,addr=0x9.0x7-deviceich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x9-deviceich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x9.0x1-deviceich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x9.0x2-deviceahci,id=sata0,bus=pci.0,addr=0x6-devicevirtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5-drivefile=/mnt/htpc/windows/VM/disks/qcow2/server-boot.qcow2,format=qcow2,if=none,id=drive-virtio-disk0-devicevirtio-blk-pci,scsi=off,bus=pci.0,addr=0xa,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1-drivefile=/dev/sda,format=raw,if=none,id=drive-virtio-disk1-devicevirtio-blk-pci,scsi=off,bus=pci.0,addr=0xb,drive=drive-virtio-disk1,id=virtio-disk1-netdevtap,fd=24,id=hostnet0,vhost=on,vhostfd=26-devicevirtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:12:34:56,bus=pci.0,addr=0x3-spiceport=5902,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on-deviceqxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2-devicevirtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8-msgtimestamp=on + + + +OK, i think it was my mistake. The VM accidently used the same swap partition as the host. + diff --git a/results/classifier/105/mistranslation/1708077 b/results/classifier/105/mistranslation/1708077 new file mode 100644 index 000000000..80adfd3f3 --- /dev/null +++ b/results/classifier/105/mistranslation/1708077 @@ -0,0 +1,21 @@ +mistranslation: 0.914 +device: 0.711 +graphic: 0.592 +instruction: 0.337 +semantic: 0.277 +vnc: 0.204 +other: 0.151 +boot: 0.123 +socket: 0.109 +network: 0.078 +assembly: 0.043 +KVM: 0.004 + +PPC interrupt exception！ + +There is a exception on interrupt system when run the system with debug app on qemu-system-ppc.exe。I have try in version SHA-1: 2421f381dc38a8a6d12477c08c2f74a35a0698f8 no problem，but the next version SHA-1: 28f997a82cb509bf4775d4006b368e1bde8b7bdd have this exception。 And I found during this period in the repair of multi-threaded mutex，so I guess whether the PPC has some mutex needed are not taken into account。My english is poor，so there may be many grammatical errors。I hope you can understand the problem I described。 + +What kind of exeception are you seeing here exactly? Can you still reproduce it with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1708215 b/results/classifier/105/mistranslation/1708215 new file mode 100644 index 000000000..f98e55f18 --- /dev/null +++ b/results/classifier/105/mistranslation/1708215 @@ -0,0 +1,44 @@ +mistranslation: 0.947 +other: 0.807 +graphic: 0.799 +semantic: 0.734 +device: 0.691 +instruction: 0.484 +network: 0.425 +vnc: 0.405 +assembly: 0.345 +boot: 0.342 +socket: 0.229 +KVM: 0.079 + +Windows 10 clipboard bug + +Hello, + +I am using qemu on arch: + pacman -Q libvirt qemu linux virt-manager +libvirt 3.5.0-1 +qemu 2.9.0-2 +linux 4.12.3-1 +virt-manager 1.4.1-2 + +I have a windows 10 Guest, with all updates and the following packages installed in the guest: +- QEMU guest agent 7.3.2 +- SPICE Guest Tools 0.132 + +When I start the VM, I can copy/paste from the host to the guest. However, after I use COPY inside the VM, copy/paste is not working any more from host to guest. However, I can still copy/paste from guest to host. + +To summarize: +- copy/paste from guest to host works always +- copy/paste from host to guest works only if copy was not previously used in guest. + +If this bug needs to be reported using another portal or if I can provide any further information, please contact me. + +Best Regards, +gxgung + +UPDATE: +Restarting "SPICE VDAagent" within the VM allows me to paste again from host to VM, however as soon as I use copy within the VM, it stops working again. + +This sounds like a bug in Spice, and not like a bug in QEMU. If you still face this problem, please report it to the spice project instead (see https://www.spice-space.org/support.html). + diff --git a/results/classifier/105/mistranslation/1709025 b/results/classifier/105/mistranslation/1709025 new file mode 100644 index 000000000..8a00517b1 --- /dev/null +++ b/results/classifier/105/mistranslation/1709025 @@ -0,0 +1,62 @@ +mistranslation: 0.866 +other: 0.857 +vnc: 0.823 +instruction: 0.795 +KVM: 0.751 +graphic: 0.748 +device: 0.722 +assembly: 0.700 +semantic: 0.659 +socket: 0.641 +network: 0.635 +boot: 0.447 + +Disk corrupted after snapshot deletion + + I found the vm disk corruption after snapshot deletion sometimes(the probability is very low, I'm afraid i can't reproduce it). And I found there is a patch for it as follow, but I'm not sure whether the patch repaired the bug. + Drain disk before snapshot deletion can't guarantee anything, there is still pending IO in snapshot-deletion process. Anyone can help? + +author Zhang Haoyu <email address hidden> 2014-10-21 16:38:01 +0800 +committer Stefan Hajnoczi <email address hidden> 2014-11-03 09:48:42 +0000 +commit 3432a1929ee18e08787ce35476abd74f2c93a17c (patch) +tree 13a81c0a46707d91622f1593ccf7b926935371fd /block/snapshot.c +parent 573742a5431a99ceaba6968ae269cee247727cce (diff) +snapshot: add bdrv_drain_all() to bdrv_snapshot_delete() to avoid concurrency problem +If there are still pending i/o while deleting snapshot, +because deleting snapshot is done in non-coroutine context, and +the pending i/o read/write (bdrv_co_do_rw) is done in coroutine context, +so it's possible to cause concurrency problem between above two operations. +Add bdrv_drain_all() to bdrv_snapshot_delete() to avoid this problem. + +Signed-off-by: Zhang Haoyu <email address hidden> +Reviewed-by: Paolo Bonzini <email address hidden> +Message-id: <email address hidden> +Signed-off-by: Stefan Hajnoczi <email address hidden> +Diffstat (limited to 'block/snapshot.c') +-rw-r--r-- block/snapshot.c 4 +1 files changed, 4 insertions, 0 deletions +diff --git a/block/snapshot.c b/block/snapshot.c +index 85c52ff..698e1a1 100644 +--- a/block/snapshot.c ++++ b/block/snapshot.c +@@ -236,6 +236,10 @@ int bdrv_snapshot_delete(BlockDriverState *bs, + error_setg(errp, "snapshot_id and name are both NULL"); + return -EINVAL; + } ++ ++ /* drain all pending i/o before deleting snapshot */ ++ bdrv_drain_all(); ++ + if (drv->bdrv_snapshot_delete) { + return drv->bdrv_snapshot_delete(bs, snapshot_id, name, errp); + } + +My qemu version is 2.1.2 + +Please try again with the latest release of QEMU first (currently 2.9, or the latest RC of 2.10). QEMU 2.1.2 is very old, the bug might have been fixed in the latest release already. + +Thanks for your reply +For some reason, I can't update my version. I believe the latest version have fixed the problem in commit 3432a1929ee18e08787ce35476abd74f2c93a17c or 27a7649a48f9019fa5bd2998d8e342791397bdda. But I'm not sure the first patch have fixed the problem, as the second patch is too much change for me. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1709170 b/results/classifier/105/mistranslation/1709170 new file mode 100644 index 000000000..92af50529 --- /dev/null +++ b/results/classifier/105/mistranslation/1709170 @@ -0,0 +1,132 @@ +mistranslation: 0.909 +other: 0.874 +KVM: 0.854 +vnc: 0.853 +graphic: 0.848 +network: 0.846 +device: 0.838 +assembly: 0.833 +semantic: 0.826 +socket: 0.826 +instruction: 0.824 +boot: 0.742 + +QEMU fails to honor O_TMPFILE + +When making a call like + + open("/tmp", O_TMPFILE | O_RDWR); + +under QEMU, we ged -EISDIR. + +Under any kernel 3.11 or later, we are supposed to get an unnamed file in /tmp. In case the filesystem for /tmp does not support unnamed files, we are supposed to get EOPNOTSUPP. + +[I don't know the QEMU version, since this happened in a system I don't have access to] + +Hi Thiago, + +What is the version of glibc on the targets you are building to? There was an O_TMPFILE bug in older glibc's: + +https://sourceware.org/bugzilla/show_bug.cgi?id=17912 + +On Mon, Aug 07, 2017 at 08:18:04PM -0000, Thiago Macieira wrote: +> Public bug reported: +> +> When making a call like +> +> open("/tmp", O_TMPFILE | O_RDWR); +> +> under QEMU, we ged -EISDIR. +> +> Under any kernel 3.11 or later, we are supposed to get an unnamed file +> in /tmp. In case the filesystem for /tmp does not support unnamed files, +> we are supposed to get EOPNOTSUPP. + +Actually, -EISDIR is valid error when underlying system doesn't support O_TMPFILE. +See man openat or the kernel definition for O_TMPFILE. + +Regardless, I'm submitting a patch to properly translate the O_TMPFILE. + +Riku + + +Since O_TMPFILE might differ between guest and host, +add it to the bitmask_transtbl. While at it, fix the definitions +of O_DIRECTORY etc on arm64, which are identical to arm32 according +to kernel sources. + +This fixes open14 and openat03 ltp testcases. + +Fixes: https://bugs.launchpad.net/qemu/+bug/1709170 + +--- + linux-user/strace.c | 4 ++++ + linux-user/syscall.c | 3 +++ + linux-user/syscall_defs.h | 8 +++++++- + 3 files changed, 14 insertions(+), 1 deletion(-) + +diff --git a/linux-user/strace.c b/linux-user/strace.c +index d821d165ff..bd897a3f20 100644 +--- a/linux-user/strace.c ++++ b/linux-user/strace.c +@@ -838,6 +838,10 @@ UNUSED static struct flags open_flags[] = { + #ifdef O_PATH + FLAG_TARGET(O_PATH), + #endif ++#ifdef O_TMPFILE ++ FLAG_TARGET(O_TMPFILE), ++ FLAG_TARGET(__O_TMPFILE), ++#endif + FLAG_END, + }; + +diff --git a/linux-user/syscall.c b/linux-user/syscall.c +index 54343c06be..b3aa8099b4 100644 +--- a/linux-user/syscall.c ++++ b/linux-user/syscall.c +@@ -342,6 +342,9 @@ static bitmask_transtbl fcntl_flags_tbl[] = { + #if defined(O_PATH) + { TARGET_O_PATH, TARGET_O_PATH, O_PATH, O_PATH }, + #endif ++#if defined(O_TMPFILE) ++ { TARGET_O_TMPFILE, TARGET_O_TMPFILE, O_TMPFILE, O_TMPFILE }, ++#endif + /* Don't terminate the list prematurely on 64-bit host+guest. */ + #if TARGET_O_LARGEFILE != 0 || O_LARGEFILE != 0 + { TARGET_O_LARGEFILE, TARGET_O_LARGEFILE, O_LARGEFILE, O_LARGEFILE, }, +diff --git a/linux-user/syscall_defs.h b/linux-user/syscall_defs.h +index 40c5027e93..6e2287e918 100644 +--- a/linux-user/syscall_defs.h ++++ b/linux-user/syscall_defs.h +@@ -2416,7 +2416,7 @@ struct target_statfs64 { + #define TARGET_O_CLOEXEC 010000000 + #define TARGET___O_SYNC 000100000 + #define TARGET_O_PATH 020000000 +-#elif defined(TARGET_ARM) || defined(TARGET_M68K) ++#elif defined(TARGET_ARM) || defined(TARGET_M68K) || defined(TARGET_AARCH64) + #define TARGET_O_DIRECTORY 040000 /* must be a directory */ + #define TARGET_O_NOFOLLOW 0100000 /* don't follow links */ + #define TARGET_O_DIRECT 0200000 /* direct disk access hint */ +@@ -2513,6 +2513,12 @@ struct target_statfs64 { + #ifndef TARGET_O_PATH + #define TARGET_O_PATH 010000000 + #endif ++#ifndef TARGET___O_TMPFILE ++#define TARGET___O_TMPFILE 020000000 ++#endif ++#ifndef TARGET_O_TMPFILE ++#define TARGET_O_TMPFILE (TARGET___O_TMPFILE | TARGET_O_DIRECTORY) ++#endif + #ifndef TARGET_O_NDELAY + #define TARGET_O_NDELAY TARGET_O_NONBLOCK + #endif +-- +2.11.0 + + + +It was a Yocto 2.0 sysroot running on an Ubuntu 16.04 host. + +Fix has been released with QEMU 2.11: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=5f9cee46cd4ec4600e1a + diff --git a/results/classifier/105/mistranslation/1711602 b/results/classifier/105/mistranslation/1711602 new file mode 100644 index 000000000..167bf9df0 --- /dev/null +++ b/results/classifier/105/mistranslation/1711602 @@ -0,0 +1,946 @@ +mistranslation: 0.825 +KVM: 0.584 +device: 0.551 +semantic: 0.526 +other: 0.486 +vnc: 0.474 +graphic: 0.468 +network: 0.467 +instruction: 0.453 +assembly: 0.444 +socket: 0.262 +boot: 0.257 + +--copy-storage-all failing with qemu 2.10 + +We fixed an issue around disk locking already in regard to qemu-nbd [1], but there still seem to be issues. + +$ virsh migrate --live --copy-storage-all kvmguest-artful-normal qemu+ssh://10.22.69.196/system +error: internal error: qemu unexpectedly closed the monitor: 2017-08-18T12:10:29.800397Z qemu-system-x86_64: -chardev pty,id=charserial0: char device redirected to /dev/pts/0 (label charserial0) +2017-08-18T12:10:48.545776Z qemu-system-x86_64: load of migration failed: Input/output error + +Source libvirt log for the guest: +2017-08-18 12:09:08.251+0000: initiating migration +2017-08-18T12:09:08.809023Z qemu-system-x86_64: Unable to read from socket: Connection reset by peer +2017-08-18T12:09:08.809481Z qemu-system-x86_64: Unable to read from socket: Connection reset by peer + +Target libvirt log for the guest: +2017-08-18T12:09:08.730911Z qemu-system-x86_64: load of migration failed: Input/output error +2017-08-18 12:09:09.010+0000: shutting down, reason=crashed + +Given the timing it seems that the actual copy now works (it is busy ~10 seconds on my environment which would be the copy). +Also we don't see the old errors we saw before, but afterwards on the actual take-over it fails. + +Dmesg has no related denials as often apparmor is in the mix. + +Need to check libvirt logs of source [2] and target [3] in Detail. + +[1]: https://lists.gnu.org/archive/html/qemu-devel/2017-08/msg02200.html +[2]: http://paste.ubuntu.com/25339356/ +[3]: http://paste.ubuntu.com/25339358/ + +Is anybody but me testing this combo ? +All else seems to work nice, just this special (and only this) migration setup fails. + +--copy-storage-inc also affected. + +It seems in the copy storage set of migrations is overall affected. + +Note: We do upgrade migration checks from the old version onto the new one with the planned upgrade - that revealed that if the migration source is still at the old level the migration works (even with the 2.10 based one on the target). + + +I reached out to the people involved in the initial fixes which were related to image locking and qemu-nbd. But this might after all be something completely different. +Yet until we know better it might be wiser to reach out to more people. + +=> http://lists.nongnu.org/archive/html/qemu-devel/2017-08/msg03465.html + +The source log is virsh, I need to ensure we also have a source libvirtd log ... + +Since this is pretty reproducible here on the setup: + +- Two systems (actually two lxd containers on one system) +- Both running Artful with qemu 2.10-rc3 and libvirt 3.6 +- Storage path is not shared but set up equivalent with a manual pre-copy +- Migration with post copy is failing, no other options set, example: + $ virsh migrate --live --copy-storage-all kvmguest-artful-normal qemu+ssh://10.22.69.100/system +- Same setup works on the qemu versions in Xenial (2.5), Yakkety (2.6), and Zesty (2.8) +- In fact it seems even a migration from a Zesty qemu (2.8) to the new (2.10) works + +To simplify downloading the logs I'm attaching here a full set of: +- virsh +- source libvirtd +- target libvirtd + + + + + +I've seen something in the logs which I want to eliminate from the list of possibilities: + "warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2]" + +We had always a patch I questioned to enable svm capabilitiy for guests in general, it worked all the time but I'd have preferred to be an explicit user opt-in. +I remember seeing the warning in the past which made me neglect it at first, but maybe the target capability check is now more strict. + +I'll drop this change for a test build and run all that again to be sure. +I doubt that is the reason, but let verifying this particular lead be my task - please be open with other suggestions. + +Currently I plan to test with the svm/vmx changes disabled as well as a cross test on ppc64 and s390x which might complete the picture. + +The 'host doesn't support requested feature' is probably a red-herring in this case +The fact it's failing with an IO error but nothing else suggests either: + a) it's something closing the socket between the two qemu's + b) The I/O error is from storage/NBD + +Assuming it fails on precopy, I'd look at the qemu_loadvm_state_section_startfull to watch all the device states load. +You could also add some debug/tracing in qemu_loadvm_state to see at what point it fails. + +Dave + +Hi David, +confirming the red-herring on the cpu feature - I had a build without runnign over the weekend so this was easy to test - and still the migration fails. + +I have about 7 seconds from kicking off the migration until the sync seems to pass its first phase and then qemu is exiting (at least that is what libvirt thinks): + "closed without SHUTDOWN event; assuming the domain crashed" + +Since the qemu "lives" in that time I can try to debug what happens. +With strace to sniff where things could be I see right before the end: + 0.000203 recvmsg(27, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="", iov_len=32768}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 0 <0.000014> + 0.000049 futex(0xca65dacf4, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, 0xca4785a80, 20) = 1 <0.000016> + 0.000038 getpid() = 29750 <0.000023> + 0.000011 tgkill(29750, 29760, SIGUSR1) = 0 <0.000030> + 0.000012 futex(0xca4785a80, FUTEX_WAKE_PRIVATE, 1) = 1 <0.000048> + 0.000010 futex(0xca47b46e4, FUTEX_WAIT_PRIVATE, 19, NULL) = 0 <0.002215> + 0.000032 sendmsg(21, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="{\"timestamp\": {\"seconds\": 1503322067, \"microseconds\": 613178}, \"event\": \"MIGRATION\", \"data\": {\"status\": \"failed\"}}\r\n", iov_len=116}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 116 <0.000024> + 0.000074 write(2, "2017-08-21T13:27:47.613276Z qemu-system-x86_64: load of migration failed: Input/output error\n", 93) = 93 <0.000022> + 0.000055 close(27) = 0 <0.000090> + +Now 29750 is the main process/tgid and 29760 is the third process started on the migration. +It is the one that does the vcpu ioctl's so I assume this is just the one representing the vpu. +Well gdb should be more useful so looking with that. + +As expected by David when I trace on process_incoming_migration_co which prints the "readable" error I see the error pop up on "qemu_loadvm_state" +It appears as "Thread 4 "CPU 0/KVM" received signal SIGUSR1" and similar which is just the break down of the guest. + + +Diving "into" qemu_loadvm_state reveals that it gets until "cpu_synchronize_all_pre_loadvm". +In qemu_loadvm_state none of the initial checks fail. +Then the "ret = vmstate_load_state(f, &vmstate_configuration, &savevm_state, 0);" seems to work fine was well. +It seems reproducible in "cpu_synchronize_all_pre_loadvm" where the crash happens. + +I can catch the incoming qemu easily with: +$ while ! pid=$(pidof qemu-system-x86_64); do /bin/true; done; gdb --pid ${pid} +# Then in gdb break on "cpu_synchronize_all_pre_loadvm" +# And when I step over it I the next thing I see is the "beginning of the end" for the process +Thread 4 "CPU 0/KVM" received signal SIGUSR1, User defined signal 1. +[Switching to Thread 0x7f418136e700 (LWP 3887)] +__lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 + +The guest only has one vcpu, so CPU_FOREACH(cpu) is not much of a loop. +Looking down that path I tracked it to along: +cpu_synchronize_all_pre_loadvm -> cpu_synchronize_pre_loadvm -> kvm_cpu_synchronize_pre_loadvm -> do_run_on_cpu + +Here it queues the function "do_kvm_cpu_synchronize_pre_loadvm" onto the vcpu. +That is done via queue_work_on_cpu(cpu, &wi); which in turn uses eventually "qemu_cpu_kick_thread(cpu);" +That seems to trigger the first SIGUSR1 + +Following that I get the breakpoint that I set at "do_kvm_cpu_synchronize_pre_loadvm". +The actual function only sets "cpu->vcpu_dirty = true;" and works. + +On the way out from there, there is a "qemu_kvm_wait_io_event" which leads to the next SIGUSR1. + +Going on I see another "do_run_on_cpu" with "vapic_do_enable_tpr_reporting" as the function. +I set a breakpoint on that as well but took a full CPUstate before going on: +p *cpu +$4 = {parent_obj = {parent_obj = {class = 0x5ffe7170c0, free = 0x7f62328f15a0 <g_free>, properties = 0x5ffe736e40, ref = 1, + parent = 0x5ffe726160}, id = 0x0, realized = true, pending_deleted_event = false, opts = 0x0, hotplugged = 0, parent_bus = 0x0, gpios = { + lh_first = 0x0}, child_bus = {lh_first = 0x0}, num_child_bus = 0, instance_id_alias = -1, alias_required_for_version = 0}, nr_cores = 1, + nr_threads = 1, thread = 0x5ffe803cd0, thread_id = 8498, running = false, has_waiter = false, halt_cond = 0x5ffe803cf0, thread_kicked = true, + created = true, stop = false, stopped = true, unplug = false, crash_occurred = false, exit_request = false, interrupt_request = 4, + singlestep_enabled = 0, icount_budget = 0, icount_extra = 0, jmp_env = {{__jmpbuf = {0, 0, 0, 0, 0, 0, 0, 0}, __mask_was_saved = 0, + __saved_mask = {__val = {0 <repeats 16 times>}}}}, work_mutex = {lock = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, + __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, + initialized = true}, queued_work_first = 0x5fffefc990, queued_work_last = 0x5fffefc990, cpu_ases = 0x5ffe803c10, num_ases = 1, + as = 0x5ffe7f9690, memory = 0x5ffe725bd0, env_ptr = 0x5ffe7e44c0, tb_jmp_cache = {0x0 <repeats 4096 times>}, gdb_regs = 0x0, + gdb_num_regs = 57, gdb_num_g_regs = 57, node = {tqe_next = 0x0, tqe_prev = 0x5ffc1783f0 <cpus>}, breakpoints = {tqh_first = 0x0, + tqh_last = 0x5ffe7e4430}, watchpoints = {tqh_first = 0x0, tqh_last = 0x5ffe7e4440}, watchpoint_hit = 0x0, opaque = 0x0, mem_io_pc = 0, + mem_io_vaddr = 0, kvm_fd = 19, kvm_state = 0x5ffe7357a0, kvm_run = 0x7f62374bc000, trace_dstate_delayed = {0}, trace_dstate = {0}, + cpu_index = 0, halted = 1, can_do_io = 1, exception_index = -1, vcpu_dirty = true, throttle_thread_scheduled = false, icount_decr = {u32 = 0, + u16 = {low = 0, high = 0}}, hax_vcpu = 0x0, pending_tlb_flush = 7} + +Continuing I hit the "vapic_do_enable_tpr_reporting" with qemu still running. + +Things go on, the next candidate for "do_run_on_cpu" is "kvm_apic_put" +Another SIGUSR1 to get that kicked it seems. +"kvm_apic_put" breakpoint is reached after that kick. + +Next for "do_run_on_cpu" is "do_kvm_cpu_synchronize_post_init". And that triggered the fourth SIGUSR1. Before I only saw four, hopefully that is the same with so much breakpoints. + +Checked the cpu state again: +1880 static void do_kvm_cpu_synchronize_post_init(CPUState *cpu, run_on_cpu_data arg) +1881 { +1882 kvm_arch_put_registers(cpu, KVM_PUT_FULL_STATE); +1883 cpu->vcpu_dirty = false; +1884 } +1885 +(gdb) p cpu +$5 = (CPUState *) 0x5ffe7dc230 +(gdb) p *cpu +$6 = {parent_obj = {parent_obj = {class = 0x5ffe7170c0, free = 0x7f62328f15a0 <g_free>, properties = 0x5ffe736e40, ref = 1, + parent = 0x5ffe726160}, id = 0x0, realized = true, pending_deleted_event = false, opts = 0x0, hotplugged = 0, parent_bus = 0x0, gpios = { + lh_first = 0x0}, child_bus = {lh_first = 0x0}, num_child_bus = 0, instance_id_alias = -1, alias_required_for_version = 0}, nr_cores = 1, + nr_threads = 1, thread = 0x5ffe803cd0, thread_id = 8498, running = false, has_waiter = false, halt_cond = 0x5ffe803cf0, thread_kicked = false, + created = true, stop = false, stopped = true, unplug = false, crash_occurred = false, exit_request = false, interrupt_request = 4, + singlestep_enabled = 0, icount_budget = 0, icount_extra = 0, jmp_env = {{__jmpbuf = {0, 0, 0, 0, 0, 0, 0, 0}, __mask_was_saved = 0, + __saved_mask = {__val = {0 <repeats 16 times>}}}}, work_mutex = {lock = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, + __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, + initialized = true}, queued_work_first = 0x0, queued_work_last = 0x0, cpu_ases = 0x5ffe803c10, num_ases = 1, as = 0x5ffe7f9690, + memory = 0x5ffe725bd0, env_ptr = 0x5ffe7e44c0, tb_jmp_cache = {0x0 <repeats 4096 times>}, gdb_regs = 0x0, gdb_num_regs = 57, + gdb_num_g_regs = 57, node = {tqe_next = 0x0, tqe_prev = 0x5ffc1783f0 <cpus>}, breakpoints = {tqh_first = 0x0, tqh_last = 0x5ffe7e4430}, + watchpoints = {tqh_first = 0x0, tqh_last = 0x5ffe7e4440}, watchpoint_hit = 0x0, opaque = 0x0, mem_io_pc = 0, mem_io_vaddr = 0, kvm_fd = 19, + kvm_state = 0x5ffe7357a0, kvm_run = 0x7f62374bc000, trace_dstate_delayed = {0}, trace_dstate = {0}, cpu_index = 0, halted = 1, can_do_io = 1, + exception_index = -1, vcpu_dirty = true, throttle_thread_scheduled = false, icount_decr = {u32 = 0, u16 = {low = 0, high = 0}}, + hax_vcpu = 0x0, pending_tlb_flush = 7} + +And from here stepping into kvm_arch_put_registers: +kvm_arch_put_registers (cpu=cpu@entry=0x5ffe7dc230, level=level@entry=3) at ./target/i386/kvm.c:2591 + +That still is the same vcpu as all the time, x86_cpu is optimized out unfortunately as I had no full debug build with -O0. + +I see it setting up regs in kvm_arch_put_registers without error (all ret=0) and return to do_kvm_cpu_synchronize_post_init. +This eventually sets "cpu->vcpu_dirty = false;" + +After this seems all good I steped through the "way out" and there came another "qemu_kvm_wait_io_event(cpu);". +Without considering this being critical I stepped with "n" and qemu was gone with all its threads. + +qemu_kvm_cpu_thread_fn (arg=0x5ffe7dc230) at ./cpus.c:1134 +1134 } while (!cpu->unplug || cpu_can_run(cpu)); +(gdb) n +1127 if (cpu_can_run(cpu)) { +(gdb) n +1133 qemu_kvm_wait_io_event(cpu); +(gdb) n +[Thread 0x7f6227857700 (LWP 8498) exited] + + +After this I was trying to start closer to the issue, so I put a break on "process_incoming_migration_co" (to skip over much of the initial setup). +Once that was hit I added "qemu_kvm_cpu_thread_fn" and "qemu_kvm_wait_io_event". + +Of course when I try that the other functions do not trigger. +Maybe it is partially influenced by the debugging itself and/or the timing changes it causes. + +I'll check what else I can find with slightly different debugging, but so much as an update for now. + +oh yeh you want to tell gdb to ignore SIGUSR1, something like: + handle SIGUSR1 nostop noprint pass + +Sure, but initially I wanted to see what is going on overall so I let it pop up. + +Started a debugging another session today. +First I confirmed with + (gdb) catch syscall exit exit_group +That this is the "normal" exit along the error message we knew: + migrate_set_state(&mis->state, MIGRATION_STATUS_ACTIVE, + MIGRATION_STATUS_FAILED); + error_report("load of migration failed: %s", strerror(-ret)); + qemu_fclose(mis->from_src_file); + exit(EXIT_FAILURE); + +I found that already the retval of qemu_loadvm_state it -5. +Every thing else afterwards is cleanup. + +Inside qemu_loadvm_state the first 2/3 pass and then that ret=-5 is from "ret = qemu_file_get_error(f);". + +Via a watchpoints I found that the error is set by qemu_fill_buffer. + +b qemu_loadvm_state +handle SIGUSR1 nostop noprint pass +c +# on the break check and watch the status +(gdb) p f +$1 = (QEMUFile *) 0xb9babb3c00 +(gdb) p *f +$2 = {ops = 0xb9b89880a0 <channel_input_ops>, hooks = 0x0, opaque = 0xb9bbabfe00, bytes_xfer = 0, xfer_limit = 0, pos = 0, buf_index = 0, + buf_size = 0, buf = '\000' <repeats 32767 times>, may_free = {0}, iov = {{iov_base = 0x0, iov_len = 0} <repeats 64 times>}, iovcnt = 0, + last_error = 0} + +# ok still no err, set watchpoint +(gdb) p &(f->last_error) +$4 = (int *) 0xb9babbc044 +(gdb) watch *(int *) 0xb9babbc044 +Hardware watchpoint 2: *(int *) 0xb9babbc044 + +# This catches the following +Thread 1 "qemu-system-x86" hit Hardware watchpoint 2: *(int *) 0xb9babbc044 + +Old value = 0 +New value = -5 +0x000000b9b82bd0ec in qemu_file_set_error (ret=-5, f=0xb9babb3c00) at ./migration/qemu-file.c:125 +warning: Source file is more recent than executable. +125 f->last_error = ret; +(gdb) bt +#0 0x000000b9b82bd0ec in qemu_file_set_error (ret=-5, f=0xb9babb3c00) at ./migration/qemu-file.c:125 +#1 qemu_fill_buffer (f=0xb9babb3c00) at ./migration/qemu-file.c:299 +#2 0x000000b9b82bdbb1 in qemu_peek_byte (f=0xb9babb3c00, offset=0) at ./migration/qemu-file.c:553 +#3 0x000000b9b82bdc1b in qemu_get_byte (f=f@entry=0xb9babb3c00) at ./migration/qemu-file.c:566 +#4 0x000000b9b82b5853 in qemu_loadvm_state_main (f=f@entry=0xb9babb3c00, mis=0xb9b8a4f700 <mis_current>) at ./migration/savevm.c:1947 +#5 0x000000b9b82b864f in qemu_loadvm_state (f=f@entry=0xb9babb3c00) at ./migration/savevm.c:2032 +#6 0x000000b9b82af5c3 in process_incoming_migration_co (opaque=0xb9babb3c00) at ./migration/migration.c:320 +#7 0x000000b9b83e42a6 in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at ./util/coroutine-ucontext.c:79 +#8 0x00007fbf3702fac0 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 +#9 0x00007fffe3f9f800 in ?? () +#10 0x0000000000000000 in ?? () + +So this is failing I/O that iterates over a channel. +I was tracking down the len, pending and pos used. + +I found that this is not completely broken (like no access or generla I/O error) +It starts at pos 0 and iterated with varying offsets, but works for quite some time. +Example: + +[...] +Thread 1 "qemu-system-x86" hit Breakpoint 2, qemu_fill_buffer (f=f@entry=0xd3b66f3c00) at ./migration/qemu-file.c:295 +295 if (len > 0) { +$11183 = 28728 +$11184 = 4040 +$11185 = {ops = 0xd3b3d740a0 <channel_input_ops>, hooks = 0x0, opaque = 0xd3b75ee490, bytes_xfer = 0, xfer_limit = 0, pos = 107130146, + buf_index = 0, buf_size = 4040, + buf = "\v\327\a\000\021\000\[...]\000"..., + may_free = {0}, iov = {{iov_base = 0x0, iov_len = 0} <repeats 64 times>}, iovcnt = 0, last_error = 0} +[...] + +Well you could see the whole file read passing by one by one buffer +Yet this isn't particularly fast, so track the one that has len==0 + (gdb) b ./migration/qemu-file.c:295 if len == 0 + +And I got it as: +(gdb) p *f +$11195 = {ops = 0xd3b3d740a0 <channel_input_ops>, hooks = 0x0, opaque = 0xd3b75ee490, bytes_xfer = 0, xfer_limit = 0, pos = 319638837, + buf_index = 0, buf_size = 0, buf = '\000' <repeats 5504 times>..., may_free = {0}, iov = {{iov_base = 0x0, iov_len = 0} <repeats 64 times>}, + iovcnt = 0, last_error = 0} + +Here pending == 0 so buf_size = 0 as well also pos is further down incremented to 319638837. + +Checking in detail I found that I had pending=0 and buf_size=0 as well as non aligned pos entried, but they worked. +So I excluded the buf_size=0/pending=0 as well as the alignment as reasons. +Maybe it just iterates pos out of the range that is working? + + +(gdb) handle SIGUSR1 nostop noprint pass +(gdb) b migration/qemu-file.c:295 +(gdb) command +p f->pos +c +end + +That showed the pos is ever increasing and fails at an offset it never read before. Yet the absolute number was different. +$1 = 0 +$2 = 8948 +$3 = 41423 +[...] +$11359 = 326387440 +$11360 = 326420208 => This was the one failing this time + + +This was a different f->pos than last time, so I wondered if this would change every time. +With a less interactive gdb config I got in three tries: +1. 313153311 +2. 313313376 +3. 313571856 +So a different f->pos to fail each time. + +Different but rather close. +I wondered if the reasons I got a higher one when tracing in more detail printing all offsets could be that there still is something copied/synced and only slowly gets available. + +I stepped through rather slowly and got to 322429260 this time. +So slower continuing on the iteration over qemu_fill_buffer makes it fail "later"? + +Finally it is surely interesting which channel that actually is- likely the migration socket? +And yes, ioc->name in qio_channel_read is: + $8 = 0x56ab78e5c0 "migration-socket-incoming + +So TL;DR summary for now: +- error triggers in qio_channel_read +- file is migration-socket-incoming +- reads work a while, but then fail at high f->pos offsets (slightly different ones each time) +- slower execution seems to lead to slightly higher offsets that are failing +- only happens on --copy-storage-* migrations (libvirt/virsh argument) + +I don't really know atm where to look deeper - is there a good side channel that I could use to look at what is going on on the migration-socket-incoming - Maybe from the source and target while I block in gdb? + +OK, so that looks like a real case of the migration stream failing and getting an IO error; so the question is why: + a) Is the source qemu dieing first and closing the socket? + b) Is libvirt closing the socket for some reason + + + +also, you might want to chase it a bit further down, I think we've got: + + qemu-file-channel.c:channel_get_buffer + io/channel-socket.c or io/channel-file.c qio_channel_file_readv + + it would be good to know what the readv/readmsg is actually returning in the case where it's failing. + +Dave + +I'll track down the actual read and then add debugging the source at the same time (that should be the best way to track the migration socket on both sides). +This might be slightly tricky since I don't know exactly on which offset but I can surely start over 310*10^6 it seems. + +I'll report back once I know more, thanks for your guidance David + +Hmm i just tried to reproduce this and hit (on the source): + +main_channel_client_handle_migrate_connected: client 0x5607d785f610 connected: 0 seamless 0 +qemu-system-x86_64: /root/qemu/io/channel.c:303: qio_channel_yield: Assertion `!ioc->write_coroutine' failed. +2017-08-22 10:50:04.888+0000: shutting down, reason=crashed + + +OK, 3rd try and I've hit the same behaviour as Christian. + + +Stack from qemu_fill_buffer to qio_channel_socket_readv +#0 qio_channel_socket_readv (ioc=<optimized out>, iov=<optimized out>, niov=<optimized out>, fds=0x0, nfds=0x0, errp=0x0) + at ./io/channel-socket.c:477 +#1 0x0000001486ec97e2 in qio_channel_read (ioc=ioc@entry=0x148a73a6c0, + buf=buf@entry=\060\nLw", buflen=buflen@entry=28728, errp=errp@entry=0x0) at ./io/channel.c:112 +#2 0x0000001486e005ec in channel_get_buffer (opaque=<optimized out>, + buf=0x1489844c00 "\060\nLw", pos=<optimized out>, size=28728) at ./migration/qemu-file-channel.c:80 +#3 0x0000001486dff095 in qemu_fill_buffer (f=f@entry=0x1489843c00) at ./migration/qemu-file.c:293 + +I checked that sioc->fd, &msg, sflags) is in fact the socket. +With e.g. with this fd being 27 +tcp ESTAB 1405050 0 ::ffff:10.22.69.30:49152 ::ffff:10.22.69.157:49804 users:(("qemu-system-x86",pid=29273,fd=27)) ino:3345152 sk:30 <-> + skmem:(r1420644,rb1495660,t0,tb332800,f668,w0,o0,bl0,d14) ts sack cubic wscale:7,7 rto:200 rtt:0.04/0.02 ato:80 mss:8948 cwnd:10 bytes_received:1981460 segs_out:37 segs_in:247 data_segs_in:231 send 17896.0Mbps lastsnd:254728 lastrcv:250372 lastack:250372 rcv_rtt:0.205 rcv_space:115461 minrtt:0.04 + +I need to break on the fail of that recvmsg in qio_channel_socket_readv +# the following does not work due to optimization the ret value is only around later +b io/channel-socket.c:478 if ret < 0 +But catching it "inside" the if works +b io/channel-socket.c:479 + + +Take the following with a grain of salt, this is very threaded and noisy to debug. + +Once I hit it the recmsg returned "-1", that was on f->pos = 311641887 +But at the same time I could confirm (via ss) that the socket itself is still open on source and target of the migration. + +-1 is EAGAIN and returns QIO_CHANNEL_ERR_BLOCK +That seems to arrive in nbd_rwv nbd/common.c:44). +And led to "qio_channel_yield" + +There are a few corouting switches in between so I hope I'm not loosing anything. +But that first ret<0 actually worked, it seems the yield and retry got it working. + +I got back to qemu_fill_buffer iterating further after this. +This hit ret<0 in qio_channel_socket_readv again at f->pos 311641887. + +This time on returning the QIO_CHANNEL_ERR_BLOCK it returned to "./migration/qemu-file-channel.c:81". +That was interesting as it is different than before. +After this it seemed to become a death spiral - recmsg returned -1 every time (still on the same offset). +It passed back through the nbd_rwv which called qio_channel_yield for multiple times. + +Then it continued and later on on 321998304 is the last I saw. +It did no more pass b io/channel-socket.c:479 at all, but then led to the exit. + +Hmm, I might have lost myself on the coroutine switches - but it is odd at least. +Trying to redo less interactive and with a bit more prep ... +Maybe the results are more reliable then ... + +Getting back with more later ... + +Only now read comment #27, thanks David for reproducing with me, it is somewhat relieving that you seem to see the same. + +(4th try) breakpoint on qemu_file_set_error, it's bdrv_inactivate_all that's returning the error. + +(gdb) list +1155 if (inactivate_disks) { +1156 /* Inactivate before sending QEMU_VM_EOF so that the +1157 * bdrv_invalidate_cache_all() on the other end won't fail. */ +1158 ret = bdrv_inactivate_all(); +1159 if (ret) { +1160 qemu_file_set_error(f, ret); +1161 return ret; +1162 } +1163 } + + +For me qemu_file_set_error was always called from qemu_fill_buffer, interesting that it seems different for you. +I'll rerun a few times to ensure it really always is always from qemu_fill_buffer for me. + +The difference with the qemu_file_set_error is I'm looking on the source - because what's happening is the source is erroring so closing the socket, and so the error you're seeing on the destination is real - the socket just EOF'd! + +repeated the assert in #26: +Program received signal SIGABRT, Aborted. +0x00007f02163005f7 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 +56 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); +(gdb) where +#0 0x00007f02163005f7 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 +#1 0x00007f0216301ce8 in __GI_abort () at abort.c:90 +#2 0x00007f02162f9566 in __assert_fail_base (fmt=0x7f0216449288 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x560ac0191e93 "!ioc->write_coroutine", file=file@entry=0x560ac0191e66 "/root/qemu/io/channel.c", line=line@entry=303, function=function@entry=0x560ac0191f60 <__PRETTY_FUNCTION__.22239> "qio_channel_yield") + at assert.c:92 +#3 0x00007f02162f9612 in __GI___assert_fail (assertion=assertion@entry=0x560ac0191e93 "!ioc->write_coroutine", file=file@entry=0x560ac0191e66 "/root/qemu/io/channel.c", line=line@entry=303, function=function@entry=0x560ac0191f60 <__PRETTY_FUNCTION__.22239> "qio_channel_yield") at assert.c:101 +#4 0x0000560ac0036a08 in qio_channel_yield (ioc=ioc@entry=0x560ac2397c90, condition=condition@entry=G_IO_OUT) + at /root/qemu/io/channel.c:303 +#5 0x0000560ac001930e in nbd_rwv (ioc=0x560ac2397c90, iov=<optimized out>, niov=<optimized out>, length=<optimized out>, do_read=do_read@entry=false, errp=errp@entry=0x0) at /root/qemu/nbd/common.c:47 +#6 0x0000560ac0007e24 in nbd_co_send_request (bs=bs@entry=0x560ac30167a0, request=request@entry=0x7f0209afc9a0, qiov=qiov@entry=0x560ac2428d68) at /root/qemu/block/nbd-client.c:154 +#7 0x0000560ac0008244 in nbd_client_co_pwritev (bs=0x560ac30167a0, offset=3414163456, bytes=<optimized out>, qiov=0x560ac2428d68, flags=<optimized out>) at /root/qemu/block/nbd-client.c:260 +#8 0x0000560ac00030e1 in bdrv_driver_pwritev (bs=bs@entry=0x560ac30167a0, offset=offset@entry=3414163456, bytes=bytes@entry=589824, qiov=qiov@entry=0x560ac2428d68, flags=flags@entry=0) at /root/qemu/block/io.c:877 +#9 0x0000560ac0004480 in bdrv_aligned_pwritev (req=req@entry=0x7f0209afcba0, offset=offset@entry=3414163456, bytes=589824, align=align@entry=1, qiov=qiov@entry=0x560ac2428d68, flags=flags@entry=0, child=0x560ac1f0a9b0, child=0x560ac1f0a9b0) at /root/qemu/block/io.c:1382 +#10 0x0000560ac0005258 in bdrv_co_pwritev (child=0x560ac1f0a9b0, offset=offset@entry=3414163456, bytes=<optimized out>, qiov=qiov@entry=0x560ac2428d68, flags=0) at /root/qemu/block/io.c:1633 +#11 0x0000560abffbf564 in raw_co_pwritev (bs=0x560ac22807f0, offset=3414163456, bytes=<optimized out>, qiov=0x560ac2428d68, flags=<optimized out>) at /root/qemu/block/raw-format.c:243 +#12 0x0000560ac00030e1 in bdrv_driver_pwritev (bs=bs@entry=0x560ac22807f0, offset=offset@entry=3414163456, bytes=bytes@entry=589824, qiov=qiov@entry=0x560ac2428d68, flags=flags@entry=0) at /root/qemu/block/io.c:877 +#13 0x0000560ac0004480 in bdrv_aligned_pwritev (req=req@entry=0x7f0209afce70, offset=offset@entry=3414163456, bytes=589824, align=align@entry=1, qiov=qiov@entry=0x560ac2428d68, flags=flags@entry=0, child=0x560ac33c1e70, child=0x560ac33c1e70) at /root/qemu/block/io.c:1382 +#14 0x0000560ac0005258 in bdrv_co_pwritev (child=0x560ac33c1e70, offset=offset@entry=3414163456, bytes=<optimized out>, bytes@entry=589824, qiov=qiov@entry=0x560ac2428d68, flags=0) at /root/qemu/block/io.c:1633 +#15 0x0000560abfff5173 in blk_co_pwritev (blk=0x560ac14f31e0, offset=3414163456, bytes=589824, qiov=0x560ac2428d68, flags=<optimized out>) at /root/qemu/block/block-backend.c:1062 +#16 0x0000560abfff528a in blk_aio_write_entry (opaque=0x560ac2c18f70) at /root/qemu/block/block-backend.c:1253 +#17 0x0000560ac0092cca in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) + at /root/qemu/util/coroutine-ucontext.c:79 +#18 0x00007f0216312110 in __start_context () at /lib64/libc.so.6 +#19 0x00007fff12c4db30 in () +#20 0x0000000000000000 in () +(gdb) + +In 5/5 tries this was on qemu_fill_buffer for my case. + +But that was on the receiving side, and what you found is closer to the root cause on the source of the migration. +I checked on qemu_file_set_error on the source and can confirm your finding that on the source it is from bdrv_inactivate_all. + +#0 qemu_file_set_error (f=f@entry=0x6b76b46c00, ret=ret@entry=-1) at ./migration/qemu-file.c:124 +#1 0x0000006b727140cb in qemu_savevm_state_complete_precopy (f=0x6b76b46c00, iterable_only=iterable_only@entry=false, + inactivate_disks=inactivate_disks@entry=true) at ./migration/savevm.c:1160 +#2 0x0000006b7270c84b in migration_completion (start_time=<synthetic pointer>, old_vm_running=<synthetic pointer>, current_active_state=4, + s=0x6b74ef53b0) at ./migration/migration.c:1858 +#3 migration_thread (opaque=0x6b74ef53b0) at ./migration/migration.c:2023 +#4 0x00007f61a740e74a in start_thread (arg=0x7f61467fc700) at pthread_create.c:456 +#5 0x00007f61a714acaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97 + +Also as I outlined - what seems ages ago in comment #6 - if the source is a qemu 2.8 the migration works for me which would kind of match assuming the root cause is in the source. + +OK, Stefan posted a patch for that assert (see 'nbd-client: avoid spurious qui_channel_yield() re-entry) so now I'm running with the following patch and I'm seeing the bdrv_inactivate return a -1 for +drive-virtio-disk0 +Christian: Could you see what your source says with this patch? + +diff --git a/block.c b/block.c +index 3615a68..f9bd689 100644 +--- a/block.c ++++ b/block.c +@@ -4078,9 +4078,11 @@ static int bdrv_inactivate_recurse(BlockDriverState *bs, + BdrvChild *child, *parent; + int ret; + ++ fprintf(stderr, "%s: entry for %s\n", __func__, bdrv_get_device_or_node_name(bs)); + if (!setting_flag && bs->drv->bdrv_inactivate) { + ret = bs->drv->bdrv_inactivate(bs); + if (ret < 0) { ++ fprintf(stderr, "%s: exit 1(%d) for %s\n", __func__, ret, bdrv_get_device_or_node_name(bs)); + return ret; + } + } +@@ -4094,6 +4096,7 @@ static int bdrv_inactivate_recurse(BlockDriverState *bs, + if (parent->role->inactivate) { + ret = parent->role->inactivate(parent); + if (ret < 0) { ++ fprintf(stderr, "%s: exit 2(%d) for %s\n", __func__, ret, bdrv_get_device_or_node_name(bs)); + bs->open_flags &= ~BDRV_O_INACTIVE; + return ret; + } +@@ -4109,6 +4112,7 @@ static int bdrv_inactivate_recurse(BlockDriverState *bs, + QLIST_FOREACH(child, &bs->children, next) { + ret = bdrv_inactivate_recurse(child->bs, setting_flag); + if (ret < 0) { ++ fprintf(stderr, "%s: exit 3(%d) for %s\n", __func__, ret, bdrv_get_device_or_node_name(bs)); + return ret; + } + } +@@ -4117,6 +4121,7 @@ static int bdrv_inactivate_recurse(BlockDriverState *bs, + * driver */ + bdrv_release_persistent_dirty_bitmaps(bs); + ++ fprintf(stderr, "%s: exit end good for %s\n", __func__, bdrv_get_device_or_node_name(bs)); + return 0; + } + + + +Building with the attached debug patch ... + +I didn't add Stefans patch yet. +Note: the Mentioned patch is at: Note: http://lists.nongnu.org/archive/html/qemu-devel/2017-08/msg04027.html + +With your debug patch applied I get: +2017-08-22 17:57:04.486+0000: initiating migration +bdrv_inactivate_recurse: entry for drive-virtio-disk0 +bdrv_inactivate_recurse: entry for #block145 +bdrv_inactivate_recurse: entry for #block328 +bdrv_inactivate_recurse: entry for #block210 +bdrv_inactivate_recurse: exit end good for #block210 +bdrv_inactivate_recurse: exit end good for #block328 +bdrv_inactivate_recurse: entry for #block082 +bdrv_inactivate_recurse: exit end good for #block082 +bdrv_inactivate_recurse: exit end good for #block145 +bdrv_inactivate_recurse: exit end good for drive-virtio-disk0 +bdrv_inactivate_recurse: entry for #block763 +bdrv_inactivate_recurse: entry for #block631 +bdrv_inactivate_recurse: exit end good for #block631 +bdrv_inactivate_recurse: exit end good for #block763 +bdrv_inactivate_recurse: entry for drive-virtio-disk1 +bdrv_inactivate_recurse: entry for #block544 +bdrv_inactivate_recurse: entry for #block405 +bdrv_inactivate_recurse: exit end good for #block405 +bdrv_inactivate_recurse: exit end good for #block544 +bdrv_inactivate_recurse: exit end good for drive-virtio-disk1 +bdrv_inactivate_recurse: entry for #block1086 +bdrv_inactivate_recurse: entry for #block919 +bdrv_inactivate_recurse: exit end good for #block919 +bdrv_inactivate_recurse: exit end good for #block1086 +bdrv_inactivate_recurse: entry for drive-virtio-disk0 +bdrv_inactivate_recurse: exit 2(-1) for drive-virtio-disk0 + +I'm currently building one with Stefans patch applied as well over (my) night, but let me know if there is more that makes sense to try. + +With the patch from Stefan and your debug applied source and target I still run into the same issue I'd say. +Id's are slightly off, but they are different on every try anyway. + +Still looks the same for me: +bdrv_inactivate_recurse: entry for drive-virtio-disk0 +bdrv_inactivate_recurse: entry for #block184 +bdrv_inactivate_recurse: entry for #block319 +bdrv_inactivate_recurse: entry for #block218 +bdrv_inactivate_recurse: exit end good for #block218 +bdrv_inactivate_recurse: exit end good for #block319 +bdrv_inactivate_recurse: entry for #block092 +bdrv_inactivate_recurse: exit end good for #block092 +bdrv_inactivate_recurse: exit end good for #block184 +bdrv_inactivate_recurse: exit end good for drive-virtio-disk0 +bdrv_inactivate_recurse: entry for #block1905 +bdrv_inactivate_recurse: entry for #block1889 +bdrv_inactivate_recurse: exit end good for #block1889 +bdrv_inactivate_recurse: exit end good for #block1905 +bdrv_inactivate_recurse: entry for drive-virtio-disk1 +bdrv_inactivate_recurse: entry for #block551 +bdrv_inactivate_recurse: entry for #block423 +bdrv_inactivate_recurse: exit end good for #block423 +bdrv_inactivate_recurse: exit end good for #block551 +bdrv_inactivate_recurse: exit end good for drive-virtio-disk1 +bdrv_inactivate_recurse: entry for #block2246 +bdrv_inactivate_recurse: entry for #block2106 +bdrv_inactivate_recurse: exit end good for #block2106 +bdrv_inactivate_recurse: exit end good for #block2246 +bdrv_inactivate_recurse: entry for drive-virtio-disk0 +bdrv_inactivate_recurse: exit 2(-1) for drive-virtio-disk0 + +OK, yeh that's the same symptom I saw - it's that final failure that causes bdrv_inactivate_all to return a failure and fail the source migration. + +Please see Fam's patch series "[PATCH for-2.10 0/4] block: Fix non-shared storage migration" that fixes this issue. + +yes, seems to fix it for me. + +Thanks Christian for filing this; we probably wouldn't have spotted it before the release without it +(which the test Stefan has just added will hopefully cure!). + +Hi Stefan, +I was part of the report around the series in "[PATCH for-2.10 0/4] block: Fix non-shared storage migration", but this is happening on rc3 which contains this. + +AFAIK Fam's series is: +dd7fdaad iotests: Add non-shared storage migration case 192 (Fam) +5f7772c4 block-backend: Defer shared_perm tightening migration completion (Fam) +3dff24f2 nbd: Fix order of bdrv_set_perm and bdrv_invalidate_cache (Kevin) +80adf54e stubs: Add vm state change handler stubs (Fam) + +All these got into v2.10.0-rc3 which these tests are based on already. +IMHO - This is not complete for qemu 2.10 and a regression since 2.9 (well since 2.8 as I haven't tested 2.9 personally). + +Ok, clarified with Stefanha +It has exactly the same title as a series of 18th August which was related to a similar issue. +It is about an hour old now on qemu-devel, quoting + +"This fixes the issue reported as https://bugs.launchpad.net/bugs/1711602 + +Fam Zheng (3): + block-backend: Refactor inactivate check + block-backend: Allow more "can inactivate" cases + mirror: Mark target BB as "force allow inactivate" + +Stefan Hajnoczi (1): + block: Update open_flags after ->inactivate() callback" + + +I'll prep a build with that and test as well + +On 08/23/2017 09:55 AM, ChristianEhrhardt wrote: +> Ok, clarified with Stefanha +> It has exactly the same title as a series of 18th August which was related to a similar issue. +> It is about an hour old now on qemu-devel, quoting +> +> "This fixes the issue reported as +> https://bugs.launchpad.net/bugs/1711602 +> +> Fam Zheng (3): +> block-backend: Refactor inactivate check +> block-backend: Allow more "can inactivate" cases +> mirror: Mark target BB as "force allow inactivate" +> +> Stefan Hajnoczi (1): +> block: Update open_flags after ->inactivate() callback" +> +> +> I'll prep a build with that and test as well + +Here's what is brewing for my pull request, although if you can +successfully test things, I'm happy to add a Tested-by: tag before +actually sending the pull request: + +git fetch git://repo.or.cz/qemu/ericb.git nbd + +-- +Eric Blake, Principal Software Engineer +Red Hat, Inc. +1-919-301-3266 +Virtualization: qemu.org | libvirt.org + + + +Hmm, +it gets further but can still not complete this kind of migration: + +$ virsh migrate --live --copy-storage-all kvmguest-artful-normal qemu+ssh://10.22.69.30/system + +Source: +2017-08-23 16:49:23.022+0000: initiating migration +Unexpected error in bdrv_check_perm() at /build/qemu-VjSgVJ/qemu-2.10~rc3+dfsg/block.c:1574: +2017-08-23T16:49:23.203181Z qemu-system-x86_64: Block node is read-only +2017-08-23 16:49:23.762+0000: shutting down, reason=crashed + +Target: +2017-08-23T16:49:23.495478Z qemu-system-x86_64: Failed to load virtio_pci/modern_state:modern_state +2017-08-23T16:49:23.495505Z qemu-system-x86_64: Failed to load virtio/extra_state:extra_state +2017-08-23T16:49:23.495510Z qemu-system-x86_64: Failed to load virtio-balloon:virtio +2017-08-23T16:49:23.495515Z qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:06.0/virtio-balloon' +2017-08-23T16:49:23.496071Z qemu-system-x86_64: load of migration failed: Input/output error +2017-08-23 16:49:23.797+0000: shutting down, reason=crashed + +I was to eager to get this close-to-real so I don't have Davids fprintf's applied anymore - I'll build those and then run it in the debugger, but until then what I can see is that behavior slightly changes (worse). +It now crashes the guest on the source as well when aborting the migration. + +I need to debug to confirm, but it seems it still aborts the migration + -> qemu-system-x86_64: load of migration failed: Input/output error +But then can't fall back to the source and crashes at + -> qemu-system-x86_64: Block node is read-only + +That was rc3 +: +- nbd-client-avoid-spurious-qio_channel_yield.patch +- the four patches mentioned in comment #43 + +I could also re-base onto master + pacthes or rc4 if there is one soon. +For now building with Davids debug statements applied again to check if we still abort around that assert. + +I need to recheck with that combo - I'd seen that error but only when I'd commented out 'if (!blk->dev && !blk_name(blk)[0]) {' when debugging earlier. + +Looks good here, just retested: + +here's teh top of my git: + +f89f59fad5119f878aaedf711af90802ddcb99c7 nbd-client: avoid spurious qio_channel_yield() re-entry +cf26039a2b50f078b4ad90b88eea5bb28971c0d8 block: Update open_flags after ->inactivate() callback +8ccc527d84ec9a5052cfae19edbc44abb5ac03ae mirror: Mark target BB as "force allow inactivate" +34c3f17c99a43f261560edbd3da1188dd0c398ab block-backend: Allow more "can inactivate" cases +952ad9fd9dd43e92016d5bfc0ff93bdeaec13bf9 block-backend: Refactor inactivate check +1f296733876434118fd766cfef5eb6f29ecab6a8 Update version for v2.10.0-rc3 release + + +just tested current head - 1eed33994e28d4a0437ba6e944bbc3ec5e4a29a0 - seems to work for me. + +Yeah seems to be slightly different than the former assert. + +2017-08-23 18:41:54.556+0000: initiating migration +bdrv_inactivate_recurse: entry for drive-virtio-disk0 +bdrv_inactivate_recurse: entry for #block133 +bdrv_inactivate_recurse: entry for #block329 +bdrv_inactivate_recurse: entry for #block202 +bdrv_inactivate_recurse: exit end good for #block202 +bdrv_inactivate_recurse: exit end good for #block329 +bdrv_inactivate_recurse: entry for #block025 +bdrv_inactivate_recurse: exit end good for #block025 +bdrv_inactivate_recurse: exit end good for #block133 +bdrv_inactivate_recurse: exit end good for drive-virtio-disk0 +bdrv_inactivate_recurse: entry for #block799 +bdrv_inactivate_recurse: entry for #block626 +bdrv_inactivate_recurse: exit end good for #block626 +bdrv_inactivate_recurse: exit end good for #block799 +bdrv_inactivate_recurse: entry for drive-virtio-disk1 +bdrv_inactivate_recurse: entry for #block570 +bdrv_inactivate_recurse: entry for #block485 +bdrv_inactivate_recurse: exit end good for #block485 +bdrv_inactivate_recurse: exit end good for #block570 +bdrv_inactivate_recurse: exit end good for drive-virtio-disk1 +bdrv_inactivate_recurse: entry for #block1058 +bdrv_inactivate_recurse: entry for #block920 +bdrv_inactivate_recurse: exit end good for #block920 +bdrv_inactivate_recurse: exit end good for #block1058 +bdrv_inactivate_recurse: entry for drive-virtio-disk0 +Unexpected error in bdrv_check_perm() at /build/qemu-0OVYHF/qemu-2.10~rc3+dfsg/block.c:1574: +2017-08-23T18:41:54.730131Z qemu-system-x86_64: Block node is read-only + +Which is: +1553 /* +1554 * Check whether permissions on this node can be changed in a way that +1555 * @cumulative_perms and @cumulative_shared_perms are the new cumulative +1556 * permissions of all its parents. This involves checking whether all necessary +1557 * permission changes to child nodes can be performed. +1558 * +1559 * A call to this function must always be followed by a call to bdrv_set_perm() +1560 * or bdrv_abort_perm_update(). +1561 */ +1562 static int bdrv_check_perm(BlockDriverState *bs, uint64_t cumulative_perms, +1563 uint64_t cumulative_shared_perms, +1564 GSList *ignore_children, Error **errp) +1565 { +1566 BlockDriver *drv = bs->drv; +1567 BdrvChild *c; +1568 int ret; +1569 +1570 /* Write permissions never work with read-only images */ +1571 if ((cumulative_perms & (BLK_PERM_WRITE | BLK_PERM_WRITE_UNCHANGED)) && +1572 !bdrv_is_writable(bs)) +1573 { +1574 error_setg(errp, "Block node is read-only"); +1575 return -EPERM; +1576 } + +Adding in debug symbols to see in gdb which device that actually is showed me: +I don't know what you might need so the full struct: + +(gdb) p *bs +$2 = {open_flags = 2050, read_only = false, encrypted = false, sg = false, probed = false, force_share = false, implicit = true, + drv = 0x1a67219800 <bdrv_mirror_top>, opaque = 0x0, aio_context = 0x1a684ae0d0, aio_notifiers = {lh_first = 0x1a6a4850e0}, + walking_aio_notifiers = false, filename = "/var/lib/uvtool/libvirt/images/kvmguest-artful-normal.qcow", '\000' <repeats 4037 times>, + backing_file = "/var/lib/uvtool/libvirt/images/kvmguest-artful-normal.qcow", '\000' <repeats 4037 times>, + backing_format = "qcow2\000\000\000\000\000\000\000\000\000\000", full_open_options = 0x0, + exact_filename = "/var/lib/uvtool/libvirt/images/kvmguest-artful-normal.qcow", '\000' <repeats 4037 times>, backing = 0x1a6971a4a0, + file = 0x0, bl = {request_alignment = 1, max_pdiscard = 0, pdiscard_alignment = 0, max_pwrite_zeroes = 0, pwrite_zeroes_alignment = 0, + opt_transfer = 0, max_transfer = 0, min_mem_alignment = 512, opt_mem_alignment = 4096, max_iov = 1024}, supported_write_flags = 0, + supported_zero_flags = 0, node_name = "#block814", '\000' <repeats 22 times>, node_list = {tqe_next = 0x1a684b44d0, tqe_prev = 0x1a6b02e0c0}, + bs_list = {tqe_next = 0x1a6a010030, tqe_prev = 0x1a6ab6bc50}, monitor_list = {tqe_next = 0x0, tqe_prev = 0x0}, refcnt = 3, op_blockers = {{ + lh_first = 0x1a69e18e80}, {lh_first = 0x1a69e18ea0}, {lh_first = 0x1a69e18ec0}, {lh_first = 0x1a69e18ee0}, {lh_first = 0x1a69e18f00}, { + lh_first = 0x0}, {lh_first = 0x1a69e18f40}, {lh_first = 0x1a69e18f60}, {lh_first = 0x1a69e18f80}, {lh_first = 0x1a69e18fa0}, { + lh_first = 0x1a6989be30}, {lh_first = 0x1a69e18fc0}, {lh_first = 0x1a69e18fe0}, {lh_first = 0x1a69352e90}, {lh_first = 0x1a69352eb0}, { + lh_first = 0x1a69352ed0}}, job = 0x1a69e18bf0, inherits_from = 0x0, children = {lh_first = 0x1a6971a4a0}, parents = { + lh_first = 0x1a69e18e00}, options = 0x1a69b636a0, explicit_options = 0x1a69e16bb0, detect_zeroes = BLOCKDEV_DETECT_ZEROES_OPTIONS_OFF, + backing_blocker = 0x1a686e2e00, total_sectors = 16777216, before_write_notifiers = {notifiers = {lh_first = 0x0}}, write_threshold_offset = 0, + write_threshold_notifier = {notify = 0x0, node = {le_next = 0x0, le_prev = 0x0}}, dirty_bitmap_mutex = {lock = {__data = {__lock = 0, + __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, + __size = '\000' <repeats 39 times>, __align = 0}, initialized = true}, dirty_bitmaps = {lh_first = 0x0}, wr_highest_offset = { + value = 1190584320}, copy_on_read = 0, in_flight = 0, serialising_in_flight = 0, wakeup = false, io_plugged = 0, enable_write_cache = 0, + quiesce_counter = 0, write_gen = 2, reqs_lock = {locked = 0, ctx = 0x0, from_push = {slh_first = 0x0}, to_pop = {slh_first = 0x0}, + handoff = 0, sequence = 0, holder = 0x0}, tracked_requests = {lh_first = 0x0}, flush_queue = {entries = {sqh_first = 0x0, + sqh_last = 0x1a69b63680}}, active_flush_req = false, flushed_gen = 2} + +And that effectively is my root disk: + +At least the trivial flag in the struct is "read_only = false". +Also on a FS level it is rw: +-rw------- 1 root root 717160448 Aug 23 18:50 /var/lib/uvtool/libvirt/images/kvmguest-artful-normal.qcow +(qemu is running privileged in this setup with UID 0, so no reason to mark that as read only IMHO) + +So I checked the full context of the if that leads to the error: + (cumulative_perms & (BLK_PERM_WRITE | BLK_PERM_WRITE_UNCHANGED)) + 3 (in my case) & ( 0x2 | 0x4) + ok that is a match + +So it goes further to + !bdrv_is_writable(bs) + +Which effectively is: + !bdrv_is_read_only(bs) && !(bs->open_flags & BDRV_O_INACTIVE); + !bs->read_only ! (2050 & 0x800) + !false !(true) + true false + +So the problem is that BDRV_O_INACTIVE is set? +Sorry I don't see why that is so (maybe too late for today). +But I hope that helps in understanding the remaining case. + +I checked against your coommit list and I didn't have the following yet. +cf26039a2b50f078b4ad90b88eea5bb28971c0d8 block: Update open_flags after ->inactivate() callback +I took it now from the PULL 0/6 of Eric that appeared after my last test. +Building with that now to report once again. + +If there is no build hickup that next test should just fit in before I fall asleep. +Hoping for the best to report a tested by in time if possible. + +Yes, with all the series of [1] on top it finally works. +Saw it already being merged on master. +Expecting a late rc4 or early release tag and then wrap all it up. + +Thanks everybody involved! + +[1]: http://lists.nongnu.org/archive/html/qemu-devel/2017-08/msg04513.html + +This bug was fixed in the package qemu - 1:2.10~rc4+dfsg-0ubuntu1 + +--------------- +qemu (1:2.10~rc4+dfsg-0ubuntu1) artful; urgency=medium + + * Merge with Upstream 2.10-rc4; This fixes a migration issue (LP: #1711602); + Remaining changes: + - qemu-kvm to systemd unit + - d/qemu-kvm-init: script for QEMU KVM preparation modules, ksm, + hugepages and architecture specifics + - d/qemu-kvm.service: systemd unit to call qemu-kvm-init + - d/qemu-system-common.install: install systemd unit and helper script + - d/qemu-system-common.maintscript: clean old sysv and upstart scripts + - d/qemu-system-common.qemu-kvm.default: defaults for + /etc/default/qemu-kvm + - d/rules: install /etc/default/qemu-kvm + - Enable nesting by default + - set nested=1 module option on intel. (is default on amd) + - re-load kvm_intel.ko if it was loaded without nested=1 + - d/p/ubuntu/expose-vmx_qemu64cpu.patch: expose nested kvm by default + in qemu64 cpu type. + - d/p/ubuntu/enable-svm-by-default.patch: Enable nested svm by default + in qemu64 on amd + - libvirt/qemu user/group support + - qemu-system-common.postinst: remove acl placed by udev, and add udevadm + trigger. + - qemu-system-common.preinst: add kvm group if needed + - Distribution specific machine type + - d/p/ubuntu/define-ubuntu-machine-types.patch: define distro machine + types to ease future live vm migration. + - d/qemu-system-x86.NEWS Info on fixed machine type defintions + - improved dependencies + - Make qemu-system-common depend on qemu-block-extra + - Make qemu-utils depend on qemu-block-extra + - let qemu-utils recommend sharutils + - s390x support + - Create qemu-system-s390x package + - Include s390-ccw.img firmware + - Enable numa support for s390x + - ppc64[le] support + - d/qemu-system-ppc.links provide usr/bin/qemu-system-ppc64le symlink + - Enable seccomp for ppc64el + - bump libseccomp-dev dependency, 2.3 is the minimum for ppc64 + - arch aware kvm wrappers + - update VCS-git to match the Artful branch + - disable missing x32 architecture + - d/rules: or32 is now named or1k (since 4a09d0bb) + - d/qemu-system-common.docs: new paths since (ac06724a) + - d/qemu-system-common.install: qmp-commands.txt removed, but replaced + by qapi-schema.json which is already packaged (since 4d8bb958) + - d/p/02_kfreebsd.patch: utimensat is no more optional upstream (Update + to Debian patch to match qemu 2.10) + - s390x package now builds correctly on all architectures (LP 1710695) + * Added changes: + - d/qemu-system-common.docs: adapt new path of live-block-operations.rst + since 8508eee7 + - d/qemu-system-common.docs: adapt q35 config paths since 9ca019c1 + - make nios2/hppa not installed explicitly until further stablized + - d/qemu-guest-agent.install: add the new guest agent reference man page + qemu-ga-ref + - d/qemu-system-common.install: add the now generated qapi/qmp reference + along the qapi intro + - d/not-installed: ignore further generated (since 56e8bdd4) files in + dh_missing that are already provided in other formats qemu-doc, + qemu-qmp-ref,qemu-ga-ref + - d/p/ubuntu/define-ubuntu-machine-types.patch: update to match new + changes in 2.10-rc4 + + -- Christian Ehrhardt <email address hidden> Fri, 25 Aug 2017 07:49:30 +0200 + diff --git a/results/classifier/105/mistranslation/1711828 b/results/classifier/105/mistranslation/1711828 new file mode 100644 index 000000000..41f55a033 --- /dev/null +++ b/results/classifier/105/mistranslation/1711828 @@ -0,0 +1,74 @@ +mistranslation: 0.939 +instruction: 0.939 +other: 0.853 +device: 0.830 +semantic: 0.808 +graphic: 0.753 +assembly: 0.691 +network: 0.669 +socket: 0.634 +vnc: 0.580 +boot: 0.460 +KVM: 0.448 + +lock mov non generated #UD + +qemu 2.8.1 debian 9.1 + +Could you please add a proper description to this bug? Please also try first whether your problem also occurs with the latest released version of QEMU (version 2.9 or the 2.10 release candidate), to see whether it has been fixed there already. + + + +sorry i english poor： + + +intel manual say： +The LOCK prefix can be prepended only to the following instructions and only to those forms of the instructions +where the destination operand is a memory operand: ADD, ADC, AND, BTC, BTR, BTS, CMPXCHG, CMPXCH8B, +CMPXCHG16B, DEC, INC, NEG, NOT, OR, SBB, SUB, XOR, XADD, and XCHG. If the LOCK prefix is used with one of +these instructions and the source operand is a memory operand, an undefined opcode exception (#UD) may be +generated. An undefined opcode exception will also be generated if the LOCK prefix is used with any instruction not +in the above list. The XCHG instruction always asserts the LOCK# signal regardless of the presence or absence of +the LOCK prefix. + + +but qemu NO! +lock mov forms of the instructions non generated #UD exception! +my OS : debian 9.1 +QEMU: qemu 2.8.1 + + + + + + + +At 2017-08-21 12:54:44, "Thomas Huth" <email address hidden> wrote: +>Could you please add a proper description to this bug? Please also try +>first whether your problem also occurs with the latest released version +>of QEMU (version 2.9 or the 2.10 release candidate), to see whether it +>has been fixed there already. +> +>** Changed in: qemu +> Status: New => Incomplete +> +>-- +>You received this bug notification because you are subscribed to the bug +>report. +>https://bugs.launchpad.net/bugs/1711828 +> +>Title: +> lock mov non generated #UD +> +>Status in QEMU: +> Incomplete +> +>Bug description: +> qemu 2.8.1 debian 9.1 +> +>To manage notifications about this bug go to: +>https://bugs.launchpad.net/qemu/+bug/1711828/+subscriptions + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1715296 b/results/classifier/105/mistranslation/1715296 new file mode 100644 index 000000000..b5e4512c0 --- /dev/null +++ b/results/classifier/105/mistranslation/1715296 @@ -0,0 +1,35 @@ +mistranslation: 0.925 +other: 0.742 +semantic: 0.735 +device: 0.726 +network: 0.676 +instruction: 0.559 +socket: 0.518 +graphic: 0.468 +vnc: 0.466 +boot: 0.258 +KVM: 0.141 +assembly: 0.118 + +qemu: invalid serial port configuration + +The tty_serial_init() function sets the port c_oflags as follows: +tty.c_oflag |= OPOST not clearing ONLCR, ONLRET and others. +The result is that the postprocess output is enabled and host translates 0xa (LF) to 0xd 0xa (CR LF) which breaks the binary transmissions on serial port even if you set the port to raw mode (no matters if on host and/or guest). +The issue has been reported 11 years ago on qemu-devel mailing list: +https://lists.nongnu.org/archive/html/qemu-devel/2006-06/msg00196.html +There was also a FreeBSD patch including the fix: +https://lists.freebsd.org/pipermail/freebsd-ports/2006-October/036390.html + +I think the correct port configuration is: +tty.c_iflag &= ~(IGNBRK|BRKINT|PARMRK|ISTRIP|INLCR|IGNCR|ICRNL|IXON|IMAXBEL); +tty.c_oflag &= ~OPOST; + +In such case the host will perform no output processing and will pass the data as is. +And the guest will be able to configure input/output processing exactly as it wants. + +I believe the following bug is related: https://bugs.launchpad.net/qemu/+bug/1407813 + +Patch has now been committed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=12fb0ac0575df83cec72ec + diff --git a/results/classifier/105/mistranslation/1715715 b/results/classifier/105/mistranslation/1715715 new file mode 100644 index 000000000..0f2b2f59b --- /dev/null +++ b/results/classifier/105/mistranslation/1715715 @@ -0,0 +1,76 @@ +mistranslation: 0.695 +other: 0.682 +vnc: 0.626 +instruction: 0.624 +semantic: 0.622 +device: 0.622 +graphic: 0.614 +KVM: 0.609 +assembly: 0.602 +network: 0.601 +socket: 0.600 +boot: 0.574 + +[qemu-ppc] Segfault when booting from HD after MacOS9 install + +I created an empty 128G qcow2 image and booted from a Mac OS 9.2.1 Install CD, in which I was able to install the OS successfully to the hard drive. Upon reboot, this time from the hard drive directly, qemu-system-ppc segfaults. + +qemu --version reports "v2.10.0-244-gb07d1c2-dirty", but I used git commit b07d1c2f5607489d4d4a6a65ce36a3e896ac065e and built with "./configure --target-list=ppc-softmmu --enable-debug --disable-strip". + +Here is the command-line arguments: + +qemu-system-ppc -boot c -g 1024x768x32 -M mac99 -m 256 -prom-env 'auto-boot?=true' -prom-env 'boot-args=-v' -prom-env 'vga-ndrv?=true' -drive file=../os9.img,format=raw,media=cdrom -drive file=MacOS9.qcow2,format=qcow2,media=disk -spice port=5901,password=XXX -net nic,model=rtl8139 -net user -monitor stdio + +And the GDB backtrace: + +Program terminated with signal SIGSEGV, Segmentation fault. +#0 0x0000559065fe7d3a in timer_mod (ts=0x0, expire_time=888960717010) at util/qemu-timer.c:462 +462 timer_mod_ns(ts, expire_time * ts->scale); +[Current thread is 1 (Thread 0x7f60e43cb700 (LWP 9853))] +(gdb) bt +#0 0x0000559065fe7d3a in timer_mod (ts=0x0, expire_time=888960717010) at util/qemu-timer.c:462 +#1 0x0000559065d63769 in openpic_tmr_set_tmr (tmr=0x5590676fa7e0, val=96, enabled=true) at hw/intc/openpic.c:861 +#2 0x0000559065d63995 in openpic_tmr_write (opaque=0x5590676f71f0, addr=16, val=96, len=4) at hw/intc/openpic.c:912 +#3 0x0000559065b02811 in memory_region_write_accessor (mr=0x5590676f7710, addr=32, value=0x7f60e43c7da8, size=4, shift=0, mask=4294967295, attrs=...) at /home/bp/qemu/memory.c:529 +#4 0x0000559065b02a29 in access_with_adjusted_size (addr=32, value=0x7f60e43c7da8, size=1, access_size_min=4, access_size_max=4, access=0x559065b02727 <memory_region_write_accessor>, mr=0x5590676f7710, attrs=...) at /home/bp/qemu/memory.c:595 +#5 0x0000559065b051eb in memory_region_dispatch_write (mr=0x5590676f7710, addr=32, data=96, size=1, attrs=...) at /home/bp/qemu/memory.c:1337 +#6 0x0000559065aa3a36 in address_space_write_continue (as=0x559067614d90, addr=2147750160, attrs=..., buf=0x7f60e43c7ed0 "`_'\310`\177", len=1, addr1=32, l=1, mr=0x5590676f7710) at /home/bp/qemu/exec.c:2942 +#7 0x0000559065aa3b84 in address_space_write (as=0x559067614d90, addr=2147750160, attrs=..., buf=0x7f60e43c7ed0 "`_'\310`\177", len=1) at /home/bp/qemu/exec.c:2987 +#8 0x0000559065aa2ec0 in subpage_write (opaque=0x7f60c8275fc0, addr=272, value=96, len=1, attrs=...) at /home/bp/qemu/exec.c:2565 +#9 0x0000559065b02906 in memory_region_write_with_attrs_accessor (mr=0x7f60c8275fc0, addr=272, value=0x7f60e43c7fc8, size=1, shift=0, mask=255, attrs=...) at /home/bp/qemu/memory.c:555 +#10 0x0000559065b029d3 in access_with_adjusted_size (addr=272, value=0x7f60e43c7fc8, size=1, access_size_min=1, access_size_max=8, access=0x559065b02818 <memory_region_write_with_attrs_accessor>, mr=0x7f60c8275fc0, attrs=...) at /home/bp/qemu/memory.c:590 +#11 0x0000559065b0523a in memory_region_dispatch_write (mr=0x7f60c8275fc0, addr=272, data=96, size=1, attrs=...) at /home/bp/qemu/memory.c:1344 +#12 0x0000559065b175db in io_writex (env=0x7f60e43d42a0, iotlbentry=0x7f60e43e8130, mmu_idx=3, val=96, addr=2147750160, retaddr=140054158295744, size=1) at /home/bp/qemu/accel/tcg/cputlb.c:807 +#13 0x0000559065b18055 in io_writeb (env=0x7f60e43d42a0, mmu_idx=3, index=65, val=96 '`', addr=2147750160, retaddr=140054158295744) at /home/bp/qemu/softmmu_template.h:265 +#14 0x0000559065b181ea in helper_ret_stb_mmu (env=0x7f60e43d42a0, addr=2147750160, val=96 '`', oi=3, retaddr=140054158295744) at /home/bp/qemu/softmmu_template.h:300 +#15 0x00007f60e65ac2c0 in code_gen_buffer () +#16 0x0000559065b1ff26 in cpu_tb_exec (cpu=0x7f60e43cc010, itb=0x7f60e65ac5c0 <code_gen_buffer+935318>) at /home/bp/qemu/accel/tcg/cpu-exec.c:166 +#17 0x0000559065b20bfd in cpu_loop_exec_tb (cpu=0x7f60e43cc010, tb=0x7f60e65ac5c0 <code_gen_buffer+935318>, last_tb=0x7f60e43c8678, tb_exit=0x7f60e43c8674) at /home/bp/qemu/accel/tcg/cpu-exec.c:578 +#18 0x0000559065b20eed in cpu_exec (cpu=0x7f60e43cc010) at /home/bp/qemu/accel/tcg/cpu-exec.c:676 +#19 0x0000559065aebc3d in tcg_cpu_exec (cpu=0x7f60e43cc010) at /home/bp/qemu/cpus.c:1270 +#20 0x0000559065aebe64 in qemu_tcg_rr_cpu_thread_fn (arg=0x7f60e43cc010) at /home/bp/qemu/cpus.c:1365 +#21 0x00007f60f56f06ba in start_thread (arg=0x7f60e43cb700) at pthread_create.c:333 +#22 0x00007f60f542682d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 + + +Any idea what is going on? + +I've just tested MacOS 9.2.1 as part of my QEMU pre-release testing and it works fine for me with latest QEMU git and the following command line: + +qemu-system-ppc -M mac99 -m 256 -drive file=os921.qcow2,format=qcow2,media=disk -net nic,model=rtl8139 -net user + +Note that the QEMU mac99 machine now defaults to using the sungem device which should give out-of-the-box networking for supported OS 9 and OS X versions, including 9.2.1 as you mention, if you simply specify "-net nic,model=sungem -net user" instead. Otherwise you will need to make sure that the rtl8139 MacOS 9 drivers have been installed inside the guest. + +If that doesn't help then does it work if you disable spice and/or reduce the size of the disk image? Many older OSs will struggle to read disks that are 128G in size so you may find that your image is corrupted - perhaps try using something around 4G instead? + +I just tried the latest git and it actually boots fine with your command... so I guess whatever issue I was having (the null dereference in the timer code I pasted above) must have been fixed... however I've noticed another issue with a different command that causes the bootup to hang: + +qemu-system-ppc -boot c -g 1024x768x32 -M mac99 -m 256 -prom-env 'auto-boot?=true' -prom-env 'boot-args=-v' -prom-env 'vga-ndrv?=true' -drive file=os9.2.1.iso,format=raw,media=cdrom -drive file=os921.qcow2,format=qcow2,media=disk -spice port=5901,password=XXX -net nic,model=sungem -net user -monitor stdio + +This hangs at bootup at "Trying hd:,\\:tbxi" and never progresses any further. If I remove the cdrom then it boots fine... however, simply adding the cdrom to your working command, it still works there... not sure what's going on, but thanks for the help. I have something that works now. + + +Looking through old bug tickets ... can you still reproduce the segfault with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1719 b/results/classifier/105/mistranslation/1719 new file mode 100644 index 000000000..3c29d5752 --- /dev/null +++ b/results/classifier/105/mistranslation/1719 @@ -0,0 +1,20 @@ +mistranslation: 0.686 +graphic: 0.650 +device: 0.591 +semantic: 0.539 +socket: 0.454 +other: 0.422 +network: 0.408 +vnc: 0.367 +instruction: 0.304 +boot: 0.217 +assembly: 0.033 +KVM: 0.017 + +Allow TCG plugins to read memory +Additional information: +* `include/qemu/plugin.h` +* `include/qemu/qemu-plugin.h` +* `plugin/api.c` + +PANDA implemented this already (not sure if this solution is acceptable for the mainline QEMU): https://github.com/qemu/qemu/commit/72c661a7f141ab41fbce5e95eb3593b69f40e246 diff --git a/results/classifier/105/mistranslation/1719339 b/results/classifier/105/mistranslation/1719339 new file mode 100644 index 000000000..4d4dda965 --- /dev/null +++ b/results/classifier/105/mistranslation/1719339 @@ -0,0 +1,51 @@ +mistranslation: 0.763 +KVM: 0.614 +vnc: 0.506 +other: 0.456 +device: 0.429 +network: 0.422 +instruction: 0.395 +boot: 0.370 +assembly: 0.361 +semantic: 0.350 +socket: 0.341 +graphic: 0.337 + +serial8250: too much work for irq3 + +It's know issue and sometimes mentioned since 2007. But it seems not fixed. + +http://lists.gnu.org/archive/html/qemu-devel/2008-02/msg00140.html +https://bugzilla.redhat.com/show_bug.cgi?id=986761 +http://old-list-archives.xenproject.org/archives/html/xen-devel/2009-02/msg00696.html + +I don't think fixes like increases PASS_LIMIT (/drivers/tty/serial/8250.c) or remove this annoying message (https://patchwork.kernel.org/patch/3920801/) is real fix. Some fix was proposed by H. Peter Anvin https://lkml.org/lkml/2008/2/7/485. + +Can reproduce on Debian Strech host (Qemu 1:2.8+dfsg-6+deb9u2), Ubuntu 16.04.2 LTS (Qemu 1:2.5+dfsg-5ubuntu10.15) also tried to use master branch (QEMU emulator version 2.10.50 (v2.10.0-766-ga43415ebfd-dirty)) if we write a lot of message into console (dmesg or dd if=/dev/zero of=/dev/ttyS1). + +/usr/local/bin/qemu-system-x86_64 -name guest=ultra1,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-27-ultra1/master-key.aes -machine pc-i440fx-2.8,accel=kvm,usb=off,dump-guest-core=off -cpu Skylake-Client,ds=on,acpi=on,ss=on,ht=on,tm=on,pbe=on,dtes64=on,monitor=on,ds_cpl=on,vmx=on,smx=on,est=on,tm2=on,xtpr=on,pdcm=on,osxsave=on,tsc_adjust=on,clflushopt=on,pdpe1gb=on -m 4096 -realtime mlock=off -smp 4,sockets=1,cores=4,threads=1 -uuid 4537ca29-73b2-40c3-9b43-666de182ba5f -display none -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-27-ultra1/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x8.0x7 -drive file=/home/dzagorui/csr/csr_disk.qcow2,format=qcow2,if=none,id=drive-ide0-0-0 -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -netdev tap,fd=26,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=52:54:00:a9:4c:86,bus=pci.0,addr=0x3 -chardev socket,id=charserial0,host=127.0.0.1,port=4000,telnet,server,nowait -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charserial1,host=127.0.0.1,port=4001,telnet,server,nowait -device isa-serial,chardev=charserial1,id=serial1 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x2 -msg timestamp=on + +Use simpler setup for reproducing. +Was used only qemu-system-x86_64 (without using high-level wrappers and managers of virtual machines: libvirt, virsh, virt-install, virt-manager etc..). My setup with two consoles: + +/usr/local/bin/qemu-system-x86_64 -cpu host -enable-kvm -m 256 -smp 4 -kernel /home/dzagorui//bzImage -append 'root=/dev/ram0 loglevel=9 rw console=ttyS0' -initrd /home/dzagorui/initrd.cpio -display none -chardev socket,id=charserial0,host=127.0.0.1,port=4002,telnet,server,nowait -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charserial1,host=127.0.0.1,port=4003,telnet,server,nowait -device isa-serial,chardev=charserial1,id=serial1 + +I noticed one thing, that -smp parameter affects this issue. When -smp 1 i can't reproduce this issue at all, when -smp 2 i can produce this issue only in second console (ttyS1), when -smp 4 and higher the issue produces on both consoles (ttyS1/ttyS0). +My Host cpu i5-6200U has 2 cores and 4 threads. + +For reproducing was used this commands (no matter what console we use ttyS1 or ttyS0): +#dmesg > /dev/ttyS* +#dd if=/dev/zero of=/dev/ttyS* + +I'm seeing this on AWS EC2 when there's (apparently) high logging volume to the console, very similarly to https://www.reddit.com/r/sysadmin/comments/6zuqad/mongodb_aws_ec2_serial8250_too_much_work_for_irq4/ + +On further investigation of my instance, there appeared to be no high logging volume to the console, nor anything using the /dev/ttyS0 other than agetty. Switching from the generic kernel to the AWS kernel seems to have stabilised it. + +Further update: AWS kernel experienced the same error messages after just over 3 hours of runtime. + +The QEMU project is currently considering to move 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 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/105/mistranslation/1720 b/results/classifier/105/mistranslation/1720 new file mode 100644 index 000000000..13ed7de4a --- /dev/null +++ b/results/classifier/105/mistranslation/1720 @@ -0,0 +1,53 @@ +mistranslation: 0.979 +graphic: 0.856 +device: 0.768 +instruction: 0.647 +other: 0.543 +semantic: 0.435 +network: 0.426 +socket: 0.400 +boot: 0.380 +assembly: 0.306 +KVM: 0.296 +vnc: 0.194 + +Problems in mapping memory regions in multiple machines using GPEX pci-host +Description of problem: +Multiple machines use the GPEX pci-host model. This model forsees 3 MMIO regions: +1. ECAM space +2. MMIO space +3. IO space + +In the different machines, aliases to the 3 memory regions are created which are then mapped onto the sysbus. + +For the ARM virt machine for example following calls are happening: + + ecam_alias = g_new0(MemoryRegion, 1); + ecam_reg = sysbus_mmio_get_region(SYS_BUS_DEVICE(dev), 0); + memory_region_init_alias(ecam_alias, OBJECT(dev), "pcie-ecam", ecam_reg, 0, size_ecam); + memory_region_add_subregion(get_system_memory(), base_ecam, ecam_alias); + + mmio_alias = g_new0(MemoryRegion, 1); + mmio_reg = sysbus_mmio_get_region(SYS_BUS_DEVICE(dev), 1); + memory_region_init_alias(mmio_alias, OBJECT(dev), "pcie-mmio", mmio_reg, base_mmio, size_mmio); + memory_region_add_subregion(get_system_memory(), base_mmio, mmio_alias); + +We now add a generic PCIe root port (gen_pcie_root_port.c) on the PCIBus exposed by the GPEX device: + + pci_create_simple(PCI_HOST_BRIDGE(dev)->bus, -1, "pcie-root-port"); + +This device contains an MSI-x table which is accessible via BAR 0. + +However, if we try to access this space we always get 0xFFFFFFFF as a return value on reads because the memory regions are not correctly mapped IMO. + +If we again look at the mapping of the MMIO space: + + memory_region_init_alias(mmio_alias, OBJECT(dev), "pcie-mmio", mmio_reg, base_mmio, size_mmio); + memory_region_add_subregion(get_system_memory(), base_mmio, mmio_alias); + +The alias is created to the MMIO region in the GPEX device, at offset base_mmio. Afterwards the memory region alias is mapped onto the sysbus at offset base_mmio. To me it seems that the offset is incorrect in creating the alias and should be 0 instead: + + memory_region_init_alias(mmio_alias, OBJECT(dev), "pcie-mmio", mmio_reg, 0, size_mmio); + memory_region_add_subregion(get_system_memory(), base_mmio, mmio_alias); + +With this change the above scenario (accessing the MSI-x table of the generic PCIe root port) is working. I'm not sure if this is the correct fix for this problem and how to cope with e.g. high MMIO regions (as are also present in the virt machine). diff --git a/results/classifier/105/mistranslation/1720971 b/results/classifier/105/mistranslation/1720971 new file mode 100644 index 000000000..142438464 --- /dev/null +++ b/results/classifier/105/mistranslation/1720971 @@ -0,0 +1,27 @@ +mistranslation: 0.726 +graphic: 0.586 +network: 0.573 +other: 0.551 +socket: 0.521 +device: 0.499 +instruction: 0.335 +semantic: 0.301 +vnc: 0.247 +KVM: 0.185 +assembly: 0.123 +boot: 0.118 + +qemu/hw/block/onenand.c:522: strange if statement ? + +[qemu/hw/block/onenand.c:523]: (warning) Opposite inner 'if' condition leads to a dead code block. + +Source code is + + for (b = 0; b < s->blocks; b ++) { + if (b >= s->blocks) { + s->status |= ONEN_ERR_CMD; + break; + } + +Inner if condition will never be true. + diff --git a/results/classifier/105/mistranslation/1722857 b/results/classifier/105/mistranslation/1722857 new file mode 100644 index 000000000..ca2f6c388 --- /dev/null +++ b/results/classifier/105/mistranslation/1722857 @@ -0,0 +1,25 @@ +mistranslation: 0.875 +vnc: 0.644 +device: 0.613 +semantic: 0.524 +graphic: 0.519 +instruction: 0.494 +boot: 0.394 +socket: 0.354 +network: 0.298 +other: 0.259 +assembly: 0.095 +KVM: 0.013 + +Missing PCI "programming interface" ID emulation for USB host controllers + +Qemu doesn't currently emulate the correct value of the "register level programming interface" field in the PCI config space of USB host controllers. As a result, some guest operating systems (most notably Windows) fail to load e.g. generic xHCI drivers, and instead ask for a vendor-specific driver, which may not be always available. + +Example: "-device nec-usb-xhci" emulates a Renesas (formerly NEC) uPD720202 xHCI controller. However, in the PCI config space, it shows us as class 0C, subclass 03, prog-if 00 (UHCI) where as the real uPD720202 (and all real xHCI controllers) have prog-if 30 (xHCI). A Windows guest booted with this option will not recognize devices attached to the XHCI controller unless drivers from Renesas are manually installed first, even though recent Windows versions include a generic xHCI driver that works perfectly well with real uPD720202 hardware. + +That sounds surprising ... according to the source code: +https://git.qemu.org/?p=qemu.git;a=blob;f=hw/usb/hcd-xhci.c;hb=v5.1.0#l3386 +... QEMU already sets 0x30 as programming interface byte there. Could you please double-check whether your problem still occurs with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1728325 b/results/classifier/105/mistranslation/1728325 new file mode 100644 index 000000000..c55a6bd35 --- /dev/null +++ b/results/classifier/105/mistranslation/1728325 @@ -0,0 +1,90 @@ +mistranslation: 0.743 +other: 0.728 +graphic: 0.704 +assembly: 0.699 +device: 0.695 +instruction: 0.637 +vnc: 0.596 +semantic: 0.587 +network: 0.477 +boot: 0.464 +socket: 0.462 +KVM: 0.246 + +POWER8: Wrong behaviour with float-to-int punning + +Building a reduced test program with 'gcc -O2 -fno-inline -mcpu=power8' produces wrong results at runtime. I don't think gcc is at fault here. + +--- +#include <stdio.h> + +int getWord(const float x) +{ + return *(int*)&x; +} + +void main() +{ + int foo = getWord(+123.456f); + int bar = getWord(-123.456f); + + printf("%d\n", foo); + printf("%d\n", bar); + return; +} +--- + +This prints: +--- +0 +0 +--- + +Compiling with 'gcc -O2 -fno-inline -mcpu=power7' and you instead get the expected result: +--- +1123477881 +-1024005767 +--- + + +The different between the two programs is: + +--- power7.s ++++ power8.s +@@ -6,9 +6,9 @@ + .globl getWord + .type getWord, @function + getWord: +- stfs 1,-16(1) +- ori 2,2,0 +- lwa 3,-16(1) ++ xscvdpspn 0,1 ++ mfvsrwz 3,0 ++ extsw 3,3 + blr + .long 0 + .byte 0,0,0,0,0,0,0,0 + .size getWord,.-getWord + + +Seems like qemu doesn't handle xscvdpspn/mfvsrwz correctly. + +https://github.com/qemu/qemu/commit/7ee19fb9d682689d36c849576c808cf92e3bae40 +https://github.com/qemu/qemu/commit/f5c0f7f981333da59cc35c3210d05ec1775c97c1 + +I am running: + +qemu-ppc64le-static -L /usr/powerpc64le-linux-gnu ./a.out + +This is buggy C. + +https://gcc.gnu.org/bugs/#nonbugs_c + +The original code used a union. It generates the same assembler all the same. + +The QEMU project is currently considering to move 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 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/105/mistranslation/1729501 b/results/classifier/105/mistranslation/1729501 new file mode 100644 index 000000000..96327ab78 --- /dev/null +++ b/results/classifier/105/mistranslation/1729501 @@ -0,0 +1,246 @@ +mistranslation: 0.915 +other: 0.903 +graphic: 0.882 +instruction: 0.876 +semantic: 0.873 +device: 0.866 +socket: 0.862 +assembly: 0.862 +network: 0.854 +boot: 0.848 +vnc: 0.847 +KVM: 0.836 + +qemu crashes with assertion error `off_cur_end >= off_cur' failed + +My host environment: Xen + QEMU + +git clones today's xen git and qemut git (2017-10-31) + +xen -- git://xenbits.xen.org/xen.git +commit 24fb44e971a62b345c7b6ca3c03b454a1e150abe + +qemu -- https://github.com/qemu/qemu +commit 47ba789c97c8d201d01058b00a14d8a9a85fcfe9 + +QEMU was compiled using: +./configure --prefix=/mnt/bin/ --enable-xen --target-list=i386-softmmu --extra-cflags="-I/mnt/xen/tools/include -I/mnt/xen/tools/libxc -I/mnt/xen/tools/xenstore" --extra-ldflags="-L/mnt/xen/tools/libxc -L/mnt/xen/tools/xenstore" --enable-debug --enable-debug-stack-usage + +Xen was configured with the above QEMU distribution: +./configure --with-system-qemu=/mnt/bin/bin/qemu-system-i386 + +QEMU command line: +/mnt/bin/bin/qemu-system-i386 -xen-domid 28 -chardev socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-28,server,nowait -no-shutdown -mon chardev=libxl-cmd,mode=control -chardev socket,id=libxenstat-cmd,path=/var/run/xen/qmp-libxenstat-28,server,nowait -mon chardev=libxenstat-cmd,mode=control -nodefaults -no-user-config -name ubu_hvm -vnc 0.0.0.0:1,to=99 -display none -serial pty -device cirrus-vga,vgamem_mb=8 -boot order=c -smp 2,maxcpus=2 -device rtl8139,id=nic0,netdev=net0,mac=00:16:3e:74:34:32 -netdev type=tap,id=net0,ifname=vif28.0-emu,script=no,downscript=no -device rtl8139,id=nic1,netdev=net1,mac=00:16:3e:5f:48:e4 -netdev type=tap,id=net1,ifname=vif28.1-emu,script=no,downscript=no -machine xenfv -m 1504 -drive file=/mnt/10G.hdd,if=ide,index=0,media=disk,format=raw,cache=writeback + +Produce: +I run a fuzzer program in guest vm, it may set incorrect values for graphics registers, sequencer registers and other registers. + +Seeing the following error from /var/log/xen/qemu-dm-<vm-name>.log: +qemu-system-i386: hw/display/cirrus_vga.c:712: cirrus_invalidate_region: Assertion `off_cur_end >= off_cur' failed. + +I can reproduce it at anytime, if you need to gather more diagnostic information or try test patches, I'm happy to help. + + +gdb bt: +#0 0x00007f81a64f8c37 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 +#1 0x00007f81a64fc028 in __GI_abort () at abort.c:89 +#2 0x00007f81a64f1bf6 in __assert_fail_base (fmt=0x7f81a6646018 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", + assertion=assertion@entry=0x55d70cf8cdf2 "off_cur_end >= off_cur", file=file@entry=0x55d70cf8cda9 "hw/display/cirrus_vga.c", line=line@entry=712, + function=function@entry=0x55d70cf8db60 <__PRETTY_FUNCTION__.40643> "cirrus_invalidate_region") at assert.c:92 +#3 0x00007f81a64f1ca2 in __GI___assert_fail (assertion=0x55d70cf8cdf2 "off_cur_end >= off_cur", file=0x55d70cf8cda9 "hw/display/cirrus_vga.c", line=712, + function=0x55d70cf8db60 <__PRETTY_FUNCTION__.40643> "cirrus_invalidate_region") at assert.c:101 +#4 0x000055d70cb66445 in cirrus_invalidate_region (s=0x55d70ee3a4b0, off_begin=4190568, off_pitch=1842, bytesperline=5056, lines=2922) at hw/display/cirrus_vga.c:712 +#5 0x000055d70cb6660c in cirrus_bitblt_common_patterncopy (s=0x55d70ee3a4b0) at hw/display/cirrus_vga.c:752 +#6 0x000055d70cb6676d in cirrus_bitblt_videotovideo_patterncopy (s=0x55d70ee3a4b0) at hw/display/cirrus_vga.c:786 +#7 0x000055d70cb670c5 in cirrus_bitblt_videotovideo (s=0x55d70ee3a4b0) at hw/display/cirrus_vga.c:986 +#8 0x000055d70cb678bf in cirrus_bitblt_start (s=0x55d70ee3a4b0) at hw/display/cirrus_vga.c:1136 +#9 0x000055d70cb6880b in cirrus_vga_write_gr (s=0x55d70ee3a4b0, reg_index=42, reg_value=228) at hw/display/cirrus_vga.c:1652 +#10 0x000055d70cb6ab86 in cirrus_vga_ioport_write (opaque=0x55d70ee3a4b0, addr=975, val=228, size=1) at hw/display/cirrus_vga.c:2754 +#11 0x000055d70c91d9c0 in memory_region_write_accessor (mr=0x55d70ee4af70, addr=31, value=0x7fffdaaeaf38, size=1, shift=8, mask=255, attrs=...) + at /mnt/qemu/memory.c:560 +#12 0x000055d70c91dc3a in access_with_adjusted_size (addr=30, value=0x7fffdaaeaf38, size=2, access_size_min=1, access_size_max=1, + access_fn=0x55d70c91d8c9 <memory_region_write_accessor>, mr=0x55d70ee4af70, attrs=...) at /mnt/qemu/memory.c:627 +#13 0x000055d70c920f48 in memory_region_dispatch_write (mr=0x55d70ee4af70, addr=30, data=58410, size=2, attrs=...) at /mnt/qemu/memory.c:1503 +#14 0x000055d70c8c51e0 in flatview_write_continue (fv=0x55d70ecb66d0, addr=974, attrs=..., buf=0x7fffdaaeb0f0 "*\344W\026\377\177", len=4, addr1=30, l=2, + mr=0x55d70ee4af70) at /mnt/qemu/exec.c:2951 +#15 0x000055d70c8c5390 in flatview_write (fv=0x55d70ecb66d0, addr=974, attrs=..., buf=0x7fffdaaeb0f0 "*\344W\026\377\177", len=4) at /mnt/qemu/exec.c:3002 +#16 0x000055d70c8c5406 in address_space_write (as=0x55d70d70d5e0 <address_space_io>, addr=974, attrs=..., buf=0x7fffdaaeb0f0 "*\344W\026\377\177", len=4) + at /mnt/qemu/exec.c:3014 +#17 0x000055d70c914fb3 in cpu_outl (addr=974, val=374858794) at /mnt/qemu/ioport.c:81 +#18 0x000055d70ca0253f in do_outp (addr=974, size=4, val=374858794) at /mnt/qemu/hw/i386/xen/xen-hvm.c:782 +#19 0x000055d70ca02888 in cpu_ioreq_pio (req=0x7fffdaaeb210) at /mnt/qemu/hw/i386/xen/xen-hvm.c:852 +#20 0x000055d70ca02f2e in handle_ioreq (state=0x55d70e0cf3d0, req=0x7fffdaaeb210) at /mnt/qemu/hw/i386/xen/xen-hvm.c:961 +#21 0x000055d70ca0343e in cpu_handle_ioreq (opaque=0x55d70e0cf3d0) at /mnt/qemu/hw/i386/xen/xen-hvm.c:1089 +#22 0x000055d70ce75d69 in aio_dispatch_handlers (ctx=0x55d70e098550) at util/aio-posix.c:406 +#23 0x000055d70ce75f0b in aio_dispatch (ctx=0x55d70e098550) at util/aio-posix.c:437 +#24 0x000055d70ce70b46 in aio_ctx_dispatch (source=0x55d70e098550, callback=0x0, user_data=0x0) at util/async.c:261 +#25 0x00007f81a7215e04 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 +#26 0x000055d70ce74455 in glib_pollfds_poll () at util/main-loop.c:214 +#27 0x000055d70ce7456a in os_host_main_loop_wait (timeout=16061710) at util/main-loop.c:261 +#28 0x000055d70ce7463f in main_loop_wait (nonblocking=0) at util/main-loop.c:515 +#29 0x000055d70ca8e6a6 in main_loop () at vl.c:1995 +#30 0x000055d70ca96815 in main (argc=42, argv=0x7fffdaaeb888, envp=0x7fffdaaeb9e0) at vl.c:4897 + + + + Hi, + +> > -device cirrus-vga,vgamem_mb=8 + +Don't do that. cirrus has 4 MB video memory, like physical hardware +has. And you can't change that (i.e. the guest wouldn't be able to use +it if you assign more). The switch exists for live migration +compatibility only, because older qemu versions erroneously assigned +more than 4 MB to cirrus. + +I expect you can't trigger the assert any more if you remove +"vgamem_mb=8". + +cheers, + Gerd + + + +Hi Gerd, + +Xen toolstack uses 8 MB by default, see: +https://github.com/xen-project/xen/blob/staging/tools/libxl/libxl_create.c#L292 + +Now I change it to 4MB, QEMU command line: +/mnt/bin/bin/qemu-system-i386 -xen-domid 38 -chardev socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-38,server,nowait -no-shutdown -mon chardev=libxl-cmd,mode=control -chardev socket,id=libxenstat-cmd,path=/var/run/xen/qmp-libxenstat-38,server,nowait -mon chardev=libxenstat-cmd,mode=control -nodefaults -no-user-config -name ubu_hvm -vnc 0.0.0.0:1,to=99 -display none -serial pty -device cirrus-vga,vgamem_mb=4 -boot order=c -smp 2,maxcpus=2 -device rtl8139,id=nic0,netdev=net0,mac=00:16:3e:74:34:32 -netdev type=tap,id=net0,ifname=vif38.0-emu,script=no,downscript=no -device rtl8139,id=nic1,netdev=net1,mac=00:16:3e:5f:48:e4 -netdev type=tap,id=net1,ifname=vif38.1-emu,script=no,downscript=no -machine xenfv -m 1508 -drive file=/mnt/10G.hdd,if=ide,index=0,media=disk,format=raw,cache=writeback + +Run fuzzer program again and get two segfaults: + +(gdb) bt +#0 0x000055709265e647 in vga_draw_text (s=0x5570949744b0, full_update=1) at /mnt/qemu/hw/display/vga.c:1283 +#1 0x000055709265fd04 in vga_update_display (opaque=0x5570949744b0) at /mnt/qemu/hw/display/vga.c:1766 +#2 0x0000557092a13756 in graphic_hw_update (con=0x557094a7bb20) at ui/console.c:263 +#3 0x0000557092a27f8e in vnc_refresh (dcl=0x7fc1f688b070) at ui/vnc.c:2855 +#4 0x0000557092a1774e in dpy_refresh (s=0x557094a74c60) at ui/console.c:1594 +#5 0x0000557092a1344c in gui_update (opaque=0x557094a74c60) at ui/console.c:201 +#6 0x0000557092b7282a in timerlist_run_timers (timer_list=0x557093bd1800) at util/qemu-timer.c:536 +#7 0x0000557092b72895 in qemu_clock_run_timers (type=QEMU_CLOCK_REALTIME) at util/qemu-timer.c:547 +#8 0x0000557092b72d96 in qemu_clock_run_all_timers () at util/qemu-timer.c:662 +#9 0x0000557092b73666 in main_loop_wait (nonblocking=0) at util/main-loop.c:521 +#10 0x000055709278d6a6 in main_loop () at vl.c:1995 +#11 0x0000557092795815 in main (argc=42, argv=0x7fffd33f1eb8, envp=0x7fffd33f2010) at vl.c:4897 + +(gdb) bt +#0 __memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:36 +#1 0x000055bed7158e30 in vnc_refresh_server_surface (vd=0x7fb9acfc4010) at ui/vnc.c:2827 +#2 0x000055bed7158fc4 in vnc_refresh (dcl=0x7fb9acfc4070) at ui/vnc.c:2862 +#3 0x000055bed714874e in dpy_refresh (s=0x55bed95d5c60) at ui/console.c:1594 +#4 0x000055bed714444c in gui_update (opaque=0x55bed95d5c60) at ui/console.c:201 +#5 0x000055bed72a382a in timerlist_run_timers (timer_list=0x55bed8732800) at util/qemu-timer.c:536 +#6 0x000055bed72a3895 in qemu_clock_run_timers (type=QEMU_CLOCK_REALTIME) at util/qemu-timer.c:547 +#7 0x000055bed72a3d96 in qemu_clock_run_all_timers () at util/qemu-timer.c:662 +#8 0x000055bed72a4666 in main_loop_wait (nonblocking=0) at util/main-loop.c:521 +#9 0x000055bed6ebe6a6 in main_loop () at vl.c:1995 +#10 0x000055bed6ec6815 in main (argc=42, argv=0x7ffd8134a6c8, envp=0x7ffd8134a820) at vl.c:4897 + +Attached gdb full backtrace. + +Hi Gerd, + +Would you please take a look at this patch, testing shows it prevents these crashes. I'm not an expert, just to give you more information. + +I cannot public the fuzzer program, if you need to gather more diagnostic information or try test patches, I'm happy to help. + + +diff --git a/hw/display/vga.c b/hw/display/vga.c +index 1d19f6b..ab6cd47 100644 +--- a/hw/display/vga.c ++++ b/hw/display/vga.c +@@ -1240,6 +1240,24 @@ static void vga_draw_text(VGACommonState *s, int full_update) + palette = s->last_palette; + x_incr = cw * surface_bytes_per_pixel(surface); + ++ /* ++ * In theory, line_offset = width * 4, if line_offset is ++ * less than width * 4, then afterwards, memory operation ++ * on server surface might overflow ++ */ ++ if (s->line_offset < 4 * width) { ++ s->line_offset = 4 * width; ++ line_offset = s->line_offset; ++ } ++ ++ /* ++ * The above if statement might introduce overflow since it ++ * might increase s->line_offset ++ */ ++ if (s->start_addr * 4 + line_offset * height >= s->vram_size) { ++ height = (s->vram_size - 1 - s->start_addr * 4) / line_offset; ++ } ++ + if (full_update) { + s->full_update_text = 1; + } +@@ -1464,7 +1482,7 @@ static void vga_draw_graphic(VGACommonState *s, int full_update) + { + DisplaySurface *surface = qemu_console_surface(s->con); + int y1, y, update, linesize, y_start, double_scan, mask, depth; +- int width, height, shift_control, bwidth, bits; ++ int width, height, shift_control, bwidth, bits, bpp; + ram_addr_t page0, page1, region_start, region_end; + DirtyBitmapSnapshot *snap = NULL; + int disp_width, multi_scan, multi_run; +@@ -1522,6 +1540,13 @@ static void vga_draw_graphic(VGACommonState *s, int full_update) + } + + depth = s->get_bpp(s); ++ bpp = depth / 8; ++ if (s->line_offset < disp_width * bpp) { ++ s->line_offset = disp_width * bpp; ++ } ++ if (s->start_addr * 4 + s->line_offset * height >= s->vram_size) { ++ height = (s->vram_size - 1 - s->start_addr * 4) / s->line_offset; ++ } + + /* + * Check whether we can share the surface with the backend +@@ -1717,7 +1742,7 @@ static void vga_draw_graphic(VGACommonState *s, int full_update) + static void vga_draw_blank(VGACommonState *s, int full_update) + { + DisplaySurface *surface = qemu_console_surface(s->con); +- int i, w; ++ int i, h, w; + uint8_t *d; + + if (!full_update) +@@ -1727,12 +1752,16 @@ static void vga_draw_blank(VGACommonState *s, int full_update) + + w = s->last_scr_width * surface_bytes_per_pixel(surface); + d = surface_data(surface); ++ if (w > surface_stride(surface)) { ++ w = surface_stride(surface); ++ } ++ h = MIN(s->last_scr_height, surface_height(surface)); + for(i = 0; i < s->last_scr_height; i++) { + memset(d, 0, w); + d += surface_stride(surface); + } + dpy_gfx_update(s->con, 0, 0, +- s->last_scr_width, s->last_scr_height); ++ w, h); + } + + #define GMODE_TEXT 0 + + + + +Hi Gerd, + +Any chance to have a look? + +This issue still can be reproduced with the latest code. +(commit 281f327487c9c9b1599f93c589a408bbf4a651b8) + +Please check the attachment for full gdb backtrace. + +The issue has been fixed: http://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg02174.html + + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=7cdc61becd095b64a78 + diff --git a/results/classifier/105/mistranslation/1730101 b/results/classifier/105/mistranslation/1730101 new file mode 100644 index 000000000..fbb5b05f4 --- /dev/null +++ b/results/classifier/105/mistranslation/1730101 @@ -0,0 +1,23 @@ +mistranslation: 0.925 +device: 0.893 +boot: 0.815 +graphic: 0.810 +instruction: 0.783 +other: 0.669 +semantic: 0.623 +network: 0.512 +socket: 0.415 +vnc: 0.411 +assembly: 0.250 +KVM: 0.047 + +The guest is only starting after its SDL window gets focus + +I’m using i3wm and have workspace assigning rules that make QEMU’s SDL window be assigned to a workspace I don’t really switch to. + +When I run start a guest machine, its SDL window is moved to that workspace (I never see it); but the machine freezes after displaying that black window. It only starts booting after I switch to the workspace and view the window. + +Which version of SDL have you been using here? SDL 1.2 or SDL 2.0? If you were using 1.2, could you please try with 2.0 instead? Support for 1.2 has been removed now. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1731277 b/results/classifier/105/mistranslation/1731277 new file mode 100644 index 000000000..d7443f8b2 --- /dev/null +++ b/results/classifier/105/mistranslation/1731277 @@ -0,0 +1,54 @@ +mistranslation: 0.822 +graphic: 0.822 +other: 0.776 +device: 0.748 +semantic: 0.696 +instruction: 0.635 +socket: 0.568 +vnc: 0.535 +network: 0.469 +assembly: 0.394 +KVM: 0.391 +boot: 0.355 + +Provide target specific qemu man pages + +Right now, all qemu target binaries (qemu-system-...) share the same man page. + +The current man page is primarily focused on x86, and therefore the information given is entirely wrong for e.g. arm, powerpc or s390x. + +NAME + qemu-doc - QEMU Emulator User Documentation + +SYNOPSIS + qemu-system-i386 [options] [disk_image] + +DESCRIPTION + The QEMU PC System emulator simulates the following peripherals: + + - i440FX host PCI bridge and PIIX3 PCI to ISA bridge + + - Cirrus CLGD 5446 PCI VGA card or dummy VGA card with Bochs VESA extensions (hardware level, including all non + standard modes). + + - PS/2 mouse and keyboard + + - 2 PCI IDE interfaces with hard disk and CD-ROM support + + - Floppy disk + +... + +We should have target specific man pages, with the common options/settings factored out, so they are included in all target specific man pages. + +"man qemu-system-s390x" should give s390x specific (+common) information and "man qemu-system-x86_64" should contain x86 specific (+common) information. + +I'm kind of hoping that moving to Sphinx for our docs toolchain will allow us to for instance have the board specific information in doc comments in each board source file, which could then be automatically assembled into the right documentation. The current manpages are autobuilt from the monolithic qemu-doc.texi, which is woefully out of date in many areas... + + +The QEMU project is currently considering to move 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 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/105/mistranslation/1735 b/results/classifier/105/mistranslation/1735 new file mode 100644 index 000000000..f7ad04caa --- /dev/null +++ b/results/classifier/105/mistranslation/1735 @@ -0,0 +1,42 @@ +mistranslation: 0.657 +vnc: 0.643 +network: 0.415 +device: 0.391 +graphic: 0.338 +assembly: 0.330 +socket: 0.293 +other: 0.290 +KVM: 0.288 +instruction: 0.233 +boot: 0.219 +semantic: 0.168 + +[riscv-pmp] Pmp_hart_has_privs local variable name easily misunderstood +Additional information: +```c +// int => bool +static int pmp_is_in_range(CPURISCVState *env, int pmp_index, + target_ulong addr); + +bool pmp_hart_has_privs(CPURISCVState *env, target_ulong addr, + target_ulong size, pmp_priv_t privs, + pmp_priv_t *allowed_privs, target_ulong mode) +{ + int i = 0; + int pmp_size = 0; + // easily misunderstood local variable + target_ulong s = 0; + target_ulong e = 0; + + for (i = 0; i < MAX_RISCV_PMPS; i++) { + s = pmp_is_in_range(env, i, addr); + e = pmp_is_in_range(env, i, addr + pmp_size - 1); + + /* partially inside */ + if ((s + e) == 1) { + + } + + /* fully inside */ + if ((s + e) == 2) { +``` diff --git a/results/classifier/105/mistranslation/1736376 b/results/classifier/105/mistranslation/1736376 new file mode 100644 index 000000000..f23a71ece --- /dev/null +++ b/results/classifier/105/mistranslation/1736376 @@ -0,0 +1,29 @@ +mistranslation: 0.802 +device: 0.522 +graphic: 0.481 +semantic: 0.478 +network: 0.462 +instruction: 0.435 +vnc: 0.368 +other: 0.334 +socket: 0.326 +boot: 0.240 +assembly: 0.116 +KVM: 0.024 + +CVE-2017-7471 repeated? + +In the hw/9pfs/9p-proxy.c file I can see the following which is changed because of CVE-2017-7471 in the hw/9pfs/9p-local.c. I might be wrong but I guess that should be changed as well. + +if(dir_path){ +v9fs_path_sprintf(target,"%s/%s",dir_path->data,name); +} +else{ +v9fs_path_sprintf(target,"%s",name); +} + +When using the proxy backend, all accesses to the host filesystem are handled by an external process running in a chroot() jail. No need to bother about paths in this case. + +CVE-2017-7471 is only applicable to the local backend, because accesses are handled by QEMU directly in this case. + + diff --git a/results/classifier/105/mistranslation/1743214 b/results/classifier/105/mistranslation/1743214 new file mode 100644 index 000000000..c508369b4 --- /dev/null +++ b/results/classifier/105/mistranslation/1743214 @@ -0,0 +1,62 @@ +mistranslation: 0.894 +boot: 0.853 +KVM: 0.852 +device: 0.772 +assembly: 0.731 +instruction: 0.720 +other: 0.662 +graphic: 0.655 +semantic: 0.586 +socket: 0.535 +vnc: 0.523 +network: 0.445 + +OS/2 Warp 3 support broken in 2.11 + +Hello, I used to run OS/2 Warp 3 on QEMU with the following command line: qemu-system-i386 -vga cirrus -soundhw sb16 -hda os2warp3v2.img -boot c. It runs OK on QEMU 2.10, but immediately gives TRAP 0006 (invalid opcode?) on QEMU 2.11 (see screenshot). +If it is important I have Fixpack 40 and GRADD installed in OS/2. +Here is the image: +https://drive.google.com/open?id=15umPecy7JlPLKUP6520MB_87CfrCDWO5 + + + +On Sun, 14 Jan 2018, MVoloshin wrote: +> Hello, I used to run OS/2 Warp 3 on QEMU with the following command +> line: qemu-system-i386 -vga cirrus -soundhw sb16 -hda os2warp3v2.img +> -boot c. It runs OK on QEMU 2.10, but immediately gives TRAP 0006 +> (invalid opcode?) on QEMU 2.11 (see screenshot). +> +> If it is important I have Fixpack 40 and GRADD installed in OS/2. +> Here is the image: +> https://drive.google.com/open?id=15umPecy7JlPLKUP6520MB_87CfrCDWO5 + +This image boots for me without problem with latest version from git so +either it's already fixed or the problem is elsewhere. Can you try latest +git version? If it still does not work with that maybe you need to provide +more details, like configure options or what host arch/OS are you on. + + + +I used QEMU 2.11 for Windows from Stephan Weil (http://qemu.weilnetz.de/). I have Windows 10 (v1709) x64. + +On Sun, 14 Jan 2018, Stefan Weil wrote: +> Zoltan, did you run the test with KVM enabled? +> +> I get a crash when I run the image with latest QEMU on Linux with TCG. + +No, I've used the same command as in the bug report. Now I've retried with +explicit -M pc,accel=tcg and -M pc,accel=kvm and it boots without problem +for me both ways on Linux. If it crashes for you maybe you could try +bisecting, that's what I was trying to do to help but I can't reproduce +it. + +Regards, +BALATON Zoltan + +It looks like this bug affects only QEMU for Windows. + +The QEMU project is currently considering to move 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 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/105/mistranslation/1753 b/results/classifier/105/mistranslation/1753 new file mode 100644 index 000000000..5b62d3912 --- /dev/null +++ b/results/classifier/105/mistranslation/1753 @@ -0,0 +1,16 @@ +mistranslation: 0.902 +device: 0.890 +graphic: 0.885 +network: 0.853 +semantic: 0.851 +assembly: 0.791 +other: 0.736 +vnc: 0.601 +boot: 0.498 +socket: 0.439 +KVM: 0.437 +instruction: 0.224 + +Does the qemu have luks2 support? +Description of problem: +Does the qemu have luks2 support? diff --git a/results/classifier/105/mistranslation/1753437 b/results/classifier/105/mistranslation/1753437 new file mode 100644 index 000000000..8a5894522 --- /dev/null +++ b/results/classifier/105/mistranslation/1753437 @@ -0,0 +1,61 @@ +mistranslation: 0.580 +device: 0.438 +semantic: 0.409 +socket: 0.362 +vnc: 0.279 +other: 0.271 +instruction: 0.270 +network: 0.249 +graphic: 0.217 +boot: 0.176 +assembly: 0.119 +KVM: 0.102 + +pc-bios/s390-ccw/libc: size_t should be unsigned + +qemu/pc-bios/s390-ccw/libc.c:82]: (style) Unsigned variable 'num_idx' can't be negative so it is unnecessary to test it. + +Source code is + + + while (num_idx >= 0) { + +but + + size_t num_idx = 1; /* account for NUL */ + +So there is no escape from the while loop. + +Adding qemu-s390x. + +On 03/05/2018 11:31 AM, dcb wrote: +> Public bug reported: +> +> qemu/pc-bios/s390-ccw/libc.c:82]: (style) Unsigned variable 'num_idx' +> can't be negative so it is unnecessary to test it. +> +> Source code is +> +> +> while (num_idx >= 0) { +> +> but +> +> size_t num_idx = 1; /* account for NUL */ +> +> So there is no escape from the while loop. +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> + + + +Looks like the mailing list <-> launchpad bridge again ignored mails to the corresponding mailing list thread. It's not a real bug, see here for details: +https://lists.gnu.org/archive/html/qemu-devel/2018-03/msg01142.html +I'll try to remember to clean this up the next time we update the s390-ccw bios. + +Fix has been committed: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=e4f869621203955761c + diff --git a/results/classifier/105/mistranslation/1754542 b/results/classifier/105/mistranslation/1754542 new file mode 100644 index 000000000..361eaf10b --- /dev/null +++ b/results/classifier/105/mistranslation/1754542 @@ -0,0 +1,2018 @@ +mistranslation: 0.554 +other: 0.552 +device: 0.482 +KVM: 0.468 +vnc: 0.464 +instruction: 0.449 +graphic: 0.446 +semantic: 0.439 +boot: 0.399 +assembly: 0.388 +network: 0.378 +socket: 0.314 + +colo: vm crash with segmentation fault + +I use Arch Linux x86_64 +both qemu 2.11.1 Zhang Chen's(https://github.com/zhangckid/qemu/commits/colo-with-virtio-net-internal-jul10) +Following document 'COLO-FT.txt', +I test colo feature on my hosts + +I run this command +Primary: +sudo qemu-system-x86_64 -boot c -enable-kvm -m 2048 -smp 2 -qmp stdio -name primary \ +-device piix3-usb-uhci \ +-device usb-tablet -netdev tap,id=hn0,vhost=off \ +-device virtio-net-pci,id=net-pci0,netdev=hn0 \ +-drive if=virtio,id=colo-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,children.0.file.filename=/var/lib/libvirt/images/1.raw,children.0.driver=raw -S + +Secondary: +sudo qemu-system-x86_64 -boot c -enable-kvm -m 2048 -smp 2 -qmp stdio -name secondary \ +-device piix3-usb-uhci \ +-device usb-tablet -netdev tap,id=hn0,vhost=off \ +-device virtio-net-pci,id=net-pci0,netdev=hn0 \ +-drive if=none,id=colo-disk0,file.filename=/var/lib/libvirt/images/2.raw,driver=raw,node-name=node0 \ +-drive if=virtio,id=active-disk0,driver=replication,mode=secondary,\ +file.driver=qcow2,top-id=active-disk0,\ +file.file.filename=/mnt/ramfs/active_disk.img,\ +file.backing.driver=qcow2,\ +file.backing.file.filename=/mnt/ramfs/hidden_disk.img,\ +file.backing.backing=colo-disk0 \ +-incoming tcp:0:8888 + +Secondary: +{'execute':'qmp_capabilities'} +{ 'execute': 'nbd-server-start', + 'arguments': {'addr': {'type': 'inet', 'data': {'host': '192.168.0.33', 'port': '8889'} } } +} +{'execute': 'nbd-server-add', 'arguments': {'device': 'colo-disk0', 'writable': true } } + +Primary: +{'execute':'qmp_capabilities'} +{ 'execute': 'human-monitor-command', + 'arguments': {'command-line': 'drive_add -n buddy driver=replication,mode=primary,file.driver=nbd,file.host=192.168.0.33,file.port=8889,file.export=colo-disk0,node-name=nbd_client0'}} +{ 'execute':'x-blockdev-change', 'arguments':{'parent': 'colo-disk0', 'node': 'nbd_client0' } } +{ 'execute': 'migrate-set-capabilities', + 'arguments': {'capabilities': [ {'capability': 'x-colo', 'state': true } ] } } +{ 'execute': 'migrate', 'arguments': {'uri': 'tcp:192.168.0.33:8888' } } +{ 'execute': 'migrate-set-parameters' , 'arguments':{ 'x-checkpoint-delay': 2000 } } + +Above are all OK.Two VM syncing. + +Primary: +{ 'execute': 'x-blockdev-change', 'arguments': {'parent': 'colo-disk0', 'child': 'children.1'}} +{ 'execute': 'human-monitor-command','arguments': {'command-line': 'drive_del blk-buddy0'}} + +Secondary: +{ 'execute': 'nbd-server-stop' } +{ 'execute': 'x-colo-lost-heartbeat' } + +But When I execute x-colo-lost-heartbeat.Primary run Secondary cash + + + { 'execute': 'nbd-server-stop' } +{"return": {}} +qemu-system-x86_64: Disconnect client, due to: Unexpected end-of-file before all bytes were read + { 'execute': 'x-colo-lost-heartbeat' } +{"return": {}} +qemu-system-x86_64: Can't receive COLO message: Input/output error +** +ERROR:/build/qemu/src/qemu-2.11.1/qom/object.c:907:object_unref: assertion failed (obj->ref > 0): (0 > 0) +[1] 2972 abort sudo /usr/bin/qemu-system-x86_64 -boot c -enable-kvm -m 2048 -smp 2 -qmp stdi + +Hi Suiheng, + +Sorry for slow reply, the document 'COLO-FT.txt' in qemu is out of date, I +will update it lately. +Please follow this step to run COLO(the command has been changed). +https://wiki.qemu.org/Features/COLO + +Thanks +Zhang Chen + + + +On Fri, Mar 9, 2018 at 10:54 AM, 李穗恒 <email address hidden> wrote: + +> Public bug reported: +> +> I use Arch Linux x86_64 +> both qemu 2.11.1 and Zhang Chen's(https://github.com/ +> zhangckid/qemu/commits/colo-with-virtio-net-internal-jul10) +> Following document 'COLO-FT.txt', +> I test colo feature on my hosts +> +> I run this command +> Primary: +> sudo qemu-system-x86_64 -boot c -enable-kvm -m 2048 -smp 2 -qmp stdio +> -name primary \ +> -device piix3-usb-uhci \ +> -device usb-tablet -netdev tap,id=hn0,vhost=off \ +> -device virtio-net-pci,id=net-pci0,netdev=hn0 \ +> -drive if=virtio,id=colo-disk0,driver=quorum,read-pattern= +> fifo,vote-threshold=1,children.0.file.filename=/var/ +> lib/libvirt/images/1.raw,children.0.driver=raw -S +> +> Secondary: +> sudo qemu-system-x86_64 -boot c -enable-kvm -m 2048 -smp 2 -qmp stdio +> -name secondary \ +> -device piix3-usb-uhci \ +> -device usb-tablet -netdev tap,id=hn0,vhost=off \ +> -device virtio-net-pci,id=net-pci0,netdev=hn0 \ +> -drive if=none,id=colo-disk0,file.filename=/var/lib/libvirt/ +> images/2.raw,driver=raw,node-name=node0 \ +> -drive if=virtio,id=active-disk0,driver=replication,mode=secondary,\ +> file.driver=qcow2,top-id=active-disk0,\ +> file.file.filename=/mnt/ramfs/active_disk.img,\ +> file.backing.driver=qcow2,\ +> file.backing.file.filename=/mnt/ramfs/hidden_disk.img,\ +> file.backing.backing=colo-disk0 \ +> -incoming tcp:0:8888 +> +> Secondary: +> {'execute':'qmp_capabilities'} +> { 'execute': 'nbd-server-start', +> 'arguments': {'addr': {'type': 'inet', 'data': {'host': '192.168.0.33', +> 'port': '8889'} } } +> } +> {'execute': 'nbd-server-add', 'arguments': {'device': 'colo-disk0', +> 'writable': true } } +> +> Primary: +> {'execute':'qmp_capabilities'} +> { 'execute': 'human-monitor-command', +> 'arguments': {'command-line': 'drive_add -n buddy +> driver=replication,mode=primary,file.driver=nbd,file. +> host=192.168.0.34,file.port=8889,file.export=colo-disk0, +> node-name=nbd_client0'}} +> { 'execute':'x-blockdev-change', 'arguments':{'parent': 'colo-disk0', +> 'node': 'nbd_client0' } } +> { 'execute': 'migrate-set-capabilities', +> 'arguments': {'capabilities': [ {'capability': 'x-colo', 'state': +> true } ] } } +> { 'execute': 'migrate', 'arguments': {'uri': 'tcp:192.168.0.34:8888' } } +> { 'execute': 'migrate-set-parameters' , 'arguments':{ +> 'x-checkpoint-delay': 2000 } } +> +> Above are all OK.Two VM syncing. +> +> Primary: +> { 'execute': 'x-blockdev-change', 'arguments': {'parent': 'colo-disk0', +> 'child': 'children.1'}} +> { 'execute': 'human-monitor-command','arguments': {'command-line': +> 'drive_del blk-buddy0'}} +> +> Secondary: +> { 'execute': 'nbd-server-stop' } +> { 'execute': 'x-colo-lost-heartbeat' } +> +> But When I execute x-colo-lost-heartbeat.Primary run Secondary cash +> +> { 'execute': 'nbd-server-stop' } +> {"return": {}} +> qemu-system-x86_64: Disconnect client, due to: Unexpected end-of-file +> before all bytes were read +> { 'execute': 'x-colo-lost-heartbeat' } +> {"return": {}} +> qemu-system-x86_64: Can't receive COLO message: Input/output error +> ** +> ERROR:/build/qemu/src/qemu-2.11.1/qom/object.c:907:object_unref: +> assertion failed (obj->ref > 0): (0 > 0) +> [1] 2972 abort sudo /usr/bin/qemu-system-x86_64 -boot c +> -enable-kvm -m 2048 -smp 2 -qmp stdi +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> +> ** Tags: colo +> +> ** Description changed: +> +> I use Arch Linux x86_64 +> - both qemu 2.11.1 Zhang Chen's(https://github.com/ +> zhangckid/qemu/commits/colo-with-virtio-net-internal-jul10) +> + both qemu 2.11.1 and Zhang Chen's(https://github.com/ +> zhangckid/qemu/commits/colo-with-virtio-net-internal-jul10) +> Following document 'COLO-FT.txt', +> I test colo feature on my hosts +> +> I run this command +> Primary: +> sudo qemu-system-x86_64 -boot c -enable-kvm -m 2048 -smp 2 -qmp +> stdio -name primary \ +> -device piix3-usb-uhci \ +> -device usb-tablet -netdev tap,id=hn0,vhost=off \ +> -device virtio-net-pci,id=net-pci0,netdev=hn0 \ +> -drive if=virtio,id=colo-disk0,driver=quorum,read-pattern= +> fifo,vote-threshold=1,children.0.file.filename=/var/ +> lib/libvirt/images/1.raw,children.0.driver=raw -S +> +> Secondary: +> sudo qemu-system-x86_64 -boot c -enable-kvm -m 2048 -smp 2 -qmp stdio +> -name secondary \ +> -device piix3-usb-uhci \ +> -device usb-tablet -netdev tap,id=hn0,vhost=off \ +> -device virtio-net-pci,id=net-pci0,netdev=hn0 \ +> -drive if=none,id=colo-disk0,file.filename=/var/lib/libvirt/ +> images/2.raw,driver=raw,node-name=node0 \ +> -drive if=virtio,id=active-disk0,driver=replication,mode=secondary,\ +> file.driver=qcow2,top-id=active-disk0,\ +> file.file.filename=/mnt/ramfs/active_disk.img,\ +> file.backing.driver=qcow2,\ +> file.backing.file.filename=/mnt/ramfs/hidden_disk.img,\ +> file.backing.backing=colo-disk0 \ +> -incoming tcp:0:8888 +> +> Secondary: +> {'execute':'qmp_capabilities'} +> { 'execute': 'nbd-server-start', +> - 'arguments': {'addr': {'type': 'inet', 'data': {'host': +> '192.168.0.33', 'port': '8889'} } } +> + 'arguments': {'addr': {'type': 'inet', 'data': {'host': +> '192.168.0.33', 'port': '8889'} } } +> } +> {'execute': 'nbd-server-add', 'arguments': {'device': 'colo-disk0', +> 'writable': true } } +> +> Primary: +> {'execute':'qmp_capabilities'} +> { 'execute': 'human-monitor-command', +> - 'arguments': {'command-line': 'drive_add -n buddy +> driver=replication,mode=primary,file.driver=nbd,file. +> host=192.168.0.33,file.port=8889,file.export=colo-disk0, +> node-name=nbd_client0'}} +> + 'arguments': {'command-line': 'drive_add -n buddy +> driver=replication,mode=primary,file.driver=nbd,file. +> host=192.168.0.33,file.port=8889,file.export=colo-disk0, +> node-name=nbd_client0'}} +> { 'execute':'x-blockdev-change', 'arguments':{'parent': 'colo-disk0', +> 'node': 'nbd_client0' } } +> { 'execute': 'migrate-set-capabilities', +> - 'arguments': {'capabilities': [ {'capability': 'x-colo', 'state': +> true } ] } } +> + 'arguments': {'capabilities': [ {'capability': 'x-colo', 'state': +> true } ] } } +> { 'execute': 'migrate', 'arguments': {'uri': 'tcp:192.168.0.33:8888' } } +> { 'execute': 'migrate-set-parameters' , 'arguments':{ +> 'x-checkpoint-delay': 2000 } } +> +> Above are all OK.Two VM syncing. +> +> Primary: +> { 'execute': 'x-blockdev-change', 'arguments': {'parent': 'colo-disk0', +> 'child': 'children.1'}} +> { 'execute': 'human-monitor-command','arguments': {'command-line': +> 'drive_del blk-buddy0'}} +> +> Secondary: +> { 'execute': 'nbd-server-stop' } +> { 'execute': 'x-colo-lost-heartbeat' } +> +> But When I execute x-colo-lost-heartbeat.Primary run Secondary cash +> +> - +> - { 'execute': 'nbd-server-stop' } +> + { 'execute': 'nbd-server-stop' } +> {"return": {}} +> qemu-system-x86_64: Disconnect client, due to: Unexpected end-of-file +> before all bytes were read +> - { 'execute': 'x-colo-lost-heartbeat' } +> + { 'execute': 'x-colo-lost-heartbeat' } +> {"return": {}} +> qemu-system-x86_64: Can't receive COLO message: Input/output error +> ** +> ERROR:/build/qemu/src/qemu-2.11.1/qom/object.c:907:object_unref: +> assertion failed (obj->ref > 0): (0 > 0) +> [1] 2972 abort sudo /usr/bin/qemu-system-x86_64 -boot c +> -enable-kvm -m 2048 -smp 2 -qmp stdi +> +> ** Tags added: colo +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1754542 +> +> Title: +> colo: secondary vm crash when execute x-colo-lost-heartbeat +> +> Status in QEMU: +> New +> +> Bug description: +> I use Arch Linux x86_64 +> both qemu 2.11.1 and Zhang Chen's(https://github.com/ +> zhangckid/qemu/commits/colo-with-virtio-net-internal-jul10) +> Following document 'COLO-FT.txt', +> I test colo feature on my hosts +> +> I run this command +> Primary: +> sudo qemu-system-x86_64 -boot c -enable-kvm -m 2048 -smp 2 -qmp +> stdio -name primary \ +> -device piix3-usb-uhci \ +> -device usb-tablet -netdev tap,id=hn0,vhost=off \ +> -device virtio-net-pci,id=net-pci0,netdev=hn0 \ +> -drive if=virtio,id=colo-disk0,driver=quorum,read-pattern= +> fifo,vote-threshold=1,children.0.file.filename=/var/ +> lib/libvirt/images/1.raw,children.0.driver=raw -S +> +> Secondary: +> sudo qemu-system-x86_64 -boot c -enable-kvm -m 2048 -smp 2 -qmp stdio +> -name secondary \ +> -device piix3-usb-uhci \ +> -device usb-tablet -netdev tap,id=hn0,vhost=off \ +> -device virtio-net-pci,id=net-pci0,netdev=hn0 \ +> -drive if=none,id=colo-disk0,file.filename=/var/lib/libvirt/ +> images/2.raw,driver=raw,node-name=node0 \ +> -drive if=virtio,id=active-disk0,driver=replication,mode=secondary,\ +> file.driver=qcow2,top-id=active-disk0,\ +> file.file.filename=/mnt/ramfs/active_disk.img,\ +> file.backing.driver=qcow2,\ +> file.backing.file.filename=/mnt/ramfs/hidden_disk.img,\ +> file.backing.backing=colo-disk0 \ +> -incoming tcp:0:8888 +> +> Secondary: +> {'execute':'qmp_capabilities'} +> { 'execute': 'nbd-server-start', +> 'arguments': {'addr': {'type': 'inet', 'data': {'host': +> '192.168.0.33', 'port': '8889'} } } +> } +> {'execute': 'nbd-server-add', 'arguments': {'device': 'colo-disk0', +> 'writable': true } } +> +> Primary: +> {'execute':'qmp_capabilities'} +> { 'execute': 'human-monitor-command', +> 'arguments': {'command-line': 'drive_add -n buddy +> driver=replication,mode=primary,file.driver=nbd,file. +> host=192.168.0.34,file.port=8889,file.export=colo-disk0, +> node-name=nbd_client0'}} +> { 'execute':'x-blockdev-change', 'arguments':{'parent': 'colo-disk0', +> 'node': 'nbd_client0' } } +> { 'execute': 'migrate-set-capabilities', +> 'arguments': {'capabilities': [ {'capability': 'x-colo', 'state': +> true } ] } } +> { 'execute': 'migrate', 'arguments': {'uri': 'tcp:192.168.0.34:8888' } } +> { 'execute': 'migrate-set-parameters' , 'arguments':{ +> 'x-checkpoint-delay': 2000 } } +> +> Above are all OK.Two VM syncing. +> +> Primary: +> { 'execute': 'x-blockdev-change', 'arguments': {'parent': 'colo-disk0', +> 'child': 'children.1'}} +> { 'execute': 'human-monitor-command','arguments': {'command-line': +> 'drive_del blk-buddy0'}} +> +> Secondary: +> { 'execute': 'nbd-server-stop' } +> { 'execute': 'x-colo-lost-heartbeat' } +> +> But When I execute x-colo-lost-heartbeat.Primary run Secondary cash +> +> { 'execute': 'nbd-server-stop' } +> {"return": {}} +> qemu-system-x86_64: Disconnect client, due to: Unexpected end-of-file +> before all bytes were read +> { 'execute': 'x-colo-lost-heartbeat' } +> {"return": {}} +> qemu-system-x86_64: Can't receive COLO message: Input/output error +> ** +> ERROR:/build/qemu/src/qemu-2.11.1/qom/object.c:907:object_unref: +> assertion failed (obj->ref > 0): (0 > 0) +> [1] 2972 abort sudo /usr/bin/qemu-system-x86_64 -boot c +> -enable-kvm -m 2048 -smp 2 -qmp stdi +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1754542/+subscriptions +> +> + + + Hi Suiheng, + +Sorry for slow reply, the document 'COLO-FT.txt' in qemu is out of date, I +will update it lately. +Please follow this step to run COLO(the command has been changed). +https://wiki.qemu.org/Features/COLO + +Thanks +Zhang Chen + +On Fri, Mar 9, 2018 at 10:54 AM, 李穗恒 <email address hidden> wrote: + +> Public bug reported: +> +> I use Arch Linux x86_64 +> both qemu 2.11.1 and Zhang Chen's(https://github.com/ +> zhangckid/qemu/commits/colo-with-virtio-net-internal-jul10) +> Following document 'COLO-FT.txt', +> I test colo feature on my hosts +> +> I run this command +> Primary: +> sudo qemu-system-x86_64 -boot c -enable-kvm -m 2048 -smp 2 -qmp stdio +> -name primary \ +> -device piix3-usb-uhci \ +> -device usb-tablet -netdev tap,id=hn0,vhost=off \ +> -device virtio-net-pci,id=net-pci0,netdev=hn0 \ +> -drive if=virtio,id=colo-disk0,driver=quorum,read-pattern= +> fifo,vote-threshold=1,children.0.file.filename=/var/ +> lib/libvirt/images/1.raw,children.0.driver=raw -S +> +> Secondary: +> sudo qemu-system-x86_64 -boot c -enable-kvm -m 2048 -smp 2 -qmp stdio +> -name secondary \ +> -device piix3-usb-uhci \ +> -device usb-tablet -netdev tap,id=hn0,vhost=off \ +> -device virtio-net-pci,id=net-pci0,netdev=hn0 \ +> -drive if=none,id=colo-disk0,file.filename=/var/lib/libvirt/ +> images/2.raw,driver=raw,node-name=node0 \ +> -drive if=virtio,id=active-disk0,driver=replication,mode=secondary,\ +> file.driver=qcow2,top-id=active-disk0,\ +> file.file.filename=/mnt/ramfs/active_disk.img,\ +> file.backing.driver=qcow2,\ +> file.backing.file.filename=/mnt/ramfs/hidden_disk.img,\ +> file.backing.backing=colo-disk0 \ +> -incoming tcp:0:8888 +> +> Secondary: +> {'execute':'qmp_capabilities'} +> { 'execute': 'nbd-server-start', +> 'arguments': {'addr': {'type': 'inet', 'data': {'host': '192.168.0.33', +> 'port': '8889'} } } +> } +> {'execute': 'nbd-server-add', 'arguments': {'device': 'colo-disk0', +> 'writable': true } } +> +> Primary: +> {'execute':'qmp_capabilities'} +> { 'execute': 'human-monitor-command', +> 'arguments': {'command-line': 'drive_add -n buddy +> driver=replication,mode=primary,file.driver=nbd,file. +> host=192.168.0.34,file.port=8889,file.export=colo-disk0, +> node-name=nbd_client0'}} +> { 'execute':'x-blockdev-change', 'arguments':{'parent': 'colo-disk0', +> 'node': 'nbd_client0' } } +> { 'execute': 'migrate-set-capabilities', +> 'arguments': {'capabilities': [ {'capability': 'x-colo', 'state': +> true } ] } } +> { 'execute': 'migrate', 'arguments': {'uri': 'tcp:192.168.0.34:8888' } } +> { 'execute': 'migrate-set-parameters' , 'arguments':{ +> 'x-checkpoint-delay': 2000 } } +> +> Above are all OK.Two VM syncing. +> +> Primary: +> { 'execute': 'x-blockdev-change', 'arguments': {'parent': 'colo-disk0', +> 'child': 'children.1'}} +> { 'execute': 'human-monitor-command','arguments': {'command-line': +> 'drive_del blk-buddy0'}} +> +> Secondary: +> { 'execute': 'nbd-server-stop' } +> { 'execute': 'x-colo-lost-heartbeat' } +> +> But When I execute x-colo-lost-heartbeat.Primary run Secondary cash +> +> { 'execute': 'nbd-server-stop' } +> {"return": {}} +> qemu-system-x86_64: Disconnect client, due to: Unexpected end-of-file +> before all bytes were read +> { 'execute': 'x-colo-lost-heartbeat' } +> {"return": {}} +> qemu-system-x86_64: Can't receive COLO message: Input/output error +> ** +> ERROR:/build/qemu/src/qemu-2.11.1/qom/object.c:907:object_unref: +> assertion failed (obj->ref > 0): (0 > 0) +> [1] 2972 abort sudo /usr/bin/qemu-system-x86_64 -boot c +> -enable-kvm -m 2048 -smp 2 -qmp stdi +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> +> ** Tags: colo +> +> ** Description changed: +> +> I use Arch Linux x86_64 +> - both qemu 2.11.1 Zhang Chen's(https://github.com/ +> zhangckid/qemu/commits/colo-with-virtio-net-internal-jul10) +> + both qemu 2.11.1 and Zhang Chen's(https://github.com/ +> zhangckid/qemu/commits/colo-with-virtio-net-internal-jul10) +> Following document 'COLO-FT.txt', +> I test colo feature on my hosts +> +> I run this command +> Primary: +> sudo qemu-system-x86_64 -boot c -enable-kvm -m 2048 -smp 2 -qmp +> stdio -name primary \ +> -device piix3-usb-uhci \ +> -device usb-tablet -netdev tap,id=hn0,vhost=off \ +> -device virtio-net-pci,id=net-pci0,netdev=hn0 \ +> -drive if=virtio,id=colo-disk0,driver=quorum,read-pattern= +> fifo,vote-threshold=1,children.0.file.filename=/var/ +> lib/libvirt/images/1.raw,children.0.driver=raw -S +> +> Secondary: +> sudo qemu-system-x86_64 -boot c -enable-kvm -m 2048 -smp 2 -qmp stdio +> -name secondary \ +> -device piix3-usb-uhci \ +> -device usb-tablet -netdev tap,id=hn0,vhost=off \ +> -device virtio-net-pci,id=net-pci0,netdev=hn0 \ +> -drive if=none,id=colo-disk0,file.filename=/var/lib/libvirt/ +> images/2.raw,driver=raw,node-name=node0 \ +> -drive if=virtio,id=active-disk0,driver=replication,mode=secondary,\ +> file.driver=qcow2,top-id=active-disk0,\ +> file.file.filename=/mnt/ramfs/active_disk.img,\ +> file.backing.driver=qcow2,\ +> file.backing.file.filename=/mnt/ramfs/hidden_disk.img,\ +> file.backing.backing=colo-disk0 \ +> -incoming tcp:0:8888 +> +> Secondary: +> {'execute':'qmp_capabilities'} +> { 'execute': 'nbd-server-start', +> - 'arguments': {'addr': {'type': 'inet', 'data': {'host': +> '192.168.0.33', 'port': '8889'} } } +> + 'arguments': {'addr': {'type': 'inet', 'data': {'host': +> '192.168.0.33', 'port': '8889'} } } +> } +> {'execute': 'nbd-server-add', 'arguments': {'device': 'colo-disk0', +> 'writable': true } } +> +> Primary: +> {'execute':'qmp_capabilities'} +> { 'execute': 'human-monitor-command', +> - 'arguments': {'command-line': 'drive_add -n buddy +> driver=replication,mode=primary,file.driver=nbd,file. +> host=192.168.0.33,file.port=8889,file.export=colo-disk0, +> node-name=nbd_client0'}} +> + 'arguments': {'command-line': 'drive_add -n buddy +> driver=replication,mode=primary,file.driver=nbd,file. +> host=192.168.0.33,file.port=8889,file.export=colo-disk0, +> node-name=nbd_client0'}} +> { 'execute':'x-blockdev-change', 'arguments':{'parent': 'colo-disk0', +> 'node': 'nbd_client0' } } +> { 'execute': 'migrate-set-capabilities', +> - 'arguments': {'capabilities': [ {'capability': 'x-colo', 'state': +> true } ] } } +> + 'arguments': {'capabilities': [ {'capability': 'x-colo', 'state': +> true } ] } } +> { 'execute': 'migrate', 'arguments': {'uri': 'tcp:192.168.0.33:8888' } } +> { 'execute': 'migrate-set-parameters' , 'arguments':{ +> 'x-checkpoint-delay': 2000 } } +> +> Above are all OK.Two VM syncing. +> +> Primary: +> { 'execute': 'x-blockdev-change', 'arguments': {'parent': 'colo-disk0', +> 'child': 'children.1'}} +> { 'execute': 'human-monitor-command','arguments': {'command-line': +> 'drive_del blk-buddy0'}} +> +> Secondary: +> { 'execute': 'nbd-server-stop' } +> { 'execute': 'x-colo-lost-heartbeat' } +> +> But When I execute x-colo-lost-heartbeat.Primary run Secondary cash +> +> - +> - { 'execute': 'nbd-server-stop' } +> + { 'execute': 'nbd-server-stop' } +> {"return": {}} +> qemu-system-x86_64: Disconnect client, due to: Unexpected end-of-file +> before all bytes were read +> - { 'execute': 'x-colo-lost-heartbeat' } +> + { 'execute': 'x-colo-lost-heartbeat' } +> {"return": {}} +> qemu-system-x86_64: Can't receive COLO message: Input/output error +> ** +> ERROR:/build/qemu/src/qemu-2.11.1/qom/object.c:907:object_unref: +> assertion failed (obj->ref > 0): (0 > 0) +> [1] 2972 abort sudo /usr/bin/qemu-system-x86_64 -boot c +> -enable-kvm -m 2048 -smp 2 -qmp stdi +> +> ** Tags added: colo +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1754542 +> +> Title: +> colo: secondary vm crash when execute x-colo-lost-heartbeat +> +> Status in QEMU: +> New +> +> Bug description: +> I use Arch Linux x86_64 +> both qemu 2.11.1 and Zhang Chen's(https://github.com/ +> zhangckid/qemu/commits/colo-with-virtio-net-internal-jul10) +> Following document 'COLO-FT.txt', +> I test colo feature on my hosts +> +> I run this command +> Primary: +> sudo qemu-system-x86_64 -boot c -enable-kvm -m 2048 -smp 2 -qmp +> stdio -name primary \ +> -device piix3-usb-uhci \ +> -device usb-tablet -netdev tap,id=hn0,vhost=off \ +> -device virtio-net-pci,id=net-pci0,netdev=hn0 \ +> -drive if=virtio,id=colo-disk0,driver=quorum,read-pattern= +> fifo,vote-threshold=1,children.0.file.filename=/var/ +> lib/libvirt/images/1.raw,children.0.driver=raw -S +> +> Secondary: +> sudo qemu-system-x86_64 -boot c -enable-kvm -m 2048 -smp 2 -qmp stdio +> -name secondary \ +> -device piix3-usb-uhci \ +> -device usb-tablet -netdev tap,id=hn0,vhost=off \ +> -device virtio-net-pci,id=net-pci0,netdev=hn0 \ +> -drive if=none,id=colo-disk0,file.filename=/var/lib/libvirt/ +> images/2.raw,driver=raw,node-name=node0 \ +> -drive if=virtio,id=active-disk0,driver=replication,mode=secondary,\ +> file.driver=qcow2,top-id=active-disk0,\ +> file.file.filename=/mnt/ramfs/active_disk.img,\ +> file.backing.driver=qcow2,\ +> file.backing.file.filename=/mnt/ramfs/hidden_disk.img,\ +> file.backing.backing=colo-disk0 \ +> -incoming tcp:0:8888 +> +> Secondary: +> {'execute':'qmp_capabilities'} +> { 'execute': 'nbd-server-start', +> 'arguments': {'addr': {'type': 'inet', 'data': {'host': +> '192.168.0.33', 'port': '8889'} } } +> } +> {'execute': 'nbd-server-add', 'arguments': {'device': 'colo-disk0', +> 'writable': true } } +> +> Primary: +> {'execute':'qmp_capabilities'} +> { 'execute': 'human-monitor-command', +> 'arguments': {'command-line': 'drive_add -n buddy +> driver=replication,mode=primary,file.driver=nbd,file. +> host=192.168.0.34,file.port=8889,file.export=colo-disk0, +> node-name=nbd_client0'}} +> { 'execute':'x-blockdev-change', 'arguments':{'parent': 'colo-disk0', +> 'node': 'nbd_client0' } } +> { 'execute': 'migrate-set-capabilities', +> 'arguments': {'capabilities': [ {'capability': 'x-colo', 'state': +> true } ] } } +> { 'execute': 'migrate', 'arguments': {'uri': 'tcp:192.168.0.34:8888' } } +> { 'execute': 'migrate-set-parameters' , 'arguments':{ +> 'x-checkpoint-delay': 2000 } } +> +> Above are all OK.Two VM syncing. +> +> Primary: +> { 'execute': 'x-blockdev-change', 'arguments': {'parent': 'colo-disk0', +> 'child': 'children.1'}} +> { 'execute': 'human-monitor-command','arguments': {'command-line': +> 'drive_del blk-buddy0'}} +> +> Secondary: +> { 'execute': 'nbd-server-stop' } +> { 'execute': 'x-colo-lost-heartbeat' } +> +> But When I execute x-colo-lost-heartbeat.Primary run Secondary cash +> +> { 'execute': 'nbd-server-stop' } +> {"return": {}} +> qemu-system-x86_64: Disconnect client, due to: Unexpected end-of-file +> before all bytes were read +> { 'execute': 'x-colo-lost-heartbeat' } +> {"return": {}} +> qemu-system-x86_64: Can't receive COLO message: Input/output error +> ** +> ERROR:/build/qemu/src/qemu-2.11.1/qom/object.c:907:object_unref: +> assertion failed (obj->ref > 0): (0 > 0) +> [1] 2972 abort sudo /usr/bin/qemu-system-x86_64 -boot c +> -enable-kvm -m 2048 -smp 2 -qmp stdi +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1754542/+subscriptions +> +> + + +Hi Zhang Chen， +I follow the https://wiki.qemu.org/Features/COLO, And Vm no crash. +But SVM rebooting constantly after print RESET, PVM normal startup. + +Secondary: +{"timestamp": {"seconds": 1521421788, "microseconds": 541058}, "event": "RESUME"} +{"timestamp": {"seconds": 1521421808, "microseconds": 493484}, "event": "STOP"} +{"timestamp": {"seconds": 1521421808, "microseconds": 686466}, "event": "RESUME"} +{"timestamp": {"seconds": 1521421808, "microseconds": 696152}, "event": "RESET", "data": {"guest": true}} +{"timestamp": {"seconds": 1521421808, "microseconds": 740653}, "event": "RESET", "data": {"guest": true}} +{"timestamp": {"seconds": 1521421818, "microseconds": 742222}, "event": "STOP"} +{"timestamp": {"seconds": 1521421818, "microseconds": 969883}, "event": "RESUME"} +{"timestamp": {"seconds": 1521421818, "microseconds": 979986}, "event": "RESET", "data": {"guest": true}} +{"timestamp": {"seconds": 1521421819, "microseconds": 22652}, "event": "RESET", "data": {"guest": true}} + + +The command(I run two VM in sample machine): + +Primary: +sudo /home/lee/Documents/qemu/x86_64-softmmu/qemu-system-x86_64 -enable-kvm -boot c -m 2048 -smp 2 -qmp stdio -name primary -cpu qemu64,+kvmclock -device piix3-usb-uhci -device usb-tablet \ + -netdev tap,id=hn0,vhost=off,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown -device rtl8139,id=e0,netdev=hn0 \ + -chardev socket,id=mirror0,host=192.168.0.33,port=9003,server,nowait \ + -chardev socket,id=compare1,host=192.168.0.33,port=9004,server,wait \ + -chardev socket,id=compare0,host=192.168.0.33,port=9001,server,nowait \ + -chardev socket,id=compare0-0,host=192.168.0.33,port=9001 \ + -chardev socket,id=compare_out,host=192.168.0.33,port=9005,server,nowait \ + -chardev socket,id=compare_out0,host=192.168.0.33,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=/var/lib/libvirt/images/1.raw,children.0.driver=raw -S + +Secondary: +sudo /home/lee/Documents/qemu/x86_64-softmmu/qemu-system-x86_64 -boot c -m 2048 -smp 2 -qmp stdio -name secondary -enable-kvm -cpu qemu64,+kvmclock \ + -device piix3-usb-uhci -device usb-tablet \ + -netdev tap,id=hn0,vhost=off,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown \ + -device rtl8139,netdev=hn0 \ + -chardev socket,id=red0,host=192.168.0.33,port=9003,reconnect=1 \ + -chardev socket,id=red1,host=192.168.0.33,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=colo-disk0,file.filename=/var/lib/libvirt/images/2.raw,driver=raw,node-name=node0 \ + -drive if=ide,id=active-disk0,driver=replication,mode=secondary,file.driver=qcow2,top-id=active-disk0,file.file.filename=/mnt/ramfs/active_disk.img,file.backing.driver=qcow2,file.backing.file.filename=/mnt/ramfs/hidden_disk.img,file.backing.backing=colo-disk0 \ + -incoming tcp:0:8888 + +Secondary: + {'execute':'qmp_capabilities'} + { 'execute': 'nbd-server-start', + 'arguments': {'addr': {'type': 'inet', 'data': {'host': '192.168.0.33', 'port': '8889'} } } + } + {'execute': 'nbd-server-add', 'arguments': {'device': 'colo-disk0', 'writable': true } } + {'execute': 'trace-event-set-state', 'arguments': {'name': 'colo*', 'enable': true} } + + +Primary: + {'execute':'qmp_capabilities'} + { 'execute': 'human-monitor-command', + 'arguments': {'command-line': 'drive_add -n buddy driver=replication,mode=primary,file.driver=nbd,file.host=192.168.0.33,file.port=8889,file.export=colo-disk0,node-name=node0'}} + { 'execute':'x-blockdev-change', 'arguments':{'parent': 'colo-disk0', 'node': 'node0' } } + { 'execute': 'migrate-set-capabilities', + 'arguments': {'capabilities': [ {'capability': 'x-colo', 'state': true } ] } } + { 'execute': 'migrate', 'arguments': {'uri': 'tcp:192.168.0.33:8888' } } + +Thanks +Suiheng + +It is my trace event file. +I read it many times, but still can't find the cause of the error. +I just found after colo_vm_state_change ide_reset and ps2_kbd_reset ... + + + +It is svn trace even + +Hi Suiheng, + +I made a new guest image and retest it, and got the same bug from latest +branch. +I found that after the COLO checkpoint begin, the secondary guest always +send +reset request to Qemu like someone still push the reset button in the guest. +And this bug occurred in COLO frame related codes. This part of codes wrote +by Li zhijian and Zhang hailiang and currently maintained by Zhang hailiang. +So, I add them to this thread. + +CC Zhijian and Hailiang: +Any idea or comments about this bug? + +If you want to test COLO currently, you can try the old version of COLO: +https://github.com/zhangckid/qemu/tree/qemu-colo-18mar10-legacy + + +Thanks +Zhang Chen + +On Mon, Mar 19, 2018 at 10:08 AM, 李穗恒 <email address hidden> wrote: + +> Hi Zhang Chen， +> I follow the https://wiki.qemu.org/Features/COLO, And Vm no crash. +> But SVM rebooting constantly after print RESET, PVM normal startup. +> +> Secondary: +> {"timestamp": {"seconds": 1521421788, "microseconds": 541058}, "event": +> "RESUME"} +> {"timestamp": {"seconds": 1521421808, "microseconds": 493484}, "event": +> "STOP"} +> {"timestamp": {"seconds": 1521421808, "microseconds": 686466}, "event": +> "RESUME"} +> {"timestamp": {"seconds": 1521421808, "microseconds": 696152}, "event": +> "RESET", "data": {"guest": true}} +> {"timestamp": {"seconds": 1521421808, "microseconds": 740653}, "event": +> "RESET", "data": {"guest": true}} +> {"timestamp": {"seconds": 1521421818, "microseconds": 742222}, "event": +> "STOP"} +> {"timestamp": {"seconds": 1521421818, "microseconds": 969883}, "event": +> "RESUME"} +> {"timestamp": {"seconds": 1521421818, "microseconds": 979986}, "event": +> "RESET", "data": {"guest": true}} +> {"timestamp": {"seconds": 1521421819, "microseconds": 22652}, "event": +> "RESET", "data": {"guest": true}} +> +> +> The command(I run two VM in sample machine): +> +> Primary: +> sudo /home/lee/Documents/qemu/x86_64-softmmu/qemu-system-x86_64 +> -enable-kvm -boot c -m 2048 -smp 2 -qmp stdio -name primary -cpu +> qemu64,+kvmclock -device piix3-usb-uhci -device usb-tablet \ +> -netdev tap,id=hn0,vhost=off,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown +> -device rtl8139,id=e0,netdev=hn0 \ +> -chardev socket,id=mirror0,host=192.168.0.33,port=9003,server,nowait \ +> -chardev socket,id=compare1,host=192.168.0.33,port=9004,server,wait \ +> -chardev socket,id=compare0,host=192.168.0.33,port=9001,server,nowait +> \ +> -chardev socket,id=compare0-0,host=192.168.0.33,port=9001 \ +> -chardev socket,id=compare_out,host=192.168.0.33,port=9005,server,nowait +> \ +> -chardev socket,id=compare_out0,host=192.168.0.33,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=/var/lib/libvirt/ +> images/1.raw,children.0.driver=raw -S +> +> Secondary: +> sudo /home/lee/Documents/qemu/x86_64-softmmu/qemu-system-x86_64 -boot c +> -m 2048 -smp 2 -qmp stdio -name secondary -enable-kvm -cpu +> qemu64,+kvmclock \ +> -device piix3-usb-uhci -device usb-tablet \ +> -netdev tap,id=hn0,vhost=off,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown +> \ +> -device rtl8139,netdev=hn0 \ +> -chardev socket,id=red0,host=192.168.0.33,port=9003,reconnect=1 \ +> -chardev socket,id=red1,host=192.168.0.33,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=colo-disk0,file.filename=/var/lib/libvirt/ +> images/2.raw,driver=raw,node-name=node0 \ +> -drive if=ide,id=active-disk0,driver=replication,mode=secondary, +> file.driver=qcow2,top-id=active-disk0,file.file. +> filename=/mnt/ramfs/active_disk.img,file.backing.driver= +> qcow2,file.backing.file.filename=/mnt/ramfs/hidden_ +> disk.img,file.backing.backing=colo-disk0 \ +> -incoming tcp:0:8888 +> +> Secondary: +> {'execute':'qmp_capabilities'} +> { 'execute': 'nbd-server-start', +> 'arguments': {'addr': {'type': 'inet', 'data': {'host': +> '192.168.0.33', 'port': '8889'} } } +> } +> {'execute': 'nbd-server-add', 'arguments': {'device': 'colo-disk0', +> 'writable': true } } +> {'execute': 'trace-event-set-state', 'arguments': {'name': 'colo*', +> 'enable': true} } +> +> +> Primary: +> {'execute':'qmp_capabilities'} +> { 'execute': 'human-monitor-command', +> 'arguments': {'command-line': 'drive_add -n buddy +> driver=replication,mode=primary,file.driver=nbd,file. +> host=192.168.0.33,file.port=8889,file.export=colo-disk0,node-name=node0'}} +> { 'execute':'x-blockdev-change', 'arguments':{'parent': 'colo-disk0', +> 'node': 'node0' } } +> { 'execute': 'migrate-set-capabilities', +> 'arguments': {'capabilities': [ {'capability': 'x-colo', 'state': +> true } ] } } +> { 'execute': 'migrate', 'arguments': {'uri': 'tcp:192.168.0.33:8888' } } +> +> Thanks +> Suiheng +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1754542 +> +> Title: +> colo: vm crash with segmentation fault +> +> Status in QEMU: +> New +> +> Bug description: +> I use Arch Linux x86_64 +> Zhang Chen's(https://github.com/zhangckid/qemu/tree/qemu-colo-18mar10) +> Following document 'COLO-FT.txt', +> I test colo feature on my hosts +> +> I run this command +> Primary: +> sudo /usr/local/bin/qemu-system-x86_64 -enable-kvm -m 2048 -smp 2 -qmp +> stdio -name primary \ +> -device piix3-usb-uhci \ +> -device usb-tablet -netdev tap,id=hn0,vhost=off \ +> -device virtio-net-pci,id=net-pci0,netdev=hn0 \ +> -drive if=virtio,id=primary-disk0,driver=quorum,read-pattern= +> fifo,vote-threshold=1,\ +> children.0.file.filename=/var/lib/libvirt/images/1.raw,\ +> children.0.driver=raw -S +> +> Secondary: +> sudo /usr/local/bin/qemu-system-x86_64 -enable-kvm -m 2048 -smp 2 -qmp +> stdio -name secondary \ +> -device piix3-usb-uhci \ +> -device usb-tablet -netdev tap,id=hn0,vhost=off \ +> -device virtio-net-pci,id=net-pci0,netdev=hn0 \ +> -drive if=none,id=secondary-disk0,file.filename=/var/lib/ +> libvirt/images/2.raw,driver=raw,node-name=node0 \ +> -drive if=virtio,id=active-disk0,driver=replication,mode=secondary,\ +> file.driver=qcow2,top-id=active-disk0,\ +> file.file.filename=/mnt/ramfs/active_disk.img,\ +> file.backing.driver=qcow2,\ +> file.backing.file.filename=/mnt/ramfs/hidden_disk.img,\ +> file.backing.backing=secondary-disk0 \ +> -incoming tcp:0:8888 +> +> Secondary: +> {'execute':'qmp_capabilities'} +> { 'execute': 'nbd-server-start', +> 'arguments': {'addr': {'type': 'inet', 'data': {'host': +> '192.168.0.34', 'port': '8889'} } } +> } +> {'execute': 'nbd-server-add', 'arguments': {'device': 'secondary-disk0', +> 'writable': true } } +> +> Primary: +> {'execute':'qmp_capabilities'} +> { 'execute': 'human-monitor-command', +> 'arguments': {'command-line': 'drive_add -n buddy +> driver=replication,mode=primary,file.driver=nbd,file. +> host=192.168.0.34,file.port=8889,file.export=secondary- +> disk0,node-name=nbd_client0'}} +> { 'execute':'x-blockdev-change', 'arguments':{'parent': 'primary-disk0', +> 'node': 'nbd_client0' } } +> { 'execute': 'migrate-set-capabilities', +> 'arguments': {'capabilities': [ {'capability': 'x-colo', 'state': +> true } ] } } +> { 'execute': 'migrate', 'arguments': {'uri': 'tcp:192.168.0.34:8888' } } +> And two VM with cash +> Primary: +> {"timestamp": {"seconds": 1520763655, "microseconds": 511415}, "event": +> "RESUME"} +> [1] 329 segmentation fault sudo /usr/local/bin/qemu-system-x86_64 +> -boot c -enable-kvm -m 2048 -smp 2 -qm +> +> Secondary: +> {"timestamp": {"seconds": 1520763655, "microseconds": 510907}, "event": +> "RESUME"} +> [1] 367 segmentation fault sudo /usr/local/bin/qemu-system-x86_64 +> -boot c -enable-kvm -m 2048 -smp 2 -qm +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1754542/+subscriptions +> + + +I took a photo when SVM print reset. +It seems like kernel panic. +I hope this will help. + + +SVM error photo + +Thanks zhijian. + +On Fri, Mar 23, 2018 at 4:34 PM, Li Zhijian <email address hidden> +wrote: + +> Just noticed that's a little old, you may need to rebase it +> +> +> Thanks +> +> +> On 03/23/2018 11:51 AM, Li Zhijian wrote: +> +>> +>> +>> On 03/21/2018 02:04 PM, Zhang Chen wrote: +>> +>>> Hi Suiheng, +>>> +>>> I made a new guest image and retest it, and got the same bug from latest +>>> branch. +>>> I found that after the COLO checkpoint begin, the secondary guest always +>>> send +>>> reset request to Qemu like someone still push the reset button in the +>>> guest. +>>> And this bug occurred in COLO frame related codes. This part of codes +>>> wrote +>>> by Li zhijian and Zhang hailiang and currently maintained by Zhang +>>> hailiang. +>>> So, I add them to this thread. +>>> +>>> CC Zhijian and Hailiang: +>>> Any idea or comments about this bug? +>>> +>> +>> One clue is the memory of SVM not is same with PVM. +>> we can try to compare the memory after checkpoint, i had a draft patch to +>> do this before. +>> +>> +>> Thanks +>> +>> +>> +>> +>> +>>> If you want to test COLO currently, you can try the old version of COLO: +>>> https://github.com/zhangckid/qemu/tree/qemu-colo-18mar10-legacy +>>> +>>> +>>> Thanks +>>> Zhang Chen +>>> +>>> On Mon, Mar 19, 2018 at 10:08 AM, 李穗恒 <<email address hidden> +>>> <mailto:<email address hidden>>> wrote: +>>> +>>> Hi Zhang Chen， +>>> I follow the https://wiki.qemu.org/Features/COLO < +>>> https://wiki.qemu.org/Features/COLO>, And Vm no crash. +>>> +>>> But SVM rebooting constantly after print RESET, PVM normal startup. +>>> +>>> Secondary: +>>> {"timestamp": {"seconds": 1521421788, "microseconds": 541058}, +>>> "event": "RESUME"} +>>> {"timestamp": {"seconds": 1521421808, "microseconds": 493484}, +>>> "event": "STOP"} +>>> {"timestamp": {"seconds": 1521421808, "microseconds": 686466}, +>>> "event": "RESUME"} +>>> {"timestamp": {"seconds": 1521421808, "microseconds": 696152}, +>>> "event": "RESET", "data": {"guest": true}} +>>> {"timestamp": {"seconds": 1521421808, "microseconds": 740653}, +>>> "event": "RESET", "data": {"guest": true}} +>>> {"timestamp": {"seconds": 1521421818, "microseconds": 742222}, +>>> "event": "STOP"} +>>> {"timestamp": {"seconds": 1521421818, "microseconds": 969883}, +>>> "event": "RESUME"} +>>> {"timestamp": {"seconds": 1521421818, "microseconds": 979986}, +>>> "event": "RESET", "data": {"guest": true}} +>>> {"timestamp": {"seconds": 1521421819, "microseconds": 22652}, +>>> "event": "RESET", "data": {"guest": true}} +>>> +>>> +>>> The command(I run two VM in sample machine): +>>> +>>> Primary: +>>> sudo /home/lee/Documents/qemu/x86_64-softmmu/qemu-system-x86_64 +>>> -enable-kvm -boot c -m 2048 -smp 2 -qmp stdio -name primary -cpu +>>> qemu64,+kvmclock -device piix3-usb-uhci -device usb-tablet \ +>>> -netdev tap,id=hn0,vhost=off,script=/e +>>> tc/qemu-ifup,downscript=/etc/qemu-ifdown -device +>>> rtl8139,id=e0,netdev=hn0 \ +>>> -chardev socket,id=mirror0,host=192.168.0.33,port=9003,server,nowait +>>> \ +>>> -chardev socket,id=compare1,host=192.168.0.33,port=9004,server,wait +>>> \ +>>> -chardev socket,id=compare0,host=192.168.0.33,port=9001,server,nowait +>>> \ +>>> -chardev socket,id=compare0-0,host=192.168.0.33,port=9001 \ +>>> -chardev socket,id=compare_out,host=192 +>>> .168.0.33,port=9005,server,nowait \ +>>> -chardev socket,id=compare_out0,host=192.168.0.33,port=9005 \ +>>> -object filter-mirror,id=m0,netdev=hn0,queue=tx,outdev=mirror0 \ +>>> -object filter-redirector,netdev=hn0,i +>>> d=redire0,queue=rx,indev=compare_out \ +>>> -object filter-redirector,netdev=hn0,i +>>> d=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=qu +>>> orum,read-pattern=fifo,vote-threshold=1,children.0.file.file +>>> name=/var/lib/libvirt/images/1.raw,children.0.driver=raw -S +>>> +>>> Secondary: +>>> sudo /home/lee/Documents/qemu/x86_64-softmmu/qemu-system-x86_64 +>>> -boot c -m 2048 -smp 2 -qmp stdio -name secondary -enable-kvm -cpu +>>> qemu64,+kvmclock \ +>>> -device piix3-usb-uhci -device usb-tablet \ +>>> -netdev tap,id=hn0,vhost=off,script=/e +>>> tc/qemu-ifup,downscript=/etc/qemu-ifdown \ +>>> -device rtl8139,netdev=hn0 \ +>>> -chardev socket,id=red0,host=192.168.0.33,port=9003,reconnect=1 +>>> \ +>>> -chardev socket,id=red1,host=192.168.0.33,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=colo-disk0,file.fil +>>> ename=/var/lib/libvirt/images/2.raw,driver=raw,node-name=node0 \ +>>> -drive if=ide,id=active-disk0,driver= +>>> replication,mode=secondary,file.driver=qcow2,top-id=active- +>>> disk0,file.file.filename=/mnt/ramfs/active_disk.img,file. +>>> backing.driver=qcow2,file.backing.file.filename=/mnt/ +>>> ramfs/hidden_disk.img,file.backing.backing=colo-disk0 \ +>>> -incoming tcp:0:8888 +>>> +>>> Secondary: +>>> {'execute':'qmp_capabilities'} +>>> { 'execute': 'nbd-server-start', +>>> 'arguments': {'addr': {'type': 'inet', 'data': {'host': +>>> '192.168.0.33', 'port': '8889'} } } +>>> } +>>> {'execute': 'nbd-server-add', 'arguments': {'device': +>>> 'colo-disk0', 'writable': true } } +>>> {'execute': 'trace-event-set-state', 'arguments': {'name': +>>> 'colo*', 'enable': true} } +>>> +>>> +>>> Primary: +>>> {'execute':'qmp_capabilities'} +>>> { 'execute': 'human-monitor-command', +>>> 'arguments': {'command-line': 'drive_add -n buddy +>>> driver=replication,mode=primary,file.driver=nbd,file.host= +>>> 192.168.0.33,file.port=8889,file.export=colo-disk0,node-name=node0'}} +>>> { 'execute':'x-blockdev-change', 'arguments':{'parent': +>>> 'colo-disk0', 'node': 'node0' } } +>>> { 'execute': 'migrate-set-capabilities', +>>> 'arguments': {'capabilities': [ {'capability': 'x-colo', +>>> 'state': true } ] } } +>>> { 'execute': 'migrate', 'arguments': {'uri': 'tcp: +>>> 192.168.0.33:8888 <http://192.168.0.33:8888>' } } +>>> +>>> Thanks +>>> Suiheng +>>> +>>> -- +>>> You received this bug notification because you are subscribed to the +>>> bug +>>> report. +>>> https://bugs.launchpad.net/bugs/1754542 < +>>> https://bugs.launchpad.net/bugs/1754542> +>>> +>>> Title: +>>> colo: vm crash with segmentation fault +>>> +>>> Status in QEMU: +>>> New +>>> +>>> Bug description: +>>> I use Arch Linux x86_64 +>>> Zhang Chen's(https://github.com/zhangckid/qemu/tree/qemu-colo-18ma +>>> r10 <https://github.com/zhangckid/qemu/tree/qemu-colo-18mar10>) +>>> +>>> Following document 'COLO-FT.txt', +>>> I test colo feature on my hosts +>>> +>>> I run this command +>>> Primary: +>>> sudo /usr/local/bin/qemu-system-x86_64 -enable-kvm -m 2048 -smp 2 +>>> -qmp stdio -name primary \ +>>> -device piix3-usb-uhci \ +>>> -device usb-tablet -netdev tap,id=hn0,vhost=off \ +>>> -device virtio-net-pci,id=net-pci0,netdev=hn0 \ +>>> -drive if=virtio,id=primary-disk0,driver=quorum,read-pattern=fifo, +>>> vote-threshold=1,\ +>>> children.0.file.filename=/var/lib/libvirt/images/1.raw,\ +>>> children.0.driver=raw -S +>>> +>>> Secondary: +>>> sudo /usr/local/bin/qemu-system-x86_64 -enable-kvm -m 2048 -smp 2 +>>> -qmp stdio -name secondary \ +>>> -device piix3-usb-uhci \ +>>> -device usb-tablet -netdev tap,id=hn0,vhost=off \ +>>> -device virtio-net-pci,id=net-pci0,netdev=hn0 \ +>>> -drive if=none,id=secondary-disk0,file.filename=/var/lib/libvirt/ +>>> images/2.raw,driver=raw,node-name=node0 \ +>>> -drive if=virtio,id=active-disk0,driv +>>> er=replication,mode=secondary,\ +>>> file.driver=qcow2,top-id=active-disk0,\ +>>> file.file.filename=/mnt/ramfs/active_disk.img,\ +>>> file.backing.driver=qcow2,\ +>>> file.backing.file.filename=/mnt/ramfs/hidden_disk.img,\ +>>> file.backing.backing=secondary-disk0 \ +>>> -incoming tcp:0:8888 +>>> +>>> Secondary: +>>> {'execute':'qmp_capabilities'} +>>> { 'execute': 'nbd-server-start', +>>> 'arguments': {'addr': {'type': 'inet', 'data': {'host': +>>> '192.168.0.34', 'port': '8889'} } } +>>> } +>>> {'execute': 'nbd-server-add', 'arguments': {'device': +>>> 'secondary-disk0', 'writable': true } } +>>> +>>> Primary: +>>> {'execute':'qmp_capabilities'} +>>> { 'execute': 'human-monitor-command', +>>> 'arguments': {'command-line': 'drive_add -n buddy +>>> driver=replication,mode=primary,file.driver=nbd,file.host= +>>> 192.168.0.34,file.port=8889,file.export=secondary-disk0, +>>> node-name=nbd_client0'}} +>>> { 'execute':'x-blockdev-change', 'arguments':{'parent': +>>> 'primary-disk0', 'node': 'nbd_client0' } } +>>> { 'execute': 'migrate-set-capabilities', +>>> 'arguments': {'capabilities': [ {'capability': 'x-colo', +>>> 'state': true } ] } } +>>> { 'execute': 'migrate', 'arguments': {'uri': 'tcp: +>>> 192.168.0.34:8888 <http://192.168.0.34:8888>' } } +>>> And two VM with cash +>>> Primary: +>>> {"timestamp": {"seconds": 1520763655, "microseconds": 511415}, +>>> "event": "RESUME"} +>>> [1] 329 segmentation fault sudo /usr/local/bin/qemu-system-x86_64 +>>> -boot c -enable-kvm -m 2048 -smp 2 -qm +>>> +>>> Secondary: +>>> {"timestamp": {"seconds": 1520763655, "microseconds": 510907}, +>>> "event": "RESUME"} +>>> [1] 367 segmentation fault sudo /usr/local/bin/qemu-system-x86_64 +>>> -boot c -enable-kvm -m 2048 -smp 2 -qm +>>> +>>> To manage notifications about this bug go to: +>>> https://bugs.launchpad.net/qemu/+bug/1754542/+subscriptions < +>>> https://bugs.launchpad.net/qemu/+bug/1754542/+subscriptions> +>>> +>>> +>>> +>> +> -- +> Best regards. +> Li Zhijian (8528) +> +> +> +> + + +Hi Suiheng, + +This bug have been fixed in my latest patch. +Please retest it. +https://<email address hidden>/msg538383.html + +github: +https://github.com/zhangckid/qemu/tree/qemu-colo-18jun1 + +Thanks +Zhang Chen + +Hi, Zhang Chen + +It seems virtio blk isn't working. + +I test coloft against https://github.com/zhangckid/qemu/tree/qemu-colo-18jul22, got the following error on very early stage: + +On primary: +qemu-system-x86_64: Can't receive COLO message: Input/output error + +On secondary: +qemu-system-x86_64: block.c:4893: bdrv_detach_aio_context: Assertion `!bs->walking_aio_notifiers' failed. + +Run the test as follows: + +1. Setup primary: + +# qemu-img create -b centos6base.img -f qcow2 centos6sp.img +# qemu-system-x86_64 -machine dump-guest-core=off -accel kvm -m 128 \ +-smp 2 -name primary -serial stdio \ +-qmp unix://root/wangchao/pvm.monitor.sock,server,nowait -vnc :10 \ +-netdev tap,id=hn0,vhost=off,script=no,downscript=no -drive \ +if=virtio,id=primary-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,children.0.file.filename=/root/wangchao/images/centos6sp.img,children.0.driver=qcow2 \ +-S -nodefaults + +2. Setup secondary: + +# qemu-img create -b centos6base.img -f qcow2 centos6sp.img +# qemu-img create -f qcow2 /dev/shm/active.img 20G +# qemu-img create -f qcow2 /dev/shm/hidden.img 20G +# qemu-system-x86_64 -machine dump-guest-core=off -accel kvm -m 128 \ +-smp 2 -name secondary -serial stdio \ +-qmp unix://root/wangchao/svm.monitor.sock,server,nowait -vnc :10 \ +-netdev tap,id=hn0,vhost=off,script=no,downscript=no \ +-drive if=none,id=secondary-disk0,file.filename=/root/wangchao/images/centos6sp.img,driver=qcow2,node-name=node0 \ +-drive if=virtio,id=active-disk0,driver=replication,mode=secondary,top-id=active-disk0,file.driver=qcow2,file.file.filename=/dev/shm/active.img,file.backing.driver=qcow2,file.backing.file.filename=/dev/shm/hidden.img,file.backing.backing=secondary-disk0 \ +-incoming tcp:0:8888 -nodefaults + +3. Issue the following qmp: + +On secondary: +{'execute':'qmp_capabilities'} +{'execute': 'nbd-server-start', 'arguments': {'addr': {'type': 'inet', 'data': {'host': 'x.x.x.x', 'port': '8889'} } } } +{'execute': 'nbd-server-add', 'arguments': {'device':'secondary-disk0', 'writable': true } } + +On primary: +{'execute': 'qmp_capabilities'} +{'execute': 'human-monitor-command', 'arguments': {'command-line': 'drive_add -n buddy driver=replication,mode=primary,file.driver=nbd,file.host=x.x.x.x,file.port=8889,file.export=secondary-disk0,node-name=nbd_client0'}} +{'execute': 'x-blockdev-change', 'arguments':{'parent': 'primary-disk0', 'node': 'nbd_client0' } } +{'execute': 'migrate-set-capabilities', 'arguments': {'capabilities': [{'capability': 'x-colo', 'state': true } ] } } +{'execute': 'migrate', 'arguments': {'uri': 'tcp:x.x.x.x:8888'}} + +4. Then secondary immediately crashed: +qemu-system-x86_64: block.c:4893: bdrv_detach_aio_context: Assertion `!bs->walking_aio_notifiers' failed. + +(gdb) bt +#0 0x00007fb50d241277 in raise () from /lib64/libc.so.6 +#1 0x00007fb50d242968 in abort () from /lib64/libc.so.6 +#2 0x00007fb50d23a096 in __assert_fail_base () from /lib64/libc.so.6 +#3 0x00007fb50d23a142 in __assert_fail () from /lib64/libc.so.6 +#4 0x0000000000706ae9 in bdrv_detach_aio_context (bs=0x2e84000) at block.c:4893 +#5 0x0000000000706ab8 in bdrv_detach_aio_context (bs=bs@entry=0x315d400) at block.c:4911 +#6 0x0000000000706c16 in bdrv_set_aio_context (bs=0x315d400, new_context=0x2e17180) at block.c:4960 +#7 0x000000000070a43d in block_job_attached_aio_context (new_context=<optimized out>, opaque=0x2d92000) at blockjob.c:111 +#8 0x0000000000706b93 in bdrv_attach_aio_context (bs=0x2e84000, new_context=new_context@entry=0x2e17180) at block.c:4942 +#9 0x0000000000706b2b in bdrv_attach_aio_context (bs=0x315d400, new_context=new_context@entry=0x2e17180) at block.c:4930 +#10 0x0000000000706b2b in bdrv_attach_aio_context (bs=0x2ff8800, new_context=new_context@entry=0x2e17180) at block.c:4930 +#11 0x0000000000706b2b in bdrv_attach_aio_context (bs=bs@entry=0x2ff5400, new_context=new_context@entry=0x2e17180) at block.c:4930 +#12 0x0000000000706c29 in bdrv_set_aio_context (bs=0x2ff5400, new_context=0x2e17180) at block.c:4966 +#13 0x0000000000748a17 in blk_set_aio_context (blk=<optimized out>, new_context=<optimized out>) at block/block-backend.c:1894 +#14 0x000000000049b60a in virtio_blk_data_plane_start (vdev=<optimized out>) at /root/wangchao/qemu-colo-18jul22/hw/block/dataplane/virtio-blk.c:215 +#15 0x000000000069ceda in virtio_bus_start_ioeventfd (bus=bus@entry=0x46280f8) at hw/virtio/virtio-bus.c:223 +#16 0x00000000006a2480 in virtio_pci_start_ioeventfd (proxy=0x4620000) at hw/virtio/virtio-pci.c:288 +#17 virtio_pci_common_write (opaque=0x4620000, addr=<optimized out>, val=<optimized out>, size=<optimized out>) at hw/virtio/virtio-pci.c:1288 +#18 0x00000000004673b8 in memory_region_write_accessor (mr=0x46209d0, addr=20, value=<optimized out>, size=1, shift=<optimized out>, mask=<optimized out>, attrs=...) at /root/wangchao/qemu-colo-18jul22/memory.c:527 +#19 0x0000000000466c63 in access_with_adjusted_size (addr=addr@entry=20, value=value@entry=0x7fb509ba4788, size=size@entry=1, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=access_fn@entry=0x467340 <memory_region_write_accessor>, mr=mr@entry=0x46209d0, attrs=attrs@entry=...) at /root/wangchao/qemu-colo-18jul22/memory.c:594 +#20 0x0000000000469388 in memory_region_dispatch_write (mr=mr@entry=0x46209d0, addr=addr@entry=20, data=15, size=1, attrs=attrs@entry=...) at /root/wangchao/qemu-colo-18jul22/memory.c:1473 +#21 0x000000000041ada0 in flatview_write_continue (fv=fv@entry=0x459ec80, addr=addr@entry=4273963028, attrs=..., attrs@entry=..., buf=buf@entry=0x7fb51019a028 <Address 0x7fb51019a028 out of bounds>, len=len@entry=1, addr1=20, l=1,mr=0x46209d0) at /root/wangchao/qemu-colo-18jul22/exec.c:3255 +#22 0x000000000041af62 in flatview_write (fv=0x459ec80, addr=4273963028, attrs=..., buf=0x7fb51019a028 <Address 0x7fb51019a028 out of bounds>, len=1) at /root/wangchao/qemu-colo-18jul22/exec.c:3294 + +It seems we were trying to do another aio_notifiers walk *inside a aio_notifiers walk*. + +Thanks +WANG Chao + +Hi Chao, + +Yes, virtio blk isn't supported by current COLO, you can try the "-drive +if=ide xxxxxxxx". + +Thanks +Zhang Chen + +On Fri, Jul 27, 2018 at 12:53 PM, WANG Chao <email address hidden> +wrote: + +> Hi, Zhang Chen +> +> It seems virtio blk isn't working. +> +> I test coloft against https://github.com/zhangckid/qemu/tree/qemu-colo- +> 18jul22, got the following error on very early stage: +> +> On primary: +> qemu-system-x86_64: Can't receive COLO message: Input/output error +> +> On secondary: +> qemu-system-x86_64: block.c:4893: bdrv_detach_aio_context: Assertion +> `!bs->walking_aio_notifiers' failed. +> +> Run the test as follows: +> +> 1. Setup primary: +> +> # qemu-img create -b centos6base.img -f qcow2 centos6sp.img +> # qemu-system-x86_64 -machine dump-guest-core=off -accel kvm -m 128 \ +> -smp 2 -name primary -serial stdio \ +> -qmp unix://root/wangchao/pvm.monitor.sock,server,nowait -vnc :10 \ +> -netdev tap,id=hn0,vhost=off,script=no,downscript=no -drive \ +> if=virtio,id=primary-disk0,driver=quorum,read-pattern= +> fifo,vote-threshold=1,children.0.file.filename=/root/wangchao/images/ +> centos6sp.img,children.0.driver=qcow2 \ +> -S -nodefaults +> +> 2. Setup secondary: +> +> # qemu-img create -b centos6base.img -f qcow2 centos6sp.img +> # qemu-img create -f qcow2 /dev/shm/active.img 20G +> # qemu-img create -f qcow2 /dev/shm/hidden.img 20G +> # qemu-system-x86_64 -machine dump-guest-core=off -accel kvm -m 128 \ +> -smp 2 -name secondary -serial stdio \ +> -qmp unix://root/wangchao/svm.monitor.sock,server,nowait -vnc :10 \ +> -netdev tap,id=hn0,vhost=off,script=no,downscript=no \ +> -drive if=none,id=secondary-disk0,file.filename=/root/wangchao/ +> images/centos6sp.img,driver=qcow2,node-name=node0 \ +> -drive if=virtio,id=active-disk0,driver=replication,mode= +> secondary,top-id=active-disk0,file.driver=qcow2,file.file. +> filename=/dev/shm/active.img,file.backing.driver=qcow2, +> file.backing.file.filename=/dev/shm/hidden.img,file. +> backing.backing=secondary-disk0 \ +> -incoming tcp:0:8888 -nodefaults +> +> 3. Issue the following qmp: +> +> On secondary: +> {'execute':'qmp_capabilities'} +> {'execute': 'nbd-server-start', 'arguments': {'addr': {'type': 'inet', +> 'data': {'host': 'x.x.x.x', 'port': '8889'} } } } +> {'execute': 'nbd-server-add', 'arguments': {'device':'secondary-disk0', +> 'writable': true } } +> +> On primary: +> {'execute': 'qmp_capabilities'} +> {'execute': 'human-monitor-command', 'arguments': {'command-line': +> 'drive_add -n buddy driver=replication,mode=primary,file.driver=nbd,file. +> host=x.x.x.x,file.port=8889,file.export=secondary-disk0, +> node-name=nbd_client0'}} +> {'execute': 'x-blockdev-change', 'arguments':{'parent': 'primary-disk0', +> 'node': 'nbd_client0' } } +> {'execute': 'migrate-set-capabilities', 'arguments': {'capabilities': +> [{'capability': 'x-colo', 'state': true } ] } } +> {'execute': 'migrate', 'arguments': {'uri': 'tcp:x.x.x.x:8888'}} +> +> 4. Then secondary immediately crashed: +> qemu-system-x86_64: block.c:4893: bdrv_detach_aio_context: Assertion +> `!bs->walking_aio_notifiers' failed. +> +> (gdb) bt +> #0 0x00007fb50d241277 in raise () from /lib64/libc.so.6 +> #1 0x00007fb50d242968 in abort () from /lib64/libc.so.6 +> #2 0x00007fb50d23a096 in __assert_fail_base () from /lib64/libc.so.6 +> #3 0x00007fb50d23a142 in __assert_fail () from /lib64/libc.so.6 +> #4 0x0000000000706ae9 in bdrv_detach_aio_context (bs=0x2e84000) at +> block.c:4893 +> #5 0x0000000000706ab8 in bdrv_detach_aio_context (bs=bs@entry=0x315d400) +> at block.c:4911 +> #6 0x0000000000706c16 in bdrv_set_aio_context (bs=0x315d400, +> new_context=0x2e17180) at block.c:4960 +> #7 0x000000000070a43d in block_job_attached_aio_context +> (new_context=<optimized out>, opaque=0x2d92000) at blockjob.c:111 +> #8 0x0000000000706b93 in bdrv_attach_aio_context (bs=0x2e84000, +> new_context=new_context@entry=0x2e17180) at block.c:4942 +> #9 0x0000000000706b2b in bdrv_attach_aio_context (bs=0x315d400, +> new_context=new_context@entry=0x2e17180) at block.c:4930 +> #10 0x0000000000706b2b in bdrv_attach_aio_context (bs=0x2ff8800, +> new_context=new_context@entry=0x2e17180) at block.c:4930 +> #11 0x0000000000706b2b in bdrv_attach_aio_context (bs=bs@entry=0x2ff5400, +> new_context=new_context@entry=0x2e17180) at block.c:4930 +> #12 0x0000000000706c29 in bdrv_set_aio_context (bs=0x2ff5400, +> new_context=0x2e17180) at block.c:4966 +> #13 0x0000000000748a17 in blk_set_aio_context (blk=<optimized out>, +> new_context=<optimized out>) at block/block-backend.c:1894 +> #14 0x000000000049b60a in virtio_blk_data_plane_start (vdev=<optimized +> out>) at /root/wangchao/qemu-colo-18jul22/hw/block/dataplane/ +> virtio-blk.c:215 +> #15 0x000000000069ceda in virtio_bus_start_ioeventfd (bus=bus@entry=0x46280f8) +> at hw/virtio/virtio-bus.c:223 +> #16 0x00000000006a2480 in virtio_pci_start_ioeventfd (proxy=0x4620000) at +> hw/virtio/virtio-pci.c:288 +> #17 virtio_pci_common_write (opaque=0x4620000, addr=<optimized out>, +> val=<optimized out>, size=<optimized out>) at hw/virtio/virtio-pci.c:1288 +> #18 0x00000000004673b8 in memory_region_write_accessor (mr=0x46209d0, +> addr=20, value=<optimized out>, size=1, shift=<optimized out>, +> mask=<optimized out>, attrs=...) at /root/wangchao/qemu-colo- +> 18jul22/memory.c:527 +> #19 0x0000000000466c63 in access_with_adjusted_size (addr=addr@entry=20, +> value=value@entry=0x7fb509ba4788, size=size@entry=1, +> access_size_min=<optimized out>, access_size_max=<optimized out>, +> access_fn=access_fn@entry=0x467340 <memory_region_write_accessor>, +> mr=mr@entry=0x46209d0, attrs=attrs@entry=...) at /root/wangchao/qemu-colo- +> 18jul22/memory.c:594 +> #20 0x0000000000469388 in memory_region_dispatch_write (mr=mr@entry=0x46209d0, +> addr=addr@entry=20, data=15, size=1, attrs=attrs@entry=...) at +> /root/wangchao/qemu-colo-18jul22/memory.c:1473 +> #21 0x000000000041ada0 in flatview_write_continue (fv=fv@entry=0x459ec80, +> addr=addr@entry=4273963028, attrs=..., attrs@entry=..., buf=buf@entry=0x7fb51019a028 +> <Address 0x7fb51019a028 out of bounds>, len=len@entry=1, addr1=20, +> l=1,mr=0x46209d0) at /root/wangchao/qemu-colo-18jul22/exec.c:3255 +> #22 0x000000000041af62 in flatview_write (fv=0x459ec80, addr=4273963028, +> attrs=..., buf=0x7fb51019a028 <Address 0x7fb51019a028 out of bounds>, +> len=1) at /root/wangchao/qemu-colo-18jul22/exec.c:3294 +> +> It seems we were trying to do another aio_notifiers walk *inside a +> aio_notifiers walk*. +> +> Thanks +> WANG Chao +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1754542 +> +> Title: +> colo: vm crash with segmentation fault +> +> Status in QEMU: +> New +> +> Bug description: +> I use Arch Linux x86_64 +> Zhang Chen's(https://github.com/zhangckid/qemu/tree/qemu-colo-18mar10) +> Following document 'COLO-FT.txt', +> I test colo feature on my hosts +> +> I run this command +> Primary: +> sudo /usr/local/bin/qemu-system-x86_64 -enable-kvm -m 2048 -smp 2 -qmp +> stdio -name primary \ +> -device piix3-usb-uhci \ +> -device usb-tablet -netdev tap,id=hn0,vhost=off \ +> -device virtio-net-pci,id=net-pci0,netdev=hn0 \ +> -drive if=virtio,id=primary-disk0,driver=quorum,read-pattern= +> fifo,vote-threshold=1,\ +> children.0.file.filename=/var/lib/libvirt/images/1.raw,\ +> children.0.driver=raw -S +> +> Secondary: +> sudo /usr/local/bin/qemu-system-x86_64 -enable-kvm -m 2048 -smp 2 -qmp +> stdio -name secondary \ +> -device piix3-usb-uhci \ +> -device usb-tablet -netdev tap,id=hn0,vhost=off \ +> -device virtio-net-pci,id=net-pci0,netdev=hn0 \ +> -drive if=none,id=secondary-disk0,file.filename=/var/lib/ +> libvirt/images/2.raw,driver=raw,node-name=node0 \ +> -drive if=virtio,id=active-disk0,driver=replication,mode=secondary,\ +> file.driver=qcow2,top-id=active-disk0,\ +> file.file.filename=/mnt/ramfs/active_disk.img,\ +> file.backing.driver=qcow2,\ +> file.backing.file.filename=/mnt/ramfs/hidden_disk.img,\ +> file.backing.backing=secondary-disk0 \ +> -incoming tcp:0:8888 +> +> Secondary: +> {'execute':'qmp_capabilities'} +> { 'execute': 'nbd-server-start', +> 'arguments': {'addr': {'type': 'inet', 'data': {'host': +> '192.168.0.34', 'port': '8889'} } } +> } +> {'execute': 'nbd-server-add', 'arguments': {'device': 'secondary-disk0', +> 'writable': true } } +> +> Primary: +> {'execute':'qmp_capabilities'} +> { 'execute': 'human-monitor-command', +> 'arguments': {'command-line': 'drive_add -n buddy +> driver=replication,mode=primary,file.driver=nbd,file. +> host=192.168.0.34,file.port=8889,file.export=secondary- +> disk0,node-name=nbd_client0'}} +> { 'execute':'x-blockdev-change', 'arguments':{'parent': 'primary-disk0', +> 'node': 'nbd_client0' } } +> { 'execute': 'migrate-set-capabilities', +> 'arguments': {'capabilities': [ {'capability': 'x-colo', 'state': +> true } ] } } +> { 'execute': 'migrate', 'arguments': {'uri': 'tcp:192.168.0.34:8888' } } +> And two VM with cash +> Primary: +> {"timestamp": {"seconds": 1520763655, "microseconds": 511415}, "event": +> "RESUME"} +> [1] 329 segmentation fault sudo /usr/local/bin/qemu-system-x86_64 +> -boot c -enable-kvm -m 2048 -smp 2 -qm +> +> Secondary: +> {"timestamp": {"seconds": 1520763655, "microseconds": 510907}, "event": +> "RESUME"} +> [1] 367 segmentation fault sudo /usr/local/bin/qemu-system-x86_64 +> -boot c -enable-kvm -m 2048 -smp 2 -qm +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1754542/+subscriptions +> + + +Yes, ide works. + +And by the way, how about other virtio devices or vhost-xxx? Are they supported by COLO? + +Do you know the working set of devices? My preliminary test shows ide, e1000, rtl8139 work. + +Thanks +WANG Chao + +Currently, we support virtio-net, and not support all vhost-xxx. + + + +On Fri, Jul 27, 2018 at 6:41 PM WANG Chao <email address hidden> +wrote: + +> Yes, ide works. +> +> And by the way, how about other virtio devices or vhost-xxx? Are they +> supported by COLO? +> +> Do you know the working set of devices? My preliminary test shows ide, +> e1000, rtl8139 work. +> +> Thanks +> WANG Chao +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1754542 +> +> Title: +> colo: vm crash with segmentation fault +> +> Status in QEMU: +> New +> +> Bug description: +> I use Arch Linux x86_64 +> Zhang Chen's(https://github.com/zhangckid/qemu/tree/qemu-colo-18mar10) +> Following document 'COLO-FT.txt', +> I test colo feature on my hosts +> +> I run this command +> Primary: +> sudo /usr/local/bin/qemu-system-x86_64 -enable-kvm -m 2048 -smp 2 -qmp +> stdio -name primary \ +> -device piix3-usb-uhci \ +> -device usb-tablet -netdev tap,id=hn0,vhost=off \ +> -device virtio-net-pci,id=net-pci0,netdev=hn0 \ +> -drive +> if=virtio,id=primary-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,\ +> children.0.file.filename=/var/lib/libvirt/images/1.raw,\ +> children.0.driver=raw -S +> +> Secondary: +> sudo /usr/local/bin/qemu-system-x86_64 -enable-kvm -m 2048 -smp 2 -qmp +> stdio -name secondary \ +> -device piix3-usb-uhci \ +> -device usb-tablet -netdev tap,id=hn0,vhost=off \ +> -device virtio-net-pci,id=net-pci0,netdev=hn0 \ +> -drive +> if=none,id=secondary-disk0,file.filename=/var/lib/libvirt/images/2.raw,driver=raw,node-name=node0 +> \ +> -drive if=virtio,id=active-disk0,driver=replication,mode=secondary,\ +> file.driver=qcow2,top-id=active-disk0,\ +> file.file.filename=/mnt/ramfs/active_disk.img,\ +> file.backing.driver=qcow2,\ +> file.backing.file.filename=/mnt/ramfs/hidden_disk.img,\ +> file.backing.backing=secondary-disk0 \ +> -incoming tcp:0:8888 +> +> Secondary: +> {'execute':'qmp_capabilities'} +> { 'execute': 'nbd-server-start', +> 'arguments': {'addr': {'type': 'inet', 'data': {'host': +> '192.168.0.34', 'port': '8889'} } } +> } +> {'execute': 'nbd-server-add', 'arguments': {'device': 'secondary-disk0', +> 'writable': true } } +> +> Primary: +> {'execute':'qmp_capabilities'} +> { 'execute': 'human-monitor-command', +> 'arguments': {'command-line': 'drive_add -n buddy +> driver=replication,mode=primary,file.driver=nbd,file.host=192.168.0.34,file.port=8889,file.export=secondary-disk0,node-name=nbd_client0'}} +> { 'execute':'x-blockdev-change', 'arguments':{'parent': 'primary-disk0', +> 'node': 'nbd_client0' } } +> { 'execute': 'migrate-set-capabilities', +> 'arguments': {'capabilities': [ {'capability': 'x-colo', 'state': +> true } ] } } +> { 'execute': 'migrate', 'arguments': {'uri': 'tcp:192.168.0.34:8888' } } +> And two VM with cash +> Primary: +> {"timestamp": {"seconds": 1520763655, "microseconds": 511415}, "event": +> "RESUME"} +> [1] 329 segmentation fault sudo /usr/local/bin/qemu-system-x86_64 +> -boot c -enable-kvm -m 2048 -smp 2 -qm +> +> Secondary: +> {"timestamp": {"seconds": 1520763655, "microseconds": 510907}, "event": +> "RESUME"} +> [1] 367 segmentation fault sudo /usr/local/bin/qemu-system-x86_64 +> -boot c -enable-kvm -m 2048 -smp 2 -qm +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1754542/+subscriptions +> + + +Hi Zhang Chen , + +I try colo follow https://wiki.qemu.org/Features/COLO. +It work well. But disk performance slow. +Only host performance 10%. +Can virtio blk supported by current colo? +Or is there any other way to improve disk performance. + +Thanks +Zhang Chen + +Hi Zhang Chen , + +I try colo follow https://wiki.qemu.org/Features/COLO. +It work well. But disk performance slow. +Only host performance 10%. +Can virtio blk supported by current colo? +Or is there any other way to improve disk performance. + +Thanks +lee + +Hi Lee, + +Can you introduce to me the detail test step about disk performance? +I want to look into it when I have time. + +Thanks +Zhang Chen + +On Wed, Nov 27, 2019 at 10:50 AM lee <email address hidden> wrote: +> +> Hi Zhang Chen , +> +> I try colo follow https://wiki.qemu.org/Features/COLO. +> It work well. But disk performance slow. +> Only host performance 10%. +> Can virtio blk supported by current colo? +> Or is there any other way to improve disk performance. +> +> Thanks +> Zhang Chen +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1754542 +> +> Title: +> colo: vm crash with segmentation fault +> +> Status in QEMU: +> Fix Released +> +> Bug description: +> I use Arch Linux x86_64 +> Zhang Chen's(https://github.com/zhangckid/qemu/tree/qemu-colo-18mar10) +> Following document 'COLO-FT.txt', +> I test colo feature on my hosts +> +> I run this command +> Primary: +> sudo /usr/local/bin/qemu-system-x86_64 -enable-kvm -m 2048 -smp 2 -qmp stdio -name primary \ +> -device piix3-usb-uhci \ +> -device usb-tablet -netdev tap,id=hn0,vhost=off \ +> -device virtio-net-pci,id=net-pci0,netdev=hn0 \ +> -drive if=virtio,id=primary-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,\ +> children.0.file.filename=/var/lib/libvirt/images/1.raw,\ +> children.0.driver=raw -S +> +> Secondary: +> sudo /usr/local/bin/qemu-system-x86_64 -enable-kvm -m 2048 -smp 2 -qmp stdio -name secondary \ +> -device piix3-usb-uhci \ +> -device usb-tablet -netdev tap,id=hn0,vhost=off \ +> -device virtio-net-pci,id=net-pci0,netdev=hn0 \ +> -drive if=none,id=secondary-disk0,file.filename=/var/lib/libvirt/images/2.raw,driver=raw,node-name=node0 \ +> -drive if=virtio,id=active-disk0,driver=replication,mode=secondary,\ +> file.driver=qcow2,top-id=active-disk0,\ +> file.file.filename=/mnt/ramfs/active_disk.img,\ +> file.backing.driver=qcow2,\ +> file.backing.file.filename=/mnt/ramfs/hidden_disk.img,\ +> file.backing.backing=secondary-disk0 \ +> -incoming tcp:0:8888 +> +> Secondary: +> {'execute':'qmp_capabilities'} +> { 'execute': 'nbd-server-start', +> 'arguments': {'addr': {'type': 'inet', 'data': {'host': '192.168.0.34', 'port': '8889'} } } +> } +> {'execute': 'nbd-server-add', 'arguments': {'device': 'secondary-disk0', 'writable': true } } +> +> Primary: +> {'execute':'qmp_capabilities'} +> { 'execute': 'human-monitor-command', +> 'arguments': {'command-line': 'drive_add -n buddy driver=replication,mode=primary,file.driver=nbd,file.host=192.168.0.34,file.port=8889,file.export=secondary-disk0,node-name=nbd_client0'}} +> { 'execute':'x-blockdev-change', 'arguments':{'parent': 'primary-disk0', 'node': 'nbd_client0' } } +> { 'execute': 'migrate-set-capabilities', +> 'arguments': {'capabilities': [ {'capability': 'x-colo', 'state': true } ] } } +> { 'execute': 'migrate', 'arguments': {'uri': 'tcp:192.168.0.34:8888' } } +> And two VM with cash +> Primary: +> {"timestamp": {"seconds": 1520763655, "microseconds": 511415}, "event": "RESUME"} +> [1] 329 segmentation fault sudo /usr/local/bin/qemu-system-x86_64 -boot c -enable-kvm -m 2048 -smp 2 -qm +> +> Secondary: +> {"timestamp": {"seconds": 1520763655, "microseconds": 510907}, "event": "RESUME"} +> [1] 367 segmentation fault sudo /usr/local/bin/qemu-system-x86_64 -boot c -enable-kvm -m 2048 -smp 2 -qm +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1754542/+subscriptions + + +Hi Zhang Chen +I use sysbench compare Host、Qemu Native VM(virtio-blk)、Qemu Native VM、Qemu +colo disk performance. +The result in below attachment. +Qemu Native VM(virtio-blk) use -device virtio-blk-pci +Qemu colo follow https://wiki.qemu.org/Features/COLO +Thanks +Lee + +Zhang Chen <email address hidden> 于2019年11月27日周三 上午11:15写道： + +> Hi Lee, +> +> Can you introduce to me the detail test step about disk performance? +> I want to look into it when I have time. +> +> Thanks +> Zhang Chen +> +> On Wed, Nov 27, 2019 at 10:50 AM lee <email address hidden> wrote: +> > +> > Hi Zhang Chen , +> > +> > I try colo follow https://wiki.qemu.org/Features/COLO. +> > It work well. But disk performance slow. +> > Only host performance 10%. +> > Can virtio blk supported by current colo? +> > Or is there any other way to improve disk performance. +> > +> > Thanks +> > Zhang Chen +> > +> > -- +> > You received this bug notification because you are subscribed to the bug +> > report. +> > https://bugs.launchpad.net/bugs/1754542 +> > +> > Title: +> > colo: vm crash with segmentation fault +> > +> > Status in QEMU: +> > Fix Released +> > +> > Bug description: +> > I use Arch Linux x86_64 +> > Zhang Chen's(https://github.com/zhangckid/qemu/tree/qemu-colo-18mar10) +> > Following document 'COLO-FT.txt', +> > I test colo feature on my hosts +> > +> > I run this command +> > Primary: +> > sudo /usr/local/bin/qemu-system-x86_64 -enable-kvm -m 2048 -smp 2 -qmp +> stdio -name primary \ +> > -device piix3-usb-uhci \ +> > -device usb-tablet -netdev tap,id=hn0,vhost=off \ +> > -device virtio-net-pci,id=net-pci0,netdev=hn0 \ +> > -drive +> if=virtio,id=primary-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,\ +> > children.0.file.filename=/var/lib/libvirt/images/1.raw,\ +> > children.0.driver=raw -S +> > +> > Secondary: +> > sudo /usr/local/bin/qemu-system-x86_64 -enable-kvm -m 2048 -smp 2 -qmp +> stdio -name secondary \ +> > -device piix3-usb-uhci \ +> > -device usb-tablet -netdev tap,id=hn0,vhost=off \ +> > -device virtio-net-pci,id=net-pci0,netdev=hn0 \ +> > -drive +> if=none,id=secondary-disk0,file.filename=/var/lib/libvirt/images/2.raw,driver=raw,node-name=node0 +> \ +> > -drive if=virtio,id=active-disk0,driver=replication,mode=secondary,\ +> > file.driver=qcow2,top-id=active-disk0,\ +> > file.file.filename=/mnt/ramfs/active_disk.img,\ +> > file.backing.driver=qcow2,\ +> > file.backing.file.filename=/mnt/ramfs/hidden_disk.img,\ +> > file.backing.backing=secondary-disk0 \ +> > -incoming tcp:0:8888 +> > +> > Secondary: +> > {'execute':'qmp_capabilities'} +> > { 'execute': 'nbd-server-start', +> > 'arguments': {'addr': {'type': 'inet', 'data': {'host': +> '192.168.0.34', 'port': '8889'} } } +> > } +> > {'execute': 'nbd-server-add', 'arguments': {'device': +> 'secondary-disk0', 'writable': true } } +> > +> > Primary: +> > {'execute':'qmp_capabilities'} +> > { 'execute': 'human-monitor-command', +> > 'arguments': {'command-line': 'drive_add -n buddy +> driver=replication,mode=primary,file.driver=nbd,file.host=192.168.0.34,file.port=8889,file.export=secondary-disk0,node-name=nbd_client0'}} +> > { 'execute':'x-blockdev-change', 'arguments':{'parent': +> 'primary-disk0', 'node': 'nbd_client0' } } +> > { 'execute': 'migrate-set-capabilities', +> > 'arguments': {'capabilities': [ {'capability': 'x-colo', +> 'state': true } ] } } +> > { 'execute': 'migrate', 'arguments': {'uri': 'tcp:192.168.0.34:8888' +> } } +> > And two VM with cash +> > Primary: +> > {"timestamp": {"seconds": 1520763655, "microseconds": 511415}, +> "event": "RESUME"} +> > [1] 329 segmentation fault sudo /usr/local/bin/qemu-system-x86_64 +> -boot c -enable-kvm -m 2048 -smp 2 -qm +> > +> > Secondary: +> > {"timestamp": {"seconds": 1520763655, "microseconds": 510907}, +> "event": "RESUME"} +> > [1] 367 segmentation fault sudo /usr/local/bin/qemu-system-x86_64 +> -boot c -enable-kvm -m 2048 -smp 2 -qm +> > +> > To manage notifications about this bug go to: +> > https://bugs.launchpad.net/qemu/+bug/1754542/+subscriptions +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1754542 +> +> Title: +> colo: vm crash with segmentation fault +> +> Status in QEMU: +> Fix Released +> +> Bug description: +> I use Arch Linux x86_64 +> Zhang Chen's(https://github.com/zhangckid/qemu/tree/qemu-colo-18mar10) +> Following document 'COLO-FT.txt', +> I test colo feature on my hosts +> +> I run this command +> Primary: +> sudo /usr/local/bin/qemu-system-x86_64 -enable-kvm -m 2048 -smp 2 -qmp +> stdio -name primary \ +> -device piix3-usb-uhci \ +> -device usb-tablet -netdev tap,id=hn0,vhost=off \ +> -device virtio-net-pci,id=net-pci0,netdev=hn0 \ +> -drive +> if=virtio,id=primary-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,\ +> children.0.file.filename=/var/lib/libvirt/images/1.raw,\ +> children.0.driver=raw -S +> +> Secondary: +> sudo /usr/local/bin/qemu-system-x86_64 -enable-kvm -m 2048 -smp 2 -qmp +> stdio -name secondary \ +> -device piix3-usb-uhci \ +> -device usb-tablet -netdev tap,id=hn0,vhost=off \ +> -device virtio-net-pci,id=net-pci0,netdev=hn0 \ +> -drive +> if=none,id=secondary-disk0,file.filename=/var/lib/libvirt/images/2.raw,driver=raw,node-name=node0 +> \ +> -drive if=virtio,id=active-disk0,driver=replication,mode=secondary,\ +> file.driver=qcow2,top-id=active-disk0,\ +> file.file.filename=/mnt/ramfs/active_disk.img,\ +> file.backing.driver=qcow2,\ +> file.backing.file.filename=/mnt/ramfs/hidden_disk.img,\ +> file.backing.backing=secondary-disk0 \ +> -incoming tcp:0:8888 +> +> Secondary: +> {'execute':'qmp_capabilities'} +> { 'execute': 'nbd-server-start', +> 'arguments': {'addr': {'type': 'inet', 'data': {'host': +> '192.168.0.34', 'port': '8889'} } } +> } +> {'execute': 'nbd-server-add', 'arguments': {'device': 'secondary-disk0', +> 'writable': true } } +> +> Primary: +> {'execute':'qmp_capabilities'} +> { 'execute': 'human-monitor-command', +> 'arguments': {'command-line': 'drive_add -n buddy +> driver=replication,mode=primary,file.driver=nbd,file.host=192.168.0.34,file.port=8889,file.export=secondary-disk0,node-name=nbd_client0'}} +> { 'execute':'x-blockdev-change', 'arguments':{'parent': 'primary-disk0', +> 'node': 'nbd_client0' } } +> { 'execute': 'migrate-set-capabilities', +> 'arguments': {'capabilities': [ {'capability': 'x-colo', 'state': +> true } ] } } +> { 'execute': 'migrate', 'arguments': {'uri': 'tcp:192.168.0.34:8888' } } +> And two VM with cash +> Primary: +> {"timestamp": {"seconds": 1520763655, "microseconds": 511415}, "event": +> "RESUME"} +> [1] 329 segmentation fault sudo /usr/local/bin/qemu-system-x86_64 +> -boot c -enable-kvm -m 2048 -smp 2 -qm +> +> Secondary: +> {"timestamp": {"seconds": 1520763655, "microseconds": 510907}, "event": +> "RESUME"} +> [1] 367 segmentation fault sudo /usr/local/bin/qemu-system-x86_64 +> -boot c -enable-kvm -m 2048 -smp 2 -qm +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1754542/+subscriptions +> + + diff --git a/results/classifier/105/mistranslation/1756080 b/results/classifier/105/mistranslation/1756080 new file mode 100644 index 000000000..b54e7994d --- /dev/null +++ b/results/classifier/105/mistranslation/1756080 @@ -0,0 +1,20 @@ +mistranslation: 0.887 +other: 0.852 +boot: 0.822 +device: 0.687 +instruction: 0.600 +semantic: 0.511 +graphic: 0.416 +socket: 0.333 +vnc: 0.291 +network: 0.261 +assembly: 0.166 +KVM: 0.098 + +QEMU does not provide non-Linux kernels with ATAGS structure on ARM targets + +This would be a useful feature. Many kernels, particularly hobbyist kernels, have support for ATAGS. + +QEMU doesn't care whether the kernel you provide it is Linux or something else. If you pass -kernel something that's not an ELF file, we'll load and boot it using the Linux boot protocol (including ATAGS, potentially). If you pass an ELF file or pass -bios a binary blob, we'll just start it in the way the CPU usually resets, on the assumption it can deal with whatever that is. + + diff --git a/results/classifier/105/mistranslation/1756519 b/results/classifier/105/mistranslation/1756519 new file mode 100644 index 000000000..e988af9f2 --- /dev/null +++ b/results/classifier/105/mistranslation/1756519 @@ -0,0 +1,71 @@ +mistranslation: 0.443 +other: 0.397 +KVM: 0.318 +vnc: 0.313 +device: 0.258 +instruction: 0.231 +graphic: 0.228 +semantic: 0.193 +assembly: 0.190 +socket: 0.185 +network: 0.181 +boot: 0.170 + +qemu linux-user crash in QOM path canonicalization during do_fork() call to cpu_create + +qemu-riscv64 version 2.11.50 (v2.11.0-2491-g2bb39a657a) crashes running gcc libgomp.c/sort-1.c testsuite test case with the following message: + +(process:11683): GLib-CRITICAL **: g_hash_table_iter_next: assertion 'ri->version == ri->hash_table->version' failed +** +ERROR:qom/object.c:1665:object_get_canonical_path_component: code should not be reached +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x60139c16 + + +Backtrace obtained via gdb: + +#0 raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 +#1 0x0000000060139b21 in abort () at abort.c:79 +#2 0x0000000060100505 in g_assertion_message (domain=domain@entry=0x0, file=file@entry=0x60213ca1 "qom/object.c", line=line@entry=1665, + func=func@entry=0x60214420 <__func__.18106> "object_get_canonical_path_component", message=message@entry=0x7fffe8000cd0 "code should not be reached") + at gtestutils.c:2430 +#3 0x0000000060100586 in g_assertion_message_expr (domain=0x0, file=0x60213ca1 "qom/object.c", line=1665, + func=0x60214420 <__func__.18106> "object_get_canonical_path_component", expr=<optimized out>) at gtestutils.c:2453 +#4 0x0000000060098334 in object_get_canonical_path_component (obj=0x7fffe81340b0) at qom/object.c:1665 +#5 0x0000000060098366 in object_get_canonical_path (obj=0x7fffe81340b0) at qom/object.c:1675 +#6 0x000000006008e152 in device_set_realized (obj=0x7fffe81340b0, value=true, errp=0x7ffff762fe68) at hw/core/qdev.c:874 +#7 0x0000000060098bf4 in property_set_bool (obj=0x7fffe81340b0, v=0x7fffe80fd3c0, name=0x60213694 "realized", opaque=0x7fffe80fd140, errp=0x7ffff762fe68) + at qom/object.c:1926 +#8 0x0000000060096fee in object_property_set (obj=0x7fffe81340b0, v=0x7fffe80fd3c0, name=0x60213694 "realized", errp=0x7ffff762fe68) at qom/object.c:1122 +#9 0x0000000060099ebd in object_property_set_qobject (obj=0x7fffe81340b0, value=0x7fffe80fd310, name=0x60213694 "realized", errp=0x7ffff762fe68) + at qom/qom-qobject.c:27 +#10 0x0000000060097274 in object_property_set_bool (obj=0x7fffe81340b0, value=true, name=0x60213694 "realized", errp=0x7ffff762fe68) at qom/object.c:1191 +#11 0x0000000060092ec5 in cpu_create (typename=0x6250e1a0 "any-riscv-cpu") at qom/cpu.c:61 +#12 0x000000006009301a in cpu_generic_init (typename=0x601dd58f "riscv-cpu", cpu_model=0x601dd527 "any") at qom/cpu.c:98 +#13 0x000000006004cb61 in cpu_copy (env=0x7ffff008cd60) at /opt/qemu/linux-user/main.c:3881 +#14 0x000000006005b79a in do_fork (env=0x7ffff008cd60, flags=4001536, newsp=275531880704, parent_tidptr=275531882704, newtls=275531884288, + child_tidptr=275531882704) at /opt/qemu/linux-user/syscall.c:6348 +#15 0x0000000060063e56 in do_syscall (cpu_env=0x7ffff008cd60, num=220, arg1=4001536, arg2=275531880704, arg3=275531882704, arg4=275531884288, + arg5=275531882704, arg6=275531884288, arg7=0, arg8=0) at /opt/qemu/linux-user/syscall.c:10001 +#16 0x000000006004c89f in cpu_loop (env=0x7ffff008cd60) at /opt/qemu/linux-user/main.c:3600 +#17 0x000000006005b68f in clone_func (arg=0x7ffff7775050) at /opt/qemu/linux-user/syscall.c:6311 +#18 0x0000000060121797 in start_thread (arg=0x7ffff7632700) at pthread_create.c:463 +#19 0x000000006019b4fb in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + + +Attached is a test case source code extracted from libgomp test suite. + +Note that it is a multi-threaded and requires 5 or more threads to fail. Number of launched threads is controlled by OMP_NUM_THREADS evironment variable, defaulting to number of hardware threads. Changing constants in the test case makes it fail with different numbers of threads. + +I will attach statically linked riscv64 binary executable if size limits permit. + + + + + +I noticed that this crash is not target specific and it is possible to reproduce it using qemu-x86_64 with the testcase above + +The following patch should fix that: http://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg07437.html + +Should be fixed by 73a988d957b9142e0 (which is the patch jcmvbkbc mentions in comment #4), now in master and will be in 2.12.0. + + diff --git a/results/classifier/105/mistranslation/1767126 b/results/classifier/105/mistranslation/1767126 new file mode 100644 index 000000000..b6056a9be --- /dev/null +++ b/results/classifier/105/mistranslation/1767126 @@ -0,0 +1,28 @@ +mistranslation: 0.744 +graphic: 0.618 +semantic: 0.476 +other: 0.473 +device: 0.433 +network: 0.182 +instruction: 0.161 +boot: 0.115 +vnc: 0.042 +socket: 0.042 +KVM: 0.026 +assembly: 0.016 + +Man page documents qemu -drive if=scsi but it no longer works + +The qemu man page section documenting the -drive option contains + + if=interface + This option defines on which type on interface the drive is + connected. Available types are: ide, scsi, sd, mtd, floppy, + pflash, virtio, none. + +but if=scsi no longer works as of version 2.12.0. + +If you really have to make backwards incompatible changes, it would be helpful if you could at least document them. + +The -drive if=scsi still works on the machines that have a SCSI bus by default. And the change for x86 has been documented in the ChangeLog: https://wiki.qemu.org/ChangeLog/2.12 + diff --git a/results/classifier/105/mistranslation/177 b/results/classifier/105/mistranslation/177 new file mode 100644 index 000000000..ca4275808 --- /dev/null +++ b/results/classifier/105/mistranslation/177 @@ -0,0 +1,14 @@ +mistranslation: 0.994 +other: 0.716 +semantic: 0.663 +device: 0.316 +graphic: 0.214 +network: 0.162 +vnc: 0.118 +boot: 0.042 +instruction: 0.033 +assembly: 0.026 +KVM: 0.018 +socket: 0.013 + +qemu-bridge-helper undocumented and broken diff --git a/results/classifier/105/mistranslation/1772086 b/results/classifier/105/mistranslation/1772086 new file mode 100644 index 000000000..e8ebe27e7 --- /dev/null +++ b/results/classifier/105/mistranslation/1772086 @@ -0,0 +1,46 @@ +mistranslation: 0.865 +semantic: 0.766 +other: 0.657 +device: 0.626 +instruction: 0.554 +graphic: 0.549 +network: 0.489 +vnc: 0.429 +socket: 0.409 +boot: 0.294 +KVM: 0.257 +assembly: 0.150 + +malformed serial data being sent from guest + +When sending data through serial from guest each time 0x0A byte is sent 0x0D is sent before it. For example, when sending {0x29, 0x0A} on the other end I receive {0x29, 0x0D, 0x0A}. + +Something somewhere in the stack is converting LF to CRLF. This could be something inside your guest, or in QEMU, or in the host; to find out where we need more detail. + +Can you describe your setup, including: + * complete QEMU command line + * how you're sending data inside the guest + * how you're reading it on the host end +please? + + +I am unable to provide complete QEMU command line as I'm using virt-manager to deal with configuration. I can say that two serial ports are linked with physical ones through the /dev/ttyS* files. +The guests I tested it with are Windows 98 and Windows XP. For the testing I connected one port to another. I could confirm through a kernel level serial monitor that I was indeed sending just \n but on the second port I received \r\n. I also received \r\n when the port was read by the host. +Host is Ubuntu Xenial. + +After doing a bit of research I think line 142 in file chardev/char-serial.c is problematic. https://github.com/qemu/qemu/blob/master/chardev/char-serial.c#L142 + +It enables output processing, which is something unwanted here. With a simple test program I found out that by default, besides OPOST, ONLCR flag is set in c_oflag. I guess fix would be removing OPOST flag, which would disable any output processing, or setting c_oflag to 0 just to be sure. + +Seems like the problems isn't really new and might be at least 6 years old if not more. https://robert.penz.name/550/mapping-a-serial-device-to-a-kvm-guest-may-lead-to-communication-problems/ + +It's even older than 6 years, see: +https://lists.nongnu.org/archive/html/qemu-devel/2006-06/msg00196.html +and: +https://bugs.launchpad.net/qemu/+bug/1407813 +https://bugs.launchpad.net/qemu/+bug/1715296 + + +Patch has now been committed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=12fb0ac0575df83cec72ec + diff --git a/results/classifier/105/mistranslation/1773743 b/results/classifier/105/mistranslation/1773743 new file mode 100644 index 000000000..c08a93afa --- /dev/null +++ b/results/classifier/105/mistranslation/1773743 @@ -0,0 +1,43 @@ +mistranslation: 0.990 +instruction: 0.787 +device: 0.740 +semantic: 0.739 +graphic: 0.724 +other: 0.716 +vnc: 0.657 +network: 0.520 +socket: 0.506 +boot: 0.277 +KVM: 0.215 +assembly: 0.158 + +qemu-user -g xxx -E LD_PROFILE=xxx segfault + +Here is two simple steps to reproduce the bug: + +$ qemu-x86_64 -E LD_PROFILE=libc.so.6 -E LD_PROFILE_OUTPUT=. -g 12345 -L / /bin/ls + +(libc.so and /bin/ls might change on your system, in this case we just need a binary with a profilable needed library) + +In a other window launch: + +$ gdb +(gdb) target remote :12345 +(gdb) c + +At this point qemu will segfault. + +It seems this problem is appends when sigprof passed to gdb. +One way I have found to bypass this: +patch gdbstub.c gdb_handlesig and ignore sig if +sig == TARGET_SIGPROF +(which means now I can't catch sigprof on gdb anymore) + +We were mis-parsing the 'vCont' packet in the gdb protocol, so when gdb told us "send a SIGPROF (0x1b)" we skipped the first digit in the hex signal number and interpreted it as "send an 0xb", which happens to be SIGSEGV. + +Should be fixed by this: +https://<email address hidden>/ + + +https://gitlab.com/qemu-project/qemu/-/commit/3ddd9036389f5f577e09 + diff --git a/results/classifier/105/mistranslation/1774412 b/results/classifier/105/mistranslation/1774412 new file mode 100644 index 000000000..1b50a0cfe --- /dev/null +++ b/results/classifier/105/mistranslation/1774412 @@ -0,0 +1,30 @@ +mistranslation: 0.991 +semantic: 0.835 +device: 0.773 +vnc: 0.743 +network: 0.735 +graphic: 0.732 +socket: 0.638 +other: 0.609 +instruction: 0.505 +KVM: 0.497 +assembly: 0.463 +boot: 0.455 + +-icount sleep=on|off documentation is confusing + +The documentation for the -icount option in the qemu man page says: + +"When the virtual cpu is sleeping, the virtual time will advance at default speed unless sleep=on|off is specified. With sleep=on|off, the virtual time will jump to the next timer deadline instantly whenever the virtual cpu goes to sleep mode and will not advance if no timer is enabled." + +Taking this literally and specifying "sleep=on|off" on the command line does not work, so presumably the two instances of "sleep=on|off" should be either "sleep=on" or "sleep=off", +whichever is correct :) + +Also, the synopsis line "-icount [shift=N|auto][,rr=record|replay,rrfile=filename,rrsnapshot=snapshot" fails to mention the sleep keyword at all. + +Should be fixed by this patch: +https://<email address hidden>/ + + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=fa647905e6baae9510e7d + diff --git a/results/classifier/105/mistranslation/1776096 b/results/classifier/105/mistranslation/1776096 new file mode 100644 index 000000000..456425465 --- /dev/null +++ b/results/classifier/105/mistranslation/1776096 @@ -0,0 +1,96 @@ +mistranslation: 0.922 +other: 0.899 +vnc: 0.889 +network: 0.885 +instruction: 0.869 +semantic: 0.862 +assembly: 0.860 +boot: 0.856 +socket: 0.854 +graphic: 0.850 +device: 0.848 +KVM: 0.820 + +qemu 2.12.0 qemu-system-ppc illegal instruction on ppc64le, crashes emulator + +% uname -a +Linux tim.floodgap.com 4.16.14-300.fc28.ppc64le #1 SMP Tue Jun 5 15:59:48 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux + +STR: +Start QEMU and boot Mac OS X 10.4.11. +Download the current version of TenFourFox (I used G3 so that AltiVec was not a confounder). +Try to start TenFourFox in safe mode (hold down Option as you double-click while the icon bounces in the Dock). + +Expected: +TenFourFox starts. + +Actual: +The entire emulator exits with an illegal instruction error. + +Trace of session (including some disassembly so you can see where TCG went wrong): + +tim:/home/spectre/src/qemu-2.12.0/ppc-softmmu/% gdb --args ./qemu-system-ppc -M mac99,accel=tcg -m 2048 -prom-env boot-args=-v -boot c -drive file=tigerhd.img,format=raw,cache=none -netdev user,id=mynet0 -device usb-net,netdev=mynet0 -usb -device usb-tablet + +GNU gdb (GDB) Fedora 8.1-15.fc28 +[...] +Reading symbols from ./qemu-system-ppc...done. +(gdb) run +[...] + +Thread 6 "qemu-system-ppc" received signal SIGSEGV, Segmentation fault. +[Switching to Thread 0x7ffff242ea30 (LWP 7017)] +0xfffffffffffffffc in ?? () +#0 0xfffffffffffffffc in () +#1 0x00007fffd4edec00 in code_gen_buffer () +#2 0x00000000100c9e20 in cpu_tb_exec (itb=<optimized out>, cpu=<optimized out>) at /home/spectre/src/qemu-2.12.0/accel/tcg/cpu-exec.c:169 +#3 0x00000000100c9e20 in cpu_loop_exec_tb (tb_exit=<synthetic pointer>, last_tb=<synthetic pointer>, tb=<optimized out>, cpu=<optimized out>) + at /home/spectre/src/qemu-2.12.0/accel/tcg/cpu-exec.c:626 +#4 0x00000000100c9e20 in cpu_exec (cpu=<optimized out>) + at /home/spectre/src/qemu-2.12.0/accel/tcg/cpu-exec.c:734 +#5 0x000000001007decc in tcg_cpu_exec (cpu=0x11774e10) + at /home/spectre/src/qemu-2.12.0/cpus.c:1362 +(gdb) disas 0x00007fffd4edebf0, 0x00007fffd4edec10 +Dump of assembler code from 0x7fffd4edebf0 to 0x7fffd4edec10: + 0x00007fffd4edebf0 <code_gen_buffer+284027700>: addi r0,r4,3 + 0x00007fffd4edebf4 <code_gen_buffer+284027704>: rlwinm r0,r0,0,0,19 + 0x00007fffd4edebf8 <code_gen_buffer+284027708>: cmplw cr7,r0,r12 + 0x00007fffd4edebfc <code_gen_buffer+284027712>: bnel cr7,0x7fffd4ed8b64 <code_gen_buffer+284002984> + 0x00007fffd4edec00 <code_gen_buffer+284027716>: lwbrx r14,r3,r4 + 0x00007fffd4edec04 <code_gen_buffer+284027720>: stw r14,40(r27) + 0x00007fffd4edec08 <code_gen_buffer+284027724>: clrldi r4,r14,32 + 0x00007fffd4edec0c <code_gen_buffer+284027728>: rlwinm r3,r4,25,19,26 +End of assembler dump. +(gdb) disas 0x7fffd4ed8b60, 0x7fffd4ed8b70 +Dump of assembler code from 0x7fffd4ed8b60 to 0x7fffd4ed8b70: + 0x00007fffd4ed8b60 <code_gen_buffer+284002980>: bctrl + 0x00007fffd4ed8b64 <code_gen_buffer+284002984>: mtctr r3 + 0x00007fffd4ed8b68 <code_gen_buffer+284002988>: mr r31,r3 + 0x00007fffd4ed8b6c <code_gen_buffer+284002992>: li r3,0 +End of assembler dump. +(gdb) i reg ctr +ctr 0xffffffffffffffff 18446744073709551615 + +It appears that the branch at 0x00007fffd4edebfc caused a jump back (a return?) through CTR, but CTR has -1 in it, hence setting PC to 0xfffffffffffffffc. I am not sure how to debug this further. + +Sorry, more complete disassembly of the apparent actual fault: + + 0x00007fffd4ed8b64 <code_gen_buffer+284002984>: mtctr r3 + 0x00007fffd4ed8b68 <code_gen_buffer+284002988>: mr r31,r3 + 0x00007fffd4ed8b6c <code_gen_buffer+284002992>: li r3,0 + 0x00007fffd4ed8b70 <code_gen_buffer+284002996>: bctr + + +Hi, Cameron. + +The step "Start QEMU and boot Mac OS X 10.4.11" is not clear to me. Is there a location where one could download such image and boot? + +I wonder how one without access to a Mac image can reproduce this issue. + +Cheers +Murilo + +The QEMU project is currently considering to move 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 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/105/mistranslation/1777293 b/results/classifier/105/mistranslation/1777293 new file mode 100644 index 000000000..d3e20fd7b --- /dev/null +++ b/results/classifier/105/mistranslation/1777293 @@ -0,0 +1,26 @@ +mistranslation: 0.920 +semantic: 0.716 +graphic: 0.516 +device: 0.344 +other: 0.318 +instruction: 0.298 +boot: 0.104 +network: 0.101 +vnc: 0.068 +assembly: 0.046 +socket: 0.025 +KVM: 0.018 + +[REQUEST] SHARING MEMORY WITH HOST + +Instead of a preallocated memory heap I would like for QEMU to share memory using shm. + +Example: Instead of using 16gb out of 32gb of ram to run Windows 10, there would be no option to allocate it, but to share the hosts resources; ie giving the host full access to the entire ram stack + + +I'm not a great programmer but I'm pretty sure QEMU's team could find this useful + +Sorry, but I have a hard to to imagine what you exactly mean here. Do you mean a possibility for one application in the guest and one in the host to share a piece of memory? Or do you mean that the operating systems in the host and guest should somehow share the memory (why?)? Or do you just look for a possibility to avoid that the guest has a lot of memory allocated to it when it does not need it? In the latter case, there is already virtio-balloon, so you should have a look at the virtio drivers if you need something like this. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1777969 b/results/classifier/105/mistranslation/1777969 new file mode 100644 index 000000000..a2ba898af --- /dev/null +++ b/results/classifier/105/mistranslation/1777969 @@ -0,0 +1,118 @@ +mistranslation: 0.785 +boot: 0.634 +vnc: 0.627 +other: 0.599 +KVM: 0.589 +graphic: 0.582 +device: 0.572 +instruction: 0.558 +network: 0.532 +assembly: 0.529 +semantic: 0.528 +socket: 0.524 + +Crash with UEFI, q35, AHCI, and <= SystemRescueCD 4.3.0 + +I am getting a crash when booting <= SystemRescueCD 4.3.0 in UEFI mode with q35 machine and from a AHCI device with qemu 2.11.1 and 2.12.0. The crash doesn't occur if I compile with --enable-trace-backends=simple or if I use virtio-scsi. The original crash was noticed on Gentoo with hardened gcc 6.4.0 and an Intel CPU, the test system to reproduce the crash is on Gentoo with non-hardened gcc 5.4.0 and an Intel CPU. + +OVMF version is from Gentoo: edk2-ovmf-2017_p20180211-bin.tar.xz + +Here is the commands I have run on qemu 2.12.0 to reproduce the issue although it also crashes with accel=kvm removed: +./configure --target-list="x86_64-softmmu" +make +qemu-system-x86_64 -nodefaults -machine q35,accel=kvm -cpu qemu64 -drive if=pflash,format=raw,unit=0,file=/usr/share/edk2-ovmf/OVMF_CODE.fd,readonly=on -drive if=pflash,format=raw,unit=1,file=OVMF_VARS.fd -m 512 -drive file=systemrescuecd-x86-4.3.0.iso,if=none,id=cdrom-sysresc,readonly=on -device ide-cd,bus=ide.0,unit=0,drive=cdrom-sysresc,bootindex=5 -device VGA -display gtk + +Valgrind says "Bad permissions for mapped region at address 0x4C022FE0" for the crash. + +Here is a backtrace from gdb: +Program received signal SIGSEGV, Segmentation fault. +0x00007f42dcbc5833 in malloc () from /lib64/libc.so.6 +(gdb) bt +#0 0x00007f42dcbc5833 in malloc () from /lib64/libc.so.6 +#1 0x00007f42e10117d9 in g_malloc () from /usr/lib64/libglib-2.0.so.0 +#2 0x000055a3ff9def8f in qemu_aio_get (aiocb_info=aiocb_info@entry=0x55a4001b39a0 <thread_pool_aiocb_info>, bs=bs@entry=0x0, cb=cb@entry=0x55a3ff9dfe20 <thread_pool_co_cb>, opaque=opaque@entry=0x7f42961e30b0) at util/aiocb.c:33 +#3 0x000055a3ff9e0249 in thread_pool_submit_aio (pool=pool@entry=0x55a400c038d0, func=func@entry=0x55a3ff956620 <aio_worker>, arg=arg@entry=0x55a400bd30b0, cb=cb@entry=0x55a3ff9dfe20 <thread_pool_co_cb>, + opaque=opaque@entry=0x7f42961e30b0) at util/thread-pool.c:251 +#4 0x000055a3ff9e0423 in thread_pool_submit_co (pool=0x55a400c038d0, func=func@entry=0x55a3ff956620 <aio_worker>, arg=arg@entry=0x55a400bd30b0) at util/thread-pool.c:289 +#5 0x000055a3ff956b50 in paio_submit_co (bs=0x55a400bff180, fd=<optimized out>, offset=362702848, qiov=<optimized out>, bytes=2048, type=1) at block/file-posix.c:1536 +#6 0x000055a3ff95c82a in bdrv_driver_preadv (bs=bs@entry=0x55a400bff180, offset=offset@entry=362702848, bytes=bytes@entry=2048, qiov=qiov@entry=0x7f42961e3650, flags=0) at block/io.c:924 +#7 0x000055a3ff960154 in bdrv_aligned_preadv (child=child@entry=0x55a400c03a20, req=req@entry=0x7f42961e32e0, offset=offset@entry=362702848, bytes=bytes@entry=2048, align=align@entry=1, qiov=qiov@entry=0x7f42961e3650, flags=0) + at block/io.c:1228 +#8 0x000055a3ff960434 in bdrv_co_preadv (child=0x55a400c03a20, offset=362702848, bytes=2048, qiov=0x7f42961e3650, flags=0) at block/io.c:1324 +#9 0x000055a3ff95c82a in bdrv_driver_preadv (bs=bs@entry=0x55a400bf8e50, offset=offset@entry=362702848, bytes=bytes@entry=2048, qiov=qiov@entry=0x7f42961e3650, flags=0) at block/io.c:924 +#10 0x000055a3ff960154 in bdrv_aligned_preadv (child=child@entry=0x55a400be92c0, req=req@entry=0x7f42961e3510, offset=offset@entry=362702848, bytes=bytes@entry=2048, align=align@entry=512, qiov=qiov@entry=0x7f42961e3650, flags=0) + at block/io.c:1228 +#11 0x000055a3ff960434 in bdrv_co_preadv (child=0x55a400be92c0, offset=offset@entry=362702848, bytes=bytes@entry=2048, qiov=qiov@entry=0x7f42961e3650, flags=flags@entry=0) at block/io.c:1324 +#12 0x000055a3ff94f4ce in blk_co_preadv (blk=0x55a400bf8ba0, offset=362702848, bytes=2048, qiov=0x7f42961e3650, flags=0) at block/block-backend.c:1158 +#13 0x000055a3ff94f5ac in blk_read_entry (opaque=0x7f42961e3670) at block/block-backend.c:1206 +#14 0x000055a3ff94e000 in blk_prw (blk=0x55a400bf8ba0, offset=362702848, buf=<optimized out>, bytes=bytes@entry=2048, co_entry=co_entry@entry=0x55a3ff94f590 <blk_read_entry>, flags=flags@entry=0) at block/block-backend.c:1243 +#15 0x000055a3ff94f076 in blk_pread (blk=<optimized out>, offset=<optimized out>, buf=<optimized out>, count=count@entry=2048) at block/block-backend.c:1409 +#16 0x000055a3ff7d8b93 in cd_read_sector_sync (s=0x55a401a0faa0) at hw/ide/atapi.c:124 +#17 ide_atapi_cmd_reply_end (s=0x55a401a0faa0) at hw/ide/atapi.c:269 +#18 0x000055a3ff7dde0e in ahci_start_transfer (dma=0x55a401a0f9f0) at hw/ide/ahci.c:1325 +#19 0x000055a3ff7d870c in ide_atapi_cmd_reply_end (s=0x55a401a0faa0) at hw/ide/atapi.c:285 +#20 0x000055a3ff7dde0e in ahci_start_transfer (dma=0x55a401a0f9f0) at hw/ide/ahci.c:1325 +#21 0x000055a3ff7d870c in ide_atapi_cmd_reply_end (s=0x55a401a0faa0) at hw/ide/atapi.c:285 +#22 0x000055a3ff7dde0e in ahci_start_transfer (dma=0x55a401a0f9f0) at hw/ide/ahci.c:1325 +#23 0x000055a3ff7d870c in ide_atapi_cmd_reply_end (s=0x55a401a0faa0) at hw/ide/atapi.c:285 +#24 0x000055a3ff7dde0e in ahci_start_transfer (dma=0x55a401a0f9f0) at hw/ide/ahci.c:1325 +#25 0x000055a3ff7d870c in ide_atapi_cmd_reply_end (s=0x55a401a0faa0) at hw/ide/atapi.c:285 +#26 0x000055a3ff7dde0e in ahci_start_transfer (dma=0x55a401a0f9f0) at hw/ide/ahci.c:1325 +#27 0x000055a3ff7d870c in ide_atapi_cmd_reply_end (s=0x55a401a0faa0) at hw/ide/atapi.c:285 +#28 0x000055a3ff7dde0e in ahci_start_transfer (dma=0x55a401a0f9f0) at hw/ide/ahci.c:1325 +#29 0x000055a3ff7d870c in ide_atapi_cmd_reply_end (s=0x55a401a0faa0) at hw/ide/atapi.c:285 +#30 0x000055a3ff7dde0e in ahci_start_transfer (dma=0x55a401a0f9f0) at hw/ide/ahci.c:1325 +#31 0x000055a3ff7d870c in ide_atapi_cmd_reply_end (s=0x55a401a0faa0) at hw/ide/atapi.c:285 +#32 0x000055a3ff7dde0e in ahci_start_transfer (dma=0x55a401a0f9f0) at hw/ide/ahci.c:1325 +#33 0x000055a3ff7d870c in ide_atapi_cmd_reply_end (s=0x55a401a0faa0) at hw/ide/atapi.c:285 +#34 0x000055a3ff7dde0e in ahci_start_transfer (dma=0x55a401a0f9f0) at hw/ide/ahci.c:1325 +#35 0x000055a3ff7d870c in ide_atapi_cmd_reply_end (s=0x55a401a0faa0) at hw/ide/atapi.c:285 +#36 0x000055a3ff7dde0e in ahci_start_transfer (dma=0x55a401a0f9f0) at hw/ide/ahci.c:1325 +#37 0x000055a3ff7d870c in ide_atapi_cmd_reply_end (s=0x55a401a0faa0) at hw/ide/atapi.c:285 +#38 0x000055a3ff7dde0e in ahci_start_transfer (dma=0x55a401a0f9f0) at hw/ide/ahci.c:1325 +#39 0x000055a3ff7d870c in ide_atapi_cmd_reply_end (s=0x55a401a0faa0) at hw/ide/atapi.c:285 +#40 0x000055a3ff7dde0e in ahci_start_transfer (dma=0x55a401a0f9f0) at hw/ide/ahci.c:1325 +#41 0x000055a3ff7d870c in ide_atapi_cmd_reply_end (s=0x55a401a0faa0) at hw/ide/atapi.c:285 +#42 0x000055a3ff7dde0e in ahci_start_transfer (dma=0x55a401a0f9f0) at hw/ide/ahci.c:1325 +#43 0x000055a3ff7d870c in ide_atapi_cmd_reply_end (s=0x55a401a0faa0) at hw/ide/atapi.c:285 +#44 0x000055a3ff7dde0e in ahci_start_transfer (dma=0x55a401a0f9f0) at hw/ide/ahci.c:1325 +#45 0x000055a3ff7d870c in ide_atapi_cmd_reply_end (s=0x55a401a0faa0) at hw/ide/atapi.c:285 + +Hmm... Is this a stack size protection fault due to the hardening? + +We tried to fix the ATAPI recursion depth issue recently, but caused a regression that stops us from booting with SeaBIOS (maybe UEFI too?) and patches are pending to fix this, so sit tight and I'll have a git commit for you to try soon. + +--js + +Okay thanks. I forgot to mention I am running the Gentoo version of kernel 4.14 series. Here is the configure settings for gcc from my desktop system used to reproduce the crash that originally occurred on the hardened server, and even though the desktop system isn't using hardened profile, this gcc is using some hardened features: + +/var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/gcc-5.4.0/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/5.4.0 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/5.4.0 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/5.4.0/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/5.4.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/include/g++-v5 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/5.4.0/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 5.4.0-r3 p1.3, pie-0.6.5' --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-altivec --disable-fixed-point --enable-targets=all --disable-libgcj --enable-libgomp --disable-libmudflap --disable-libssp --disable-libcilkrts --disable-libmpx --enable-vtable-verify --enable-libvtv --enable-lto --without-isl --enable-libsanitizer + +With git bisect, I have narrowed down the crash to git commit: e4baa9f00b9ddf47ac2811eb58a3931434b848f7 . For git commit: 0e168d35519ee04590a439cd6631f53cd954edd0 , I don't get the crash. + +It looks like this crash is fixed with git commit: bed9bcfa3275a9cfee82846a9f521c4858a9739a + +That's: + +commit bed9bcfa3275a9cfee82846a9f521c4858a9739a +Author: Paolo Bonzini <email address hidden> +Date: Wed Jun 6 15:09:51 2018 -0400 + + ide: push end_transfer_func out of start_transfer callback, rename callback + + Now that end_transfer_func is a tail call in ahci_start_transfer, + formalize the fact that the callback (of which ahci_start_transfer is + the sole implementation) takes care of the transfer too: rename it to + pio_transfer and, if it is present, call the end_transfer_func as soon + as it returns. + + +Which is also in part what caused a regression that we later fixed; + +For anyone stumbling across this in google: you'll find that this should be settled properly for the QEMU 3.0 release. + + +As to why a trace-events patch surfaces this crash in a 'hardened' binary, I'm not sure -- but the root cause is absolutely a stack depth bug which has been present in AHCI since it was checked in to QEMU. + +This bug can be considered fixed as of 3.0; thanks. + diff --git a/results/classifier/105/mistranslation/1778 b/results/classifier/105/mistranslation/1778 new file mode 100644 index 000000000..a52eec52d --- /dev/null +++ b/results/classifier/105/mistranslation/1778 @@ -0,0 +1,14 @@ +mistranslation: 0.892 +device: 0.832 +graphic: 0.678 +other: 0.537 +network: 0.353 +boot: 0.272 +vnc: 0.086 +socket: 0.065 +assembly: 0.046 +instruction: 0.035 +semantic: 0.026 +KVM: 0.020 + +Spice audio play at wrong speed and frequency after qemu-7.2.0 diff --git a/results/classifier/105/mistranslation/1779120 b/results/classifier/105/mistranslation/1779120 new file mode 100644 index 000000000..da9ea013f --- /dev/null +++ b/results/classifier/105/mistranslation/1779120 @@ -0,0 +1,115 @@ +mistranslation: 0.785 +other: 0.782 +device: 0.733 +KVM: 0.726 +socket: 0.712 +boot: 0.711 +vnc: 0.708 +network: 0.707 +assembly: 0.701 +instruction: 0.685 +semantic: 0.677 +graphic: 0.673 + +disk missing in the guest contingently when hotplug several virtio scsi disks consecutively + +Hi, I found a bug that disk missing (not all disks missing ) in the guest contingently when hotplug several virtio scsi disks consecutively. After rebooting the guest,the missing disks appear again. + +The guest is centos7.3 running on a centos7.3 host and the scsi controllers are configed with iothread. The scsi controller xml is below: + + <controller type='scsi' index='0' model='virtio-scsi'> + <driver iothread='26'/> + <alias name='scsi0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> + </controller> + + +If the scsi controllers are configed without iothread, disks are all can be seen in the guest when hotplug several virtio scsi disks consecutively. + +I think the biggest difference between them is that scsi controllers with iothread call virtio_notify_irqfd to notify guest and scsi controllers without + +iothread call virtio_notify instead. What make it difference? Will interrupts are lost when call virtio_notify_irqfd due to race condition for some unknow reasons? Maybe guys more familiar with scsi dataplane can help. Thanks for your reply! + +Please post the following information: +(host)# rpm -qa | grep qemu-kvm +(guest)# uname -r + +What are the exact steps to reproduce this issue (virsh command-lines and XML)? + +I also met this bug + +Hi, Stefan. +(host)# rpm -qa | grep qemu-kvm +qemu-kvm-2.8.1-25.142.x86_64 +(guest)# uname -r +3.10.0-514.el7.x86_64 + +I also tried the newest version of qemu-kvm, but it also met this issue. +The steps to reproduce this issue are below: + +1)attach four virtio-scsi controller with dataplane to vm. + <controller type='scsi' index='0' model='virtio-scsi'> + <driver iothread='1'/> + <alias name='scsi0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' +function='0x0'/> + </controller> + <controller type='scsi' index='1' model='virtio-scsi'> + <driver iothread='2'/> + <alias name='scsi1'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' +function='0x0'/> + </controller> + <controller type='scsi' index='2' model='virtio-scsi'> + <driver iothread='3'/> + <alias name='scsi2'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x0b' +function='0x0'/> + </controller> + <controller type='scsi' index='3' model='virtio-scsi'> + <driver iothread='4'/> + <alias name='scsi3'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x0c' +function='0x0'/> + </controller> + +2)attach 35 virtio-scsi disks(sda - sdai) to vm consecutively. One +controller has 15 scsi disks. +A example of disk xml is below: + <disk type='block' device='lun' rawio='yes'> + <driver name='qemu' type='raw' cache='none' io='native'/> + <source dev='/dev/mapper/360022a11000c1e0a0787bb2500000139'/> + <backingStore/> + <target dev='sda' bus='scsi'/> + <shareable/> + <alias name='scsi0-0-0-0'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + + You can write a shell script like this: + for((i=1;i++;i<=35)) + do + virsh attach-device centos7.3_64_server scsi_disk_$i.xml +--config --live + done + +This issue is a probabilistic event. If it does not appear, repeat the +above steps several more times. +Thank you! + +On 2018/6/28 21:01, Stefan Hajnoczi wrote: +> Please post the following information: +> (host)# rpm -qa | grep qemu-kvm +> (guest)# uname -r +> +> What are the exact steps to reproduce this issue (virsh command-lines +> and XML)? +> + + + +The QEMU project is currently considering to move 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 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/105/mistranslation/1780812 b/results/classifier/105/mistranslation/1780812 new file mode 100644 index 000000000..90b245d37 --- /dev/null +++ b/results/classifier/105/mistranslation/1780812 @@ -0,0 +1,29 @@ +mistranslation: 0.966 +semantic: 0.850 +graphic: 0.838 +instruction: 0.832 +device: 0.831 +network: 0.722 +socket: 0.701 +other: 0.627 +vnc: 0.565 +boot: 0.541 +KVM: 0.286 +assembly: 0.160 + +Full-Screen Switch Does Nothing When Using SDL + +When using SDL switches, e.g. + +-sdl -full-screen -display sdl + +... you'd expect the display to start full-screen, as per the switch description, but it just starts in a window. Pressing the full-screen key combination (Ctrl+Alt+F) enters fullscreen mode as expected. + +Tested on QEmu 2.12.0 using qemu-system-x86_64. + +Suggested a patch here: +http://marc.info/?<email address hidden> + +Fix has been merged: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=6fb34ffcaae0823 + diff --git a/results/classifier/105/mistranslation/1780814 b/results/classifier/105/mistranslation/1780814 new file mode 100644 index 000000000..81a3d1107 --- /dev/null +++ b/results/classifier/105/mistranslation/1780814 @@ -0,0 +1,63 @@ +mistranslation: 0.817 +graphic: 0.759 +device: 0.740 +other: 0.592 +instruction: 0.565 +semantic: 0.555 +network: 0.533 +socket: 0.439 +vnc: 0.383 +boot: 0.381 +KVM: 0.220 +assembly: 0.120 + +lib/raid6/neon4.c:118:1: internal compiler error + +I am facing below issue when i am trying to cross compile kernel for raspberry pi 3. +please give solution . + + +Below is log + + + +CHK include/config/kernel.release + CHK include/generated/uapi/linux/version.h + CHK include/generated/utsrelease.h + CHK include/generated/bounds.h + CHK include/generated/timeconst.h + CHK include/generated/asm-offsets.h + CALL scripts/checksyscalls.sh + CHK scripts/mod/devicetable-offsets.h + CHK include/generated/compile.h + CHK kernel/config_data.h + CC [M] lib/raid6/neon4.o +lib/raid6/neon4.c: In function ‘raid6_neon4_gen_syndrome_real’: +lib/raid6/neon4.c:118:1: internal compiler error: in dwarf2out_frame_debug_adjust_cfa, at dwarf2cfi.c:1078 + } + ^ +Please submit a full bug report, +with preprocessed source if appropriate. +See <https://bugs.launchpad.net/gcc-linaro> for instructions. +scripts/Makefile.build:328: recipe for target 'lib/raid6/neon4.o' failed +make[2]: *** [lib/raid6/neon4.o] Error 1 +scripts/Makefile.build:587: recipe for target 'lib/raid6' failed +make[1]: *** [lib/raid6] Error 2 +Makefile:1034: recipe for target 'lib' failed + +Hi -- this is an internal compiler error reported by your compiler. It's not a QEMU bug. The message suggests that you report it as a GCC bug: "See <https://bugs.launchpad.net/gcc-linaro> for instructions". + + +Thanks peter maydell for your comments. + + + +Hi Peter Maydell , + +is that GCC compiler error or cross-compiler error ? + +It must be the cross compiler. (Why did you report this against QEMU anyway?) + + +I thought it was QEMU issue. Sorry for that. + diff --git a/results/classifier/105/mistranslation/1788098 b/results/classifier/105/mistranslation/1788098 new file mode 100644 index 000000000..3a7a85916 --- /dev/null +++ b/results/classifier/105/mistranslation/1788098 @@ -0,0 +1,1006 @@ +mistranslation: 0.514 +device: 0.512 +network: 0.502 +instruction: 0.496 +boot: 0.495 +semantic: 0.486 +assembly: 0.473 +KVM: 0.431 +other: 0.411 +graphic: 0.380 +socket: 0.344 +vnc: 0.344 + +Avoid migration issues with aligned 2MB THB + +------- Comment From <email address hidden> 2018-08-20 17:12 EDT------- +Hi, in some environments it was observed that this qemu patch to enable THP made it more likely to hit guest migration issues, however the following kernel patch resolves those migration issues: + +https://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git/commit/?h=kvm-ppc-next&id=c066fafc595eef5ae3c83ae3a8305956b8c3ef15 +KVM: PPC: Book3S HV: Use correct pagesize in kvm_unmap_radix() + +Once merged upstream, it would be good to include that change as well to avoid potential migration problems. Should I open a new bug for that or is it better to track here? + +Note Paelzer: I have not seen related migration issues myself, but it seems reasonable and confirmed by IBM. + +Oh, I just realized while initially reported against qemu in bug 1781526 that this is a kernel, and not a qemu patch. + +That spreads the timeline a bit: +- this should be in Cosmic before Release to avoid issues due to the fix of 1781526. + - since that is kind of short I'll bump priority there. +- This has to be in Bionic before a fix for bug 1781526 (I'll wait with a qemu change until this one is complete) + +I'm marking the qemu task invalid (no action there other than to track the Bionic release of this which will finally unblock the SRU of bug 1781526 to Bionic). + +I'm adding a kernel task to reflect that this is a kernel change that is needed. +Finally I'm adding a Cosmic and Bionic Task. + +This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window: + +apport-collect 1788098 + +and then change the status of the bug to 'Confirmed'. + +If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'. + +This change has been made by an automated script, maintained by the Ubuntu Kernel Team. + +For this particular case the log files are not needed and/or applicable. +After discussing in #stable-kernel I set it to confirmed. + +FYI: this is essentially an IBM request, reverse mirroring will happen at some point, but I wanted to make you aware right now + +I built a test kernel with the following patch: +KVM: PPC: Book3S HV: Use correct pagesize in kvm_unmap_radix() + +The test kernel can be downloaded from: +http://kernel.ubuntu.com/~jsalisbury/lp1788098 + +Can you test this kernel and see if it resolves this bug? + +Note about installing test kernels: +• If the test kernel is prior to 4.15(Bionic) you need to install the linux-image and linux-image-extra .deb packages. +• If the test kernel is 4.15(Bionic) or newer, you need to install the linux-modules, linux-modules-extra and linux-image-unsigned .deb packages. + +Thanks in advance! + +------- Comment From <email address hidden> 2018-08-30 10:29 EDT------- +Thanks, I've asked for some testing assistance from our KVM team but will note here some of the details from the original report of this problem.. + +repro steps are just a simple local host migration. + +..they later noted that increasing the speed was a workaround: +(qemu) migrate_set_speed 1G + +so you would want to test w/ default speed to confirm the issue is resolved + +(qemu) migrate -d tcp:localhost:4444 + +using " cosmic qemu version 1:2.12+dfsg-3 " from Bug 169712 / LP 1781526 (which enables qemu to use 2MB THP backing for powerpc), plus the test kernel build from this bug. + +Note without the kernel fix discussed in this bug, a migration problem might still happen even without that qemu THP patch if you got lucky enough to have a 2MB alignment by chance. + +Marking as incomplete while awaiting the IBM testing assistance described in comment #6. + +Nothing yet happened here. +I also declared the related qemu fix that is blocked by this as incomplete. +@manoj/jfh - maybe time for triage-r here? + +After discussions with IBM, reducing the priority. + +------- Comment From <email address hidden> 2018-12-21 12:10 EDT------- +Hello, + +I have been trying to reproduce this bug over this week, but I couldn't do so on Ubuntu. + +Could anyone verify what I have been doing wrong? + +################# + +## QEMU + +I have built version Qemu 3.1.0 and made sure the patch that enables THP was included: +../configure --target-list=ppc-linux-user,ppc64-linux-user,ppc64le-linux-user,ppc-softmmu,ppc64-softmmu --enable-debug-info --enable-trace-backends=log --python=/usr/bin/python3 && make -j $(nproc)' + +./ppc-softmmu/qemu-system-ppc -version +QEMU emulator version 3.1.0 (v3.1.0-dirty) + +## Kernel + +uname -a +Linux NAME 4.15.0-20-generic #21-Ubuntu SMP Tue Apr 24 06:14:44 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux + +cat /sys/kernel/mm/transparent_hugepage/enabled +[always] madvise never + +## CLI command + +Both commands were sent on the same host, (1) is the "migrating from" instance and (2) is the "migrate to" instance. + +(1) +MALLOC_PERTURB_=1 /home/leonardo/qemu/build/ppc64-softmmu/qemu-system-ppc64 \ +-nographic \ +-serial mon:stdio \ +-S \ +-name 'avocado-vt-vm1' \ +-machine pseries \ +-nodefaults \ +-vga std \ +-device pci-bridge,id=pci_bridge,bus=pci.0,addr=0x3,chassis_nr=1 \ +-device virtio-serial-pci,id=virtio_serial_pci0,bus=pci.0,addr=0x4 \ +-object rng-random,filename=/dev/random,id=passthrough-RHq4nIpF \ +-device virtio-rng-pci,id=virtio-rng-pci-aXCni2OX,rng=passthrough-RHq4nIpF,bus=pci.0,addr=0x5 \ +-device nec-usb-xhci,id=usb1,bus=pci.0,addr=0x6 \ +-device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pci.0,addr=0x7 \ +-drive id=drive_image1,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=/home/leonardo/images/ubuntu-18.04-ppc64le.qcow2 \ +-device scsi-hd,id=image1,drive=drive_image1 \ +-m 8192 \ +-smp 4,maxcpus=4,cores=2,threads=1,sockets=2 \ +-device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 \ +-vnc :0 \ +-rtc base=utc,clock=host \ +-boot order=cdn,once=c,menu=off,strict=off \ +-enable-kvm \ +-watchdog i6300esb \ +-watchdog-action reset \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x9 + +(2) Same as above. Changes only a few stuff: +- -name 'avocado-vt-vm1' \ ++ -name 'avocado-vt-vm2' \ +- -vnc :0 \ ++ -vnc :1 \ ++ -incoming tcp:0:5801 \ + +## Testing and Results + +(1) On guest : +# stress --io 5 --cpu 4 +stress: info: [812] dispatching hogs: 4 cpu, 5 io, 0 vm, 0 hdd + +(1) on Qemu Terminal: +(qemu) migrate_set_speed 256 +(qemu) migrate -d tcp:0:5801 +(qemu) info migrate +globals: +store-global-state: on +only-migratable: off +send-configuration: on +send-section-footer: on +capabilities: xbzrle: off rdma-pin-all: off auto-converge: off zero-blocks: off compress: off events: off postcopy-ram: off x-colo: off release-ram: off block: off return-path: off pause-before-switchover: off x +-multifd: off dirty-bitmaps: off +Migration status: completed +total time: 1776 milliseconds +downtime: 61 milliseconds +setup: 9 milliseconds +transferred ram: 422571 kbytes +throughput: 1964.89 mbps +remaining ram: 0 kbytes +total ram: 8405056 kbytes +duplicate: 2006371 pages +skipped: 0 pages +normal: 101037 pages +normal bytes: 404148 kbytes +dirty sync count: 3 +page size: 4 kbytes +(qemu) info status +VM status: paused (postmigrate) + +It's all over on ~2 seconds, no issues. Stress stay running on the new machine. (after cont) + +### + +Other Qemu tested, with the same result: +v2.12 git +v3.0.0 git +Debian 1:2.12+dfsg-3ubuntu8) + +Other Host Kernel tested, with the same result: +4.18.0 - Vanilla, no patch +4.15.0-42-generic +4.15.0-42-generic + patch +4.15.0-32-generic (provided by jsalisbury) +4.15.0-20-generic +4.15.0 - Vanilla, no patch + +------- Comment From <email address hidden> 2019-01-04 06:12 EDT------- +I have tried the following test in order to reproduce the bug: + +## +root@localhost:~# uname -a +Linux localhost 4.15.0-20-generic #21-Ubuntu SMP Tue Apr 24 06:14:44 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux +root@localhost:~# cat /sys/kernel/mm/transparent_hugepage/enabled +[always] madvise never +## + +dd if=/dev/urandom of=/dev/shm/img bs=2M count=2000 +md5sum /dev/shm/img > test.md5 + +After the migration, i did: +md5sum -c test.md5 +And the result was OK. (memory not corrupted). + +I also modified the above test allocating chunks of 2M, this way: + +for i in {0001..2000} ; do dd if=/dev/urandom of=/dev/shm/img_${i} bs=2M count=1 ; done +md5sum /dev/shm/* > test.md5 + +After the migration, i did: +md5sum -c test.md5 +And the result was OK for every file. (memory not corrupted). + +Conclusion: +- I have found no difference between patched and unpatched kernel during the tests. +- The memory after the migration seems fine, returning the same memory block (tested with md5sum) + +Is there any other suggestion about how to reproduce the bug? + +Thanks! + +------- Comment From <email address hidden> 2019-01-04 14:29 EDT------- +Test: Verify all memory after migration + +################### +Host: +################### + +# uname -a +Linux host 4.15.0-20-generic #21-Ubuntu SMP Tue Apr 24 06:14:44 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux + +#cat /sys/kernel/mm/transparent_hugepage/enabled +[always] madvise never + +#cat /proc/cpuinfo +[...] +processor : 159 +cpu : POWER9, altivec supported +clock : 2300.000000MHz +revision : 2.2 (pvr 004e 1202) + +timebase : 512000000 +platform : PowerNV +model : 8375-42A +machine : PowerNV 8375-42A +firmware : OPAL +MMU : Radix + +As previously, I have built version Qemu 3.1.0 and made sure the patch that enables THP was included: +#../configure --target-list=ppc-linux-user,ppc64-linux-user,ppc64le-linux-user,ppc-softmmu,ppc64-softmmu --enable-debug-info --enable-trace-backends=log --python=/usr/bin/python3 && make -j $(nproc)' + +#./ppc-softmmu/qemu-system-ppc -version +QEMU emulator version 3.1.0 (v3.1.0-dirty) + +################### +Guest: +################### + +### CLI 1: Migrating from: +MALLOC_PERTURB_=1 /home/leonardo/qemu/build/ppc64-softmmu/qemu-system-ppc64 \ +-nographic \ +-serial mon:stdio \ +-name 'avocado-vt-vm1' \ +-machine pseries \ +-nodefaults \ +-vga std \ +-device pci-bridge,id=pci_bridge,bus=pci.0,addr=0x3,chassis_nr=1 \ +-device virtio-serial-pci,id=virtio_serial_pci0,bus=pci.0,addr=0x4 \ +-object rng-random,filename=/dev/random,id=passthrough-RHq4nIpF \ +-device virtio-rng-pci,id=virtio-rng-pci-aXCni2OX,rng=passthrough-RHq4nIpF,bus=pci.0,addr=0x5 \ +-device nec-usb-xhci,id=usb1,bus=pci.0,addr=0x6 \ +-device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pci.0,addr=0x7 \ +-drive id=drive_image1,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=/home/leonardo/images/ubuntu-18.04-ppc64le.qcow2 \ +-device scsi-hd,id=image1,drive=drive_image1 \ +-m 8192 \ +-smp 4,maxcpus=4,cores=2,threads=1,sockets=2 \ +-device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 \ +-vnc :0 \ +-rtc base=utc,clock=host \ +-boot order=cdn,once=c,menu=off,strict=off \ +-enable-kvm \ +-watchdog i6300esb \ +-watchdog-action reset \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x9 \ +-initrd /boot/initrd.img-4.15.0-20-generic \ +-kernel /boot/vmlinux-4.15.0-20-generic \ +-append "root=UUID=b4ef9412-06d6-4947-9969-f15c7cc2c986 ro quiet splash + +### CLI 2: Migrating To +Copy of CLI 1, changing: + +- -name 'avocado-vt-vm1' \ ++ -name 'avocado-vt-vm2' \ ++ -S +- -vnc :0 \ ++ -vnc :1 \ ++ -incoming tcp:0:5801 \ + +### Inside Guest: + +#uname -a +Linux localhost 4.15.0-20-generic #21-Ubuntu SMP Tue Apr 24 06:14:44 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux + +# cat /sys/kernel/mm/transparent_hugepage/enabled +[always] madvise never + +#cat /proc/cpuinfo +processor : 3 +cpu : POWER9 (architected), altivec supported +clock : 2900.000000MHz +revision : 2.2 (pvr 004e 1202) + +timebase : 512000000 +platform : pSeries +model : IBM pSeries (emulated by qemu) +machine : CHRP IBM pSeries (emulated by qemu) +MMU : Radix + +################### +Test Software: +################### +I created a simple C file to: +- allocate 2MB blocks, +- write urandom to them, +- md5sum all the blocks together, +- stops, allowing migration, +- re-md5sum everything, +- free the blocks. + +The attached source file is copied to guest, then compiled: +#gcc -o memtest memtest.c -lcrypto + +################### +Procedure +################### + +Use CLI commands to bring up Guest "Migrate from" and "Migrate to". + +On "Migrate from": +root@localhost:~# ./memtest +Block 0 +Block 128 +[...] +Block 3968 +Allocated 4075 blocks of 2097152 size. +Md5 = 209a63b9c1f9acd13fa32236229daa9b <Will change each run> +Press enter key to check memory integrity +<ctrl + z> +[1]+ Stopped ./memtest +root@localhost:~# free -h +total used free shared buff/cache available +Mem: 8.0G 7.7G 246M 64K 21M 37M +Swap: 758M 758M 0B + +- Enter Qemu Monitor: <ctrl + a, c > +QEMU 3.1.0 monitor - type 'help' for more information +(qemu) migrate -d tcp:0:5801 +<Wait till completed> +(qemu) info status +VM status: paused (postmigrate) +(qemu) info migrate +globals: +store-global-state: on +only-migratable: off +send-configuration: on +send-section-footer: on +decompress-error-check: on +capabilities: xbzrle: off rdma-pin-all: off auto-converge: off zero-blocks: off compress: off events: off +postcopy-ram: off x-colo: off release-ram: off block: off return-path: off pause-before-switchover: off +x-multifd: off dirty-bitmaps: off postcopy-blocktime: off late-block-activate: off +Migration status: completed +total time: 248950 milliseconds +downtime: 112 milliseconds +setup: 18 milliseconds +transferred ram: 9847781 kbytes +throughput: 269.52 mbps +remaining ram: 0 kbytes +total ram: 8405056 kbytes +duplicate: 143398 pages +skipped: 0 pages +normal: 2456826 pages +normal bytes: 9827304 kbytes +dirty sync count: 7 +page size: 4 kbytes +multifd bytes: 0 kbytes + +On "Migrate to": +- Enter Qemu Monitor: <ctrl + a, c > +(qemu) info status +VM status: paused +(qemu) cont +(qemu) +- Exit Qemu Monitor: <ctrl + a, c > +root@localhost:~# fg +./teste +<press enter> +Block 0 +Block 128 +[...] +Block 3968 +Freed 4075 blocks of 2097152 size. +Md5 = 209a63b9c1f9acd13fa32236229daa9b +MD5 match! + +################### +Results +################### +- It allocates (almost) all memory, migrate, verify all memory. +- All memory seems to be intact after migration. +- I did this test at least 5 times, MD5 matches everytime. + +################### +NEEDINFO +################### +I still could not reproduce the bug. Is there any suggestion on how to reproduce it? +Am I missing something? + + +------- Comment (attachment only) From <email address hidden> 2019-01-04 14:32 EDT------- + + +Hi Leonardo, +thanks for your efforts trying to verify that. +Given that you couldn't trigger it I wonder what to do. +Currently it is incomplete waiting for such a test, but as it seems to elude you I'd suggest we call the bug invalid until we would know otherwise. + +For the related bug 1781526 I would think it faces a similar destiny. +There also the test/verification kind of left us with Jhopper. +It was said that this bug here might occur more often if 1781526 would be applied. +While we couldn't trigger the bug here, I'm reluctant to push a nice but minor performance fix while we know it might trigger more crashes. + +Therefore I'll set BOTH bugs to invalid and would ask the kernel Team to stop working on this one here until one can provide a working trigger&verification. + +------- Comment From <email address hidden> 2019-01-24 09:26 EDT------- +By suggestion of Michael Ranweiler, I did some concurrent migration tests. +In fact, I just repeated the procedure used before, but did it twice at roughly the same time (in parallel). + +The results are attached. +Migration 1: from1.txt to1.txt +Migration 2: from2.txt to2.txt + + +------- Comment (attachment only) From <email address hidden> 2019-01-24 09:28 EDT------- + + +------- Comment From <email address hidden> 2019-01-24 09:34 EDT------- +By the test results, the problem doesn't seem to reproduce. + +Are there any other suggestions to reproduce it? + + +------- Comment (attachment only) From <email address hidden> 2019-01-24 09:29 EDT------- + + + +------- Comment (attachment only) From <email address hidden> 2019-01-24 09:30 EDT------- + + + +------- Comment (attachment only) From <email address hidden> 2019-01-24 09:33 EDT------- + + +Thanks for your continuous efforts on this Leonardo, I have no further suggestion. +I think to stay on the safe side we will keep everything as-is for now. + +I'd say it is IBMs call to decide between this now: +a) Speed: Call 1781526 unblocked by the evaluation here. We'd re-consider SRUing that bug then based on your call this won't cause issues on ppc64el. +b) Safety: since it was only a minor performance improvement but has the potential hidden breakage associated we keep 1781526 in Won't Fix + +------- Comment From <email address hidden> 2019-02-08 14:05 EDT------- +In a meeting with lagarcia, I was informed this patch is very important, and that it is already on kernel 4.18-15 onwards. + +In fact, including this one. there are two important patches on this subject: + +https://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git/commit/?h=kvm-ppc-next&id=c066fafc595eef5ae3c83ae3a8305956b8c3ef15 +https://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git/commit/?h=kvm-ppc-next&id=6579804c431712d56956a63b1a01509441cc6800 + +As I said before, for 18.10 onwards (kernel >= 4.18), the patch is available from kernel upstream source, but for Ubuntu 18.04 they may not be so easily applied. + +So I will work on backporting them to v4.15. + +------- Comment From <email address hidden> 2019-02-19 20:52 EDT------- +(In reply to comment #34) +> In a meeting with lagarcia, I was informed this patch is very important, and +> that it is already on kernel 4.18-15 onwards. +> +> In fact, including this one. there are two important patches on this subject: +> +> https://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git/commit/ +> ?h=kvm-ppc-next&id=c066fafc595eef5ae3c83ae3a8305956b8c3ef15 +> https://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git/commit/ +> ?h=kvm-ppc-next&id=6579804c431712d56956a63b1a01509441cc6800 + +To get those you will need to cherry-pick the following patches from upstream: + +39c983ea0f96 KVM: PPC: Remove unused kvm_unmap_hva callback +c4c8a7643e74 KVM: PPC: Book3S HV: Radix page fault handler optimizations +f7caf712d885 KVM: PPC: Book3S HV: Streamline setting of reference and change bits +58c5c276b4c2 KVM: PPC: Book3S HV: Handle 1GB pages in radix page fault handler +31c8b0d0694a KVM: PPC: Book3S HV: Use __gfn_to_pfn_memslot() in page fault handler +e2560b108fb1 KVM: PPC: Book3S HV: Make radix use correct tlbie sequence in kvmppc_radix_tlbie_page +7e3d9a1d0f2c KVM: PPC: Book3S HV: Make radix clear pte when unmapping +df158189dbcc KVM: PPC: Book 3S HV: Do ptesync in radix guest exit path +21828c99ee91 powerpc/kvm: Switch kvm pmd allocator to custom allocator +99491e2d0e50 powerpc/mm/radix: Remove unused code +0078778a86b1 powerpc/mm/radix: implement LPID based TLB flushes to be used by KVM (note that this one will generate some conflicts) +a5fad1e95952 KVM: PPC: Book3S HV: Use a helper to unmap ptes in the radix fault path +a5704e83aa3d KVM: PPC: Book3S HV: Recursively unmap all page table entries when unmapping +d91cb39ffa7b KVM: PPC: Book3S HV: Make radix use the Linux translation flush functions for partition scope +9a4506e11b97 KVM: PPC: Book3S HV: Make radix handle process scoped LPID flush in C, with relocation on +bc64dd0e1c4e KVM: PPC: Book3S HV: radix: Refine IO region partition scope attributes +878cf2bb2d8d KVM: PPC: Book3S HV: radix: Do not clear partition PTE when RC or write bits do not match +c066fafc595e KVM: PPC: Book3S HV: Use correct pagesize in kvm_unmap_radix() +71d29f43b633 KVM: PPC: Book3S HV: Don't use compound_order to determine host mapping size +6579804c4317 KVM: PPC: Book3S HV: Avoid crash from THP collapse during radix page fault + +------- Comment From <email address hidden> 2019-02-25 18:35 EDT------- +I cherry-picked all patches on top of ubuntu-bionic (Ubuntu-4.15.0-45.48). + +Then, the next step was trying to find a way to reproduce the bug. + +I have noted, after several tests, that the previous suggestion of Michael Ranweiler was valid, but it's reproduction rate is about 50%. As previously I have tested only a few times, I could not get it to reproduce. + +How it fails: +During 'memtest' second part, on a 'migrated to' guest, one of the migrations (that occur in parallel) would exit with a "Segmentation Fault" and not conclude the normal flow of the test. +(It never reaches the puts part) + +After applying the kernel patches, it seems to work just fine all the times (I have tested 10+ times by now). + +The kernel debs generated by the building process can be downloaded on the link bellow: + +ftp://testcase.software.ibm.com/fromibm/linux/patched_kernel.tar.gz +- Please use user=anonymous, passwd=anonymous if asked +- Make sure to download it soon, as the link will be available for 3 business days. + +Building info: +command: fakeroot debian/rules binary-generic binary-perarch +git repo (before patches) : git://kernel.ubuntu.com/ubuntu/ubuntu-bionic.git +(tag: Ubuntu-4.15.0-45.48) + +Thanks for all your effort Leonardo, +that seems to make the bug valid again, but I'll leave that to JFH/Manoj to resurrect it and make it a proper kernel bug as it seems there now is a way to test it (at least you can do so) and a set of patches. I can not speak for the ack/nack of those back-ports but that the kernel Team will do then. + +This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window: + +apport-collect 1788098 + +and then change the status of the bug to 'Confirmed'. + +If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'. + +This change has been made by an automated script, maintained by the Ubuntu Kernel Team. + +In comment #22, you mentioned working on a backport of these patches to the Ubuntu 4.15 kernel. Was this successful? Is it possible to attach the backported patchsets to this bug? + +...or perhaps I've misunderstood. Are the patches listed in comment #23 the complete set required to resolve the issue (with no complex backporting required)? + +ProblemType: Bug +AlsaDevices: + total 0 + crw-rw---- 1 root audio 116, 1 Feb 26 08:00 seq + crw-rw---- 1 root audio 116, 33 Feb 26 08:00 timer +AplayDevices: Error: [Errno 2] No such file or directory: 'aplay': 'aplay' +ApportVersion: 2.20.9-0ubuntu7.5 +Architecture: ppc64el +ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord': 'arecord' +AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: +DistroRelease: Ubuntu 18.04 +HibernationDevice: RESUME=/dev/mapper/rhel_zzfp368h-swap +IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig': 'iwconfig' +Lsusb: + Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub + Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub +Package: linux (not installed) +PciMultimedia: + +ProcEnviron: + TERM=xterm + PATH=(custom, no user) + LANG=en_US.UTF-8 + SHELL=/bin/bash +ProcFB: + +ProcKernelCmdLine: root=/dev/mapper/rhel_zzfp368h-root ro quiet splash +ProcLoadAvg: 10.92 2.60 0.86 1/1347 9348 +ProcLocks: + 1: POSIX ADVISORY WRITE 3540 00:17:577 0 EOF + 2: FLOCK ADVISORY WRITE 3320 00:17:555 0 EOF + 3: POSIX ADVISORY WRITE 3628 00:17:610 0 EOF + 4: POSIX ADVISORY WRITE 1743 00:17:351 0 EOF + 5: FLOCK ADVISORY WRITE 3621 00:17:605 0 EOF +ProcSwaps: + Filename Type Size Used Priority + /dev/dm-1 partition 16646080 0 -2 +ProcVersion: Linux version 4.15.0-45-generic (buildd@bos02-ppc64el-005) (gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3)) #48-Ubuntu SMP Tue Jan 29 16:27:02 UTC 2019 +ProcVersionSignature: Ubuntu 4.15.0-45.48-generic 4.15.18 +RelatedPackageVersions: + linux-restricted-modules-4.15.0-45-generic N/A + linux-backports-modules-4.15.0-45-generic N/A + linux-firmware 1.173.3 +RfKill: Error: [Errno 2] No such file or directory: 'rfkill': 'rfkill' +Tags: bionic +Uname: Linux 4.15.0-45-generic ppc64le +UnreportableReason: This report is about a package that is not installed. +UpgradeStatus: No upgrade log present (probably fresh install) +UserGroups: + +VarLogDump_list: + total 36888 + -r--r----- 1 root root 9520107 Feb 25 15:11 FSPDUMP.13C63FW.0A00000F.20190225210916 + -r--r----- 1 root root 9556523 Feb 25 15:11 FSPDUMP.13C63FW.1A00000F.20190225211018 + -r--r----- 1 root root 9642286 Feb 26 08:00 FSPDUMP.13C63FW.2A00000F.20190226135913 + -r--r----- 1 root root 9041963 Feb 25 15:11 FSPDUMP.13C63FW.7A00000E.20190225203903 +_MarkForUpload: False +cpu_cores: Number of cores present = 40 +cpu_coreson: Number of cores online = 40 +cpu_dscr: DSCR is 16 +cpu_freq: + min: 3.499 GHz (cpu 159) + max: 3.500 GHz (cpu 2) + avg: 3.499 GHz +cpu_runmode: + Could not retrieve current diagnostics mode, + No kernel interface to firmware +cpu_smt: SMT=4 + + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +------- Comment From <email address hidden> 2019-02-26 12:36 EDT------- +(In reply to comment #41) +> ...or perhaps I've misunderstood. Are the patches listed in comment #23 the +> complete set required to resolve the issue (with no complex backporting +> required)? + +Yes, the patches listed by Paul are the only ones required to fix the issue. + +As noted by Paul, there is only one patch that causes some conflict. +I have solved this conflict and I will soon attach the full patch series. + +------- Comment From <email address hidden> 2019-02-26 12:58 EDT------- +Here are the patches: + +https://gitlab.com/LeoBras/bionic/compare/master...lp1788098 + +Also, I attached a tgz with the patches. + + + +------- Comment From <email address hidden> 2019-03-12 14:52 EDT------- +(In reply to comment #60) +The patches were sent to Ubuntu kernel-team mailing list. + +------- Comment From <email address hidden> 2019-03-14 15:47 EDT------- +Patchset SRU + +[Impact] +* VMs have a high chance to hit guest migration issues if more than one guest migration happens at a time, while using THP on ppc64le. + +* Migrating VMs in parallel will cause at least one guest to crash about half the time. Since VM migration is a upgrade/uptime strategy this has a fairly large customer impact. + +* The uploaded patches correct the behavior of THP on guests. They are available on v4.18.x onwards. + +[Test Case] + +* One can reproduce the bug by trying two guest migrations, at the same time, following this instructions on comment 12: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1788098/comments/12 + +[Regression Potential] + +* These patches are already on linux-stable since v4.18.15 (also on hwe), so there is low regression chance. + +8afc7da95a7e [Bionic] KVM: PPC: Book3S HV: Avoid crash from THP collapse during radix page fault +82f7758a9c99 [Bionic] KVM: PPC: Book3S HV: Don't use compound_order to determine host mapping size +b0f7664dc993 [Bionic] KVM: PPC: Book3S HV: Use correct pagesize in kvm_unmap_radix() +1991612ab005 [Bionic] KVM: PPC: Book3S HV: radix: Do not clear partition PTE when RC or write bits do not match +04fea11aa5fe [Bionic] KVM: PPC: Book3S HV: radix: Refine IO region partition scope attributes +9037e89d8093 [Bionic] KVM: PPC: Book3S HV: Make radix handle process scoped LPID flush in C, with relocation on +ed0a86a433c7 [Bionic] KVM: PPC: Book3S HV: Make radix use the Linux translation flush functions for partition scope +0effe5dc3cf4 [Bionic] KVM: PPC: Book3S HV: Recursively unmap all page table entries when unmapping +42cbaef5361b [Bionic] KVM: PPC: Book3S HV: Use a helper to unmap ptes in the radix fault path +414207e08540 [Bionic] powerpc/mm/radix: implement LPID based TLB flushes to be used by KVM +eb2a70df7099 [Bionic] powerpc/mm/radix: Remove unused code +ad052e60a417 [Bionic] powerpc/kvm: Switch kvm pmd allocator to custom allocator +bb2c03e387f4 [Bionic] KVM: PPC: Book 3S HV: Do ptesync in radix guest exit path +699642e0a4f8 [Bionic] KVM: PPC: Book3S HV: Make radix clear pte when unmapping +297755f60b17 [Bionic] KVM: PPC: Book3S HV: Make radix use correct tlbie sequence in kvmppc_radix_tlbie_page +d5f5570b7df4 [Bionic] KVM: PPC: Book3S HV: Use __gfn_to_pfn_memslot() in page fault handler +b0adb3223100 [Bionic] KVM: PPC: Book3S HV: Handle 1GB pages in radix page fault handler +5be468e7408b [Bionic] KVM: PPC: Book3S HV: Streamline setting of reference and change bits +860816ea1680 [Bionic] KVM: PPC: Book3S HV: Radix page fault handler optimizations +7fe24f427a09 [Bionic] KVM: PPC: Remove unused kvm_unmap_hva callback + +------- Comment From <email address hidden> 2019-03-26 13:12 EDT------- +Updating: + +The patchset was acked by Juerg Haefliger on Mar 13. + +Hi Leonardo, +unfortunately there was an issue with the SRU request and Juerg NACK-ed it, please have a look here: +https://lists.ubuntu.com/archives/kernel-team/2019-March/099128.html +Please re-submit the SRU request with the requested corrections. + +------- Comment From <email address hidden> 2019-04-08 10:37 EDT------- +This (In reply to comment #64) +> Hi Leonardo, +> unfortunately there was an issue with the SRU request and Juerg NACK-ed it, +> please have a look here: +> https://lists.ubuntu.com/archives/kernel-team/2019-March/099128.html +> Please re-submit the SRU request with the requested corrections. + +The email you posted was from March 10, and is outdated. The changes required were made, and it was acked on March 13, as said on the previous comment. + +Please see https://lists.ubuntu.com/archives/kernel-team/2019-March/099221.html + +Stefan NACK'ed the series. For some unknown reason that email did make it into the archive so here is ist content: + +> Since commit fb1522e099f0 ("KVM: update to new mmu_notifier semantic +> v2", 2017-08-31), the MMU notifier code in KVM no longer calls the +> kvm_unmap_hva callback. This removes the PPC implementations of +> kvm_unmap_hva(). + +This is not really the way SRUs should be done. We cannot remove support for +interfaces after release. Also the amount of change as a requisite should be +kept as minimal as possible. This just feels like too many changes without a +strong argument on why this must be done that way. + +-Stefan + + +------- Comment From <email address hidden> 2019-04-10 04:10 EDT------- +(In reply to comment #66) +> Stefan NACK'ed the series. For some unknown reason that email did make it +> into the archive so here is ist content: +> +> > Since commit fb1522e099f0 ("KVM: update to new mmu_notifier semantic +> > v2", 2017-08-31), the MMU notifier code in KVM no longer calls the +> > kvm_unmap_hva callback. This removes the PPC implementations of +> > kvm_unmap_hva(). +> +> This is not really the way SRUs should be done. We cannot remove support for +> interfaces after release. Also the amount of change as a requisite should be +> kept as minimal as possible. This just feels like too many changes without a +> strong argument on why this must be done that way. +> +> -Stefan + +Well it was just removing dead code, but whatever. + +The series should be fine without that patch. + +In comment #22 above, it states that "In a meeting with lagarcia, I was informed this patch is very important, and that it is already on kernel 4.18-15 onwards." + +So, I assume that the required patchset(s) are already applied to the 18.04 HWE kernel, and this bug requests a backport to the bionic 4.15 kernel. + +Next step is for the Canonical kernel team to analyse this backport request, dropping the commit fb1522e099f0 ("KVM: update to new mmu_notifier semantic v2", 2017-08-31), to assess whether it can be SRU'ed into the bionic 4.15 kernel. + +------- Comment From <email address hidden> 2019-04-10 12:08 EDT------- +(In reply to comment #68) +> In comment #22 above, it states that "In a meeting with lagarcia, I was +> informed this patch is very important, and that it is already on kernel +> 4.18-15 onwards." +> +> So, I assume that the required patchset(s) are already applied to the 18.04 +> HWE kernel, and this bug requests a backport to the bionic 4.15 kernel. +> +> Next step is for the Canonical kernel team to analyse this backport request, +> dropping the commit fb1522e099f0 ("KVM: update to new mmu_notifier semantic +> v2", 2017-08-31), to assess whether it can be SRU'ed into the bionic 4.15 +> kernel. + +I may be wrong, but the patch to be dropped is "KVM: PPC: Remove unused kvm_unmap_hva callback" (7fe24f427a09). + +On this commit, it says it's removing code that is dead since commit fb1522e099f0. + +Leonardo, since you seem to have a reliable reproducer now, could you give this test kernel [1] a try? It just contains commit c066fafc595e ("KVM: PPC: Book3S HV: Use correct pagesize in kvm_unmap_radix()") and is basically what Joe gave you (comment #5) but at that time you weren't able to reproduce the issue. + +[1] https://kernel.ubuntu.com/~juergh/lp1788098/ + +------- Comment From <email address hidden> 2019-04-29 18:50 EDT------- +(In reply to comment #70) +> Leonardo, since you seem to have a reliable reproducer now, could you give +> this test kernel [1] a try? It just contains commit c066fafc595e ("KVM: PPC: +> Book3S HV: Use correct pagesize in kvm_unmap_radix()") and is basically what +> Joe gave you (comment #5) but at that time you weren't able to reproduce the +> issue. +> +> [1] https://kernel.ubuntu.com/~juergh/lp1788098/ + +Hello Juerg, + +As you pointed, this kernel has only one of the 19 patches of the patch series. +IMHO it would't be very productive to test this kernel as is. It can as well work just fine, but it doesn't have the complete solution to this problems. +The kernel with the whole patch series is already tested, and solves many other possible issues. + +But If you think it's really important to test this one, I will try to schedule it for testing ASAP. + +Leonardo, we're evaluating the patch series for inclusion. + +Leonardo, can you elaborate on the 'other possible issues'? We're hesitant to pull 18 patches into a stable kernel under the assumption that they *might* fix some *potential* issues, without clear evidence. If you can test the single-patch kernel and report back that there are still issues then that's a much stronger case for the other patches. + +Commit 'KVM: PPC: Book3S HV: Avoid crash from THP collapse during radix page fault' that you're asking for requires all these additional backports to apply cleanly. Which makes me wonder if we're not actually introducing a problem with these backports just to fix it again later. Not saying that's the case, just wondering... + +Also, the following seem to be totally unrelated and unnecessary: + - KVM: PPC: Remove unused kvm_unmap_hva callback + - powerpc/mm/radix: Remove unused code + +While looking through the patches I also noticed that the following is the second patch of a series of 11 but it's the only one from the series that you're backporting. + - powerpc/kvm: Switch kvm pmd allocator to custom allocator +Its commit message mentions subsequent patches of that series so I'm wondering why we need/want only this single patch?? + +Remember that we have to support this kernel for years and years to come so we only want to backport the absolute necessary. + +Lastly and FYI, the following is the minimal subset of your patches that all cherry-pick cleanly: + - KVM: PPC: Book3S HV: Avoid crash from THP collapse during radix page fault + - KVM: PPC: Book3S HV: Don't use compound_order to determine host mapping size + - KVM: PPC: Book3S HV: Use correct pagesize in kvm_unmap_radix() + - KVM: PPC: Book3S HV: radix: Refine IO region partition scope attributes + - KVM: PPC: Book3S HV: Use __gfn_to_pfn_memslot() in page fault handler + - KVM: PPC: Book3S HV: Handle 1GB pages in radix page fault handler + - KVM: PPC: Book3S HV: Streamline setting of reference and change bits + - KVM: PPC: Book3S HV: Radix page fault handler optimizations + +Please provide some context why we need all the above (and potentially more). + +------- Comment From <email address hidden> 2019-05-10 19:54 EDT------- +Hello Juerg, + +As this complete list was suggested by Paul, I think he may be the best person to show the context of the patch series. + +------- Comment From <email address hidden> 2019-05-13 17:04 EDT------- +Adding Paul Mackerras - can you help with the context for the patches - beyond the potential performance impact? We were picking up this series because it fixes the migration problem, which appeared after adding a patch for bug 169712 for performance. Thanks! + +[Expired for linux (Ubuntu) because there has been no activity for 60 days.] + +[Expired for linux (Ubuntu Bionic) because there has been no activity for 60 days.] + +This bug has expired, marking it as invalid, please reopen if this is still a valid issue. + +These patches are still needed to solve the bug, so this bug need to be reopened. +We are waiting for Paul's reply. + +------- Comment From <email address hidden> 2019-09-26 15:42 EDT------- +Re-opening on our side to test in 19.10. Everything should be there for that, but it would be good to confirm this in time to get any needed fixes to 20.04, too. Just being clear at this point we don't need to target bionic - but validate on 19.10. + +------- Comment From <email address hidden> 2019-09-27 01:51 EDT------- +(In reply to comment #73) +> Leonardo, can you elaborate on the 'other possible issues'? We're hesitant +> to pull 18 patches into a stable kernel under the assumption that they +> *might* fix some *potential* issues, without clear evidence. If you can test +> the single-patch kernel and report back that there are still issues then +> that's a much stronger case for the other patches. +> +> Commit 'KVM: PPC: Book3S HV: Avoid crash from THP collapse during radix page +> fault' that you're asking for requires all these additional backports to +> apply cleanly. Which makes me wonder if we're not actually introducing a +> problem with these backports just to fix it again later. Not saying that's +> the case, just wondering... +> +> Also, the following seem to be totally unrelated and unnecessary: +> - KVM: PPC: Remove unused kvm_unmap_hva callback +> - powerpc/mm/radix: Remove unused code +> +> While looking through the patches I also noticed that the following is the +> second patch of a series of 11 but it's the only one from the series that +> you're backporting. +> - powerpc/kvm: Switch kvm pmd allocator to custom allocator +> Its commit message mentions subsequent patches of that series so I'm +> wondering why we need/want only this single patch?? +> +> Remember that we have to support this kernel for years and years to come so +> we only want to backport the absolute necessary. +> +> Lastly and FYI, the following is the minimal subset of your patches that all +> cherry-pick cleanly: +> - KVM: PPC: Book3S HV: Avoid crash from THP collapse during radix page fault +> - KVM: PPC: Book3S HV: Don't use compound_order to determine host mapping +> size +> - KVM: PPC: Book3S HV: Use correct pagesize in kvm_unmap_radix() +> - KVM: PPC: Book3S HV: radix: Refine IO region partition scope attributes +> - KVM: PPC: Book3S HV: Use __gfn_to_pfn_memslot() in page fault handler +> - KVM: PPC: Book3S HV: Handle 1GB pages in radix page fault handler +> - KVM: PPC: Book3S HV: Streamline setting of reference and change bits +> - KVM: PPC: Book3S HV: Radix page fault handler optimizations +> +> Please provide some context why we need all the above (and potentially more). + +OK, so these are the ones *not* included in the above list (oldest to newest, with upstream commit IDs): + +39c983ea0f96 KVM: PPC: Remove unused kvm_unmap_hva callback + +This one is dead code removal, it can be dropped. + +e2560b108fb1 KVM: PPC: Book3S HV: Make radix use correct tlbie sequence in kvmppc_radix_tlbie_page + +This one adds barriers which are required according to the architecture specification. It is not strictly related to fixing this bug, but if not included here, another bug should be raised to include it. It is quite safe since it is just adding barrier instructions. Without it there is a possibility of occasional mis-translation of addresses (though perhaps a very small possibility). If another bug is raised for this patch, include df158189dbcc below as well in the same bug. + +7e3d9a1d0f2c KVM: PPC: Book3S HV: Make radix clear pte when unmapping + +This fixes a real bug, though it is not strictly related to the bug in this bugzilla. If it is not included here then another bug should be raised to include it. It is a small, simple and safe change. Without it there is a possibility of guests getting stuck doing continual hypervisor page faults. + +df158189dbcc KVM: PPC: Book 3S HV: Do ptesync in radix guest exit path + +This one, like e2560b108fb1 above, adds barriers which are required according to the architecture specification. It is not strictly related to fixing this bug, but if not included here, another bug should be raised to include it. It is quite safe since it is just adding barrier instructions. + +21828c99ee91 powerpc/kvm: Switch kvm pmd allocator to custom allocator + +This one is not needed and can be dropped. + +99491e2d0e50 powerpc/mm/radix: Remove unused code + +This is dead code removal and can be dropped. + +0078778a86b1 powerpc/mm/radix: implement LPID based TLB flushes to be used by KVM + +This is not strictly needed and can be dropped if d91cb39ffa7b and 9a4506e11b97 are being dropped. + +a5fad1e95952 KVM: PPC: Book3S HV: Use a helper to unmap ptes in the radix fault path + +This is not strictly needed (code refactoring) and can be dropped. + +a5704e83aa3d KVM: PPC: Book3S HV: Recursively unmap all page table entries when unmapping + +This one fixes a memory leak, so is not strictly related to this bug. The memory leak will probably not be apparent unless users are using 1GB huge pages to back guests. + +d91cb39ffa7b KVM: PPC: Book3S HV: Make radix use the Linux translation flush functions for partition scope + +This is code refactoring and can be dropped. + +9a4506e11b97 KVM: PPC: Book3S HV: Make radix handle process scoped LPID flush in C, with relocation on + +This is code refactoring and can be dropped. + +878cf2bb2d8d KVM: PPC: Book3S HV: radix: Do not clear partition PTE when RC or write bits do not match + +This one is a performance optimization and can be dropped. + +So in summary, three of these patches should be included, whether under this bug or under other bugs. The other 9 can be dropped. + +I just double-checked all the commits that are mentioned in comment #67. + +In between (or let's better say since quite some time) they are all in Eoan master and are also all in Disco master (and with that even in bionic's hwe kernel, despite comment #66: 'no need to target bionic'). +Hence if one uses the default disco and eoan kernel today, it includes the above list of patches (#67). +With that I change at least the Eoan entry to Fix Released. + +Frank, based on your previous comment I'm also flagging disco as Fix Released. Please fix this if it makes no sense (just to be accurate). Thx! + +That was abs. correct, Rafael - thx (I just haven't had the permission to add D). + +I know it's an old bug, but I just want to confirm if my understanding is correct: + +- You have received all the suggested patchs, via mailing list +- Some of them could not be accepted +- Paul Mackerras have pointed which patches can be dropped, and which are needed to fix the issue +- By above comments, bionic hwe, disco and eoan already contain the patches. +- The patches won't be applied in bionic + +Is the above correct? + +Hi Leonardo, yes that's correct. +Focus was changed in the way to make sure that everything is in 19.10, to be well prepared for 20.04 - and 18.04 (GA kernel 4.15) is not targeted (nevertheless 18.04 HWE kernel incl. the patches). +(All according to LP comment #66.) + diff --git a/results/classifier/105/mistranslation/1788275 b/results/classifier/105/mistranslation/1788275 new file mode 100644 index 000000000..d3e02d4a2 --- /dev/null +++ b/results/classifier/105/mistranslation/1788275 @@ -0,0 +1,83 @@ +mistranslation: 0.688 +boot: 0.607 +assembly: 0.511 +semantic: 0.499 +instruction: 0.475 +graphic: 0.475 +network: 0.468 +other: 0.468 +vnc: 0.464 +KVM: 0.457 +device: 0.450 +socket: 0.414 + +-cpu ...,+topoext works only with EPYC CPU model + +See bug report at: +https://bugzilla.redhat.com/show_bug.cgi?id=1615682 + +Probably this is caused by the inconsistent legacy cache information on all CPU models except EPYC. + +--------------------------------------------- +Description of problem: +Guest should get 2 threads per core and all of them should be on-line when booting guest with old amd cpu model + smt + +Steps to Reproduce: +1.Boot rhel7.6 guest with cli: +/usr/libexec/qemu-kvm -name rhel7.6 -m 16G -machine pc,accel=kvm \ + -S \ + -cpu Opteron_G3,+topoext,xlevel=0x8000001e,enforce \ + -smp 2,threads=2 \ + -monitor stdio \ + -qmp unix:/tmp/qmp2,server,nowait \ + -device VGA \ + -vnc :0 \ + -serial unix:/tmp/console2,server,nowait \ + -uuid 115e11b2-a869-41b5-91cd-6a32a907be7f \ + -drive file=rhel7.6-20180812.qcow2,if=none,id=drive-scsi-disk0,format=qcow2,cache=none,werror=stop,rerror=stop -device ide-hd,drive=drive-scsi-disk0,id=scsi-disk0 \ + -netdev tap,id=idinWyYY,vhost=on -device virtio-net-pci,mac=2e:39:fa:ff:88:a1,id=idlbq7eA,netdev=idinWyYY \ + +2.check cpu info inside guest +3. + +Actual results: +Guest gets one online cpu, one offline cpu and one thread per core: +# lscpu +lscpu +Architecture: x86_64 +CPU op-mode(s): 32-bit, 64-bit +Byte Order: Little Endian +CPU(s): 2 +On-line CPU(s) list: 0 +Off-line CPU(s) list: 1 +Thread(s) per core: 1 +Core(s) per socket: 1 +Socket(s): 1 +NUMA node(s): 1 +Vendor ID: AuthenticAMD +CPU family: 16 +Model: 2 +Model name: AMD Opteron 23xx (Gen 3 Class Opteron) +Stepping: 3 +CPU MHz: 2096.060 +BogoMIPS: 4192.12 +Hypervisor vendor: KVM +Virtualization type: full +L1d cache: 64K +L1i cache: 64K +L2 cache: 512K +L3 cache: 16384K +NUMA node0 CPU(s): 0 +Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx lm art rep_good nopl extd_apicid pni cx16 x2apic popcnt hypervisor lahf_lm cmp_legacy abm sse4a misalignsse topoext retpoline_amd ibp_disable vmmcall + + +Expected results: +Guest should get 2 threads per core and all of them should be on-line + +--------------------------------------------- + +The QEMU project is currently considering to move 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 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/105/mistranslation/1788701 b/results/classifier/105/mistranslation/1788701 new file mode 100644 index 000000000..91d3692c9 --- /dev/null +++ b/results/classifier/105/mistranslation/1788701 @@ -0,0 +1,41 @@ +mistranslation: 0.879 +instruction: 0.826 +graphic: 0.816 +other: 0.757 +semantic: 0.751 +device: 0.673 +boot: 0.476 +assembly: 0.471 +network: 0.464 +socket: 0.342 +KVM: 0.327 +vnc: 0.277 + +"Zoom to fit" doesn't work with -display gtk -vga virtio + +qemu version: 2.12.1 + +When using -display gtk for all -vga options (std,qxl,vmware,cirrus) the option "Zoom To Fit" is unchecked and auto-resizing of the window works well; except for -vga virtio: here "Zoom To Fit" is checked and auto-resizing doesn't work. + +Proposal: disable "Zoom To Fit" as default for virtio as well + +virtio-vga will adapt the guest display to the window size (once the guest drivers are loaded). +Therefore it is not needed to auto-resize the window (to avoid display scaling). + +Well, then something isn't right here. + +"Zoom to Fit" disabled: qemu starts with a small window (1:1 scale) and resizes the window when the xserver/window manager starts (1:1 scale). This is the sane and wanted behavior. + +"Zoom to Fit" enabled: qemu starts with a small window and doesn't resizes the window when the xserver/window manager starts. The whole display is squeezed into the small window. The window simply ignores resolution changes of the guest. + +So either there is sth wrong with your statement: "Therefore it is not needed to auto-resize the window" or with my setup (my window manager is dwm, the linux guest uses modesetting as video driver). + + + + + +The QEMU project is currently considering to move 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 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/105/mistranslation/1791947 b/results/classifier/105/mistranslation/1791947 new file mode 100644 index 000000000..24f8e3762 --- /dev/null +++ b/results/classifier/105/mistranslation/1791947 @@ -0,0 +1,69 @@ +mistranslation: 0.788 +other: 0.629 +instruction: 0.588 +KVM: 0.587 +semantic: 0.575 +graphic: 0.566 +device: 0.561 +boot: 0.558 +network: 0.555 +assembly: 0.548 +vnc: 0.545 +socket: 0.544 + +isochronous usb device forwarding with windows 10 and xhci freezes + +When I try to forward isochronous usb devices (webcam, HID-Audio) into the VM the devices work for a few minutes then the device stops working and stays that way until a VM reboot or a windows driver reload. +It does not matter if I use qemu-xhci or nec-xhci. +I can gather more information, if its helpful! + +Windows build: +windows 10 pro 1803 jun 2018 + +Qemu command line: +/usr/bin/qemu-system-x86_64 -machine accel=kvm -name guest=win10,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-win10/master-key.aes -machine pc-q35-2.11,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu Skylake-Client-IBRS,ss=on,hypervisor=on,tsc_adjust=on,clflushopt=on,ssbd=on,xsaves=on,pdpe1gb=on,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -m 8192 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid 38b1258e-fea4-41fe-9e21-07c426c5b2b2 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-1-win10/monitor.sock,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 strict=on -device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1e -device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x0 -device pcie-root-port,port=0x10,chassis=3,id=pci.3,bus=pcie.0,multifunction=on,addr=0x2 -device pcie-root-port,port=0x11,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x1 -device pcie-root-port,port=0x12,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x2 -device pcie-root-port,port=0x13,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x3 -device qemu-xhci,id=usb,bus=pci.3,addr=0x0 -device virtio-serial-pci,id=virtio-serial0,bus=pci.4,addr=0x0 -drive file=/var/lib/libvirt/images/win10.qcow2,format=qcow2,if=none,id=drive-sata0-0-0 -device ide-hd,bus=ide.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 -drive file=/var/lib/libvirt/images/en_windows_10_multiple_editions_version_1803_jun_2018.iso,format=raw,if=none,id=drive-sata0-0-1,media=cdrom,readonly=on -device ide-cd,bus=ide.1,drive=drive-sata0-0-1,id=sata0-0-1 -netdev tap,fd=25,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=52:54:00:ab:33:11,bus=pci.2,addr=0x1 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0,bus=usb.0,port=1 -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pcie.0,addr=0x1 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -device virtio-balloon-pci,id=balloon0,bus=pci.5,addr=0x0 -msg timestamp=on + +Cheers, +Florian + +I tried it again today with qemu master: 19b599f7664b2ebfd0f405fb79c14dd241557452 +Unfortunately it did not work better than with qemu 2.11.2 + +The same bug also occurs with Windows 7 Enterprise SP1. + +How to reproduce: +1. download windows 10 iso april 2018 from here: + https://www.microsoft.com/en-us/software-download/windows10ISO?NavToggle=True +2. create a VM with virtmanager with q35 chipset and configure two usb redirect devices +(3. modify xml to use an xhci controller) +4. Install windows +5. redirect a usb soundcard or a usb headset into the VM +5. play some video and observe that it freezes after some time (1-20 mins) + +I have already posted a reply on Qemu-devel since everything posted here is automatically forwarded to Qemu-devel, however, the opposite is not true. So duplicating my reply on Qemu-devel: + +How exactly do you use USB redirection: via virt-manager or via spice +client (like remote viewer)? +If via spice-client, on which OS the client runs? In this case running +it with --spice-debug and collecting logs from stdio and stderr could +be helpful. +Can you also provide a usbpcap capture of the usb device's traffic +from within the VM? + +Thanks! + +Oh sorry... +I am not subscribed to Qemu-devel yet. + +I'm redirecting the usb devices via virt-manager. +Is there anything I can do? + +I attached the pcap file! + +Thank you very much! + +The QEMU project is currently considering to move 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 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/105/mistranslation/1793016 b/results/classifier/105/mistranslation/1793016 new file mode 100644 index 000000000..64ade76da --- /dev/null +++ b/results/classifier/105/mistranslation/1793016 @@ -0,0 +1,54 @@ +mistranslation: 0.895 +graphic: 0.869 +semantic: 0.848 +device: 0.729 +other: 0.670 +instruction: 0.660 +KVM: 0.642 +boot: 0.506 +network: 0.478 +socket: 0.474 +vnc: 0.331 +assembly: 0.256 + +vmdk to cqow2 invalid VMDK image descriptor + +Greetings, + +CentOS 7.5.1804 +Linux 3.10.0-862.11.6.el7.x86_64 +qemu-img version 3.0.50 (v3.0.0-614-g19b599f) + +When trying to convert a vmdk flat file to qcow2 format, I get the following error message: +qemu-img: Could not open './sk-R12-flat.vmdk': invalid VMDK image descriptor + +The command line used is +root@s11kvm:/home/goinfre> qemu-img convert -f vmdk -O qcow2 ./sk-R12-flat.vmdk ./sk-R12-flat.qcow2 + + +"file sk-R12-flat.vmdk" returns: +sk-R12-flat.vmdk: x86 boot sector; +GRand Unified Bootloader, stage1 version 0x3, boot drive 0x80, 1st sector stage2 0x40, GRUB version 0.97; +partition 1: ID=0x63, active, starthead 1, startsector 63, 16002 sectors; +partition 2: ID=0x83, starthead 0, startsector 16065, 3084480 sectors; +partition 3: ID=0x83, starthead 0, startsector 3100545, 3084480 sectors; +partition 4: ID=0x5, starthead 0, startsector 6185025, 161581770 sectors, code offset 0x48 + +Found a work around by removing the option "-f vmd" +Still a bug though. + +meant "vmdk" of course. + +Hi, + +Judging from the "file" output and the fact that you say the result is correct when removing "-f vmdk", it appears as if the input is in fact not in vmdk format but just a raw image. +I don't know too much about vmdk, but I suppose that there is a descriptor file that goes aloing with that sk-R12-flat.vmdk (e.g. "sk-R12.vmdk"). So I guess sk-R12-flat.vmdk just contains the raw image data which is pointed to by e.g. sk-R12.vmdk, and the latter would be the file that qemu expects. + +From my perspective, giving the flat file a .vmdk extension is a misnomer, and qemu's vmdk driver is correct in rejecting it -- because it is just a raw file, so it should be handled by the raw driver. But maybe it is common enough that the vmdk driver should give a hint on that. + +Note that the VMware knowledge base (https://kb.vmware.com/s/article/1002511) specifically says that "VMDK" stands for the descriptor file, and it looks like even VMware would reject flat files without a descriptor file. + +Max + +I'm closing this ticket since it was likely just a wrong file extension ... if you disagree, feel free to open the ticket again. + diff --git a/results/classifier/105/mistranslation/1793791 b/results/classifier/105/mistranslation/1793791 new file mode 100644 index 000000000..b036f4058 --- /dev/null +++ b/results/classifier/105/mistranslation/1793791 @@ -0,0 +1,296 @@ +mistranslation: 0.542 +semantic: 0.526 +KVM: 0.504 +other: 0.491 +graphic: 0.477 +vnc: 0.450 +assembly: 0.449 +boot: 0.400 +instruction: 0.398 +network: 0.398 +device: 0.371 +socket: 0.291 + +Crash with nbd_reply_chunk_iter_receive: Assertion `chunk->flags & NBD_REPLY_FLAG_DONE' failed + +Qemu version on both sides: 2.12.1 +Host A Linux: 4.9.76 +Host B Linux: 4.14.67 + +While calling from Host A: +virsh migrate virtualmachine qemu+ssh://hostB/system --live --undefinesource --persistent --verbose --copy-storage-all + +I get a qemu crash with: + +2018-09-21 16:12:23.073+0000: 14428: info : virObjectUnref:350 : OBJECT_UNREF: obj=0x7f922c03d990 +qemu-system-x86_64: block/nbd-client.c:606: nbd_reply_chunk_iter_receive: Assertion `chunk->flags & NBD_REPLY_FLAG_DONE' failed. +2018-09-21 16:12:41.230+0000: shutting down, reason=crashed +2018-09-21 16:12:52.900+0000: shutting down, reason=failed + +It doesn't do it every time, but most of the time. + +Tested with Qemu 3.0.0 and this still happens. + +Also tested with kernel 4.9.128 on one side and 4.9.76 on the other thinking it might be a kernel 4.14 issue. + +On 9/21/18 11:42 AM, Matthew Schumacher wrote: +> Public bug reported: +> +> Qemu version on both sides: 2.12.1 +> Host A Linux: 4.9.76 +> Host B Linux: 4.14.67 +> +> While calling from Host A: +> virsh migrate virtualmachine qemu+ssh://hostB/system --live --undefinesource --persistent --verbose --copy-storage-all + +Can you show the qemu command line generated by libvirt? + +> +> I get a qemu crash with: +> +> 2018-09-21 16:12:23.073+0000: 14428: info : virObjectUnref:350 : OBJECT_UNREF: obj=0x7f922c03d990 +> qemu-system-x86_64: block/nbd-client.c:606: nbd_reply_chunk_iter_receive: Assertion `chunk->flags & NBD_REPLY_FLAG_DONE' failed. + +That assertion is the client complaining that it things the server has +sent invalid data. + +> 2018-09-21 16:12:41.230+0000: shutting down, reason=crashed +> 2018-09-21 16:12:52.900+0000: shutting down, reason=failed +> +> It doesn't do it every time, but most of the time. + +Hmm - you're running under libvirt, so it's harder to inject command +line options, but I'd be interested in figuring out how to enable trace +output of nbd_* on both the server and the destination during the block +migration portion of 'virsh migrate', to see if the tail of that trace +when reproducing the failure gives any more insights into which side is +breaking the protocol. I'm also trying to inspect the code in +nbd/server.c to see if the server can ever actually send a +NBD_REPLY_TYPE_NONE packet without setting the NBD_REPLY_FLAG_DONE bit, +which is what the assertion is complaining about. + +-- +Eric Blake, Principal Software Engineer +Red Hat, Inc. +1-919-301-3266 +Virtualization: qemu.org | libvirt.org + + +Hi Eric, + +Thanks for looking at this. + +I looked at the nbd/server.c code and couldn't see how it could send a NBD_REPLY_TYPE_NONE packet without setting the NBD_REPLY_FLAG_DONE bit. The only place NBD_REPLY_TYPE_NONE is set is on line 1603: + + set_be_chunk(&chunk, NBD_REPLY_FLAG_DONE, NBD_REPLY_TYPE_NONE, handle, 0); + +Anyway, here is the command line generated: + +/usr/bin/qemu-system-x86_64 -name guest=dng-smokeping,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-7-dng-smokeping/master-key.aes -machine pc-1.1,accel=kvm,usb=off,dump-guest-core=off -cpu qemu64,pmu=off -m 4096 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -object iothread,id=iothread1 -uuid 3d0e1603-ad08-4876-9d9f-2d563fac07ea -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=26,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,clock=vm,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/datastore/vm/dng-smokeping.raw,format=raw,if=none,id=drive-virtio-disk0,cache=writeback,aio=threads -device virtio-blk-pci,iothread=iothread1,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=2,write-cache=on -drive if=none,id=drive-ide0-1-0,readonly=on -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=1 -netdev tap,fd=28,id=hostnet0,vhost=on,vhostfd=29 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:1d:da:b9,bus=pci.0,addr=0x3 -device usb-tablet,id=input0,bus=usb.0,port=1 -vnc 0.0.0.0:59 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on + + +Is there some way to turn on NBD trace? I don't see any trace code around the assert, so I'm guessing it would need to be written.... Is there a log event in QMP? Can that be used to trace what is going on? If so it would be easy to make libvirt log all of that, which should tell us what is going on... + +If that won't work, I can run the VM outside of libvirt and tell it to migrate over the QMP socket + + +I'm back to trying to figure this out. I can't use migrate and copy storage until this bug is fixed, so I'm pretty motivated. Today I configured libvirt/qemu to dump the core, and I compiled qemu with debugging symbols. Here is the backtrace. I'm not sure it says anything we don't already know. + +I may try to hack in some more debugging later today, but my C is terrible. Any other ideas on ways I can help? + +(gdb) bt full +#0 0x00007f1a6a3313f8 in raise () at /lib64/libc.so.6 +#1 0x00007f1a6a332ffa in abort () at /lib64/libc.so.6 +#2 0x00007f1a6a329c17 in __assert_fail_base () at /lib64/libc.so.6 +#3 0x00007f1a6a329cc2 in () at /lib64/libc.so.6 +#4 0x000055a6cba705a6 in nbd_reply_chunk_iter_receive (s=s@entry=0x55a6ce458200, iter=iter@entry=0x7f1945fe8890, handle=handle@entry=94174913593865, qiov=qiov@entry=0x0, reply=0x7f1945fe8800, + reply@entry=0x0, payload=payload@entry=0x0) at block/nbd-client.c:606 + local_reply = + {simple = {magic = 1732535960, error = 0, handle = 94174913593865}, structured = {magic = 1732535960, flags = 0, type = 0, handle = 94174913593865, length = 0}, {magic = 1732535960, _skip = 0, handle = 94174913593865}} + chunk = 0x7f1945fe8800 + local_err = 0x0 + __func__ = "nbd_reply_chunk_iter_receive" + __PRETTY_FUNCTION__ = "nbd_reply_chunk_iter_receive" +#5 0x000055a6cba706d6 in nbd_co_request (errp=0x7f1945fe8888, handle=94174913593865, s=0x55a6ce458200) at block/nbd-client.c:634 + iter = {ret = 0, fatal = false, err = 0x0, done = false, only_structured = true} + ret = <optimized out> + local_err = 0x0 + client = 0x55a6ce458200 + __PRETTY_FUNCTION__ = "nbd_co_request" +#6 0x000055a6cba706d6 in nbd_co_request (bs=bs@entry=0x55a6ce450130, request=request@entry=0x7f1945fe88e0, write_qiov=write_qiov@entry=0x0) at block/nbd-client.c:772 + ret = <optimized out> + local_err = 0x0 + client = 0x55a6ce458200 + __PRETTY_FUNCTION__ = "nbd_co_request" +#7 0x000055a6cba70cb5 in nbd_client_co_pwrite_zeroes (bs=0x55a6ce450130, offset=2483027968, bytes=16777216, flags=<optimized out>) at block/nbd-client.c:860 + client = <optimized out> + request = {handle = 94174913593865, from = 2483027968, len = 16777216, flags = 0, type = 6} + __PRETTY_FUNCTION__ = "nbd_client_co_pwrite_zeroes" +#8 0x000055a6cba67f44 in bdrv_co_do_pwrite_zeroes (bs=bs@entry=0x55a6ce450130, offset=offset@entry=2483027968, bytes=bytes@entry=16777216, flags=flags@entry=6) at block/io.c:1410 + num = 16777216 + drv = 0x55a6cc3b0600 <bdrv_nbd_unix> + qiov = {iov = 0x100000, niov = -834338512, nalloc = 21926, size = 1831862272} + iov = {iov_base = 0x0, iov_len = 0} + ret = -95 + need_flush = false + head = 0 + tail = 0 + max_write_zeroes = 33554432 + alignment = 512 + max_transfer = 16777216 + __PRETTY_FUNCTION__ = "bdrv_co_do_pwrite_zeroes" +#9 0x000055a6cba68373 in bdrv_aligned_pwritev (req=req@entry=0x7f1945fe8b50, offset=offset@entry=2483027968, bytes=bytes@entry=16777216, align=align@entry=512, qiov=0x0, flags=6, child=0x55a6ce333f50, child=0x55a6ce333f50) + at block/io.c:1522 + bs = 0x55a6ce450130 + drv = 0x55a6cc3b0600 <bdrv_nbd_unix> + waited = <optimized out> + ret = <optimized out> + end_sector = 4882432 + bytes_remaining = 16777216 + max_transfer = 33554432 +#10 0x000055a6cba69a42 in bdrv_co_pwritev (req=0x7f1945fe8b50, flags=6, bytes=16777216, offset=2483027968, child=0x55a6ce333f50) at block/io.c:1625 + aligned_bytes = 16777216 + bs = 0x55a6ce450130 + buf = <optimized out> + tail_padding_bytes = 0 +---Type <return> to continue, or q <return> to quit--- + local_qiov = {iov = 0x0, niov = 0, nalloc = 0, size = 1825570816} + align = 512 + head_padding_bytes = <optimized out> + ret = 0 + iov = {iov_base = 0x7f1945fe8bc0, iov_len = 1} + bs = 0x55a6ce450130 + req = + {bs = 0x55a6ce450130, offset = 2483027968, bytes = 16777216, type = BDRV_TRACKED_WRITE, serialising = false, overlap_offset = 2483027968, overlap_bytes = 16777216, list = {le_next = 0x0, le_prev = 0x7f19452dbb80}, co = 0x7f1a5c003030, wait_queue = {entries = {sqh_first = 0x0, sqh_last = 0x7f1945fe8b98}}, waiting_for = 0x0} + align = <optimized out> + head_buf = 0x0 + tail_buf = 0x0 + local_qiov = {iov = 0x7f1945fe8bc0, niov = 1, nalloc = 0, size = 94171452932608} + use_local_qiov = false + ret = <optimized out> + __PRETTY_FUNCTION__ = "bdrv_co_pwritev" +#11 0x000055a6cba69a42 in bdrv_co_pwritev (child=child@entry=0x55a6ce333f50, offset=offset@entry=2483027968, bytes=bytes@entry=16777216, qiov=qiov@entry=0x0, flags=flags@entry=6) at block/io.c:1698 + bs = 0x55a6ce450130 + req = + {bs = 0x55a6ce450130, offset = 2483027968, bytes = 16777216, type = BDRV_TRACKED_WRITE, serialising = false, overlap_offset = 2483027968, overlap_bytes = 16777216, list = {le_next = 0x0, le_prev = 0x7f19452dbb80}, co = 0x7f1a5c003030, wait_queue = {entries = {sqh_first = 0x0, sqh_last = 0x7f1945fe8b98}}, waiting_for = 0x0} + align = <optimized out> + head_buf = 0x0 + tail_buf = 0x0 + local_qiov = {iov = 0x7f1945fe8bc0, niov = 1, nalloc = 0, size = 94171452932608} + use_local_qiov = false + ret = <optimized out> + __PRETTY_FUNCTION__ = "bdrv_co_pwritev" +#12 0x000055a6cba6a3be in bdrv_co_pwrite_zeroes (child=0x55a6ce333f50, offset=2483027968, bytes=16777216, flags=<optimized out>) at block/io.c:1822 +#13 0x000055a6cba67f44 in bdrv_co_do_pwrite_zeroes (bs=bs@entry=0x55a6ce35dd80, offset=offset@entry=2483027968, bytes=bytes@entry=16777216, flags=flags@entry=6) at block/io.c:1410 + num = 16777216 + drv = 0x55a6cc3aa5a0 <bdrv_raw> + qiov = {iov = 0x6d400000, niov = -878284120, nalloc = 21926, size = 1} + iov = {iov_base = 0x0, iov_len = 0} + ret = -95 + need_flush = false + head = 0 + tail = 0 + max_write_zeroes = 2147483647 + alignment = 1 + max_transfer = 16777216 + __PRETTY_FUNCTION__ = "bdrv_co_do_pwrite_zeroes" +#14 0x000055a6cba68373 in bdrv_aligned_pwritev (req=req@entry=0x7f1945fe8e90, offset=offset@entry=2483027968, bytes=bytes@entry=16777216, align=align@entry=1, qiov=0x0, flags=6, child=0x55a6ce457960, child=0x55a6ce457960) + at block/io.c:1522 + bs = 0x55a6ce35dd80 + drv = 0x55a6cc3aa5a0 <bdrv_raw> + waited = <optimized out> + ret = <optimized out> + end_sector = 4882432 + bytes_remaining = 16777216 + max_transfer = 33554432 +#15 0x000055a6cba69a42 in bdrv_co_pwritev (req=0x7f1945fe8e90, flags=6, bytes=16777216, offset=2483027968, child=0x55a6ce457960) at block/io.c:1625 + aligned_bytes = 16777216 + bs = 0x55a6ce35dd80 + buf = <optimized out> +---Type <return> to continue, or q <return> to quit--- + tail_padding_bytes = 0 + local_qiov = {iov = 0x55a6ce3f8b40, niov = 1543529136, nalloc = 32538, size = 139746525220544} + align = 1 + head_padding_bytes = <optimized out> + ret = 0 + iov = {iov_base = 0x7f1a5c003030, iov_len = 94174870259312} + bs = 0x55a6ce35dd80 + req = + {bs = 0x55a6ce35dd80, offset = 2483027968, bytes = 16777216, type = BDRV_TRACKED_WRITE, serialising = false, overlap_offset = 2483027968, overlap_bytes = 16777216, list = {le_next = 0x0, le_prev = 0x7f19452dbec0}, co = 0x7f1a5c003030, wait_queue = {entries = {sqh_first = 0x0, sqh_last = 0x7f1945fe8ed8}}, waiting_for = 0x0} + align = <optimized out> + head_buf = 0x0 + tail_buf = 0x0 + local_qiov = {iov = 0x7f1a5c003030, niov = -877640080, nalloc = 21926, size = 139751189406384} + use_local_qiov = false + ret = <optimized out> + __PRETTY_FUNCTION__ = "bdrv_co_pwritev" +#16 0x000055a6cba69a42 in bdrv_co_pwritev (child=0x55a6ce457960, offset=offset@entry=2483027968, bytes=bytes@entry=16777216, qiov=qiov@entry=0x0, flags=6) at block/io.c:1698 + bs = 0x55a6ce35dd80 + req = + {bs = 0x55a6ce35dd80, offset = 2483027968, bytes = 16777216, type = BDRV_TRACKED_WRITE, serialising = false, overlap_offset = 2483027968, overlap_bytes = 16777216, list = {le_next = 0x0, le_prev = 0x7f19452dbec0}, co = 0x7f1a5c003030, wait_queue = {entries = {sqh_first = 0x0, sqh_last = 0x7f1945fe8ed8}}, waiting_for = 0x0} + align = <optimized out> + head_buf = 0x0 + tail_buf = 0x0 + local_qiov = {iov = 0x7f1a5c003030, niov = -877640080, nalloc = 21926, size = 139751189406384} + use_local_qiov = false + ret = <optimized out> + __PRETTY_FUNCTION__ = "bdrv_co_pwritev" +#17 0x000055a6cba5898b in blk_co_pwritev (blk=0x55a6ce4576b0, offset=2483027968, bytes=16777216, qiov=0x0, flags=<optimized out>) at block/block-backend.c:1188 + ret = <optimized out> + bs = 0x55a6ce35dd80 +#18 0x000055a6cba58a9b in blk_aio_write_entry (opaque=0x7f1a5c0084b0) at block/block-backend.c:1394 + acb = 0x7f1a5c0084b0 + rwco = 0x7f1a5c0084d8 + qiov = <optimized out> +#19 0x000055a6cbb046ba in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at util/coroutine-ucontext.c:116 + co = 0x7f1a5c003030 +#20 0x00007f1a6a346560 in __start_context () at /lib64/libc.so.6 +#21 0x00007f1a617a3fb0 in () +#22 0x0000000000000000 in () + +From the core: + +structured = {magic = 1732535960, flags = 0, type = 0, handle = 94174913593865, length = 0} + +You would think that would pass: + + chunk = &reply->structured; + + if (chunk->type == NBD_REPLY_TYPE_NONE) { + /* NBD_REPLY_FLAG_DONE is already checked in nbd_co_receive_one_chunk */ + assert(chunk->flags & NBD_REPLY_FLAG_DONE); + goto break_loop; + } + +Given: + +#define NBD_REPLY_TYPE_NONE 0 + + +Perhaps this is a problem with my compiler. (or maybe it's an ignorant guess) I'm using: + +gcc version 5.5.0 (GCC) + + + +Okay, this is probably a race condition bug. If remove: + +<iothreads>1</iothreads> +and +iothread='1' from the disk which causes the command to change from: + +-device virtio-blk-pci,iothread=iothread1,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=2,write-cache=on + +to + +-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=2,write-cache=on + +I don't get crashes anymore. + +So for sure it has something to do with iothreads. + + +The QEMU project is currently considering to move 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 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/105/mistranslation/1795369 b/results/classifier/105/mistranslation/1795369 new file mode 100644 index 000000000..4e4686d5d --- /dev/null +++ b/results/classifier/105/mistranslation/1795369 @@ -0,0 +1,56 @@ +mistranslation: 0.817 +device: 0.764 +instruction: 0.761 +other: 0.758 +graphic: 0.736 +semantic: 0.735 +boot: 0.735 +assembly: 0.732 +network: 0.730 +socket: 0.695 +KVM: 0.685 +vnc: 0.648 + +Record/replay (icount rr) causes emulation hang or exit with error about missing events in log + +Test case description: + +Guest image is Linux, which just powers off after kernel boots (instead of proceeding to user-space /init or /sbin/init). +Base cmdline: + qemu-system-x86_64 \ + -nodefaults -nographic -machine pc,accel=tcg -m 2048 -cpu qemu64 \ + -kernel bzImage -initrd rootfs -append 'nokaslr console=ttyS0 rdinit=/init_poweroff' \ + -serial SERIAL_VALUE \ + -rtc clock=vm,base=2000-01-01T00:00:00 \ + -icount 1,sleep=off,rr=RR_VALUE,rrfile=icount_rr_capture.bin + +Test 1. +When SERIAL_VALUE=none +Running with RR_VALUE=record completes successfully. +Running with RR_VALUE=replay doesn't completes. qemu process just eating ~100% cpu and memory usage doesn't grow after some moment. I don't see what happens because of problem no.2 (see below). + +Test 2. +When SERIAL_VALUE=stdio +Running with RR_VALUE=record completes successfully. +Running with RR_VALUE=replay causes exit with error: +"qemu-system-x86_64: Missing character write event in the replay log" + +Tests 3,4,5... +SERIAL_VALUE=stdio. Playing with "-rtc" clock and base suboptions, "-icount" sleep suboptions produces non-repeatable results. +In most cases running with RR_VALUE=record completes successfully (but may hang at very begining). +Running with RR_VALUE=replay with combinations of removing "-rtc base=..." and "-icount sleep=..." goes better, but at different places of boot process it may either hang (as in test 1) or exit with error (as in test 2). +When qemu "hangs", it may also happen differently: either it can be stopped by Ctrl-C, or have to be killed. + + +Guest image uploaded here: https://drive.google.com/open?id=1SHG4HyBdcPutc5Au4pyhN8z9w52et51A + +QEMU built from master (commit 042938f46e1c477419d1931381fdadffaa49d45e) with: +<SRC_ROOT>/configure --prefix=<INSTALL_ROOT> --target-list=x86_64-softmmu --enable-debug --disable-pie --enable-tcg --disable-tcg-interpreter --enable-virtfs --disable-docs --disable-guest-agent --disable-modules --disable-gnutls --disable-nettle --disable-gcrypt --disable-sdl --disable-curses --disable-vnc --disable-vnc-sasl --disable-vnc-jpeg --disable-vnc-png --disable-cocoa --disable-xen --disable-xen-pci-passthrough --disable-brlapi --disable-curl --disable-fdt --disable-bluez --disable-kvm --disable-hax --disable-hvf --disable-whpx --disable-rdma --disable-vde --disable-netmap --disable-cap-ng --disable-spice --disable-rbd --disable-libiscsi --disable-libnfs --disable-smartcard --disable-libusb --disable-live-block-migration --disable-usb-redir --disable-glusterfs --disable-tpm --disable-libssh2 --disable-numa --disable-libxml2 --disable-opengl --disable-virglrenderer --disable-qom-cast-debug --disable-tools --disable-vxhs --disable-crypto-afalg --disable-capstone --disable-replication --disable-xfsctl --disable-seccomp --disable-pvrdma --disable-libpmem + +Applying recent patches from http://lists.nongnu.org/archive/html/qemu-devel/2018-09/msg04038.html doesn't fix any of issues. + +The QEMU project is currently considering to move 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 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/105/mistranslation/1796816 b/results/classifier/105/mistranslation/1796816 new file mode 100644 index 000000000..a89c4ef27 --- /dev/null +++ b/results/classifier/105/mistranslation/1796816 @@ -0,0 +1,41 @@ +mistranslation: 0.675 +device: 0.675 +socket: 0.586 +graphic: 0.568 +other: 0.537 +network: 0.527 +instruction: 0.476 +semantic: 0.468 +vnc: 0.457 +boot: 0.391 +KVM: 0.209 +assembly: 0.155 + +Wrong keyboard in QEMU Windows for OpenSUSE PowerPC + +I am trying to run an OpenSUSE PowerPC Little Endian system under Microsoft Windows. I have an English UK keyboard. The keyboard is basically correct (I get a 'pound' sign when I press shift-3) but some of the keys are rendered incorrectly. The wrong keys are +\ renders as # (just right of left hand shift key) +| renders as ~ (shift-\) +' renders as ` (2 keys right of l) +@ renders as ¬ (shift-') +# renders as ' (3 keys right of l) +~ renders as @ (shift-#) + +QEMU command line was +>"\Program Files\qemu\qemu-system-ppc64.exe" -hda opensuse.qcow2 + +OpenSUSE was installed from download.opensuse.org/ports/ppc/tumbleweed/iso/openSUSE-Tumbleweed-DVD-ppc64le-Current.iso . + +I am running OpenSUSE in runlevel 3 (no X11). + +I don't really know whether the problem is with QEMU, the Windows port of QEMU, or with OpenSUSE Tumbleweed. + +This is with QEMU for Windows 3.0.0 from https://qemu.weilnetz.de/w64/ + +I have configured a matching PowerPC virtual machine under an OpenSUSE Tumbleweed x86_64 host with qemu-ppc64 for that platform, and the keyboard mapping is correct for all keys. So the bug I have come across is presumably a bug with the WIndows port of QEMU. + +The QEMU project is currently considering to move 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 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/105/mistranslation/1799200 b/results/classifier/105/mistranslation/1799200 new file mode 100644 index 000000000..1b79bccdf --- /dev/null +++ b/results/classifier/105/mistranslation/1799200 @@ -0,0 +1,73 @@ +mistranslation: 0.512 +KVM: 0.508 +other: 0.462 +instruction: 0.460 +vnc: 0.454 +device: 0.435 +graphic: 0.429 +semantic: 0.404 +socket: 0.395 +assembly: 0.386 +network: 0.386 +boot: 0.351 + +null pointer dereference in tcg_emit_op + +I am insert a custom tcg helper function in i386_tr_insn_start for trace the instructions. + +most of time the qemu runed ok ,but when execute some special software will lead to crash. + + +the below is the insert code: +======================================================================================= + + 8514 static void i386_tr_insn_start(DisasContextBase *dcbase, CPUState *cpu) + 8515 { + 8516 DisasContext *dc = container_of(dcbase, DisasContext, base); + 8517 TCGv_ptr ptr= tcg_const_ptr((void*)cpu); // inserted hepler code + 8518 gen_helper_mad_exec(ptr);// insert helper code + 8519 tcg_gen_insn_start(dc->base.pc_next, dc->cc_op); + 8520 } +====================================================================================== + +below is the callstack + +#0 0x000055555581df5e in tcg_emit_op (opc=opc@entry=INDEX_op_movi_i64) at /root/qemu/tcg/tcg.c:2205 +#1 0x0000555555825911 in tcg_gen_op2 (opc=opc@entry=INDEX_op_movi_i64, a1=140734736923704, a2=a2@entry=792) at /root/qemu/tcg/tcg-op.c:53 +#2 0x000055555581d713 in tcg_const_i64 (opc=INDEX_op_movi_i64, a2=792, a1=0x7378) at /root/qemu/tcg/tcg-op.h:109 +#3 0x000055555581d713 in tcg_const_i64 (arg=792, ret=<optimized out>) at /root/qemu/tcg/tcg-op.h:579 +#4 0x000055555581d713 in tcg_const_i64 (val=val@entry=792) at /root/qemu/tcg/tcg.c:1314 +#5 0x000055555582732d in tcg_gen_addi_i64 (ret=0xd18, arg1=0x378, arg2=arg2@entry=792) at /root/qemu/tcg/tcg-op.c:1200 +#6 0x000055555590ffaf in gen_sse (b=792, a=<optimized out>, r=<optimized out>) at /root/qemu/tcg/tcg-op.h:1258 +#7 0x000055555590ffaf in gen_sse (env=env@entry=0x5555567424d0, s=s@entry=0x7fffea99a610, b=b@entry=366, pc_start=pc_start@entry=4513509698, rex_r=rex_r@entry=0) at /root/qemu/target/i386/translate.c:3150 +#8 0x0000555555911d7f in disas_insn (s=s@entry=0x7fffea99a610, cpu=<optimized out>) at /root/qemu/target/i386/translate.c:8336 +#9 0x00005555559207a0 in i386_tr_translate_insn (dcbase=0x7fffea99a610, cpu=<optimized out>) at /root/qemu/target/i386/translate.c:8543 +#10 0x0000555555892649 in translator_loop (ops=0x55555622dee0 <i386_tr_ops>, db=0x7fffea99a610, cpu=0x55555673a220, tb=<optimized out>) at /root/qemu/accel/tcg/translator.c:110 +#11 0x00005555559209ef in gen_intermediate_code (cpu=cpu@entry=0x55555673a220, tb=tb@entry=0x7fff70682040 <code_gen_buffer+208150547>) at /root/qemu/target/i386/translate.c:8605 +#12 0x0000555555891437 in tb_gen_code (cpu=cpu@entry=0x55555673a220, pc=pc@entry=4513506448, cs_base=cs_base@entry=0, flags=flags@entry=4244147, cflags=cflags@entry=0) at /root/qemu/accel/tcg/translate-all.c:1728 +#13 0x000055555588f97b in cpu_exec (cf_mask=0, tb_exit=0, last_tb=0x0, cpu=0x0) at /root/qemu/accel/tcg/cpu-exec.c:410 +#14 0x000055555588f97b in cpu_exec (cpu=cpu@entry=0x55555673a220) at /root/qemu/accel/tcg/cpu-exec.c:734 +#15 0x000055555584b152 in tcg_cpu_exec (cpu=0x55555673a220) at /root/qemu/cpus.c:1405 +#16 0x000055555584d1b8 in qemu_tcg_rr_cpu_thread_fn (arg=<optimized out>) at /root/qemu/cpus.c:1505 +#17 0x00007ffff2585e25 in start_thread () at /lib64/libpthread.so.0 +#18 0x00007ffff22afbad in clone () at /lib64/libc.so.6 + +Does this bug occur with a normal build of QEMU or only with your changes to it? + +1. You're leaking the "ptr" TCG temp. Fix it, and also test your code with the --enable-debug-tcg configure flag. +2. Don't insert your helper in .insn_start; you'll have better luck in .translate_insn. + + +Hi Emilio G. Cota (cota), + for point 1, I don't know what you mean about leaking the ptr TCG temp + for point 2. what I want to do is call callback function when execute every guest instructions + so I think it's not should inset code in .translate_insn. what do you think about it? + + + + + +Hi Emilio G. Cota (cota), + thank you, + after I free the "ptr",there is no crash occur :) + diff --git a/results/classifier/105/mistranslation/1799768 b/results/classifier/105/mistranslation/1799768 new file mode 100644 index 000000000..8ba837e12 --- /dev/null +++ b/results/classifier/105/mistranslation/1799768 @@ -0,0 +1,27 @@ +mistranslation: 0.769 +device: 0.714 +network: 0.520 +socket: 0.427 +semantic: 0.384 +other: 0.328 +graphic: 0.312 +vnc: 0.308 +boot: 0.237 +KVM: 0.096 +assembly: 0.050 +instruction: 0.047 + +-nodefaults has unclear documentation + +-nodefaults has an unclear documentation, I believe it should states it does not applies to devices created by a machine model. + +See https://stackoverflow.com/questions/52908614/qemu-s-nodefaults-not-working-as-expected-to-me to read how I came to this. + + +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/156 + + diff --git a/results/classifier/105/mistranslation/1800993 b/results/classifier/105/mistranslation/1800993 new file mode 100644 index 000000000..c0b63bc27 --- /dev/null +++ b/results/classifier/105/mistranslation/1800993 @@ -0,0 +1,30 @@ +mistranslation: 0.834 +vnc: 0.771 +device: 0.736 +network: 0.686 +semantic: 0.587 +other: 0.480 +graphic: 0.420 +instruction: 0.413 +socket: 0.342 +KVM: 0.321 +boot: 0.298 +assembly: 0.053 + +How to Migration VM Built on Qemu Souce Code Installation + +Respected all, + +I followed https://wiki.qemu.org/Hosts/Linux to build qemu from source code. Its installed successfully with Ubuntu 16.04 VM created using VNC server. + +Now, Could you please suggest me how to migrate VM from one host to another?. + +Email: <email address hidden> + +Hi, this is the bug tracker and not a support request form, so I'm closing this issue. + +(You've already emailed the mailing list, so you already know where to find us!) + +Thanks, +--John + diff --git a/results/classifier/105/mistranslation/1801 b/results/classifier/105/mistranslation/1801 new file mode 100644 index 000000000..a7716ab2f --- /dev/null +++ b/results/classifier/105/mistranslation/1801 @@ -0,0 +1,64 @@ +mistranslation: 0.717 +other: 0.643 +graphic: 0.628 +semantic: 0.613 +assembly: 0.611 +device: 0.586 +instruction: 0.579 +socket: 0.539 +vnc: 0.525 +boot: 0.451 +network: 0.447 +KVM: 0.429 + +qemu-system-arm: Linux doesn't boot with UEFI (hangs after printing `EFI stub: Exiting boot services... `.) +Description of problem: +Ubuntu 23.04 (armhf) doesn't boot with UEFI. +It hangs after printing `EFI stub: Exiting boot services... `. +Steps to reproduce: +```console +$ qemu-system-arm -machine virt -m 2048 -nographic -bios /usr/local/share/qemu/edk2-arm-code.fd -hda ubuntu-23.04-server-cloudimg-armhf.img -snapshot +UEFI firmware (version edk2-stable202302-for-qemu built at 17:13:00 on Mar 15 2023) +Error: Image at 000BFD84000 start failed: Not Found +Error: Image at 000BFCEE000 start failed: Unsupported +Error: Image at 000BFC85000 start failed: Not Found +Tpm2SubmitCommand - Tcg2 - Not Found +Tpm2GetCapabilityPcrs fail! +Tpm2SubmitCommand - Tcg2 - Not Found +BdsDxe: loading Boot0001 "UEFI Misc Device" from PciRoot(0x0)/Pci(0x2,0x0) +BdsDxe: starting Boot0001 "UEFI Misc Device" from PciRoot(0x0)/Pci(0x2,0x0) +EFI stub: Booting Linux Kernel... +EFI stub: Entering in SVC mode with MMU enabled +EFI stub: Using DTB from configuration table +EFI stub: Exiting boot services... +``` +Additional information: +It still boots when vmlinuz and initrd are directly specified: +```console +$ qemu-system-arm -machine virt -m 2048 -nographic -bios /usr/local/share/qemu/edk2-arm-code.fd -hda ubuntu-23.04-server-cloudimg-armhf.img -snapshot -kernel ubuntu-23.04-server-cloudimg-armhf-vmlinuz-lpae -initrd ubuntu-23.04-server-cloudimg-armhf-initrd-generic-lpae -append "root=LABEL=cloudimg-rootfs ro" +UEFI firmware (version edk2-stable202302-for-qemu built at 17:13:00 on Mar 15 2023) +Error: Image at 000BFD84000 start failed: Not Found +Error: Image at 000BFCEE000 start failed: Unsupported +Tpm2SubmitCommand - Tcg2 - Not Found +Tpm2GetCapabilityPcrs fail! +Tpm2SubmitCommand - Tcg2 - Not Found +EFI stub: Booting Linux Kernel... +EFI stub: Entering in SVC mode with MMU enabled +EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path +EFI stub: Using DTB from configuration table +EFI stub: Exiting boot services... +[ 0.000000] Booting Linux on physical CPU 0x0 +[ 0.000000] Linux version 6.2.0-26-generic-lpae (buildd@bos02-arm64-018) (arm-linux-gnueabihf-gcc-12 (Ubuntu 12.2.0-17ubuntu1) 12.2.0, GNU ld (GNU + Binutils for Ubuntu) 2.40) #26-Ubuntu SMP Tue Jul 11 10:32:58 UTC 2023 (Ubuntu 6.2.0-26.26-generic-lpae 6.2.13) +[ 0.000000] CPU: ARMv7 Processor [414fc0f0] revision 0 (ARMv7), cr=30c5387d +... +Ubuntu 23.04 ubuntu ttyAMA0 + +ubuntu login: +``` + + +Files: +- https://cloud-images.ubuntu.com/releases/23.04/release-20230729/ubuntu-23.04-server-cloudimg-armhf.img +- https://cloud-images.ubuntu.com/releases/23.04/release-20230729/unpacked/ubuntu-23.04-server-cloudimg-armhf-vmlinuz-lpae +- https://cloud-images.ubuntu.com/releases/23.04/release-20230729/unpacked/ubuntu-23.04-server-cloudimg-armhf-initrd-generic-lpae diff --git a/results/classifier/105/mistranslation/1805445 b/results/classifier/105/mistranslation/1805445 new file mode 100644 index 000000000..1cb86d378 --- /dev/null +++ b/results/classifier/105/mistranslation/1805445 @@ -0,0 +1,96 @@ +mistranslation: 0.649 +semantic: 0.620 +instruction: 0.571 +graphic: 0.529 +other: 0.505 +KVM: 0.503 +device: 0.466 +vnc: 0.440 +assembly: 0.348 +socket: 0.334 +boot: 0.310 +network: 0.232 + +QEMU arm virt machine was stopped by STMFD command while debug process + +Hello, i have a big problem with QEMU arm virtual machine. So... +I run QEMU machine with bare-metal ThreadX fullflash from Texet TM-333 phone (Spreadtrum platform) +[CODE]qemu-system-arm -S -gdb tcp::1234,ipv4 -drive file=C:\cygwin64\home\flash.bin,if=mtd,format=raw -M palmetto-bmc -cpu arm926 -m 64M[/CODE] +I use palmetto-bmc platform because it have ARM926EJ-S core and support SPI Flash. +Then, i attach to gdb qemu process from IDA and run code step-by-step. +[IMG]https://pp.userapi.com/c847218/v847218546/13ec1c/iSIcre5-js4.jpg[/IMG] + +When the IDA run 00032534 STR R11, [R10] command +[IMG]https://pp.userapi.com/c846416/v846416708/133f60/GQzxORvf4Tg.jpg[/IMG] + +instead of store R11 on R10 adress, it jump 000328DC STMFD SP!, {R0-R12,LR} instruction... +[IMG]https://pp.userapi.com/c847218/v847218546/13ec26/32A0VcaJywg.jpg[/IMG] +and virt machine not execute new instruction... +[IMG]https://pp.userapi.com/c850624/v850624111/528f3/N7FTpgloWVU.jpg[/IMG] + +and why i did not change flash from n25q256a to n25q032a11 in aspeed.c without rebuild qemu? + + + +In your "before the STR" image the guest CPU is in mode 0x13, which is Supervisor. In the image afterwards, it is in Abort mode (0x17). I think therefore that what has happened is that the memory address the code is trying to store to is not accessible, and the guest has taken a Data Abort exception, so in the second image you are looking at your guest's exception handler code for the data abort. + +There is a long-standing bug where singlestepping an insn which takes an exception results in our stepping the insn at the exception vector entry point and then stopping, rather than stopping on the entry point, which may be confusing you here. (That's LP:757702.) + + +As a more general note, you can't expect to be able to run a flash image from one Arm system (your phone) on a different Arm system. All Arm boards are completely different in their memory layout, where they put devices, what devices are present, and so on. Trying to run an image for the wrong machine will result in it crashing very early on, when the guest tries to read a device or RAM which isn't where it expects to be. The palmetto-bmc machine will only run code that's built for that system. + + +Okey, thank you for attentioned me to arm mode. +The STR instruction is STR R11, [0x82000012]. Can I set rule for qemu to write RAM from 0x80000000 to 0x8FFFFFFF for execute basic arm instruction, Or need fix source and rebuild qemu? + +I have experience to rebuild source qemu for change spi flash from n25q256a to n25q032a11. Do you include to wishlist change flash-chip function? + +You would need to write a model of the hardware you're trying to emulate. That would require documentation of it and quite a lot of time (it's about equivalent in effort to writing a Linux port to the hardware, as a rule of thumb). + +I'm not sure what your suggestion about the SPI flash is: I assume that what we have for the aspeed boards is correct for that hardware. + + +Maybe this is correct for palmetto-board, but qemu user should be able to debug any basic arm instructions for generic arm board with general purpose SPI, I2C etc... My SPI Flash has 4 Mb, and RAM adress may start from 0x400000, This is impossible for 256 Mb Flash. It would be great, if qemu can build general arm device with var ram adr, cpu core and block dev. + +No, that is not something that QEMU supports. There is no such thing as a "generic arm board". All arm boards are different hardware, and we model only a few boards. We don't provide "put together your own model from building blocks" functionality, I'm afraid, and it's unlikely we ever will in future. + + +Hm, I am create a new machine based on palmetto-bmc +static const AspeedBoardConfig aspeed_boards[] = ...{ + .name = MACHINE_TYPE_NAME("texet-tm-333"), + .desc = "Spreadtrum teXet TM-333 (ARM926EJ-S)", + .soc_name = "ast2500-a1", + .hw_strap1 = SPREADTRUM_BMC_HW_STRAP1, + .fmc_model = "n25q032a11",h + .spi_model = "mx25l3205d", + .num_cs = 1, + .i2c_init = spreadtrum_bmc_i2c_init, + },... + +and change soc_name to the ast2500-a1, because #define AST2500_SDRAM_BASE 0x80000000 on the aspeed_soc.c also i change flash for my 4Mb fullflash image. Building qemu and this is work fine! +The STR command work correctly and STMFD/PUSH/POP also work fine. (The SP register was equal 0 in past bug) + + /* + * Allocate RAM after the memory controller has checked the size + * was valid. If not, a default value is used. + */ + ram_size = object_property_get_uint(OBJECT(&bmc->soc), "ram-size", &error_abort); + + memory_region_allocate_system_memory(&bmc->ram1, NULL, "ram1", ram_size); + memory_region_allocate_system_memory(&bmc->ram2, NULL, "ram2", ram_size); + memory_region_allocate_system_memory(&bmc->ram3, NULL, "ram3", ram_size); + + memory_region_add_subregion(get_system_memory(), sc->info->sdram_base[1], &bmc->ram1); + memory_region_add_subregion(get_system_memory(), sc->info->sdram_base[0], &bmc->ram2); + memory_region_add_subregion(get_system_memory(), sc->info->sdram_base[2], &bmc->ram3); + + object_property_add_const_link(OBJECT(&bmc->soc), "ram1", OBJECT(&bmc->ram1), &error_abort); + object_property_add_const_link(OBJECT(&bmc->soc), "ram2", OBJECT(&bmc->ram2), &error_abort); + object_property_add_const_link(OBJECT(&bmc->soc), "ram3", OBJECT(&bmc->ram3), &error_abort); + +And I can create 3 RAM section for avoid exeption handler! Maybe any devices from this adress does not appear in qemu... + + +I think there isn't a QEMU bug to address here, so I'm going to close this bug. Please let us know if there's anything we've missed. + + diff --git a/results/classifier/105/mistranslation/1811862 b/results/classifier/105/mistranslation/1811862 new file mode 100644 index 000000000..45b12e870 --- /dev/null +++ b/results/classifier/105/mistranslation/1811862 @@ -0,0 +1,57 @@ +mistranslation: 0.703 +graphic: 0.629 +semantic: 0.548 +device: 0.521 +other: 0.517 +instruction: 0.503 +boot: 0.457 +KVM: 0.340 +vnc: 0.317 +network: 0.306 +socket: 0.239 +assembly: 0.197 + +microcode version stays 0x1 even if -cpu host is used + +The microcode version of my host cpu has the following version: + +grep microcode /proc/cpuinfo | head -1 +microcode : 0x3d + +while trying to run ESXi in an nested VM, the boot bailed out with +error message that at least microcode version 0x19 is needed. It +seems they have introduced such a check on certain CPU types. + +The VM in question is using the "host-passthrough" option in libvirt +and the qemu command line reads as this: + +21172 ? Sl 0:09 /usr/libexec/qemu-kvm -name guest=hpe-env-client1,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-33-hpe-env-client1/master-key.aes -machine pc-i440fx-rhel7.6.0,accel=kvm,usb=off,dump-guest-core=off -cpu host <rest stripped> + +Running a regular Linux VM with `host-passthrough` shows that the +microcode version is still reported as 0x1. + +Within the VM: + +[root@hpe-env-client1 ~]# cat /proc/cpuinfo +processor : 0 +vendor_id : GenuineIntel +cpu family : 6 +model : 63 +model name : Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz +stepping : 2 +microcode : 0x1 +cpu MHz : 2397.222 + + +My impression is qemu should copy the hosts microcode version in this case? + +Running Qemu von RHEl8 beta here. + +[root@3parserver ~]# /usr/libexec/qemu-kvm --version +QEMU emulator version 2.12.0 (qemu-kvm-2.12.0-41.el8+2104+3e32e6f8) + +The QEMU project is currently considering to move 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 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. + +This is fixed in 5.2. + diff --git a/results/classifier/105/mistranslation/1814381 b/results/classifier/105/mistranslation/1814381 new file mode 100644 index 000000000..d293125a2 --- /dev/null +++ b/results/classifier/105/mistranslation/1814381 @@ -0,0 +1,78 @@ +mistranslation: 0.884 +other: 0.864 +assembly: 0.862 +semantic: 0.854 +socket: 0.851 +instruction: 0.850 +network: 0.845 +device: 0.842 +graphic: 0.842 +KVM: 0.839 +vnc: 0.837 +boot: 0.806 + +qemu can't resolve ::1 when no network is available + +I'm not sure if this is a qemu thing or a getaddrinfo/glibc thing, or +even just something about my laptop. However we have a test failure +in nbdkit which only occurs when my laptop is not connected to wifi or +other networking. It boils down to: + + $ qemu-img info --image-opts "file.driver=nbd,file.host=::1,file.port=1234" + qemu-img: Could not open 'file.driver=nbd,file.host=::1,file.port=1234': addre +ss resolution failed for ::1:1234: Address family for hostname not supported + +In a successful case it should connect to a local NBD server on port +1234, but if you don't have that you will see: + + qemu-img: Could not open 'file.driver=nbd,file.host=::1,file.port=1234': Faile +d to connect socket: Connection refused + +I can ‘ping6 ::1’ fine. + +It also works if I replace ‘::1’ with ‘localhost6’. + +My /etc/hosts contains: + +127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 +::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 + +ping6 output when the network is not connected: + +$ ping6 ::1 +PING ::1(::1) 56 data bytes +64 bytes from ::1: icmp_seq=1 ttl=64 time=0.082 ms +64 bytes from ::1: icmp_seq=2 ttl=64 time=0.092 ms +64 bytes from ::1: icmp_seq=3 ttl=64 time=0.089 ms +^C +--- ::1 ping statistics --- +3 packets transmitted, 3 received, 0% packet loss, time 55ms +rtt min/avg/max/mdev = 0.082/0.087/0.092/0.011 ms + + +ip output when the network is not connected: + +$ ip a show scope host +1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 + link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 + inet 127.0.0.1/8 scope host lo + valid_lft forever preferred_lft forever + inet6 ::1/128 scope host + valid_lft forever preferred_lft forever +2: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000 + link/ether e8:6a:64:5d:2c:66 brd ff:ff:ff:ff:ff:ff +3: wlp61s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000 + link/ether 1e:2b:b1:0c:99:ef brd ff:ff:ff:ff:ff:ff +5: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 1000 + link/ether 52:54:00:72:04:db brd ff:ff:ff:ff:ff:ff + + +The logic in util/qemu-sockets.c is very complicated, containing workarounds +for all sorts of broken/obsolete GAI implementations, so it's hard to tell +what's going on there. + +The QEMU project is currently considering to move 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 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/105/mistranslation/1815143 b/results/classifier/105/mistranslation/1815143 new file mode 100644 index 000000000..f2aa754d9 --- /dev/null +++ b/results/classifier/105/mistranslation/1815143 @@ -0,0 +1,110 @@ +mistranslation: 0.885 +other: 0.779 +semantic: 0.745 +instruction: 0.742 +device: 0.723 +socket: 0.697 +assembly: 0.680 +KVM: 0.652 +boot: 0.634 +graphic: 0.606 +network: 0.582 +vnc: 0.574 + + qemu-system-s390x fails when running without kvm: fatal: EXECUTE on instruction prefix 0x7f4 not implemented + +just wondering if TCG implements instruction prefix 0x7f4 + +server3:~ # zcat /boot/vmlinux-4.4.162-94.72-default.gz > /tmp/kernel + +--> starting qemu with kvm enabled works fine +server3:~ # qemu-system-s390x -nographic -kernel /tmp/kernel -initrd /boot/initrd -enable-kvm +Initializing cgroup subsys cpuset +Initializing cgroup subsys cpu +Initializing cgroup subsys cpuacct +Linux version 4.4.162-94.72-default (geeko@buildhost) (gcc version 4.8.5 (SUSE Linux) ) #1 SMP Mon Nov 12 18:57:45 UTC 2018 (9de753f) +setup.289988: Linux is running under KVM in 64-bit mode +setup.b050d0: The maximum memory size is 128MB +numa.196305: NUMA mode: plain +Write protected kernel read-only data: 8692k +[...] + +--> but starting qemu without kvm enabled works fails +server3:~ # qemu-system-s390x -nographic -kernel /tmp/kernel -initrd /boot/initrd +qemu: fatal: EXECUTE on instruction prefix 0x7f4 not implemented + +PSW=mask 0000000180000000 addr 000000000067ed6e cc 00 +R00=0000000080000000 R01=000000000067ed76 R02=0000000000000000 R03=0000000000000000 +R04=0000000000111548 R05=0000000000000000 R06=0000000000000000 R07=0000000000000000 +R08=00000000000100f6 R09=0000000000000000 R10=0000000000000000 R11=0000000000000000 +R12=0000000000ae2000 R13=0000000000681978 R14=0000000000111548 R15=000000000000bef0 +F00=0000000000000000 F01=0000000000000000 F02=0000000000000000 F03=0000000000000000 +F04=0000000000000000 F05=0000000000000000 F06=0000000000000000 F07=0000000000000000 +F08=0000000000000000 F09=0000000000000000 F10=0000000000000000 F11=0000000000000000 +F12=0000000000000000 F13=0000000000000000 F14=0000000000000000 F15=0000000000000000 +V00=00000000000000000000000000000000 V01=00000000000000000000000000000000 +V02=00000000000000000000000000000000 V03=00000000000000000000000000000000 +V04=00000000000000000000000000000000 V05=00000000000000000000000000000000 +V06=00000000000000000000000000000000 V07=00000000000000000000000000000000 +V08=00000000000000000000000000000000 V09=00000000000000000000000000000000 +V10=00000000000000000000000000000000 V11=00000000000000000000000000000000 +V12=00000000000000000000000000000000 V13=00000000000000000000000000000000 +V14=00000000000000000000000000000000 V15=00000000000000000000000000000000 +V16=00000000000000000000000000000000 V17=00000000000000000000000000000000 +V18=00000000000000000000000000000000 V19=00000000000000000000000000000000 +V20=00000000000000000000000000000000 V21=00000000000000000000000000000000 +V22=00000000000000000000000000000000 V23=00000000000000000000000000000000 +V24=00000000000000000000000000000000 V25=00000000000000000000000000000000 +V26=00000000000000000000000000000000 V27=00000000000000000000000000000000 +V28=00000000000000000000000000000000 V29=00000000000000000000000000000000 +V30=00000000000000000000000000000000 V31=00000000000000000000000000000000 +C00=0000000000000000 C01=0000000000000000 C02=0000000000000000 C03=0000000000000000 +C04=0000000000000000 C05=0000000000000000 C06=0000000000000000 C07=0000000000000000 +C08=0000000000000000 C09=0000000000000000 C10=0000000000000000 C11=0000000000000000 +C12=0000000000000000 C13=0000000000000000 C14=0000000000000000 C15=0000000000000000 + +Aborted (core dumped) + + +server3:~ # lscpu +Architecture: s390x +CPU op-mode(s): 32-bit, 64-bit +Byte Order: Big Endian +CPU(s): 2 +On-line CPU(s) list: 0,1 +Thread(s) per core: 1 +Core(s) per socket: 1 +Socket(s) per book: 1 +Book(s) per drawer: 1 +Drawer(s): 2 +NUMA node(s): 1 +Vendor ID: IBM/S390 +Machine type: 2964 +BogoMIPS: 20325.00 +Hypervisor: z/VM 6.4.0 +Hypervisor vendor: IBM +Virtualization type: full +Dispatching mode: horizontal +L1d cache: 128K +L1i cache: 96K +L2d cache: 2048K +L2i cache: 2048K +L3 cache: 65536K +L4 cache: 491520K +NUMA node0 CPU(s): 0-63 +Flags: esan3 zarch stfle msa ldisp eimm dfp edat etf3eh highgprs te vx sie +server3:~ # uname -a +Linux server3 4.4.126-94.22-default #1 SMP Wed Apr 11 07:45:03 UTC 2018 (9649989) s390x s390x s390x GNU/Linux +server3:~ # + +Which version of QEMU are you using here? I think this should be working fine with the latest version of QEMU (>= v2.10). + +Hi, Thomas, you are right, I am using 2.9.1, and it does look OK in 2.10. do you mind to point me which part of code fixed it? Thanks. + +A little bit confused here, I tired to bisect it from 2.10, but it was always good from this branch. then I went back to 2.9.1, it was always crashed. Machine type related? + +This should be the commit that fixed this issue: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=303c681a8f50eb88fbafc + +Confirmed the fix, thanks for the help. + diff --git a/results/classifier/105/mistranslation/1815413 b/results/classifier/105/mistranslation/1815413 new file mode 100644 index 000000000..fcc3e6313 --- /dev/null +++ b/results/classifier/105/mistranslation/1815413 @@ -0,0 +1,43 @@ +mistranslation: 0.792 +device: 0.597 +instruction: 0.570 +other: 0.503 +semantic: 0.445 +network: 0.206 +graphic: 0.200 +assembly: 0.135 +boot: 0.085 +socket: 0.076 +KVM: 0.030 +vnc: 0.025 + +compile with vhost-vsock support on osx + +compiling latest (3.1.0) on osx 10.14.3 with --enable-vhost-vsock and target = x86_64-softmmu results in compile errors: + +Undefined symbols for architecture x86_64: + "_vhost_dev_cleanup", referenced from: + _vhost_vsock_device_realize in vhost-vsock.o + _vhost_vsock_device_unrealize in vhost-vsock.o + "_vhost_dev_disable_notifiers", referenced from: + _vhost_vsock_set_status in vhost-vsock.o + "_vhost_dev_enable_notifiers", referenced from: + _vhost_vsock_set_status in vhost-vsock.o + "_vhost_dev_init", referenced from: + _vhost_vsock_device_realize in vhost-vsock.o + "_vhost_dev_start", referenced from: + _vhost_vsock_set_status in vhost-vsock.o + "_vhost_dev_stop", referenced from: + _vhost_vsock_set_status in vhost-vsock.o + "_vhost_virtqueue_mask", referenced from: + _vhost_vsock_set_status in vhost-vsock.o + _vhost_vsock_guest_notifier_mask in vhost-vsock.o + (maybe you meant: _cryptodev_vhost_virtqueue_mask) + "_vhost_virtqueue_pending", referenced from: + _vhost_vsock_guest_notifier_pending in vhost-vsock.o + (maybe you meant: _cryptodev_vhost_virtqueue_pending) +ld: symbol(s) not found for architecture x86_64 +clang: error: linker command failed with exit code 1 (use -v to see invocation) + +vhost devices are not available on macOS hosts, they are a Linux feature. + diff --git a/results/classifier/105/mistranslation/1816052 b/results/classifier/105/mistranslation/1816052 new file mode 100644 index 000000000..b4129a687 --- /dev/null +++ b/results/classifier/105/mistranslation/1816052 @@ -0,0 +1,106 @@ +mistranslation: 0.954 +assembly: 0.910 +semantic: 0.908 +device: 0.906 +other: 0.904 +instruction: 0.900 +vnc: 0.899 +graphic: 0.893 +KVM: 0.844 +boot: 0.840 +socket: 0.807 +network: 0.800 + +qemu system emulator fails to start if no sound card is present on host + +A plain build from git master at 81dbcfa9e1d8bab3f7c4cc923c0b40cd666f374f on Fedora 29 x86_64 host, with no options passed to configure. + +Trying to launch QEMU on a host with no audio card present: + +# ls /dev/snd/ +seq timer + +It will fail to initialize alsa and abort startup: + +# qemu-system-x86_64 -cdrom Fedora-Workstation-Live-x86_64-29-1.2.iso -m 4000 -vnc 0.0.0.0:1 +ALSA lib confmisc.c:767:(parse_card) cannot find card '0' +ALSA lib conf.c:4555:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory +ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings +ALSA lib conf.c:4555:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory +ALSA lib confmisc.c:1246:(snd_func_refer) error evaluating name +ALSA lib conf.c:4555:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory +ALSA lib conf.c:5034:(snd_config_expand) Evaluate error: No such file or directory +ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM default +alsa: Could not initialize DAC +alsa: Failed to open `default': +alsa: Reason: No such file or directory +ALSA lib confmisc.c:767:(parse_card) cannot find card '0' +ALSA lib conf.c:4555:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory +ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings +ALSA lib conf.c:4555:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory +ALSA lib confmisc.c:1246:(snd_func_refer) error evaluating name +ALSA lib conf.c:4555:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory +ALSA lib conf.c:5034:(snd_config_expand) Evaluate error: No such file or directory +ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM default +alsa: Could not initialize DAC +alsa: Failed to open `default': +alsa: Reason: No such file or directory +init fail +audio: Failed to create voice `pcspk' +qemu-system-x86_64: Initialization of device isa-pcspk failed: Initializing audio voice failed + + +git bisect blames this change: + + + commit 6a48541873f14b597630283f8f5397674ad82ea9 (HEAD, refs/bisect/bad) + Author: Gerd Hoffmann <email address hidden> + Date: Thu Jan 24 12:20:55 2019 +0100 + + audio: probe audio drivers by default + + Add the drivers listed in audio_possible_drivers to audio_drv_list, + using the try-* variants. That way the probable drivers are compiled by + default if possible. + + Additioal tweaks: + linux: reorder to: pa alsa sdl oss. + *bsd: drop pa. + + Signed-off-by: Gerd Hoffmann <email address hidden> + Message-id: <email address hidden> + + +This changed our probe order: + + Linux) + - audio_drv_list="oss" + + audio_drv_list="try-pa try-alsa try-sdl oss" + +After some debugging I can see that 'audio_init' successfully initializes the alsa driver. + +When the pcspk devices goes to AUD_open_out though, the alsa driver fails spewing the above text to stderr and thus causes QEMU to fail. + +This looks very much like the ALSA driver in QEMU is broken - audio_init() should not have succeeded unless the ALSA driver knew it could later succesfully honour AUD_open_out. + +Don't know if same but just noticed "no sound" unless I unplug and replug headphones. If I boot with no headphones plugged in I get no sound, but if I plug in headphones I get sound. Of course, then, if I unplug headphones I still get sound. Something about plugging/unplugging to the headphones jack wakes things up. + +ThinkPad T530-2394-3J8, i5-3380M 2.9GHz, Dual boot (BIOS/MBR): Grub, Ubuntu 18.10 / Win7 Pro x64 . 8GB(15GB/s), Sammy 250GB SSD. Fast! + +4.19.0-13 kern and previous. current: I take all updates. + +That was Ubuntu DD current on comment #1 + +Kris, your situation is completely different. + +I agree. Thanks. :) + +What happens if you remove "try-alsa" from the configure line? + +I would work around this issue +by applying "export QEMU_AUDIO_DRV=none" to shell before we run the qemu command. + + +This bug was fixed by commit 7183834a29fbaf422a6 which will be in 4.0. + + diff --git a/results/classifier/105/mistranslation/1819289 b/results/classifier/105/mistranslation/1819289 new file mode 100644 index 000000000..cdef86125 --- /dev/null +++ b/results/classifier/105/mistranslation/1819289 @@ -0,0 +1,247 @@ +mistranslation: 0.786 +instruction: 0.775 +semantic: 0.730 +boot: 0.722 +device: 0.701 +assembly: 0.691 +graphic: 0.684 +socket: 0.669 +vnc: 0.657 +other: 0.656 +KVM: 0.579 +network: 0.567 + +Windows 95 and Windows 98 will not install or run + +The last version of QEMU I have been able to run Windows 95 or Windows 98 on was 2.7 or 2.8. Recent versions since then even up to 3.1 will either not install or will not run 95 or 98 at all. I have tried every combination of options like isapc or no isapc, cpu pentium or cpu as 486. Tried different memory configurations, but they just don't work anymore. + +I was able to get both running on 3.11.0, but something broke again by the time I re-tested on 4.0.0. 98 seems to work on 4.0 at least, but 95 just reboots infinitely after trying to boot from HDD after the initial setup. I tried searching their mailing list and asking around but nobody seems interested in fixing it. + +Whoops, 3.11.0 does not exist. Went back and did a full bisect. 3.0.0 works fine, and the breakage starts before 3.0.1 and 3.1.0 was released, specifically, with commit 05306935b1ae49107c2dc2f301574dd6c29b6838. + +On 8/19/19 7:26 PM, Brad Parker wrote: +> Whoops, 3.11.0 does not exist. Went back and did a full bisect. 3.0.0 +> works fine, and the breakage starts before 3.0.1 and 3.1.0 was released, +> specifically, with commit 05306935b1ae49107c2dc2f301574dd6c29b6838. + +This commit is migration related. Are you trying to restore/launch a pre-installed image? + +John reported "either not install or will not run 95 or 98 at all" but you report "95 just reboots infinitely after trying to boot from HDD after the initial setup." which is slighly different. + +What host/os/distrib are you using? + +What command line are you using to start QEMU? + +If you are using migration, I wonder if the following commit might affect here: + +commit 341ba0df4c69269cac839ddbacb2a0ca641a856d +Author: Peter Maydell <email address hidden> +Date: Tue Sep 25 17:19:24 2018 +0100 + + migration/ram.c: Avoid taking address of fields in packed MultiFDInit_t struct + + Taking the address of a field in a packed struct is a bad idea, because + it might not be actually aligned enough for that pointer type (and + thus cause a crash on dereference on some host architectures). Newer + versions of clang warn about this: + + Avoid the bug by not using the "modify in place" byteswapping + functions. + + +I am not using anything related to migration, just launching with a simple flat qcow2 file, no snapshots, backing stores or anything like that. + +The host is Archlinux x64 but I'm running inside of a docker container that runs Ubuntu 18.04. + +The command-line is: + +qemu-system-i386 -spice port=5800,disable-ticketing=on -cpu pentium -m 128 -vga std -no-kvm -hda Win95C.qcow2 -nodefaults -no-hpet -no-acpi -cdrom Win95C.iso -nodefaults -M isapc -monitor stdio + +Just FYI that was the second bisect I had to do, the first time it produced an even more unrelated commit, so I assumed I must have done something wrong... apparently that is still the case. After trying the "working" commit outside of the Docker container, it now does not work... so I'm at a loss as to how to reliably bisect I guess. Never had any issues with other projects doing it though. + +Yep, these types of bugs don't necessarily bisect cleanly if they're todo with code layout or dirty memory. +Still, it's good to keep a note of the earliest patches that you find a failure on - because then we know it must be somewhere before that. + +I remember there was a problem reported booting FreeDOS as well; and I've got to wonder if it's related. + +Hopefully third time's the charm. I ran yet another bisect, between 2.5.0 (working) and 2.11.0 (not working), this time reinstalling the entire OS from scratch with a blank disk every single time. Results: + +$ git bisect good +e3af7c788b73a6495eb9d94992ef11f6ad6f3c56 is the first bad commit +commit e3af7c788b73a6495eb9d94992ef11f6ad6f3c56 +Author: Paolo Bonzini <email address hidden> +Date: Wed Apr 26 13:59:34 2017 +0200 + + target/i386: introduce x86_ld*_code + + These take care of advancing s->pc, and will provide a unified point + where to check for the 15-byte instruction length limit. + + Signed-off-by: Paolo Bonzini <email address hidden> + + target/i386/translate.c | 228 ++++++++++++++++++++++++++---------------------- + 1 file changed, 125 insertions(+), 103 deletions(-) + + +If your bisect hit e3af7c788b73a6495 can you try it with cfcca361d77142f25f applied on top? That commit fixed a bug in e3af7c788b73a6495 which may be throwing off your bisection results. + + +e3af7c788b73a6495 was indeed one of the bad commits I tested during the bisect. If I apply cfcca361d77142f25f on top of it, Windows starts up normally instead of giving me a BSOD on bootup. + +So it looks like even though that commit fixed it, it seems to break again (differently) in 3.0.0, so I'll need to do another bisect between cfcca36 and v3.0.0 then I guess. And keep working my way up to master as well. + +Just finished a bisect between cfcca36 (working) and current master (not working), here is the result: + +$ git bisect bad +cd1bfd5ef336166b275a09dc9842542bf5e63ae3 is the first bad commit +commit cd1bfd5ef336166b275a09dc9842542bf5e63ae3 +Author: Gerd Hoffmann <email address hidden> +Date: Wed Jun 20 12:17:34 2018 +0200 + + seabios: update bios and vgabios binaries + + Adds two new vgabios binaries, for ramfb and bochs-display. + + Signed-off-by: Gerd Hoffmann <email address hidden> + + pc-bios/bios-256k.bin | Bin 262144 -> 262144 bytes + pc-bios/bios.bin | Bin 131072 -> 131072 bytes + pc-bios/vgabios-bochs-display.bin | Bin 0 -> 27648 bytes + pc-bios/vgabios-cirrus.bin | Bin 38400 -> 38400 bytes + pc-bios/vgabios-qxl.bin | Bin 38912 -> 38912 bytes + pc-bios/vgabios-ramfb.bin | Bin 0 -> 28160 bytes + pc-bios/vgabios-stdvga.bin | Bin 38912 -> 38912 bytes + pc-bios/vgabios-virtio.bin | Bin 38912 -> 38912 bytes + pc-bios/vgabios-vmware.bin | Bin 38912 -> 38912 bytes + pc-bios/vgabios.bin | Bin 38400 -> 38400 bytes + 10 files changed, 0 insertions(+), 0 deletions(-) + create mode 100644 pc-bios/vgabios-bochs-display.bin + create mode 100644 pc-bios/vgabios-ramfb.bin + + +I tried reverting that commit on top of master but it did not help, so I'm guessing it broke yet again (differently) somewhere else. I'll try reverting cd1bfd5 on top of the very next commit and bisect from there to master, and see where that takes me. + +> cd1bfd5ef336166b275a09dc9842542bf5e63ae3 is the first bad commit + +Unfortunately this is a commit related to SeaBIOS submodule. +This commit only update the built BIOS roms. + +The commits before this one are the ones modifying SeaBIOS, justifying roms to be rebuilt: + +eda553a442 seabios: enable ide dma +429d3ae2c8 seabios: update submodule to release 1.11.2 + +The first one (enable ide dma) is a change in the config. +You can rebuild the BIOS image and bisect around this commit. + +You can rebuild the SeaBIOS image running this command in QEMU source repository: + + $ make -C roms bios + +This will update 'pc-bios/bios.bin' which you use while bisecting. + +The second one update the SeaBIOS submodule from commit 0551a4be2c to commit f9626ccb91. + +These are not so many commits, so the bisect won't be painful: + +$ git log --oneline 0551a4be2~..f9626ccb91 +f9626cc (tag: rel-1.11.2) cbvga_set_mode: refine clear display logic +f88297a qemu: add qemu ramfb support +a2e4001 vgasrc: add allocate_pmm() +17b01f4 pmm: use tmp zone on oom +44b17d0 bochs_display_setup: return error on failure +4ba61fa cbvga_set_mode: disable clearmem in windows x86 emulator. +dd69189 cbvga_list_modes: don't list current mode twice +5f0e7c9 cbvga_setup_modes: use real mode number instead of 0x140 +961f67c qemu: add bochs-display support +767365e cbvga: factor out cbvga_setup_modes() +7906460 optionrom: enable non-vga display devices +0551a4b (tag: rel-1.11.1) paravirt: Only enable sercon in NOGRAPHIC mode if no other console specified + +I recommend doing your bisection using 2 terminals: + +- one in QEMU source, running 'make -C roms bios' to rebuild 'pc-bios/bios.bin' and run QEMU installing your image, + +- one in roms/seabios/ where you run the 'git bisect' commands. + +Note, you don't have to rebuild QEMU. + +Alternatively, using a single terminal, you can stand in the roms/seabios/ directory, bisect and run 'make -C .. bios'. In this case it might be useful to run QEMU with -L ../../pc-bios to specify the path to the generated bios.bin. + +You are close, good luck! + +After hours bisecting various QEMU/SeaBIOS combinations, Brad figured out a new commit: + +0a7fa00a13f0852ec6fa83ab987a5ee7978d9867 is the first bad commit +Author: Emilio G. Cota <email address hidden> +Date: Mon Aug 13 20:52:26 2018 -0400 + + configure: enable mttcg for i386 and x86_64 + +Note 1: Brad was not using '-M isapc'. +Note 2: Brad was using the pc-bios/ folder checkout'd at v4.1.0 or 33f18cf7dc to avoid the SeaBIOS issues reported previously + +Brad could succeed booting QEMU using '-accel thread=single' on 0a7fa00a13. + + + +Here is the exact working command line I used for Windows 95C (OSR2.5): + +qemu-system-i386 -cpu pentium -m 128 -vga std -no-kvm -hda ~/Win95C.qcow2 -nodefaults -no-hpet -no-acpi -nodefaults -monitor stdio -sdl -boot menu=on,order=c,splash-time=2000 -accel tcg,thread=single + +To install the OS I simply added -cdrom and -fda, but everything else stayed the same. + +This was using the latest master (33f18cf, after v4.1.0) and its included bios binaries. + +I just did an install of Windows 95 in 4.2 and it installs and runs out of the box with -accel tcg. Thanks!! + +According to the last comment, the problem seems to be fixed since QEMU 4.2, right? ... so I'm closing this ticket now. If there is still something left to do, please open again. + +Per Brad on IRC, this issue persists. Re-opening to move to GitLab. + +Since there is some unclear information in here (which version is working? which is not?), could you please open a new ticket on gitlab instead, with a proper description what is not working with which version? + +Brad said later after testing v6.1 it was fixed so please disregard previous comment ¯\_(ツ)_/¯ + +This is happening again in 8.1. I used Windows 95 for a while in 6.1 and it +was fine, but when I tried to upgrade to 8.1, it started happening again. I +tried reducing the memory and it still happens. Not an urgent issue though. + +On Mon, Aug 30, 2021 at 2:05 AM Philippe Mathieu-Daudé < +<email address hidden>> wrote: + +> Brad said later after testing v6.1 it was fixed so please disregard +> previous comment ¯\_(ツ)_/¯ +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1819289 +> +> Title: +> Windows 95 and Windows 98 will not install or run +> +> Status in QEMU: +> Fix Released +> +> Bug description: +> The last version of QEMU I have been able to run Windows 95 or Windows +> 98 on was 2.7 or 2.8. Recent versions since then even up to 3.1 will +> either not install or will not run 95 or 98 at all. I have tried every +> combination of options like isapc or no isapc, cpu pentium or cpu as +> 486. Tried different memory configurations, but they just don't work +> anymore. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1819289/+subscriptions +> +> + + +I found a win98 iso image and gave this a try with qemu 8.1. It works here just fine - either kvm or tcg mode, either qemu x86_64 or i386. Without any extra options, just this: + + + qemu-system-i386 -cdrom w98.iso -drive file=w98.img,format=raw + +It also works fine with a few previous versions of qemu (tried 5.2 and 7.2). Everything tested on debian bookworm (with various versions of qemu debian packages). + diff --git a/results/classifier/105/mistranslation/1820247 b/results/classifier/105/mistranslation/1820247 new file mode 100644 index 000000000..8ea6cd411 --- /dev/null +++ b/results/classifier/105/mistranslation/1820247 @@ -0,0 +1,430 @@ +mistranslation: 0.727 +KVM: 0.714 +other: 0.677 +vnc: 0.651 +socket: 0.632 +device: 0.622 +boot: 0.616 +instruction: 0.591 +assembly: 0.567 +network: 0.555 +graphic: 0.544 +semantic: 0.498 + +QEMU random crash caused by libspice-server + +Hi, + +One of our OpenStack instances crashed. It seems there was some problem related to SPICE. Attaching what we had in qemu log. Also sending our versions: + +Linux pre-node1 4.18.0-13-generic #14~18.04.1-Ubuntu SMP Thu Dec 6 14:09:52 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux + +QEMU emulator version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.9) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + + +root@pre-node1:~# cat /var/log/libvirt/qemu/instance-00000038.log +2019-03-10 20:39:36.510+0000: starting up libvirt version: 4.0.0, package: 1ubuntu8.6 (Christian Ehrhardt <email address hidden> Fri, 09 Nov 2018 07:42:01 +0100), qemu version: 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.9), hostname: pre-node1 +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin QEMU_AUDIO_DRV=spice /usr/bin/kvm-spice -name guest=instance-00000038,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-5-instance-00000038/master-key.aes -machine pc-i440fx-bionic,accel=kvm,usb=off,dump-guest-core=off,mem-merge=off -cpu Skylake-Server-IBRS,ss=on,hypervisor=on,tsc_adjust=on,clflushopt=on,pku=on,ssbd=on,xsaves=on -m 2048 -realtime mlock=on -smp 2,sockets=1,cores=1,threads=2 -object memory-backend-file,id=ram-node0,prealloc=yes,mem-path=/dev/hugepages/libvirt/qemu/5-instance-00000038,share=yes,size=2147483648,host-nodes=0,policy=bind -numa node,nodeid=0,cpus=0-1,memdev=ram-node0 -uuid 3c3d04f3-4b25-4ea5-8836-0e06eef9dcb7 -smbios 'type=1,manufacturer=OpenStack Foundation,product=OpenStack Nova,version=18.1.1,serial=93fa1a55-ba3a-4a99-80b3-3a7bb4e964af,uuid=3c3d04f3-4b25-4ea5-8836-0e06eef9dcb7,family=Virtual Machine' -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-5-instance-00000038/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 -drive file=/var/lib/nova/instances/3c3d04f3-4b25-4ea5-8836-0e06eef9dcb7/disk,format=qcow2,if=none,id=drive-virtio-disk0,cache=none,discard=ignore,throttling.iops-read=5000,throttling.iops-write=5000 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -add-fd set=0,fd=29 -chardev pty,id=charserial0,logfile=/dev/fdset/0,logappend=on -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -spice port=5900,addr=10.252.0.101,disable-ticketing,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 -device vfio-pci,host=25:04.1,id=hostdev0,bus=pci.0,addr=0x5 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -msg timestamp=on +2019-03-10T20:39:36.568276Z qemu-system-x86_64: -chardev pty,id=charserial0,logfile=/dev/fdset/0,logappend=on: char device redirected to /dev/pts/2 (label charserial0) +inputs_channel_detach_tablet: +main_channel_link: add main channel client +main_channel_client_handle_pong: net test: latency 32.760000 ms, bitrate 33384953 bps (31.838372 Mbps) +red_qxl_set_cursor_peer: +inputs_connect: inputs channel client create + +(process:65324): Spice-WARNING **: 16:35:23.769: Failed to create channel client: Client 0x55e7c157e970: duplicate channel type 2 id 0 +red_qxl_set_cursor_peer: + +(process:65324): Spice-WARNING **: 16:35:24.142: Failed to create channel client: Client 0x55e7c157e970: duplicate channel type 4 id 0 + +(process:65324): Spice-CRITICAL **: 16:35:24.142: cursor-channel.c:353:cursor_channel_connect: condition `ccc != NULL' failed +2019-03-13 15:35:31.785+0000: shutting down, reason=crashed + + + + +I am also attaching some gdb information extracted from qemu crash dump file. These are backtraces of particular threads within the crashed QEMU process. + + +Thread 9 (Thread 0x7f69649ea5c0 (LWP 65324)): +#0 0x00007f695f02d2b7 in __libc_write (fd=26, buf=0x7ffc33f5b330, nbytes=56) at ../sysdeps/unix/sysv/linux/write.c:27 +#1 0x00007f695ff30ed3 in () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +#2 0x00007f695ff316ce in () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +#3 0x00007f695ff52db6 in () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +#4 0x00007f695ff58e38 in () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +#5 0x00007f695ff5f463 in () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +#6 0x00007f695ff5f7bb in () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +#7 0x000055e7bec94584 in () +#8 0x000055e7bec94e58 in aio_dispatch () +#9 0x000055e7bec91e3e in () +#10 0x00007f695fa45387 in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +#11 0x000055e7bec940a7 in main_loop_wait () +#12 0x000055e7be8b8486 in main () + +Thread 8 (Thread 0x7f68b78fc700 (LWP 61873)): +#0 0x00007f695f02c8c2 in futex_abstimed_wait_cancelable (private=0, abstime=0x7f68b78fb900, expected=0, futex_word=0x55e7c1531d78) + at ../sysdeps/unix/sysv/linux/futex-internal.h:205 +#1 0x00007f695f02c8c2 in do_futex_wait (sem=sem@entry=0x55e7c1531d78, abstime=abstime@entry=0x7f68b78fb900) at sem_waitcommon.c:111 +#2 0x00007f695f02c9d3 in __new_sem_wait_slow (sem=0x55e7c1531d78, abstime=0x7f68b78fb900) at sem_waitcommon.c:181 +#3 0x000055e7bec976cf in qemu_sem_timedwait () +#4 0x000055e7bec928bc in () +#5 0x00007f695f0236db in start_thread (arg=0x7f68b78fc700) at pthread_create.c:463 +#6 0x00007f695ed4c88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Thread 7 (Thread 0x7f688f7fe700 (LWP 61366)): +#0 0x00007f695f02c8c2 in futex_abstimed_wait_cancelable (private=0, abstime=0x7f688f7fd900, expected=0, futex_word=0x55e7c1531d78) + at ../sysdeps/unix/sysv/linux/futex-internal.h:205 +#1 0x00007f695f02c8c2 in do_futex_wait (sem=sem@entry=0x55e7c1531d78, abstime=abstime@entry=0x7f688f7fd900) at sem_waitcommon.c:111 +#2 0x00007f695f02c9d3 in __new_sem_wait_slow (sem=0x55e7c1531d78, abstime=0x7f688f7fd900) at sem_waitcommon.c:181 +#3 0x000055e7bec976cf in qemu_sem_timedwait () +#4 0x000055e7bec928bc in () +#5 0x00007f695f0236db in start_thread (arg=0x7f688f7fe700) at pthread_create.c:463 +#6 0x00007f695ed4c88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Thread 6 (Thread 0x7f687effd700 (LWP 61362)): +#0 0x00007f695f02c8c2 in futex_abstimed_wait_cancelable (private=0, abstime=0x7f687effc900, expected=0, futex_word=0x55e7c1531d78) + at ../sysdeps/unix/sysv/linux/futex-internal.h:205 +#1 0x00007f695f02c8c2 in do_futex_wait (sem=sem@entry=0x55e7c1531d78, abstime=abstime@entry=0x7f687effc900) at sem_waitcommon.c:111 +#2 0x00007f695f02c9d3 in __new_sem_wait_slow (sem=0x55e7c1531d78, abstime=0x7f687effc900) at sem_waitcommon.c:181 +#3 0x000055e7bec976cf in qemu_sem_timedwait () +#4 0x000055e7bec928bc in () +#5 0x00007f695f0236db in start_thread (arg=0x7f687effd700) at pthread_create.c:463 +#6 0x00007f695ed4c88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Thread 5 (Thread 0x7f68b58f1700 (LWP 60991)): +#0 0x00007f695f02c8c2 in futex_abstimed_wait_cancelable (private=0, abstime=0x7f68b58f0900, expected=0, futex_word=0x55e7c1531d78) + at ../sysdeps/unix/sysv/linux/futex-internal.h:205 +#1 0x00007f695f02c8c2 in do_futex_wait (sem=sem@entry=0x55e7c1531d78, abstime=abstime@entry=0x7f68b58f0900) at sem_waitcommon.c:111 +#2 0x00007f695f02c9d3 in __new_sem_wait_slow (sem=0x55e7c1531d78, abstime=0x7f68b58f0900) at sem_waitcommon.c:181 +#3 0x000055e7bec976cf in qemu_sem_timedwait () +#4 0x000055e7bec928bc in () +#5 0x00007f695f0236db in start_thread (arg=0x7f68b58f1700) at pthread_create.c:463 +#6 0x00007f695ed4c88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Thread 4 (Thread 0x7f69564a2700 (LWP 65331)): +#0 0x00007f695ed46839 in syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 +#1 0x000055e7bec9790b in qemu_event_wait () +#2 0x000055e7beca7ebe in () +#3 0x00007f695f0236db in start_thread (arg=0x7f69564a2700) at pthread_create.c:463 +#4 0x00007f695ed4c88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Thread 3 (Thread 0x7f695449d700 (LWP 65363)): +#0 0x00007f695ed415d7 in ioctl () at ../sysdeps/unix/syscall-template.S:78 +#1 0x000055e7be910547 in kvm_vcpu_ioctl () +#2 0x000055e7be910684 in kvm_cpu_exec () +#3 0x000055e7be8ed3f4 in () +#4 0x00007f695f0236db in start_thread (arg=0x7f695449d700) at pthread_create.c:463 +#5 0x00007f695ed4c88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Thread 2 (Thread 0x7f6952b4f700 (LWP 65366)): +#0 0x00007f695ed415d7 in ioctl () at ../sysdeps/unix/syscall-template.S:78 +#1 0x000055e7be910547 in kvm_vcpu_ioctl () +---Type <return> to continue, or q <return> to quit--- +#2 0x000055e7be910684 in kvm_cpu_exec () +#3 0x000055e7be8ed3f4 in () +#4 0x00007f695f0236db in start_thread (arg=0x7f6952b4f700) at pthread_create.c:463 +#5 0x00007f695ed4c88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Thread 1 (Thread 0x7f6951a40700 (LWP 65368)): +#0 0x00007f695ec69e97 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 +#1 0x00007f695ec6b801 in __GI_abort () at abort.c:79 +#2 0x00007f695ff81cc9 in () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +#3 0x00007f695ff63929 in () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +#4 0x00007f695ff314f1 in () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +#5 0x00007f695ff37d7b in () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +#6 0x00007f695fa451f5 in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +#7 0x00007f695fa455c0 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +#8 0x00007f695fa458d2 in g_main_loop_run () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +#9 0x00007f695ff63b3a in () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +#10 0x00007f695f0236db in start_thread (arg=0x7f6951a40700) at pthread_create.c:463 +#11 0x00007f695ed4c88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Regards, +Premysl + +Hi Premysl, +this has similarities to [1] which was fixed long ago. +In case it is reproducible for you - as it was asked back then - it might be helpful attaching SPICE_DEBUG=1 log, using remote-viewer. + +And if reproducible in general also worth a quick check to try with the latest qemu version which atm is 3.1 that you have in Debian Buster. + +[1]: https://bugzilla.redhat.com/show_bug.cgi?id=980714#c8 + +Hi Christian, + +thanks for reply, chmmm, what makes you think there are similarities? To me +it looks like a different problem. + +Regards, +Premysl + + +On Mon, Mar 18, 2019 at 8:15 AM Christian Ehrhardt < +<email address hidden>> wrote: + +> Hi Premysl, +> this has similarities to [1] which was fixed long ago. +> In case it is reproducible for you - as it was asked back then - it might +> be helpful attaching SPICE_DEBUG=1 log, using remote-viewer. +> +> And if reproducible in general also worth a quick check to try with the +> latest qemu version which atm is 3.1 that you have in Debian Buster. +> +> [1]: https://bugzilla.redhat.com/show_bug.cgi?id=980714#c8 +> +> ** Bug watch added: Red Hat Bugzilla #980714 +> https://bugzilla.redhat.com/show_bug.cgi?id=980714 +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1820247 +> +> Title: +> QEMU random crash caused by libspice-server +> +> Status in QEMU: +> New +> +> Bug description: +> Hi, +> +> One of our OpenStack instances crashed. It seems there was some +> problem related to SPICE. Attaching what we had in qemu log. Also +> sending our versions: +> +> Linux pre-node1 4.18.0-13-generic #14~18.04.1-Ubuntu SMP Thu Dec 6 +> 14:09:52 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux +> +> QEMU emulator version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.9) +> Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers +> +> +> root@pre-node1:~# cat /var/log/libvirt/qemu/instance-00000038.log +> 2019-03-10 20:39:36.510+0000: starting up libvirt version: 4.0.0, +> package: 1ubuntu8.6 (Christian Ehrhardt <email address hidden> +> Fri, 09 Nov 2018 07:42:01 +0100), qemu version: 2.11.1(Debian +> 1:2.11+dfsg-1ubuntu7.9), hostname: pre-node1 +> LC_ALL=C +> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin +> QEMU_AUDIO_DRV=spice /usr/bin/kvm-spice -name +> guest=instance-00000038,debug-threads=on -S -object +> secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-5-instance-00000038/master-key.aes +> -machine +> pc-i440fx-bionic,accel=kvm,usb=off,dump-guest-core=off,mem-merge=off -cpu +> Skylake-Server-IBRS,ss=on,hypervisor=on,tsc_adjust=on,clflushopt=on,pku=on,ssbd=on,xsaves=on +> -m 2048 -realtime mlock=on -smp 2,sockets=1,cores=1,threads=2 -object +> memory-backend-file,id=ram-node0,prealloc=yes,mem-path=/dev/hugepages/libvirt/qemu/5-instance-00000038,share=yes,size=2147483648,host-nodes=0,policy=bind +> -numa node,nodeid=0,cpus=0-1,memdev=ram-node0 -uuid +> 3c3d04f3-4b25-4ea5-8836-0e06eef9dcb7 -smbios 'type=1,manufacturer=OpenStack +> Foundation,product=OpenStack +> Nova,version=18.1.1,serial=93fa1a55-ba3a-4a99-80b3-3a7bb4e964af,uuid=3c3d04f3-4b25-4ea5-8836-0e06eef9dcb7,family=Virtual +> Machine' -no-user-config -nodefaults -chardev +> socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-5-instance-00000038/monitor.sock,server,nowait +> -mon chardev=charmonitor,id=monitor,mode=control -rtc +> base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet +> -no-shutdown -boot strict=on -device +> piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device +> virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 -drive +> file=/var/lib/nova/instances/3c3d04f3-4b25-4ea5-8836-0e06eef9dcb7/disk,format=qcow2,if=none,id=drive-virtio-disk0,cache=none,discard=ignore,throttling.iops-read=5000,throttling.iops-write=5000 +> -device +> virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 +> -add-fd set=0,fd=29 -chardev +> pty,id=charserial0,logfile=/dev/fdset/0,logappend=on -device +> isa-serial,chardev=charserial0,id=serial0 -chardev +> spicevmc,id=charchannel0,name=vdagent -device +> virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 +> -spice port=5900,addr=10.252.0.101,disable-ticketing,seamless-migration=on +> -device +> qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 +> -device vfio-pci,host=25:04.1,id=hostdev0,bus=pci.0,addr=0x5 -device +> virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -msg timestamp=on +> 2019-03-10T20:39:36.568276Z qemu-system-x86_64: -chardev +> pty,id=charserial0,logfile=/dev/fdset/0,logappend=on: char device +> redirected to /dev/pts/2 (label charserial0) +> inputs_channel_detach_tablet: +> main_channel_link: add main channel client +> main_channel_client_handle_pong: net test: latency 32.760000 ms, bitrate +> 33384953 bps (31.838372 Mbps) +> red_qxl_set_cursor_peer: +> inputs_connect: inputs channel client create +> +> (process:65324): Spice-WARNING **: 16:35:23.769: Failed to create +> channel client: Client 0x55e7c157e970: duplicate channel type 2 id 0 +> red_qxl_set_cursor_peer: +> +> (process:65324): Spice-WARNING **: 16:35:24.142: Failed to create +> channel client: Client 0x55e7c157e970: duplicate channel type 4 id 0 +> +> (process:65324): Spice-CRITICAL **: 16:35:24.142: +> cursor-channel.c:353:cursor_channel_connect: condition `ccc != NULL' failed +> 2019-03-13 15:35:31.785+0000: shutting down, reason=crashed +> +> +> +> I am also attaching some gdb information extracted from qemu crash dump +> file. These are backtraces of particular threads within the crashed QEMU +> process. +> +> +> Thread 9 (Thread 0x7f69649ea5c0 (LWP 65324)): +> #0 0x00007f695f02d2b7 in __libc_write (fd=26, buf=0x7ffc33f5b330, +> nbytes=56) at ../sysdeps/unix/sysv/linux/write.c:27 +> #1 0x00007f695ff30ed3 in () at +> /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +> #2 0x00007f695ff316ce in () at +> /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +> #3 0x00007f695ff52db6 in () at +> /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +> #4 0x00007f695ff58e38 in () at +> /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +> #5 0x00007f695ff5f463 in () at +> /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +> #6 0x00007f695ff5f7bb in () at +> /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +> #7 0x000055e7bec94584 in () +> #8 0x000055e7bec94e58 in aio_dispatch () +> #9 0x000055e7bec91e3e in () +> #10 0x00007f695fa45387 in g_main_context_dispatch () at +> /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +> #11 0x000055e7bec940a7 in main_loop_wait () +> #12 0x000055e7be8b8486 in main () +> +> Thread 8 (Thread 0x7f68b78fc700 (LWP 61873)): +> #0 0x00007f695f02c8c2 in futex_abstimed_wait_cancelable (private=0, +> abstime=0x7f68b78fb900, expected=0, futex_word=0x55e7c1531d78) +> at ../sysdeps/unix/sysv/linux/futex-internal.h:205 +> #1 0x00007f695f02c8c2 in do_futex_wait (sem=sem@entry=0x55e7c1531d78, +> abstime=abstime@entry=0x7f68b78fb900) at sem_waitcommon.c:111 +> #2 0x00007f695f02c9d3 in __new_sem_wait_slow (sem=0x55e7c1531d78, +> abstime=0x7f68b78fb900) at sem_waitcommon.c:181 +> #3 0x000055e7bec976cf in qemu_sem_timedwait () +> #4 0x000055e7bec928bc in () +> #5 0x00007f695f0236db in start_thread (arg=0x7f68b78fc700) at +> pthread_create.c:463 +> #6 0x00007f695ed4c88f in clone () at +> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 +> +> Thread 7 (Thread 0x7f688f7fe700 (LWP 61366)): +> #0 0x00007f695f02c8c2 in futex_abstimed_wait_cancelable (private=0, +> abstime=0x7f688f7fd900, expected=0, futex_word=0x55e7c1531d78) +> at ../sysdeps/unix/sysv/linux/futex-internal.h:205 +> #1 0x00007f695f02c8c2 in do_futex_wait (sem=sem@entry=0x55e7c1531d78, +> abstime=abstime@entry=0x7f688f7fd900) at sem_waitcommon.c:111 +> #2 0x00007f695f02c9d3 in __new_sem_wait_slow (sem=0x55e7c1531d78, +> abstime=0x7f688f7fd900) at sem_waitcommon.c:181 +> #3 0x000055e7bec976cf in qemu_sem_timedwait () +> #4 0x000055e7bec928bc in () +> #5 0x00007f695f0236db in start_thread (arg=0x7f688f7fe700) at +> pthread_create.c:463 +> #6 0x00007f695ed4c88f in clone () at +> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 +> +> Thread 6 (Thread 0x7f687effd700 (LWP 61362)): +> #0 0x00007f695f02c8c2 in futex_abstimed_wait_cancelable (private=0, +> abstime=0x7f687effc900, expected=0, futex_word=0x55e7c1531d78) +> at ../sysdeps/unix/sysv/linux/futex-internal.h:205 +> #1 0x00007f695f02c8c2 in do_futex_wait (sem=sem@entry=0x55e7c1531d78, +> abstime=abstime@entry=0x7f687effc900) at sem_waitcommon.c:111 +> #2 0x00007f695f02c9d3 in __new_sem_wait_slow (sem=0x55e7c1531d78, +> abstime=0x7f687effc900) at sem_waitcommon.c:181 +> #3 0x000055e7bec976cf in qemu_sem_timedwait () +> #4 0x000055e7bec928bc in () +> #5 0x00007f695f0236db in start_thread (arg=0x7f687effd700) at +> pthread_create.c:463 +> #6 0x00007f695ed4c88f in clone () at +> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 +> +> Thread 5 (Thread 0x7f68b58f1700 (LWP 60991)): +> #0 0x00007f695f02c8c2 in futex_abstimed_wait_cancelable (private=0, +> abstime=0x7f68b58f0900, expected=0, futex_word=0x55e7c1531d78) +> at ../sysdeps/unix/sysv/linux/futex-internal.h:205 +> #1 0x00007f695f02c8c2 in do_futex_wait (sem=sem@entry=0x55e7c1531d78, +> abstime=abstime@entry=0x7f68b58f0900) at sem_waitcommon.c:111 +> #2 0x00007f695f02c9d3 in __new_sem_wait_slow (sem=0x55e7c1531d78, +> abstime=0x7f68b58f0900) at sem_waitcommon.c:181 +> #3 0x000055e7bec976cf in qemu_sem_timedwait () +> #4 0x000055e7bec928bc in () +> #5 0x00007f695f0236db in start_thread (arg=0x7f68b58f1700) at +> pthread_create.c:463 +> #6 0x00007f695ed4c88f in clone () at +> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 +> +> Thread 4 (Thread 0x7f69564a2700 (LWP 65331)): +> #0 0x00007f695ed46839 in syscall () at +> ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 +> #1 0x000055e7bec9790b in qemu_event_wait () +> #2 0x000055e7beca7ebe in () +> #3 0x00007f695f0236db in start_thread (arg=0x7f69564a2700) at +> pthread_create.c:463 +> #4 0x00007f695ed4c88f in clone () at +> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 +> +> Thread 3 (Thread 0x7f695449d700 (LWP 65363)): +> #0 0x00007f695ed415d7 in ioctl () at +> ../sysdeps/unix/syscall-template.S:78 +> #1 0x000055e7be910547 in kvm_vcpu_ioctl () +> #2 0x000055e7be910684 in kvm_cpu_exec () +> #3 0x000055e7be8ed3f4 in () +> #4 0x00007f695f0236db in start_thread (arg=0x7f695449d700) at +> pthread_create.c:463 +> #5 0x00007f695ed4c88f in clone () at +> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 +> +> Thread 2 (Thread 0x7f6952b4f700 (LWP 65366)): +> #0 0x00007f695ed415d7 in ioctl () at +> ../sysdeps/unix/syscall-template.S:78 +> #1 0x000055e7be910547 in kvm_vcpu_ioctl () +> ---Type <return> to continue, or q <return> to quit--- +> #2 0x000055e7be910684 in kvm_cpu_exec () +> #3 0x000055e7be8ed3f4 in () +> #4 0x00007f695f0236db in start_thread (arg=0x7f6952b4f700) at +> pthread_create.c:463 +> #5 0x00007f695ed4c88f in clone () at +> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 +> +> Thread 1 (Thread 0x7f6951a40700 (LWP 65368)): +> #0 0x00007f695ec69e97 in __GI_raise (sig=sig@entry=6) at +> ../sysdeps/unix/sysv/linux/raise.c:51 +> #1 0x00007f695ec6b801 in __GI_abort () at abort.c:79 +> #2 0x00007f695ff81cc9 in () at +> /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +> #3 0x00007f695ff63929 in () at +> /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +> #4 0x00007f695ff314f1 in () at +> /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +> #5 0x00007f695ff37d7b in () at +> /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +> #6 0x00007f695fa451f5 in g_main_context_dispatch () at +> /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +> #7 0x00007f695fa455c0 in () at +> /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +> #8 0x00007f695fa458d2 in g_main_loop_run () at +> /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +> #9 0x00007f695ff63b3a in () at +> /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +> #10 0x00007f695f0236db in start_thread (arg=0x7f6951a40700) at +> pthread_create.c:463 +> #11 0x00007f695ed4c88f in clone () at +> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 +> +> Regards, +> Premysl +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1820247/+subscriptions +> + + +Hi, +the warnings around "duplicate channel type 2 id 0" where present in the other bug as well. +And since that often means it passes the same area of code I wanted to suggest to provide the same debug data. + +The actual crash is a different one for sure as the stack traces look different and also the old one is fixed quite some time. + +The QEMU project is currently considering to move 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 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/105/mistranslation/1823152 b/results/classifier/105/mistranslation/1823152 new file mode 100644 index 000000000..874f8f711 --- /dev/null +++ b/results/classifier/105/mistranslation/1823152 @@ -0,0 +1,89 @@ +mistranslation: 0.701 +instruction: 0.665 +other: 0.657 +network: 0.652 +graphic: 0.643 +device: 0.642 +boot: 0.639 +semantic: 0.605 +assembly: 0.592 +vnc: 0.580 +socket: 0.564 +KVM: 0.495 + +QEMU not able to boot ubuntu 18.04 as a guest + +Host information: +sushant@sushant-OptiPlex-7050:~$ lsb_release -a +No LSB modules are available. +Distributor ID: Ubuntu +Description: Ubuntu 18.04.2 LTS +Release: 18.04 +Codename: bionic + + +QEMU version: +sushant@sushant-OptiPlex-7050:~$ /usr/bin/qemu-system-x86_64 --version +QEMU emulator version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.12) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + + + +I am trying to install xubuntu 18.04 as a qemu guest. The installation process goes smoothly and I reboot. After reboot, the boot process hangs with black screen and a blinking pointer. I used the following steps to install and boot the machine: +sudo qemu-img create /var/lib/libvirt/images/xubuntu18_04.qcow2 30G + +sudo qemu-system-x86_64-spice -enable-kvm -cpu host -boot d -cdrom /home/sushant/Downloads/xubuntu-18.04.2-desktop-amd64.iso /var/lib/libvirt/images/xubuntu18_04.qcow2 -m 8G + +sudo qemu-system-x86_64-spice -enable-kvm -cpu host /var/lib/libvirt/images/xubuntu18_04.qcow2 -m 8G + + + + + + +I tried with ubuntu 18.04(deafult ubuntu) and it also hangs with error "removed slice user slice of gdm" + + +Also, if I install ubuntu 16.04 as guest, it boots smoothly. + +What should be done? + +Switched bug to the ubuntu qemu package, since qemu-system-x86_64-spice is not an upstream provided binary + +$ ll /usr/bin/qemu-system-x86_64-spice +lrwxrwxrwx 1 root root 18 Mär 25 13:32 /usr/bin/qemu-system-x86_64-spice -> qemu-system-x86_64* + +This is just a compat symlink for a very old history. +It should not be used directly anymore, but then also not matter. + +I have not seen the same with Ubuntu Desktops, so I wonder what is different in your setup. + +@Sushant - have you tried the same with e.g. libvirt (maybe through virt-manager), does it behave the same on that backend? +Furthermore this might be when the UI kicks in, could you set up (on install) an ssh client and login to log in when it is black and check what is going on at the time? + +maybe this is just this issue? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1795857 + +I am able to start the VM using 'virt-manager' but not using 'qemu-system-x86_64-spice'. I am using the command line so that I want pass 2 additional options viz. +1. -machine epc +2. -machine epc-below-4g +both for SGX virtualization. + +I dont know how to ssh to the VM since I dont know the IP address of the guest machine. + +I want to use 'qemu-system-x86_64-spice' so that I can use both the additional options. + +Quite likely @flumm +-vga cirrus => works +-vga qxl => works +-vga std (the default) stays black. + +For now @sushant add "-vga qxl" to your commandline please. + +Also adding + -net user,hostfwd=tcp::10022-:22 -net nic +And install+configuring openssh-server in the guest allows to take a look at the faild system + +In fact it shows issues with the GPU as expected. +This is not a qemu but a kernel bug and I'll dup it. + + diff --git a/results/classifier/105/mistranslation/1824704 b/results/classifier/105/mistranslation/1824704 new file mode 100644 index 000000000..d01790517 --- /dev/null +++ b/results/classifier/105/mistranslation/1824704 @@ -0,0 +1,100 @@ +mistranslation: 0.888 +semantic: 0.803 +instruction: 0.720 +other: 0.686 +device: 0.639 +graphic: 0.557 +socket: 0.372 +assembly: 0.364 +network: 0.345 +vnc: 0.291 +boot: 0.209 +KVM: 0.144 + +-k tr not working after v20171217! turkish keyboard dont working + +hi qemu + +-k tr not working after v20171217! turkish keyboard dont working + +last working without proplem at v20171217! + + +after this version tr keyboard prople. +freedos , winpe , linux images all dont working tr turkish keyboard. + +example press key " ç " show " , " +example 2 press key " . " show " ç " + +tr keyboard work always "en-us" kbd. +:(((((((( + + + +please fix this critical bug. + +Sincerely + +Can you find out which commit broke the keyboard for you? (By using "git bisect" for example) + +24 Eylül 2019 Salı tarihinde Thomas Huth <email address hidden> yazdı: + +> Can you find out which commit broke the keyboard for you? (By using "git +> bisect" for example) +> +> ** Information type changed from Private Security to Public +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1824704 +> +> Title: +> -k tr not working after v20171217! turkish keyboard dont working +> +> Status in QEMU: +> New +> +> Bug description: +> hi qemu +> +> -k tr not working after v20171217! turkish keyboard dont working +> +> last working without proplem at v20171217! +> +> after this version tr keyboard proplem. +> freedos , winpe , linux images all dont working tr turkish +> keyboard. +> +> example press key " ç " show " , " +> example 2 press key " . " show " ç " +> +> tr keyboard work always "en-us" kbd. +> :(((((((( +> +> please fix this critical bug. +> +> Sincerely +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1824704/+subscriptions +> + + +Not working turkish q keyboard + +Ç pres result, +. Press. Result ç + + +I meant which version of QEMU is still working for you? Which version fails? + +What does "localectl" print (both host and guest please)? + + after v20171217 all versions. + + +What does v20171217 refer to? A pre-built binary? Windows? Linux? Mac OS? ... sorry, but you have to be a little bit more specific. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1824768 b/results/classifier/105/mistranslation/1824768 new file mode 100644 index 000000000..961c94f21 --- /dev/null +++ b/results/classifier/105/mistranslation/1824768 @@ -0,0 +1,117 @@ +mistranslation: 0.776 +other: 0.454 +semantic: 0.388 +device: 0.369 +KVM: 0.350 +boot: 0.346 +network: 0.317 +instruction: 0.310 +graphic: 0.276 +vnc: 0.265 +assembly: 0.239 +socket: 0.174 + +Qemu ARMv7 TCG MultiThreading for i386 guest doesn't work + +Using any Linux image (in this case Alpine Linux iso) and want to use all cores of my Raspberry with --accel,thread=multi. I know there is a probably still problem with memory ordering of the host but I have also seen some very old commits which could potentially help with it. + +But anyway, with version qemu-i386 version 3.1.0 (Debian 1:3.1+dfsg-7) +I can see OpenRC starting up services and then the kernel crash. + +With version QEMU emulator version 3.1.93 (v4.0.0-rc3-dirty) +The whole machine crash with this error: +Illegal instruction + + +Using command: +./qemu-system-i386 -cdrom alpine.iso --accel tcg,thread=multi + +Full Console Output: +qemu-system-i386: warning: Guest expects a stronger memory ordering than the host provides +This may cause strange/hard to debug errors +Illegal instruction + + +Kernel: +Linux raspberrypi 4.14.98-v7+ #1200 SMP Tue Feb 12 20:27:48 GMT 2019 armv7l GNU/Linux + +CPU: +ARMv7 Processor rev 5 (v7l) +Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm +4 cores + +This is expected. The warning from QEMU is telling you that MTTCG is not supported for the combination of an Arm host and an x86 guest. It warns that you might see "strange errors", and indeed you saw an error. Don't try to use MTTCG here. + +I think this warning should probably just be an error -- QEMU shouldn't allow the user to select a feature which we know is not going to work reliably. + + +Thank you for the explanation. I found some patches a few years old, so I thought the implementation is now complete especially when ARM is getting more and more popular. + +Does it have some priority assigned? Or does it even make sense to do it? From my perspective, yes even with the broken support the whole boot process was blazingly fast on Raspberry and seemed that kernel was able to start and then crashed. Even this was so fast compared to one core. It's interesting there are no more people wanting this. Maybe I am missing another trend :) + +Implementing a stronger guest memory model than the host has is tricky -- we would need to emit barrier instructions after each guest load or store, which would slow down straight-line execution speed by quite a lot, perhaps by so much that it would outweigh the gain from being able to run more than one thread at once. (Perhaps some of the armv8 load-acquire/store-release insns would help, but they're no good to you on a v7 CPU.) + +There aren't many people overall who want to try to run emulation on anything other than x86 host. + + +Yes, I can imagine that. + +Unfortunately, my programming knowledge isn't so strong to help you with it. But can help with testing if it is useful. + +Alex Bennée pointed me to this patch: +[RFC,v3,4/5] mttcg: Implement implicit ordering semantics + +Which maybe could help. I can try to compile it and do the requested tests. + +That patch is already in QEMU (commit b32dc3370a666e23). It sounds like we're a bit further forward with this than I thought we might be, but clearly not everything necessary is implemented. + + + +Interesting, maybe that is the reason why it is not restricted to use mttcg from the command line. + +So I will be waiting here if you need :) + + + +When you say + +> ./qemu-system-i386 -cdrom alpine.iso --accel tcg,thread=multi + +you have not created multiple cpus for the guest, so thread=multi +should have no effect. + +For what it's worth, a boot of debian-9.8.0-i386-netinst.iso +(which is what I happened to have handy) works fine with + + ./qemu-system-i386 -cdrom ... -m 1G --accel tcg,thread=multi + +on an x-gene system, compiled for aarch32. + +You should note that the default memory allocation is only 128MB, +and I'd be surprised if you can boot the alpine installation in +that little memory. Certainly it does not work with debian. +On the other hand, the failure is a simple guest kernel panic +and not any kind of Illegal Instruction. + +I'll try again in a moment with a cortex-a15 system, but I'm +not expecting any different result. + +Just so we're clear, which raspberry pi revision are you using? +Based on comments I'm assuming pi 2, with the 4 core cortex-a7. + +>> ./qemu-system-i386 -cdrom alpine.iso --accel tcg,thread=multi + +I tried both, with -smp 4 and without.. + +In stable Qemu release, there is just a guest kernel panic, in v4.0.0-rc3-dirty, there is also Illegal instruction error reported + +> on an x-gene system, compiled for aarch32. +Yes, this should be Raspberry Pi 3, but I am not sure. Anyway, I can test this in one week when I receive one of those boards. + +>Just so we're clear, which raspberry pi revision are you using? +>Based on comments I'm assuming pi 2, with the 4 core cortex-a7. + +I am using Raspberry Pi 2, 4 cores, not sure where is the difference between cortex-a7 and ARMv7, in my case it is just ARMv7. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1825207 b/results/classifier/105/mistranslation/1825207 new file mode 100644 index 000000000..431fdc27c --- /dev/null +++ b/results/classifier/105/mistranslation/1825207 @@ -0,0 +1,75 @@ +mistranslation: 0.504 +other: 0.482 +boot: 0.481 +instruction: 0.480 +device: 0.475 +network: 0.407 +vnc: 0.396 +graphic: 0.390 +assembly: 0.388 +semantic: 0.380 +KVM: 0.367 +socket: 0.326 + +fw_cfg_machine_reset destroys user bootorder setting + +Demonstrated against 2.11 (ubuntu bionic 1:2.11+dfsg-1ubuntu7.12) and 3.1 (as built under bionic from the 1:3.1+dfsg-2ubuntu3 source package) although the code hasn't changed between them and github master also appears to have this same code branch. + +What I was trying to do: select a boot disk using `-fw_cfg name=bootorder,string=/pci@i0cf8/*@6` based on the qemu and seabios documentation. (Why do I want to do that? using qemu for installer testing for a specific kind of real machine and need to match the bios boot order.) + +What happened instead: same search-based boot order that I get without that option. Also, /sys/firmware/qemu_fw_cfg/by_name/bootorder/raw is empty and .../size is "0". + +Brutal work around that did a useful thing: + +--- qemu-3.1+dfsg.orig/hw/nvram/fw_cfg.c ++++ qemu-3.1+dfsg/hw/nvram/fw_cfg.c +@@ -869,8 +869,10 @@ static void fw_cfg_machine_reset(void *o + FWCfgState *s = opaque; + char *bootindex = get_boot_devices_list(&len); + ++#if 0 + ptr = fw_cfg_modify_file(s, "bootorder", (uint8_t *)bootindex, len); + g_free(ptr); ++#endif + } + +This change allowed the boot to work (so my bootorder setting was making it to seabios) and also showed up explicitly in /sys/firmware/qemu_fw_cfg. + +I don't know if fw_cfg_modify_file is intended to append rather than replace, but it doesn't; based on the seabios "Runtime_config" docs which suggest "look at the Searching bootorder for output and paste that into the bootorder file" I'd instead just have it only fill in bootorder if there's *no* existing setting, since a user can read out the defaults and copy them in as described if they want the fallback, but that's just from my interpretation of the docs. + +This bug report is invalid, for a less important reason and for a more important reason. + +(1) The less important reason is that "/pci@i0cf8/*@6" is a string that would never be generated by QEMU, as a bootorder entry. QEMU places specific OpenFirmware device paths into the "bootorder" fw_cfg file. Only SeaBIOS uses patterns like "*@6", for matching. + +The suggestion in the SeaBIOS wiki at <https://www.seabios.org/Runtime_config>, namely: + +"However, it's safe to just copy and paste the pattern into bootorder." + +is wrong, generally speaking. It might work if we consider SeaBIOS exclusively -- in that SeaBIOS would manage to parse those entries --, but they are invalid if we consider QEMU (not to mention OVMF). + +(2) But, point (1) doesn't even matter much. The more important reason why this report is invalid is that the "bootorder" fw_cfg file is under the sole ownership of QEMU. "docs/specs/fw_cfg.txt" explains, in section "Externally Provided Items": + +""" +Use of names not beginning with "opt/" is potentially dangerous and +entirely unsupported. QEMU will warn if you try. +""" + +And that matches reality, on my end: + +$ qemu-system-x86_64 -fw_cfg name=bootorder,string='/pci@i0cf8/*@6' +qemu-system-x86_64: -fw_cfg name=bootorder,string=/pci@i0cf8/*@6: warning: externally provided fw_cfg item names should be prefixed with "opt/" + + +The right way for controlling boot order is to use "bootindex=N" properties with the storage front-end devices. For exampe: + +... +-device virtio-blk-pci,drive=system-disk,bootindex=1 \ +-device scsi-cd,drive=installer-iso,bus=scsi0.0,bootindex=2 \ +... + +Hah! Thanks, I don't know how I missed the existence of bootindex (given that it looks like it went in in 2011 and is in the docs once I know the name to search for.) I was probably conflating it with the index= option. + +I did see the warning, and my reaction was "that must apply to other uses than actually passing things to seabios, since that'll just stop it from looking at them, and isn't that the entire point of the option?" Apparently not, but the warning didn't particular suggest otherwise. + +Thank you very much for taking the time to respond in detail (bootindex entirely solves my problem.) + diff --git a/results/classifier/105/mistranslation/1828723 b/results/classifier/105/mistranslation/1828723 new file mode 100644 index 000000000..08b205cf8 --- /dev/null +++ b/results/classifier/105/mistranslation/1828723 @@ -0,0 +1,45 @@ +mistranslation: 0.589 +other: 0.499 +graphic: 0.384 +semantic: 0.340 +device: 0.266 +socket: 0.193 +network: 0.165 +instruction: 0.122 +vnc: 0.109 +boot: 0.104 +KVM: 0.056 +assembly: 0.031 + +[RFE] option to suppress gemu_log() output + +With user mode emulation, messages from genu_log() are emitted unconditionally to stderr. I didn't find a way to suppress them. It would be nice to have options similar to the -D/-d options to be able to filter and/or redirect the output. + +My use case is chroot/container execution for different architectures via binfmt. In this case it will appear as if the binary in question had emitted messages like "Unsupported setsockopt ..." to stderr while in fact the message came from qemu-*-static. + +This series might be helpful: +https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg02067.html + +The -d/-D options should work in linux-user as well. You can also set QEMU_LOG_FILENAME and QEMU_LOG environment variables. Do these not work for you? + + +Although arguably the line: + + gemu_log("Unsupported setsockopt level=%d optname=%d\n", level, optname); + +Could be + + qemu_log_mask(LOG_UNIMP,....) + +Not sure where gemu_log is used, it seems to be strace related. + +Indeed I think gemu_log() is the problem here. + + +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/171 + + diff --git a/results/classifier/105/mistranslation/1829696 b/results/classifier/105/mistranslation/1829696 new file mode 100644 index 000000000..f50832fb3 --- /dev/null +++ b/results/classifier/105/mistranslation/1829696 @@ -0,0 +1,403 @@ +mistranslation: 0.848 +KVM: 0.826 +vnc: 0.810 +graphic: 0.783 +other: 0.778 +device: 0.773 +assembly: 0.764 +instruction: 0.741 +boot: 0.706 +semantic: 0.704 +socket: 0.702 +network: 0.688 + +qemu-kvm takes 100% CPU when running redhat/centos 7.6 guest VM OS + +Description +=========== +When running redhat or centos 7.6 guest os on vm, +the cpu usage is very low on vm(100% idle), but on host, +qemu-kvm reports 100% cpu busy usage. + +After searching some related bugs report, +I suspect that it is due to the clock settings in vm's domain xml. +My Openstack cluster uses the default clock settings as follow: + <clock offset='utc'> + <timer name='rtc' tickpolicy='catchup'/> + <timer name='pit' tickpolicy='delay'/> + <timer name='hpet' present='no'/> + </clock> +And in this report, https://bugs.launchpad.net/qemu/+bug/1174654 +it claims that <timer name='rtc' track='guest'/> can solve the 100% cpu usage problem when using Windows Image Guest OS, +but I makes some tests, the solusion dose not work for me. + + +Steps to reproduce +================== +* create a vm using centos or redhat 7.6 image +* using sar tool inside vm and host to check the cpu usage, and compare them + + +Expected result +=============== +host's cpu usage report should be same with vm's cpu usage + + +Actual result +============= +vm's cpu usage is 100% idle, host's cpu usage is 100% busy + + +Environment +=========== +1. Exact version of OpenStack you are running. +# rpm -qa | grep nova +openstack-nova-compute-13.1.2-1.el7.noarch +python2-novaclient-3.3.2-1.el7.noarch +python-nova-13.1.2-1.el7.noarch +openstack-nova-common-13.1.2-1.el7.noarch + +2. Which hypervisor did you use? + (For example: Libvirt + KVM, Libvirt + XEN, Hyper-V, PowerKVM, ...) + What's the version of that? +# libvirtd -V +libvirtd (libvirt) 3.9.0 + +# /usr/libexec/qemu-kvm --version +QEMU emulator version 2.6.0 (qemu-kvm-ev-2.6.0-28.el7_3.6.1), Copyright (c) 2003-2008 Fabrice Bellard + + +Logs & Configs +============== +The VM xml: +<domain type='kvm' id='29'> + <name>instance-00005022</name> + <uuid>7f5a66a5-****-****-****-75dec****bbb</uuid> + <metadata> + <nova:instance xmlns:nova="http://openstack.org/xmlns/libvirt/nova/1.0"> + <nova:package version="13.1.2-1.el7"/> + <nova:name>*******</nova:name> + <nova:creationTime>2019-05-20 03:08:46</nova:creationTime> + <nova:flavor name="2d2dab36-****-****-****-246e9****110"> + <nova:memory>2048</nova:memory> + <nova:disk>12</nova:disk> + <nova:swap>2048</nova:swap> + <nova:ephemeral>0</nova:ephemeral> + <nova:vcpus>1</nova:vcpus> + </nova:flavor> + <nova:owner> + <nova:user uuid="********************">****</nova:user> + <nova:project uuid="********************">****</nova:project> + </nova:owner> + <nova:root type="image" uuid="4496a420-****-****-****-b50f****ada3"/> + </nova:instance> + </metadata> + <memory unit='KiB'>2097152</memory> + <currentMemory unit='KiB'>2097152</currentMemory> + <vcpu placement='static'>1</vcpu> + <cputune> + <shares>1024</shares> + <vcpupin vcpu='0' cpuset='27'/> + <emulatorpin cpuset='27'/> + </cputune> + <numatune> + <memory mode='strict' nodeset='1'/> + <memnode cellid='0' mode='strict' nodeset='1'/> + </numatune> + <resource> + <partition>/machine</partition> + </resource> + <sysinfo type='smbios'> + <system> + <entry name='manufacturer'>Fedora Project</entry> + <entry name='product'>OpenStack Nova</entry> + <entry name='version'>13.1.2-1.el7</entry> + <entry name='serial'>64ab0e89-****-****-****-05312ef66983</entry> + <entry name='uuid'>7f5a66a5-****-****-****-75decaf82bbb</entry> + <entry name='family'>Virtual Machine</entry> + </system> + </sysinfo> + <os> + <type arch='x86_64' machine='pc-i440fx-rhel7.3.0'>hvm</type> + <boot dev='hd'/> + <smbios mode='sysinfo'/> + </os> + <features> + <acpi/> + <apic/> + </features> + <cpu mode='custom' match='exact' check='full'> + <model fallback='forbid'>IvyBridge</model> + <topology sockets='1' cores='1' threads='1'/> + <feature policy='require' name='hypervisor'/> + <feature policy='require' name='arat'/> + <feature policy='require' name='xsaveopt'/> + <numa> + <cell id='0' cpus='0' memory='2097152' unit='KiB'/> + </numa> + </cpu> + <clock offset='utc'> + <timer name='pit' tickpolicy='delay'/> + <timer name='rtc' tickpolicy='catchup'/> + <timer name='hpet' present='no'/> + </clock> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/libexec/qemu-kvm</emulator> + <disk type='file' device='disk'> + <driver name='qemu' type='raw' cache='none'/> + <source file='/data/instances/7f5a66a5-****-****-****-75decaf82bbb/disk'/> + <backingStore/> + <target dev='vda' bus='virtio'/> + <alias name='virtio-disk0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='raw' cache='none'/> + <source file='/data/instances/7f5a66a5-****-****-****-75decaf82bbb/disk.swap'/> + <backingStore/> + <target dev='vdb' bus='virtio'/> + <alias name='virtio-disk1'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> + </disk> + <disk type='file' device='cdrom'> + <driver name='qemu' type='raw' cache='none'/> + <source file='/data/instances/7f5a66a5-****-****-****-75decaf82bbb/disk.config'/> + <backingStore/> + <target dev='hdd' bus='ide'/> + <readonly/> + <alias name='ide0-1-1'/> + <address type='drive' controller='0' bus='1' target='0' unit='1'/> + </disk> + <controller type='usb' index='0' model='piix3-uhci'> + <alias name='usb'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> + </controller> + <controller type='pci' index='0' model='pci-root'> + <alias name='pci.0'/> + </controller> + <controller type='ide' index='0'> + <alias name='ide'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> + </controller> + <interface type='bridge'> + <mac address='fa:16:3e:a6:ea:4f'/> + <source bridge='brq52c66dc3-64'/> + <bandwidth> + <inbound average='102400'/> + <outbound average='102400'/> + </bandwidth> + <target dev='tapa29e94e5-42'/> + <model type='virtio'/> + <alias name='net0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + <serial type='file'> + <source path='/data/instances/7f5a66a5-****-****-****-75decaf82bbb/console.log'/> + <target type='isa-serial' port='0'> + <model name='isa-serial'/> + </target> + <alias name='serial0'/> + </serial> + <serial type='pty'> + <source path='/dev/pts/10'/> + <target type='isa-serial' port='1'> + <model name='isa-serial'/> + </target> + <alias name='serial1'/> + </serial> + <console type='file'> + <source path='/data/instances/7f5a66a5-****-****-****-75decaf82bbb/console.log'/> + <target type='serial' port='0'/> + <alias name='serial0'/> + </console> + <input type='tablet' bus='usb'> + <alias name='input0'/> + <address type='usb' bus='0' port='1'/> + </input> + <input type='mouse' bus='ps2'> + <alias name='input1'/> + </input> + <input type='keyboard' bus='ps2'> + <alias name='input2'/> + </input> + <graphics type='vnc' port='5910' autoport='yes' listen='0.0.0.0' keymap='en-us'> + <listen type='address' address='0.0.0.0'/> + </graphics> + <video> + <model type='cirrus' vram='16384' heads='1' primary='yes'/> + <alias name='video0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </video> + <memballoon model='virtio'> + <stats period='10'/> + <alias name='balloon0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> + </memballoon> + </devices> + <seclabel type='dynamic' model='dac' relabel='yes'> + <label>+107:+107</label> + <imagelabel>+107:+107</imagelabel> + </seclabel> +</domain> + +CPU Usage Report inside VM: +# sar -u -P 0 1 5 +Linux 3.10.0-957.el7.x86_64 (******) 05/20/2019 _x86_64_ (1 CPU) + +11:34:40 AM CPU %user %nice %system %iowait %steal %idle +11:34:41 AM 0 0.00 0.00 0.00 0.00 0.00 100.00 +11:34:42 AM 0 0.00 0.00 0.00 0.00 0.00 100.00 +11:34:43 AM 0 0.00 0.00 0.00 0.00 0.00 100.00 +11:34:44 AM 0 0.00 0.00 0.00 0.00 0.00 100.00 +11:34:45 AM 0 0.00 0.00 0.00 0.00 0.00 100.00 +Average: 0 0.00 0.00 0.00 0.00 0.00 100.00 + +CPU Usage Report ON HOST(the vm's cpu is pinned on host's no.27 physic cpu): +# sar -u -P 27 1 5 +Linux 3.10.0-862.el7.x86_64 (******) 05/20/2019 _x86_64_ (48 CPU) + +11:34:40 AM CPU %user %nice %system %iowait %steal %idle +11:34:41 AM 27 100.00 0.00 0.00 0.00 0.00 0.00 +11:34:42 AM 27 100.00 0.00 0.00 0.00 0.00 0.00 +11:34:43 AM 27 100.00 0.00 0.00 0.00 0.00 0.00 +11:34:44 AM 27 100.00 0.00 0.00 0.00 0.00 0.00 +11:34:45 AM 27 100.00 0.00 0.00 0.00 0.00 0.00 +Average: 27 100.00 0.00 0.00 0.00 0.00 0.00 + +clocksource inside VM: +# cat /sys/devices/system/clocksource/clocksource0/current_clocksource +kvm_clock + +It shows that only the version 7.6 of redhat or centos affected by this bug, +in my cluster, it is OK for versions from 6.8 to 7.5, but 7.6 is not normal. + +> # libvirtd -V +> libvirtd (libvirt) 3.9.0 +> +> # /usr/libexec/qemu-kvm --version +> QEMU emulator version 2.6.0 (qemu-kvm-ev-2.6.0-28.el7_3.6.1), Copyright (c) 2003-2008 Fabrice Bellard + +This looks like the host is running CentOS, with packages dating from approx 7.3. This is very outdated given current version is 7.6. So I don't think it is worth spending time to debug until the host OS is upgraded to the latest QEMU/libvirt/kernel packages at least to see if the problem still reproduces. + + +I tested two newest QEMU versions these days, and sadly, the problem still happens. + +I tried to find the reason why the qemu process take 100% usage of cpu, and collected some facts about it. +I compared the facts with other normal vm's qemu process(who's cpu usage is normal) and didn't turn out any interesting result. + +Please give me some guides to debug this problem if you could, thanks very much. + + + +(The full content of facts is in the attachment) +1. +======the command line to start a VM====== +# ps -ef |grep 1567284 | cat +qemu 1567284 1 99 Jun21 ? 2-18:09:33 /usr/libexec/qemu-kvm -name guest=instance-0000530a,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-instance-0000530a/master-key.aes -machine pc-i440fx-4.0,accel=kvm,usb=off,dump-guest-core=off -cpu IvyBridge -m 2048 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -object memory-backend-ram,id=ram-node0,size=2147483648,host-nodes=1,policy=bind -numa node,nodeid=0,cpus=0,memdev=ram-node0 -uuid 60d3ad85-1004-47e7-b2cb-5cf1a029ab47 -smbios type=1,manufacturer=Fedora Project,product=OpenStack Nova,version=13.1.2-1.el7,serial=c0700413-4a28-4e97-85c4-66fe3ec367dc,uuid=60d3ad85-1004-47e7-b2cb-5cf1a029ab47,family=Virtual Machine -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-1-instance-0000530a/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/data/instances/60d3ad85-1004-47e7-b2cb-5cf1a029ab47/disk,format=raw,if=none,id=drive-virtio-disk0,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/data/instances/60d3ad85-1004-47e7-b2cb-5cf1a029ab47/disk.swap,format=raw,if=none,id=drive-virtio-disk1,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk1,id=virtio-disk1 -drive file=/data/instances/60d3ad85-1004-47e7-b2cb-5cf1a029ab47/disk.config,format=raw,if=none,id=drive-ide0-1-1,readonly=on,cache=none -device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1 -netdev tap,fd=27,id=hostnet0,vhost=on,vhostfd=29 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:21:2c:70,bus=pci.0,addr=0x3 -add-fd set=2,fd=31 -chardev file,id=charserial0,path=/dev/fdset/2,append=on -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -device usb-tablet,id=input0,bus=usb.0,port=1 -vnc 0.0.0.0:0 -k en-us -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -msg timestamp=on +root 1567288 2 0 Jun21 ? 00:00:01 [vhost-1567284] +root 1567291 2 0 Jun21 ? 00:00:00 [kvm-pit/1567284] + +2. +===version of QEMU=== +# /usr/libexec/qemu-kvm --version +QEMU emulator version 4.0.0 +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers + +===version of libvirt=== +# libvirtd -V +libvirtd (libvirt) 3.9.0 + +===version of kernal=== +# uname -a +Linux txyz_40_92 3.10.0-862.el7.x86_64 #1 SMP Wed Mar 21 18:14:51 EDT 2018 x86_64 x86_64 x86_64 GNU/Linux +Red Hat Enterprise Linux Server (3.10.0-862.el7.x86_64) 7.5 (Maipo) +# modinfo kvm +filename: /lib/modules/3.10.0-862.el7.x86_64/kernel/arch/x86/kvm/kvm.ko.xz +license: GPL +author: Qumranet +retpoline: Y +rhelversion: 7.5 +srcversion: 8A3372406CDF0ACF69A0E58 +depends: irqbypass +intree: Y +vermagic: 3.10.0-862.el7.x86_64 SMP mod_unload modversions +signer: Red Hat Enterprise Linux kernel signing key +sig_key: 51:73:02:3B:F8:16:37:D7:BF:3C:51:50:13:4E:EC:84:1B:96:FD:0B +sig_hashalgo: sha256 +parm: ignore_msrs:bool +parm: min_timer_period_us:uint +parm: kvmclock_periodic_sync:bool +parm: tsc_tolerance_ppm:uint +parm: lapic_timer_advance_ns:uint +parm: vector_hashing:bool +parm: halt_poll_ns:uint +parm: halt_poll_ns_grow:uint +parm: halt_poll_ns_shrink:uint + +3. +===threads=== +# ps -Lp 1567284 + PID LWP TTY TIME CMD +1567284 1567284 ? 00:00:12 qemu-kvm +1567284 1567286 ? 00:00:00 call_rcu +1567284 1567289 ? 00:00:00 IO mon_iothread +1567284 1567290 ? 2-19:07:09 CPU 0/KVM +1567284 1567293 ? 00:00:00 vnc_worker +1567284 1637413 ? 00:00:00 worker + +===top=== +# top -H -p 1567284 +top - 13:02:07 up 164 days, 21:53, 2 users, load average: 1.00, 1.01, 1.05 +Threads: 6 total, 1 running, 5 sleeping, 0 stopped, 0 zombie +%Cpu(s): 2.1 us, 0.0 sy, 0.0 ni, 97.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st +KiB Mem : 26353241+total, 25289752+free, 2771140 used, 7863752 buff/cache +KiB Swap: 8388604 total, 8388604 free, 0 used. 25926534+avail Mem + scroll coordinates: y = 1/6 (tasks), x = 1/12 (fields) + PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND +1567290 qemu 20 0 6683072 647416 8336 R 99.7 0.2 4028:04 CPU 0/KVM +1567284 qemu 20 0 6683072 647416 8336 S 0.0 0.2 0:12.93 qemu-kvm +1567286 qemu 20 0 6683072 647416 8336 S 0.0 0.2 0:00.00 call_rcu +1567289 qemu 20 0 6683072 647416 8336 S 0.0 0.2 0:00.00 IO mon_iothread +1567293 qemu 20 0 6683072 647416 8336 S 0.0 0.2 0:00.27 vnc_worker +1637464 qemu 20 0 6683072 647416 8336 S 0.0 0.2 0:00.00 worker + +===htop=== +.... + +===vmstat on the host=== +# vmstat 1 5 +procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- + r b swpd free buff cache si so bi bo in cs us sy id wa st + 2 0 0 252897184 366768 7497768 0 0 0 0 0 0 0 0 100 0 0 + 1 0 0 252896752 366768 7497768 0 0 0 0 1394 367 2 0 98 0 0 + 1 0 0 252896752 366768 7497768 0 0 0 0 1442 387 2 0 98 0 0 + 1 0 0 252896752 366768 7497768 0 0 0 0 1479 470 2 0 98 0 0 + 1 0 0 252896752 366776 7497768 0 0 0 12 1373 371 2 0 98 0 0 + +===vmstat on the VM=== +# vmstat 1 5 +procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- + r b swpd free buff cache si so bi bo in cs us sy id wa st + 1 0 0 1490564 81708 238688 0 0 1 2 14 30 0 0 99 1 0 + 0 0 0 1490564 81708 238688 0 0 0 0 29 55 0 0 100 0 0 + 0 0 0 1490564 81708 238688 0 0 0 0 26 56 0 0 100 0 0 + 0 0 0 1490564 81708 238688 0 0 0 0 17 31 0 0 99 0 0 + 0 0 0 1490564 81708 238688 0 0 0 0 19 41 0 0 100 0 0 + +The QEMU project is currently considering to move 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/105/mistranslation/1830415 b/results/classifier/105/mistranslation/1830415 new file mode 100644 index 000000000..596a81428 --- /dev/null +++ b/results/classifier/105/mistranslation/1830415 @@ -0,0 +1,32 @@ +mistranslation: 0.671 +instruction: 0.584 +graphic: 0.569 +semantic: 0.512 +device: 0.505 +other: 0.344 +network: 0.288 +boot: 0.247 +vnc: 0.215 +socket: 0.195 +assembly: 0.078 +KVM: 0.071 + +linux-user elf loader issue + +all versions up to 4.0 (I didn't test others) +file affected linux-user/elfload.c +function load_elf_image + +if (phdr[i].p_type == PT_LOAD) { + +- abi_ulong a = phdr[i].p_vaddr - phdr[i].p_offset; ++ abi_ulong a = phdr[i].p_vaddr ; // - phdr[i].p_offset; + if (a < loaddr) { + loaddr = a; + +To the best of my understanding of the elf format p_offset is not a virtual offset. In fact, when I load statically compiled applications, the load fails because the libc before main is trying to access phdr in the executable image but that memory is not mapped -- this is caused by the wrong loaddr above. + +Have you got a test case? The check-tcg tests all pass and they are statically linked elfs. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1830872 b/results/classifier/105/mistranslation/1830872 new file mode 100644 index 000000000..ea6c495b1 --- /dev/null +++ b/results/classifier/105/mistranslation/1830872 @@ -0,0 +1,612 @@ +mistranslation: 0.745 +other: 0.741 +vnc: 0.722 +instruction: 0.712 +KVM: 0.677 +semantic: 0.670 +graphic: 0.668 +device: 0.664 +assembly: 0.656 +boot: 0.623 +network: 0.606 +socket: 0.594 + +AARCH64 to ARMv7 mistranslation in TCG + +The following guest code: + + https://github.com/tianocore/edk2/blob/3604174718e2afc950c3cc64c64ba5165c8692bd/MdePkg/Library/BaseMemoryLibOptDxe/AArch64/CopyMem.S + +implements, in hand-optimized aarch64 assembly, the CopyMem() edk2 (EFI +Development Kit II) library function. (CopyMem() basically has memmove() +semantics, to provide a standard C analog here.) The relevant functions +are InternalMemCopyMem() and __memcpy(). + +When TCG translates this aarch64 code to x86_64, everything works fine. + +When TCG translates this aarch64 code to ARMv7, the destination area of +the translated CopyMem() function becomes corrupted -- it differs from +the intended source contents. Namely, in every 4096 byte block, the +8-byte word at offset 4032 (0xFC0) is zeroed out in the destination, +instead of receiving the intended source value. + +I'm attaching two hexdumps of the same destination area: + +- "good.txt" is a hexdump of the destination area when CopyMem() was + translated to x86_64, + +- "bad.txt" is a hexdump of the destination area when CopyMem() was + translated to ARMv7. + +In order to assist with the analysis of this issue, I disassembled the +aarch64 binary with "objdump". Please find the listing in +"DxeCore.objdump", attached. The InternalMemCopyMem() function starts at +hex offset 2b2ec. The __memcpy() function starts at hex offset 2b180. + +And, I ran the guest on the ARMv7 host with "-d +in_asm,op,op_opt,op_ind,out_asm". Please find the log in +"tcg.in_asm.op.op_opt.op_ind.out_asm.log", attached. + +The TBs that correspond to (parts of) the InternalMemCopyMem() and +__memcpy() functions are scattered over the TCG log file, but the offset +between the "nice" disassembly from "DxeCore.objdump", and the in-RAM +TBs in the TCG log, can be determined from the fact that there is a +single prfm instruction in the entire binary. The instruction's offset +is 0x2b180 in "DxeCore.objdump" -- at the beginning of the __memcpy() +function --, and its RAM address is 0x472d2180 in the TCG log. Thus the +difference (= the load address of DxeCore.efi) is 0x472a7000. + +QEMU was built at commit a4f667b67149 ("Merge remote-tracking branch +'remotes/cohuck/tags/s390x-20190521-3' into staging", 2019-05-21). + +The reproducer command line is (on an ARMv7 host): + + qemu-system-aarch64 \ + -display none \ + -machine virt,accel=tcg \ + -nodefaults \ + -nographic \ + -drive if=pflash,format=raw,file=$prefix/share/qemu/edk2-aarch64-code.fd,readonly \ + -drive if=pflash,format=raw,file=$prefix/share/qemu/edk2-arm-vars.fd,snapshot=on \ + -cpu cortex-a57 \ + -chardev stdio,signal=off,mux=on,id=char0 \ + -mon chardev=char0,mode=readline \ + -serial chardev:char0 + +The apparent symptom is an assertion failure *in the guest*, such as + +> ASSERT [DxeCore] +> /home/lacos/src/upstream/qemu/roms/edk2/MdePkg/Library/BaseLib/String.c(1090): +> Length < _gPcd_FixedAtBuild_PcdMaximumAsciiStringLength + +but that is only a (distant) consequence of the CopyMem() +mistranslation, and resultant destination area corruption. + +Originally reported in the following two mailing list messages: +- http://<email address hidden> +- http://<email address hidden> + + + +Possibly related: +[Qemu-devel] "accel/tcg: demacro cputlb" break qemu-system-x86_64 +https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg07362.html + +(qemu-system-x86_64 fails to boot 64-bit kernel under TCG accel when QEMU is built for i686) + +Note to self: try to reprodouce the present issue with QEMU built at eed5664238ea^ -- this LP has originally been filed about the tree at a4f667b67149, and that commit contains eed5664238ea. So checking at eed5664238ea^ might reveal a difference. + + +Laszlo Ersek (Red Hat) <email address hidden> writes: + +> Possibly related: +> [Qemu-devel] "accel/tcg: demacro cputlb" break qemu-system-x86_64 +> https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg07362.html +> +> (qemu-system-x86_64 fails to boot 64-bit kernel under TCG accel when +> QEMU is built for i686) +> +> Note to self: try to reprodouce the present issue with QEMU built at +> eed5664238ea^ -- this LP has originally been filed about the tree at +> a4f667b67149, and that commit contains eed5664238ea. So checking at +> eed5664238ea^ might reveal a difference. + +Oops. Looks like tests/tcg/multiarch/system/memory.c didn't cover enough +cases. + +-- +Alex Bennée + + + +Alex Bennée <email address hidden> writes: + +> Laszlo Ersek (Red Hat) <email address hidden> writes: +> +>> Possibly related: +>> [Qemu-devel] "accel/tcg: demacro cputlb" break qemu-system-x86_64 +>> https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg07362.html +>> +>> (qemu-system-x86_64 fails to boot 64-bit kernel under TCG accel when +>> QEMU is built for i686) +>> +>> Note to self: try to reprodouce the present issue with QEMU built at +>> eed5664238ea^ -- this LP has originally been filed about the tree at +>> a4f667b67149, and that commit contains eed5664238ea. So checking at +>> eed5664238ea^ might reveal a difference. +> +> Oops. Looks like tests/tcg/multiarch/system/memory.c didn't cover enough +> cases. + +Actually I do see something with i386 host running the aarch64 memory +test (although so far not with a armv7 host): + + ./qemu-system-aarch64 -monitor none -display none -M virt -cpu max -display none -semihosting -kernel tests/memory + +Gives: + + Reading u64 from 0x40213004 (offset 4):....Error 0, 0, 0, 0, 250, 249, 248, 255Test complete: FAILED + +-- +Alex Bennée + + +When running on 32 bit TCG backends a wide unaligned load ends up +truncating data before returning to the guest. We specifically have +the return type as uint64_t to avoid any premature truncation so we +should use the same for the interim types. + +Hopefully fixes #1830872 + +Signed-off-by: Alex Bennée <email address hidden> +--- + accel/tcg/cputlb.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c +index cdcc3771020..b796ab1cbea 100644 +--- a/accel/tcg/cputlb.c ++++ b/accel/tcg/cputlb.c +@@ -1303,7 +1303,7 @@ load_helper(CPUArchState *env, target_ulong addr, TCGMemOpIdx oi, + && unlikely((addr & ~TARGET_PAGE_MASK) + size - 1 + >= TARGET_PAGE_SIZE)) { + target_ulong addr1, addr2; +- tcg_target_ulong r1, r2; ++ uint64_t r1, r2; + unsigned shift; + do_unaligned_access: + addr1 = addr & ~(size - 1); +-- +2.20.1 + + + +I confirm that QEMU works fine (for the use case originally reported in this LP ticket) when built at commit a6ae23831b, i.e. at the parent of eed5664238ea. + +В сообщении от Monday 03 June 2019 18:01:20 Alex Bennée написал(а): +> When running on 32 bit TCG backends a wide unaligned load ends up +> truncating data before returning to the guest. We specifically have +> the return type as uint64_t to avoid any premature truncation so we +> should use the same for the interim types. +> +> Hopefully fixes #1830872 +> +> Signed-off-by: Alex Bennée <email address hidden> +> --- +> accel/tcg/cputlb.c | 2 +- +> 1 file changed, 1 insertion(+), 1 deletion(-) +> +> diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c +> index cdcc3771020..b796ab1cbea 100644 +> --- a/accel/tcg/cputlb.c +> +++ b/accel/tcg/cputlb.c +> @@ -1303,7 +1303,7 @@ load_helper(CPUArchState *env, target_ulong addr, TCGMemOpIdx oi, +> && unlikely((addr & ~TARGET_PAGE_MASK) + size - 1 +> >= TARGET_PAGE_SIZE)) { +> target_ulong addr1, addr2; +> - tcg_target_ulong r1, r2; +> + uint64_t r1, r2; +> unsigned shift; +> do_unaligned_access: +> addr1 = addr & ~(size - 1); + +Unfortunatly, this doesn't fix 32-bit qemu-system-x86_64 .... so, my bug is separate from #1830872 ? + +I also was unable to convince qemu to use my kernel-only x86_64 gcc 6.5.0 cross-compiler .. +probably x86-64 testing on i686 requires either docker (I don't have this +) or 'real' cross-compiler (build with glibc support). + + +Sorry the patch in comment #5 wasn't visible when I wrote what would end up as comment #6. I'll test the patch later. Thanks! + +I managed to tweak the memory test enough to detect the failure on aarch64-on-armv7 and I the attached patch fixes it. Could you please double check with your test case? + +В сообщении от Monday 03 June 2019 18:51:40 Alex Bennée написал(а): +> I managed to tweak the memory test enough to detect the failure on +> aarch64-on-armv7 and I the attached patch fixes it. Could you please +> double check with your test case? +> + + +Hm, I manually applied path from LP(git diff disliked copypasted patch), +so for now git diff in qemu tree shows: + +diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c +index cdcc377102..b796ab1cbe 100644 +--- a/accel/tcg/cputlb.c ++++ b/accel/tcg/cputlb.c +@@ -1303,7 +1303,7 @@ load_helper(CPUArchState *env, target_ulong addr, TCGMemOpIdx oi, + && unlikely((addr & ~TARGET_PAGE_MASK) + size - 1 + >= TARGET_PAGE_SIZE)) { + target_ulong addr1, addr2; +- tcg_target_ulong r1, r2; ++ uint64_t r1, r2; + unsigned shift; + do_unaligned_access: + addr1 = addr & ~(size - 1); +lines 1-13/13 (END) + +--------- + +but x86_64-softmmu/qemu-system-x86_64 -kernel /boot/bzImage-4.12.0-x64 -accel tcg +still hangs at 'booting the kernel" (it decompress OK) + +I make distclean'ed source tree and reconfigured it: + ./configure --target-list=x86_64-softmmu --disable-werror --enable-debug-tcg --cross-cc-x86_64="/opt/kgcc64/bin/x86_64-unknown-linux-gnu-gcc-6.5.0" + +next, make -j 5 and test. + +Hm. + +I tried debug switches, it seems to hang a bit differently for two runs: + +x86_64-softmmu/qemu-system-x86_64 -kernel /boot/bzImage-4.12.0-x64 -accel tcg -nographic -d in_asm,op,op_opt,op_ind,out_asm + +===================== + +IN: +0xffffffff810e8a63: 48 83 c3 64 addq $0x64, %rbx +0xffffffff810e8a67: eb c2 jmp 0xffffffff810e8a2b + +OP: + ld_i32 tmp18,env,$0xfffffff0 + movi_i32 tmp19,$0x0 + brcond_i32 tmp18,tmp19,lt,$L0 + + ---- ffffffff810e8a63 0000000000000000 + movi_i32 tmp2,$0x64 + movi_i32 tmp3,$0x0 + mov_i32 tmp0,rbx_0 + mov_i32 tmp1,rbx_1 + add2_i32 tmp0,tmp1,tmp0,tmp1,tmp2,tmp3 + mov_i32 rbx_0,tmp0 + mov_i32 rbx_1,tmp1 + mov_i32 cc_src_0,tmp2 + mov_i32 cc_src_1,tmp3 + mov_i32 cc_dst_0,tmp0 + mov_i32 cc_dst_1,tmp1 + discard cc_src2_0 + discard cc_src2_1 + discard cc_op + + ---- ffffffff810e8a67 0000000000000009 + movi_i32 cc_op,$0x9 + goto_tb $0x0 + movi_i32 tmp6,$0x810e8a2b + movi_i32 tmp7,$0xffffffff + st_i32 tmp6,env,$0x80 + st_i32 tmp7,env,$0x84 + exit_tb $0xf2f1c080 + set_label $L0 + exit_tb $0xf2f1c083 + +OP after optimization and liveness analysis: + ld_i32 tmp18,env,$0xfffffff0 dead: 1 pref=0xff + movi_i32 tmp19,$0x0 pref=0xff + brcond_i32 tmp18,tmp19,lt,$L0 dead: 0 1 + + ---- ffffffff810e8a63 0000000000000000 + movi_i32 tmp2,$0x64 pref=0xff + movi_i32 tmp3,$0x0 pref=0xff + add2_i32 tmp0,tmp1,rbx_0,rbx_1,tmp2,tmp3 dead: 2 3 pref=0xff,0xff + mov_i32 rbx_0,tmp0 sync: 0 dead: 1 pref=0xff + mov_i32 rbx_1,tmp1 sync: 0 dead: 1 pref=0xff + mov_i32 cc_src_0,tmp2 sync: 0 dead: 0 1 pref=0xff + mov_i32 cc_src_1,tmp3 sync: 0 dead: 0 1 pref=0xff + mov_i32 cc_dst_0,rbx_0 sync: 0 dead: 0 1 pref=0xff + mov_i32 cc_dst_1,rbx_1 sync: 0 dead: 0 1 pref=0xff + discard cc_src2_0 pref=0xff + discard cc_src2_1 pref=0xff + discard cc_op pref=0xff mov_i32 cc_dst_0,tmp0 + mov_i32 cc_dst_1,tmp1 + discard cc_src2_0 + discard cc_src2_1 + discard cc_op + + ---- ffffffff810e8a55 0000000000000021 + movi_i32 cc_op,$0x21 + movi_i32 tmp20,$0x0 + movi_i32 tmp21,$0x0 + brcond2_i32 cc_dst_0,cc_dst_1,tmp20,tmp21,eq,$L1 + goto_tb $0x0 + movi_i32 tmp6,$0x810e8a57 + movi_i32 tmp7,$0xffffffff + st_i32 tmp6,env,$0x80 + st_i32 tmp7,env,$0x84 + exit_tb $0xf2f1c180 + set_label $L1 + goto_tb $0x1 + movi_i32 tmp6,$0x810e8a63 + movi_i32 tmp7,$0xffffffff + st_i32 tmp6,env,$0x80 + st_i32 tmp7,env,$0x84 + exit_tb $0xf2f1c181 + set_label $L0 + exit_tb $0xf2f1c183 + +OP after optimization and liveness analysis: + ld_i32 tmp18,env,$0xfffffff0 dead: 1 pref=0xff + movi_i32 tmp19,$0x0 pref=0xff + brcond_i32 tmp18,tmp19,lt,$L0 dead: 0 1 + + ---- ffffffff810e8a4c 0000000000000000 + + ---- ffffffff810e8a52 0000000000000000 + movi_i32 tmp1,$0x0 pref=0xff + movi_i32 tmp0,$0x64 pref=0xff + mov_i32 r14_0,tmp0 sync: 0 dead: 1 pref=0xf8 + mov_i32 r14_1,tmp1 sync: 0 dead: 1 pref=0xf8 + call cc_compute_c,$0x5,$2,cc_src_0,cc_src_1,cc_dst_0,cc_dst_1,cc_src_0,cc_src_1,cc_src2_0,cc_src2_1,cc_op sync: 0 1 dead: 0 1 2 3 4 5 6 7 8 pref=none,none + mov_i32 cc_dst_0,r14_0 sync: 0 dead: 0 1 pref=0xff + mov_i32 cc_dst_1,r14_1 sync: 0 dead: 0 1 pref=0xffУбито + +(killed by me) + +================== + +IN: +0xffffffff810e8a61: eb ef jmp 0xffffffff810e8a52 + +OP: + ld_i32 tmp18,env,$0xfffffff0 + movi_i32 tmp19,$0x0 + brcond_i32 tmp18,tmp19,lt,$L0 + + ---- ffffffff810e8a61 0000000000000000 + goto_tb $0x0 + movi_i32 tmp6,$0x810e8a52 + movi_i32 tmp7,$0xffffffff + st_i32 tmp6,env,$0x80 + st_i32 tmp7,env,$0x84 + exit_tb $0xf2f22900 + set_label $L0 + exit_tb $0xf2f22903 + +OP after optimization and liveness analysis: + ld_i32 tmp18,env,$0xfffffff0 dead: 1 pref=0xff + movi_i32 tmp19,$0x0 pref=0xff + brcond_i32 tmp18,tmp19,lt,$L0 dead: 0 1 + + ---- ffffffff810e8a61 0000000000000000 + goto_tb $0x0 + movi_i32 tmp6,$0x810e8a52 pref=0xff + movi_i32 tmp7,$0xffffffff pref=0xff + st_i32 tmp6,env,$0x80 dead: 0 + st_i32 tmp7,env,$0x84 dead: 0 1 + exit_tb $0xf2f22900 + set_label $L0 + exit_tb $0xf2f22903 + +OUT: [size=56] +0xf2f22980: 8b 5d f0 movl -0x10(%ebp), %ebx +0xf2f22983: 85 db testl %ebx, %ebx +0xf2f22985: 0f 8c 23 00 00 00 jl 0xf2f229ae +0xf2f2298b: e9 00 00 00 00 jmp 0xf2f22990 +0xf2f22990: c7 85 80 00 00 00 52 8a movl $0x810e8a52, 0x80(%ebp) +0xf2f22998: 0e 81 +0xf2f2299a: c7 85 84 00 00 00 ff ff movl $0xffffffff, 0x84(%ebp) +0xf2f229a2: ff ff +0xf2f229a4: b8 00 29 f2 f2 movl $0xf2f22900, %eax +0xf2f229a9: e9 69 46 c9 ff jmp 0xf2bb7017 +0xf2f229ae: b8 03 29 f2 f2 movl $0xf2f22903, %eax +0xf2f229b3: e9 5f 46 c9 ff jmp 0xf2bb7017 + +---------------- +IN: +0xffffffff810e8a52: 49 ff ce decq %r14 +0xffffffff810e8a55: 74 0c je 0xffffffff810e8a63 + +OP: + ld_i32 tmp18,env,$0xfffffff0 + movi_i32 tmp19,$0x0 + brcond_i32 tmp18,tmp19,lt,$L0 + + ---- ffffffff810e8a52 0000000000000000 + mov_i32 tmp0,r14_0 + mov_i32 tmp1,r14_1 + mov_i32 tmp0,r14_0 + mov_i32 tmp1,r14_1 + movi_i32 tmp20,$0xffffffff + movi_i32 tmp21,$0xffffffff + add2_i32 tmp0,tmp1,tmp0,tmp1,tmp20,tmp21 + mov_i32 r14_0,tmp0 + mov_i32 r14_1,tmp1 + call cc_compute_c,$0x5,$2,cc_src_0,cc_src_1,cc_dst_0,cc_dst_1,cc_src_0,cc_src_1,cc_src2_0,cc_src2_1,cc_op + mov_i32 cc_dst_0,tmp0 + mov_i32 cc_dst_1,tmp1 + discard cc_src2_0 + discard cc_src2_1 + discard cc_op + + ---- ffffffff810e8a55 0000000000000021 mov_i32 cc_dst_0,r14_0 sync: 0 dead: 1 pref=0xff + mov_i32 cc_dst_1,r14_1 sync: 0 dead: 1 pref=0xff + discard cc_src2_0 pref=0xff + discard cc_src2_1 pref=0xff + discard cc_op pref=0xff + + ---- ffffffff810e8a55 0000000000000021 + movi_i32 cc_op,$0x21 sync: 0 dead: 0 pref=0xff + movi_i32 tmp20,$0x0 pref=0xff + movi_i32 tmp21,$0x0 pref=0xff + brcond2_i32 cc_dst_0,cc_dst_1,tmp20,tmp21,eq,$L1 dead: 0 1 2 3 + goto_tb $0x0 + movi_i32 tmp6,$0x810e8a57 pref=0xff + movi_i32 tmp7,$0xffffffff pref=0xff + st_i32 tmp6,env,$0x80 dead: 0 + st_i32 tmp7,env,$0x84 dead: 0 1 + exit_tb $0xf2f229c0 + set_label $L1 + goto_tb $0x1 + movi_i32 tmp6,$0x810e8a63 pref=0xff movi_i32 cc_op,$0x9 sync: 0 dead: 0 pref=0xff + goto_tb $0x0 + movi_i32 tmp6,$0x810e8a2b pref=0xff + movi_i32 tmp7,$0xffffffff pref=0xff + st_i32 tmp6,env,$0x80 dead: 0 + st_i32 tmp7,env,$0x84 dead: 0 1 + exit_tb $0xf2f22b40 + set_label $L0 + exit_tb $0xf2f22b43 + +OUT: [size=116] +0xf2f22bc0: 8b 5d f0 movl -0x10(%ebp), %ebx +0xf2f22bc3: 85 db testl %ebx, %ebx +0xf2f22bc5: 0f 8c 5f 00 00 00 jl 0xf2f22c2a +0xf2f22bcb: 8b 5d 18 movl 0x18(%ebp), %ebx +0xf2f22bce: 8b 75 1c movl 0x1c(%ebp), %esi +0xf2f22bd1: 83 c3 64 addl $0x64, %ebx +0xf2f22bd4: 83 d6 00 adcl $0, %esi +0xf2f22bd7: 89 5d 18 movl %ebx, 0x18(%ebp) +Убито + +============================= + +try kernel I use (it works with qemu compiiled under 64-bit Slackware, and also with kvm on 32-bit x86) + +sha256sum /boot/bzImage-4.12.0-x64 +b4183376de17e8ea7a25094b7a526e99bcb8339b8703090684c93e0e0a50d284 /boot/bzImage-4.12.0-x64 + + +(+Igor) + +On 06/03/19 17:01, Alex Bennée wrote: +> When running on 32 bit TCG backends a wide unaligned load ends up +> truncating data before returning to the guest. We specifically have +> the return type as uint64_t to avoid any premature truncation so we +> should use the same for the interim types. +> +> Hopefully fixes #1830872 +> +> Signed-off-by: Alex Bennée <email address hidden> +> --- +> accel/tcg/cputlb.c | 2 +- +> 1 file changed, 1 insertion(+), 1 deletion(-) +> +> diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c +> index cdcc3771020..b796ab1cbea 100644 +> --- a/accel/tcg/cputlb.c +> +++ b/accel/tcg/cputlb.c +> @@ -1303,7 +1303,7 @@ load_helper(CPUArchState *env, target_ulong addr, TCGMemOpIdx oi, +> && unlikely((addr & ~TARGET_PAGE_MASK) + size - 1 +> >= TARGET_PAGE_SIZE)) { +> target_ulong addr1, addr2; +> - tcg_target_ulong r1, r2; +> + uint64_t r1, r2; +> unsigned shift; +> do_unaligned_access: +> addr1 = addr & ~(size - 1); +> + +Applied on top of commit ad88e4252f09c2956b99c90de39e95bab2e8e7af: + +Tested-by: Laszlo Ersek <email address hidden> + +Thanks! +Laszlo + + + +Andrew Randrianasulu <email address hidden> writes: + +> В сообщении от Monday 03 June 2019 18:01:20 Alex Bennée написал(а): +>> When running on 32 bit TCG backends a wide unaligned load ends up +>> truncating data before returning to the guest. We specifically have +>> the return type as uint64_t to avoid any premature truncation so we +>> should use the same for the interim types. +>> +>> Hopefully fixes #1830872 +>> +>> Signed-off-by: Alex Bennée <email address hidden> +>> --- +>> accel/tcg/cputlb.c | 2 +- +>> 1 file changed, 1 insertion(+), 1 deletion(-) +>> +>> diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c +>> index cdcc3771020..b796ab1cbea 100644 +>> --- a/accel/tcg/cputlb.c +>> +++ b/accel/tcg/cputlb.c +>> @@ -1303,7 +1303,7 @@ load_helper(CPUArchState *env, target_ulong addr, TCGMemOpIdx oi, +>> && unlikely((addr & ~TARGET_PAGE_MASK) + size - 1 +>> >= TARGET_PAGE_SIZE)) { +>> target_ulong addr1, addr2; +>> - tcg_target_ulong r1, r2; +>> + uint64_t r1, r2; +>> unsigned shift; +>> do_unaligned_access: +>> addr1 = addr & ~(size - 1); +> +> Unfortunatly, this doesn't fix 32-bit qemu-system-x86_64 .... so, my +> bug is separate from #1830872 ? + +I think you've hit two - one of which we have just fixed. With my +expanded memory test on i386 I'm seeing a hang but it's ok @ +pull-demacro-softmmu-100519-1. Unfortunately bisecting through the slirp +move and other i386 Werror stuff is proving painful. + +> +> I also was unable to convince qemu to use my kernel-only x86_64 gcc 6.5.0 cross-compiler .. +> probably x86-64 testing on i686 requires either docker (I don't have this +> ) or 'real' cross-compiler (build with glibc support). + + +-- +Alex Bennée + + +On Mon, 3 Jun 2019 16:01:20 +0100 +Alex Bennée <email address hidden> wrote: + +> When running on 32 bit TCG backends a wide unaligned load ends up +> truncating data before returning to the guest. We specifically have +> the return type as uint64_t to avoid any premature truncation so we +> should use the same for the interim types. +> +> Hopefully fixes #1830872 +> +> Signed-off-by: Alex Bennée <email address hidden> + +Fixes arm/virt bios-tables-test for me, so + +Tested-by: Igor Mammedov <email address hidden> + +> --- +> accel/tcg/cputlb.c | 2 +- +> 1 file changed, 1 insertion(+), 1 deletion(-) +> +> diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c +> index cdcc3771020..b796ab1cbea 100644 +> --- a/accel/tcg/cputlb.c +> +++ b/accel/tcg/cputlb.c +> @@ -1303,7 +1303,7 @@ load_helper(CPUArchState *env, target_ulong addr, TCGMemOpIdx oi, +> && unlikely((addr & ~TARGET_PAGE_MASK) + size - 1 +> >= TARGET_PAGE_SIZE)) { +> target_ulong addr1, addr2; +> - tcg_target_ulong r1, r2; +> + uint64_t r1, r2; +> unsigned shift; +> do_unaligned_access: +> addr1 = addr & ~(size - 1); + + + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=8c79b288513587e960b + diff --git a/results/classifier/105/mistranslation/1831750 b/results/classifier/105/mistranslation/1831750 new file mode 100644 index 000000000..4db79d303 --- /dev/null +++ b/results/classifier/105/mistranslation/1831750 @@ -0,0 +1,92 @@ +mistranslation: 0.794 +KVM: 0.727 +vnc: 0.693 +other: 0.662 +graphic: 0.646 +device: 0.611 +network: 0.605 +semantic: 0.556 +instruction: 0.544 +boot: 0.532 +socket: 0.515 +assembly: 0.500 + +virtual machine cpu soft lockup when qemu attach disk + +Hi, I found a problem that virtual machine cpu soft lockup when I attach a disk to the vm in the case that + +backend storage network has a large delay or IO pressure is too large. + +1) The disk xml which I attached is: + + <disk type='block' device='lun' rawio='yes'> + <driver name='qemu' type='raw' cache='none' io='native'/> + <source dev='/dev/mapper/360022a11000c1e0a0787c23a000001cb'/> + <backingStore/> + <target dev='sdb' bus='scsi'/> + <alias name='scsi0-0-1-0'/> + <address type='drive' controller='0' bus='0' target='1' unit='0'/> + </disk> + +2) The bt of qemu main thread: + +#0 0x0000ffff9d78402c in pread64 () from /lib64/libpthread.so.0 +#1 0x0000aaaace3357d8 in pread64 (__offset=0, __nbytes=4096, __buf=0xaaaad47a5200, __fd=202) at /usr/include/bits/unistd.h:99 +#2 raw_is_io_aligned (fd=fd@entry=202, buf=buf@entry=0xaaaad47a5200, len=len@entry=4096) at block/raw_posix.c:294 +#3 0x0000aaaace33597c in raw_probe_alignment (bs=bs@entry=0xaaaad32ea920, fd=202, errp=errp@entry=0xfffffef7a330) at block/raw_posix.c:349 +#4 0x0000aaaace335a48 in raw_refresh_limits (bs=0xaaaad32ea920, errp=0xfffffef7a330) at block/raw_posix.c:811 +#5 0x0000aaaace3404b0 in bdrv_refresh_limits (bs=0xaaaad32ea920, errp=0xfffffef7a330, errp@entry=0xfffffef7a360) at block/io.c:122 +#6 0x0000aaaace340504 in bdrv_refresh_limits (bs=bs@entry=0xaaaad09ce800, errp=errp@entry=0xfffffef7a3b0) at block/io.c:97 +#7 0x0000aaaace2eb9f0 in bdrv_open_common (bs=bs@entry=0xaaaad09ce800, file=file@entry=0xaaaad0e89800, options=<optimized out>, errp=errp@entry=0xfffffef7a450) +at block.c:1194 +#8 0x0000aaaace2eedec in bdrv_open_inherit (filename=<optimized out>, filename@entry=0xaaaad25f92d0 "/dev/mapper/36384c4f100630193359db7a80000011d", +reference=reference@entry=0x0, options=<optimized out>, options@entry=0xaaaad3d0f4b0, flags=<optimized out>, flags@entry=128, parent=parent@entry=0x0, +child_role=child_role@entry=0x0, errp=errp@entry=0xfffffef7a710) at block.c:1895 +#9 0x0000aaaace2ef510 in bdrv_open (filename=filename@entry=0xaaaad25f92d0 "/dev/mapper/36384c4f100630193359db7a80000011d", reference=reference@entry=0x0, +options=options@entry=0xaaaad3d0f4b0, flags=flags@entry=128, errp=errp@entry=0xfffffef7a710) at block.c:1979 +#10 0x0000aaaace331ef0 in blk_new_open (filename=filename@entry=0xaaaad25f92d0 "/dev/mapper/36384c4f100630193359db7a80000011d", reference=reference@entry=0x0, +options=options@entry=0xaaaad3d0f4b0, flags=128, errp=errp@entry=0xfffffef7a710) at block/block_backend.c:213 +#11 0x0000aaaace0da1f4 in blockdev_init (file=file@entry=0xaaaad25f92d0 "/dev/mapper/36384c4f100630193359db7a80000011d", bs_opts=bs_opts@entry=0xaaaad3d0f4b0, +errp=errp@entry=0xfffffef7a710) at blockdev.c:603 +#12 0x0000aaaace0dc478 in drive_new (all_opts=all_opts@entry=0xaaaad4dc31d0, block_default_type=<optimized out>) at blockdev.c:1116 +#13 0x0000aaaace0e3ee0 in add_init_drive ( +optstr=optstr@entry=0xaaaad0872ec0 "file=/dev/mapper/36384c4f100630193359db7a80000011d,format=raw,if=none,id=drive-scsi0-0-0-3,cache=none,aio=native") +at device_hotplug.c:46 +#14 0x0000aaaace0e3f78 in hmp_drive_add (mon=0xfffffef7a810, qdict=0xaaaad0c8f000) at device_hotplug.c:67 +#15 0x0000aaaacdf7d688 in handle_hmp_command (mon=0xfffffef7a810, cmdline=<optimized out>) at /usr/src/debug/qemu-kvm-2.8.1/monitor.c:3199 +#16 0x0000aaaacdf7d778 in qmp_human_monitor_command ( +command_line=0xaaaacfc8e3c0 "drive_add dummy file=/dev/mapper/36384c4f100630193359db7a80000011d,format=raw,if=none,id=drive-scsi0-0-0-3,cache=none,aio=native", +has_cpu_index=false, cpu_index=0, errp=errp@entry=0xfffffef7a968) at /usr/src/debug/qemu-kvm-2.8.1/monitor.c:660 +#17 0x0000aaaace0fdb30 in qmp_marshal_human_monitor_command (args=<optimized out>, ret=0xfffffef7a9e0, errp=0xfffffef7a9d8) at qmp-marshal.c:2223 +#18 0x0000aaaace3b6ad0 in do_qmp_dispatch (request=<optimized out>, errp=0xfffffef7aa20, errp@entry=0xfffffef7aa40) at qapi/qmp_dispatch.c:115 +#19 0x0000aaaace3b6d58 in qmp_dispatch (request=<optimized out>) at qapi/qmp_dispatch.c:142 +#20 0x0000aaaacdf79398 in handle_qmp_command (parser=<optimized out>, tokens=<optimized out>) at /usr/src/debug/qemu-kvm-2.8.1/monitor.c:4010 +#21 0x0000aaaace3bd6c0 in json_message_process_token (lexer=0xaaaacf834c80, input=<optimized out>, type=JSON_RCURLY, x=214, y=274) at qobject/json_streamer.c:105 +#22 0x0000aaaace3f3d4c in json_lexer_feed_char (lexer=lexer@entry=0xaaaacf834c80, ch=<optimized out>, flush=flush@entry=false) at qobject/json_lexer.c:319 +#23 0x0000aaaace3f3e6c in json_lexer_feed (lexer=0xaaaacf834c80, buffer=<optimized out>, size=<optimized out>) at qobject/json_lexer.c:369 +#24 0x0000aaaacdf77c64 in monitor_qmp_read (opaque=<optimized out>, buf=<optimized out>, size=<optimized out>) at /usr/src/debug/qemu-kvm-2.8.1/monitor.c:4040 +#25 0x0000aaaace0eab18 in tcp_chr_read (chan=<optimized out>, cond=<optimized out>, opaque=0xaaaacf90b280) at qemu_char.c:3260 +#26 0x0000ffff9dadf200 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 +#27 0x0000aaaace3c4a00 in glib_pollfds_poll () at util/main_loop.c:230 +--Type <RET> for more, q to quit, c to continue without paging-- +#28 0x0000aaaace3c4a88 in os_host_main_loop_wait (timeout=<optimized out>) at util/main_loop.c:278 +#29 0x0000aaaace3c4bf0 in main_loop_wait (nonblocking=<optimized out>) at util/main_loop.c:534 +#30 0x0000aaaace0f5d08 in main_loop () at vl.c:2120 +#31 0x0000aaaacdf3a770 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:5017 + + +From the bt we can see, when do qmp sush as drive_add, qemu main thread locks the qemu_global_mutex and do pread in raw_probe_alignmen. Pread is a synchronous operation. If backend storage network has a large delay or IO pressure is too large, the pread operation will not return for a long time, which make vcpu thread can't acquire qemu_global_mutex for a long time and make the vcpu thread unable to be scheduled for a long time. So virtual machine cpu soft lockup happened. + + +I thank qemu main thread should not hold qemu_global_mutex for a long time when do qmp that involving IO synchronous operation sush pread , ioctl, etc. + +Do you have any solutions or good ideas about it? Thanks for your reply! + + +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/176 + + diff --git a/results/classifier/105/mistranslation/1832914 b/results/classifier/105/mistranslation/1832914 new file mode 100644 index 000000000..a17ac8c1e --- /dev/null +++ b/results/classifier/105/mistranslation/1832914 @@ -0,0 +1,28 @@ +mistranslation: 0.973 +device: 0.874 +instruction: 0.829 +semantic: 0.783 +graphic: 0.731 +network: 0.566 +boot: 0.523 +other: 0.459 +socket: 0.420 +vnc: 0.347 +KVM: 0.267 +assembly: 0.098 + +Wrong error log when drive is specified qcow but qcow2 image file used. + +On archlinux qemu version 4.0.0 when I type: + +$ qemu-system-x86_64 -drive format=qcow,file=image.qcow2 ... + +I get this output in stderr + +qemu-system-x86_64 -drive format=qcow,file=image.qcow2 ...: Unsupported qcow version 3 + +image.qcow2 is a qcow2 image created by qemu-img. error states that problem is with lack support with qcow3 format but real problem is that foramt=qcow is wrong option. + +Fix has been included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=197bfa7da7c8eeb39aa5 + diff --git a/results/classifier/105/mistranslation/1833053 b/results/classifier/105/mistranslation/1833053 new file mode 100644 index 000000000..3a7bb3101 --- /dev/null +++ b/results/classifier/105/mistranslation/1833053 @@ -0,0 +1,66 @@ +mistranslation: 0.872 +KVM: 0.841 +vnc: 0.840 +boot: 0.799 +other: 0.793 +device: 0.776 +graphic: 0.771 +instruction: 0.755 +network: 0.754 +semantic: 0.731 +assembly: 0.687 +socket: 0.637 + +qemu guest crashes on spice client USB redirected device removal + +Hello, + +I am experiencing guest crashes, which cannot be reproduced at all times, but are pretty frequent (4 out of 5 tries it would crash). The guest crashes when a previously attached USB redirected device through SPICE has been removed by the client. + +Steps to reproduce: +1.) Start windows 10 guest with display driver Spice +2.) Connect to the console with remote-viewer spice://IP:PORT or via virt-viewer (tunnelled through SSH) +3.) Attach a client USB device, for example storage device, iPhone or Android phone +4.) Observe the guest OS detects it and sets it up +5.) Go back to 'USB device selection' and untick the USB device +6.) Observe the guest VM crashed and the below assertion was printed in the qemu log for this virtual machine: + +qemu-system-x86_64: /var/tmp/portage/app-emulation/qemu-4.0.0-r3/work/qemu-4.0.0/hw/usb/core.c:720: usb_ep_get: Assertion `dev != NULL' failed. +2019-06-17 09:25:09.160+0000: shutting down, reason=crashed + + +Versions of related packages on the host: +app-emulation/qemu-4.0.0-r3 +app-emulation/spice-0.14.0-r2:0 +app-emulation/spice-protocol-0.12.14:0 +net-misc/spice-gtk-0.35:0 +Kernel: 5.1.7-gentoo on Intel x86_64 CPU + +Version of the spice-tools on the guest: +virtio-win 0.1-126 +QXL 0.1-21 +mingw-vdagent-win 0.8.0 + +QEMU command line (generated by libvirt): + +/usr/bin/qemu-system-x86_64 -name guest=W10VM,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-41-W10VM/master-key.aes -machine pc-i440fx-2.12,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu qemu64,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,hv_synic,hv_stimer -m 4500 -realtime mlock=off -smp 2,maxcpus=4,sockets=4,cores=1,threads=1 -uuid b39afae2-5085-4659-891c-b3c65e65af2e -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=26,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -no-hpet -global kvm-pit.lost_tick_policy=delay -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot menu=off,strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x8 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/libvirt/images/W10VM.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-1,cache=unsafe,discard=unmap,detect-zeroes=unmap -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,device_id=drive-scsi0-0-0-1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1,bootindex=1,write-cache=on -netdev tap,fd=28,id=hostnet0,vhost=on,vhostfd=29 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:44:f6:21,bus=pci.0,addr=0x3 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -chardev socket,id=charchannel1,fd=30,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=3,chardev=charchannel1,id=channel1,name=org.qemu.guest_agent.0 -chardev spiceport,id=charchannel2,name=org.spice-space.webdav.0 -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel2,id=channel2,name=org.spice-space.webdav.0 -spice port=5901,addr=0.0.0.0,seamless-migration=on -device qxl-vga,id=video0,ram_size=134217728,vram_size=134217728,vram64_size_mb=0,vgamem_mb=64,max_outputs=1,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=1 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on + + +I have attempted to collect a backtrace, but will need direction as I am not sure on which thread to listen and where to set the breakpoint, 'thread apply all backtrace' does not seem to work well with the qemu process... + +Thank you + +Hello, +I have the same qemu behaviour. It happens every time I have unplugged physical usb device attached to guest from the host system. My device is USB GSM dongle. Some times it disconnects and reconnects again for unknown reason, may be power loss... With version 3.1.0 qemu (gentoo linux) this disconnects had normal USB device disconnects in guest system. But with version 4.0.0 it gets guest VM to crash. + +The QEMU project is currently considering to move 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 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. + + +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/179 + + diff --git a/results/classifier/105/mistranslation/1834113 b/results/classifier/105/mistranslation/1834113 new file mode 100644 index 000000000..43bb32751 --- /dev/null +++ b/results/classifier/105/mistranslation/1834113 @@ -0,0 +1,296 @@ +mistranslation: 0.912 +graphic: 0.867 +other: 0.867 +instruction: 0.866 +semantic: 0.861 +device: 0.852 +socket: 0.846 +assembly: 0.844 +boot: 0.812 +KVM: 0.792 +vnc: 0.787 +network: 0.784 + +QEMU touchpad input erratic after wakeup from sleep + +Using Ubuntu host and guest. Normally the touchpad works great. Within the last few days, suddenly, apparently after a wake from sleep, the touchpad will behave erratically. For example, it will take two clicks to select something, and when moving the cursor it will act as though it is dragging even with the button not clicked. + +A reboot fixes the issue temporarily. + +ProblemType: Bug +DistroRelease: Ubuntu 19.04 +Package: qemu 1:3.1+dfsg-2ubuntu3.1 +Uname: Linux 5.1.14-050114-generic x86_64 +ApportVersion: 2.20.10-0ubuntu27 +Architecture: amd64 +CurrentDesktop: ubuntu:GNOME +Date: Mon Jun 24 20:55:44 2019 +Dependencies: + +EcryptfsInUse: Yes +InstallationDate: Installed on 2019-02-20 (124 days ago) +InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 20180608-09:38 +Lsusb: + Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub + Bus 001 Device 002: ID 8087:0025 Intel Corp. + Bus 001 Device 003: ID 0c45:671d Microdia + Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub +MachineType: Dell Inc. Precision 5530 +ProcEnviron: + TERM=xterm-256color + PATH=(custom, no user) + XDG_RUNTIME_DIR=<set> + LANG=en_US.UTF-8 + SHELL=/bin/bash +ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.1.14-050114-generic root=UUID=18e8777c-1764-41e4-a19f-62476055de23 ro mem_sleep_default=deep mem_sleep_default=deep acpi_rev_override=1 scsi_mod.use_blk_mq=1 nouveau.modeset=0 nouveau.runpm=0 nouveau.blacklist=1 acpi_backlight=none acpi_osi=Linux acpi_osi=! +SourcePackage: qemu +UpgradeStatus: No upgrade log present (probably fresh install) +dmi.bios.date: 04/26/2019 +dmi.bios.vendor: Dell Inc. +dmi.bios.version: 1.10.1 +dmi.board.name: 0FP2W2 +dmi.board.vendor: Dell Inc. +dmi.board.version: A00 +dmi.chassis.type: 10 +dmi.chassis.vendor: Dell Inc. +dmi.modalias: dmi:bvnDellInc.:bvr1.10.1:bd04/26/2019:svnDellInc.:pnPrecision5530:pvr:rvnDellInc.:rn0FP2W2:rvrA00:cvnDellInc.:ct10:cvr: +dmi.product.family: Precision +dmi.product.name: Precision 5530 +dmi.product.sku: 087D +dmi.sys.vendor: Dell Inc. + + + +There wasn't an update in that area that I'd know of except maybe in the kernel (which has too many updates to track all of them). + +Sorry I'm really not a UI expert, lets check a few things still: +- The suspend/wakeup was that just the guest or did you supend/wakeup the host? +- you targetted this for qemu, is the bad effect only happening in the guest UI? +- If you go back to the release kernel instead of the last update does it still happen? +- In general you can always go back to packages in the release pocket, doing so can you identify an + update to one of the packages that caused this to happen? + + +1. Suspend wakeup was on host, not guest. + +2. Yes. Works fine on host, but two guests are both experiencing this. + +I was using 5.1.6, had this issue, updated to latest and it went away, but came back on sleep/awake. If it's a kernel issue, it was introduced before 5.1.6. + +It also doesn't seem to happen on every sleep, and I'm not sure if I can reproduce it. After it happened twice in two days it was enough for me to report. + +The fact that it doesn't happen every time makes it difficult to test against different versions of packages. + +For disco there has been a single qemu update for security, with the following changes: + + * SECURITY UPDATE: Add support for exposing md-clear functionality + to guests + - d/p/ubuntu/enable-md-clear.patch + - d/p/ubuntu/enable-md-no.patch + - CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091 + * SECURITY UPDATE: heap overflow when loading device tree blob + - d/p/ubuntu/CVE-2018-20815.patch: specify how large the buffer to + copy the device tree blob into is. + - CVE-2018-20815 + * SECURITY UPDATE: device driver denial of service via NULL pointer + dereference + - d/p/ubuntu/CVE-2019-5008.patch: Define skeleton 'power_mem_read' + routine + - CVE-2019-5008 + * SECURITY UPDATE: information leak in SLiRP + - d/p/ubuntu/CVE-2019-9824.patch: check sscanf result when + emulating ident. + - CVE-2019-9824 + + +$ git show b818da7a1a0dfa55c0f4edf0be10394fe4d7f3f8 | diffstat + changelog | 23 ++++++++++++ + patches/series | 5 ++ + patches/ubuntu/CVE-2018-20815.patch | 38 +++++++++++++++++++ + patches/ubuntu/CVE-2019-5008.patch | 43 ++++++++++++++++++++++ + patches/ubuntu/CVE-2019-9824.patch | 49 +++++++++++++++++++++++++ + patches/ubuntu/enable-md-clear.patch | 67 +++++++++++++++++++++++++++++++++++ + patches/ubuntu/enable-md-no.patch | 28 ++++++++++++++ + 7 files changed, 253 insertions(+) + +I took a cursory look through the five patches, but none leap out as anything relating to touchpads, and don't appear to be related to power management, but hard to say for certain. + + +touchpad issues with power management can be challenging to sort out, and it's not unusual for them to reproduce non-reliably. Power management problems are almost always kernel-related, though I know it can be labor intensive to test. + +However, I've seen the double-action behavior myself with touchpads and keyboards, and the problem wasn't the kernel; in at least one of those cases the cause was a second package that was consuming input events, which resolved through a combination of apt-get purges and reboots. Reviewing the tail end of /var/log/apt/history.log and rolling things back one by one might reveal something, but you'd need to do multiple suspend/resume cycles to test each time. You mentioned seeing this behavior starting a couple days ago, so you could focus attention on changes within the past week or so. (And check when the qemu 1:3.1+dfsg-2ubuntu3.1 update installed (and when you subsequently rebooted)). + +An alternative thing to test would be to see if there are differences in what processes are running when the bug is reproducing, vs. when it is not. You'd want to examine the process tables on both the host and guest. But its possible something starts stealing events after resume, that wasn't doing so before, and diffing process tables won't show that; instead, the way to diagnose this would be to kill X clients one by one (e.g. `xlsclients -la`). + +Beyond that, I can just offer some of the standard troubleshooting techniques for input device troubles: + + * Check if your bios firmware is up to date + * Identify your touchpad device and driver (xinput / sudo lsinput / sudo lshw -C input) + * Check input device properties if using evdev/synaptics (i.e. have any settings changed?) + * xev is a helpful testing tool + * Good luck + + +Rebooting the guest when this is happening does not fix the issue, for what that's worth. + +Last upgrades before this happened are: + +Start-Date: 2019-06-20 23:46:55 +Commandline: apt dist-upgrade +Requested-By: a (1001) +Upgrade: intel-microcode:amd64 (3.20190514.0ubuntu0.19.04.3, 3.20190618.0ubuntu0.19.04.1) +End-Date: 2019-06-20 23:47:11 + +Start-Date: 2019-06-24 08:23:45 +Commandline: apt dist-upgrade +Requested-By: a (1001) +Upgrade: snapd:amd64 (2.38+19.04, 2.39.2+19.04), firefox:amd64 (67.0.3+build1-0ubuntu0.19.04.1, 67.0.4+build1-0ubuntu0.19.04.1) +End-Date: 2019-06-24 08:24:00 + +I also see a bunch of updates to libvirt on 2019-06-19. + +Should I try downgrading intel-microcode? + +Looks like the 3.20190514.0ubuntu0.19.04.3 version of intel-microcode is no longer published, how can I revert to it for testing? + +If you don't have the cache the archive only leaves the release version as well as the latest one in -updates and the latest one in -security. It will not be that easy from apt to use any other. +But Launchpad keeps all of the publishing history [1] and there you'll find the version still [2] and from there at the amd64 build the deb file [3]. + +But that said, I doubt that intel-microcode is really involved - not saying it would not be worth a try, but my hopes on it are low to affect this case. + +[1]: https://launchpad.net/ubuntu/+source/intel-microcode/+publishinghistory +[2]: https://launchpad.net/ubuntu/+source/intel-microcode/3.20190514.0ubuntu0.18.04.3 +[3]: https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+build/16832070/+files/intel-microcode_3.20190514.0ubuntu0.18.04.3_amd64.deb + +Looking into libvirt, the release skipped several version numbers and went straight from 4.6.0 to 5.0.0, which were released 5 months apart. Also, 5.0.0 is itself several releases behind. + +I'll test 4.60 first, then try the latest version of libvirt and see if either fixes the issue. + +Actually, the version of libvirt I'd upgraded from was 5.0.0-1ubuntu2.2 -> 5.0.0-1ubuntu2.3. + +Downgrading all of libvirt-clients libvirt-daemon libvirt-daemon-driver-storage-rbd libvirt-daemon-system libvirt0 to 5.0.0-1ubuntu2.2 seems to have fixed this after several sleep-resume cycles, although it's hard to be sure. Does any change in libvirt seem relevant? + + +Related changes are + 3 * SECURITY UPDATE: DoS via incorrect permissions check + 4 - debian/patches/CVE-2019-3886-1.patch: disallow virDomainGetHostname + 5 for read-only connections in src/libvirt-domain.c. + 6 - debian/patches/CVE-2019-3886-2.patch: enforce ACL write permission + 7 for getting guest time & hostname in src/remote/remote_protocol.x. + 8 - CVE-2019-3886 + 9 * SECURITY UPDATE: privilege escalation via incorrect socket permissions + 10 - debian/patches/CVE-2019-10132-1.patch: reject clients unless their + 11 UID matches the current UID in src/admin/admin_server_dispatch.c. + 12 - debian/patches/CVE-2019-10132-2.patch: restrict sockets to mode 0600 + 13 in src/locking/virtlockd-admin.socket.in, + 14 src/locking/virtlockd.socket.in. + 15 - debian/patches/CVE-2019-10132-3.patch: restrict sockets to mode 0600 + 16 in src/logging/virtlogd-admin.socket.in, + 17 src/logging/virtlogd.socket.in. + 18 - CVE-2019-10132 + +None of these is important for mouse integration :-/ +So it might be a red herring. + +I'll try a few full boot-sleep-resume cycles on both versions and see how often it replicates + +The issue replicated on the older libvirt, so it wasn't that. Only thing left to try is intel-microcode now + +intel-microcode is closely related to kernel behavior, and so wouldn't surprise me if it's involved - like I mentioned earlier invariably input device + power management bugs are something kernel related. + +However, looking at the diff for the intel-microcode upgrade the changes are highly processor specific, and affects a small handful: + +http://launchpadlibrarian.net/424908874/intel-microcode_3.20190514.0ubuntu0.19.04.1_3.20190514.0ubuntu0.19.04.3.diff.gz + +I'm guessing for a qemu environment these aren't even relevant, but if one of the lines matches your host cpu then perhaps this would be worth more investigation. Otherwise, probably another red herring. + + +There is more you could try though. I suggested some ideas in my previous comment. You could also run xlsclients before and after reproducing the error, and see if there are any new X clients running that might have a grab on the cursor, and then kill them until the touchpad comes back. (See http://who-t.blogspot.com/2010/11/high-level-overview-of-grabs.html) + + +I hate to mention this as a possibility, but like I mentioned earlier, sometimes these bugs can reproduce very non-reliably. I've seen cases where, for instance, the root cause always existed but it was some change in usage or other random things, that caused the input behavior to suddenly start happening, only to disappear again - quite mysteriously - after some other system change. + +The way input devices work, at least in context of this particular bug, is that each movement or click generates an "event", that gets communicated up through the system through various layers until an application consumes it. You can read about this in more extensive detail at https://www.x.org/wiki/Development/Documentation/InputEventProcessing/ +That leads us to two questions for this case: A) Is the event getting generated at all? and B) If it is, then is something unexpectedly consuming it? So a good first step would be to eliminate one or the other of these. You've made some progress towards ruling out B. + +For testing if the event is getting generated, the tool 'xev' is one of the easiest and handiest places to start from. Have you had a chance to give that a test? Run it from the command line when you've got the non-responsive touchpad, and use the touchpad and see if anything prints in the xev window. You can do some googling to get some tips and tricks for filtering xev output and to understand what its output means. + +'xdotool' can also be useful; it's intended for automation but it lets you manhandle mouse events, such as force a click or mouse up/down. Longshot but at least is easy / low risk to try. + +My guess though is the event isn't even getting generated. In that case i'd proceed with the standard troubleshooting techniques to see if something's wrong with the device itself, and go from there. + +>Core Gen8 Mobile + +That's my i9-8950HK. + +What I don't understand is why it works perfectly on the host but not on the guest. And the fact that it persists even when rebooting the guest implies it's not an issue with the guest runtime or anything. It seems like the issue must be with the way qemu is sending the events through to the guest, which I have no idea about. + +Also, it never ignores my clicks. It's generating clicks that I never made - specifically, when moving the cursor it's acting as if I had clicked and dragged. So moving the cursor on a webpage just selects a bunch of text, moving it across the desktop draws a window, etc. + +I will try some of the other troubleshooting methods. + +1. seems like same issue on older intel-microcode. + +2. I checked xev on the guest while issue was occuring with the following results: + +when moving the cursor, a buttonpress event is generated along with a bunch of motionnotify events. After moving it, if I click or touch the touchpad without moving it it shows only a buttonrelease but no buttonpress. + +This is consistent with the behavior I'm seeing: when I move, it's as if I clicked right before, producing the dragging motion. And once it's registered buttonpress, another buttonpress event won't be generated until a buttonrelease one is generated. + +xev works as expected on the host. + +The issue is a phantom buttonpress event being generated on the guest somehow. + + +xlsclients has the same output both times. + +Hi Avi, +for the sake of giving it a try I had a second level guest and suspended/resumed the first level guest a few times. I can't reproduce it. + +OTOH you seem to have a hard time to identify which change introduced this - if it was any change at all and not just by accident not showing up before. + +I feel bad for you, but right now there isn't much we could action to further help. +Especially bad since you were always so prompt in feedback to our questions and suggestions :-/ + +I'll monitor the bug if you come up with new insights or questions on your debugging I'll try to help as I did so far. Thanks to Bryce who understands UI more than I do for his input as well. + +But given the current state, this most likely will stay incomplete and un-actionable :-/ + +Avi, + +Something I have realized we missed as a feedback here - or maybe I missed checking previous comments - is how your mouse is being setup for the guest. Is it being PS/2 emulated (default) or is it being given as an USB device (when qemu cmd line has "-usb -device usb-tablet"). Also, are you using SPICE protocol (perhaps with USB direction option ?). + +Are you able to tell which xserver-xorg-input-XX module is being used inside the guest ? You will probably find that information from Xorg log files (check if you're using xf86-input-wacom or xserver-xorg-input-evdev or some other). + +Another thing that comes to my mind as well, are you using powersaving features ? Specifically the I2C bus I'm concerned. Using "powertop", you are able to change "Runtime PM for I2C Adapter" option under the Tunables Tab (turning the power mgmt to off). I would like to know if you are able to reproduce the issue without having power management enabled for I2C. You can try disabling only I2C and then disabling all PM options as a second attempt. + +From your host: + +Device #1 + +[ 2.834320] input: WCOM488E:00 056A:488E Mouse as /devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-1/i2c-WCOM488E:00/0018:056A:488E.0001/input/input12 + +[ 3.064686] input: Wacom HID 488E Finger as /devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-1/i2c-WCOM488E:00/0018:056A:488E.0001/input/input17 + +Device #2 + +[ 2.834860] input: SYNA2393:00 06CB:7A13 Mouse as /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-6/i2c-SYNA2393:00/0018:06CB:7A13.0002/input/input13 + +[ 2.834929] input: SYNA2393:00 06CB:7A13 Touchpad as /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-6/i2c-SYNA2393:00/0018:06CB:7A13.0002/input/input14 + +Could you describe your input devices ? How many mice, trackpads, pens, etc, you are using connected to the host ? + +Thanks! And sorry for so many questions =). + + + +Right now it stopped happening, although I did see something briefly last week that fixed itself on a reboot. + +If it happens again I'll check those details. + +[Expired for QEMU because there has been no activity for 60 days.] + +[Expired for libvirt (Ubuntu) because there has been no activity for 60 days.] + +[Expired for qemu (Ubuntu) because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1834613 b/results/classifier/105/mistranslation/1834613 new file mode 100644 index 000000000..55798f660 --- /dev/null +++ b/results/classifier/105/mistranslation/1834613 @@ -0,0 +1,81 @@ +mistranslation: 0.420 +graphic: 0.298 +other: 0.268 +semantic: 0.226 +assembly: 0.223 +vnc: 0.217 +instruction: 0.198 +device: 0.195 +socket: 0.190 +KVM: 0.189 +network: 0.150 +boot: 0.105 + +Crypto related operations failing on Alpine Linux on QEMU 4.0 + +I'm unable to boot the netboot image of Alpine Linux using QEMU 4.0. + +Steps to reproduce: + +curl -O http://dl-cdn.alpinelinux.org/alpine/v3.10/releases/ppc64le/netboot/vmlinuz-vanilla +curl -O http://dl-cdn.alpinelinux.org/alpine/v3.10/releases/ppc64le/netboot/initramfs-vanilla +qemu-system-ppc64 -kernel vmlinuz-vanilla -initrd initramfs-vanilla -nographic -append "console=hvc0 ip=dhcp alpine_repo=http://dl-cdn.alpinelinux.org/alpine/v3.10/main" + +The init script will automatically download and install an in-memory Alpine Linux environment. However, with QEMU 4.0, the installation process will fail with "BAD SIGNATURE" errors: + + + + * Installing packages to root filesystem: fetch http://dl-cdn.alpinelinux.org/alpine/edge/main/ppc64le/APKINDEX.tar.gz +(1/20) Installing musl (1.1.22-r2) +ERROR: musl-1.1.22-r2: BAD signature (2/20) Installing busybox (1.30.1-r2) +ERROR: busybox-1.30.1-r2: BAD signature (3/20) Installing alpine-baselayout (3.1.2-r0) +Executing alpine-baselayout-3.1.2-r0.pre-install ERROR: alpine-baselayout-3.1.2-r0.pre-install: script exited with error 127 +ERROR: alpine-baselayout-3.1.2-r0: BAD signature (4/20) Installing openrc (0.41.2-r1) +ERROR: openrc-0.41.2-r1: BAD signature (5/20) Installing alpine-conf (3.8.3-r0) +ERROR: alpine-conf-3.8.3-r0: BAD signature (6/20) Installing libcrypto1.1 (1.1.1c-r0) +ERROR: libcrypto1.1-1.1.1c-r0: BAD signature (7/20) Installing libssl1.1 (1.1.1c-r0) +ERROR: libssl1.1-1.1.1c-r0: BAD signature (8/20) Installing ca-certificates-cacert (20190108-r0) +ERROR: ca-certificates-cacert-20190108-r0: BAD signature (9/20) Installing libtls-standalone (2.9.1-r0) +ERROR: libtls-standalone-2.9.1-r0: BAD signature (10/20) Installing ssl_client (1.30.1-r2) +ERROR: ssl_client-1.30.1-r2: BAD signature (11/20) Installing zlib (1.2.11-r1) +ERROR: zlib-1.2.11-r1: BAD signature (12/20) Installing apk-tools (2.10.4-r1) +ERROR: apk-tools-2.10.4-r1: BAD signature (13/20) Installing busybox-suid (1.30.1-r2) +ERROR: busybox-suid-1.30.1-r2: BAD signature (14/20) Installing busybox-initscripts (3.1-r7) +ERROR: busybox-initscripts-3.1-r7: BAD signature (15/20) Installing scanelf (1.2.3-r0) +ERROR: scanelf-1.2.3-r0: BAD signature (16/20) Installing musl-utils (1.1.22-r2) +ERROR: musl-utils-1.1.22-r2: BAD signature (17/20) Installing libc-utils (0.7.1-r0) +ERROR: libc-utils-0.7.1-r0: BAD signature (18/20) Installing alpine-keys (2.1-r2) +ERROR: alpine-keys-2.1-r2: BAD signature (19/20) Installing alpine-base (3.10.0-r0) +ERROR: alpine-base-3.10.0-r0: BAD signature (20/20) Installing openssl (1.1.1c-r0) +ERROR: openssl-1.1.1c-r0: BAD signature 20 errors; 0 MiB in 0 packages +ok. +grep: /sysroot/etc/inittab: No such file or directory +/sbin/init not found in new root. Launching emergency recovery shell +Type exit to continue boot. +sh: can't access tty; job control turned off +/ # + + +If I boot up a disk image created by a previous version QEMU, crypto related operations like verifying a RSA signature using the "openssl" command will also fail. + +I didn't see these errors on previous QEMU versions or other architectures on QEMU 4.0 + +Fix for that is already included in git master: + +2a1224359008 target/ppc: Fix lxvw4x, lxvh8x and lxvb16x + +More fix for +8b3b2d75c7c0 ("introduce get_cpu_vsr{l,h}() and set_cpu_vsr{l,h}() helpers for VSR register access") +are availabe: + +77bd8937c03d target/ppc: Fix xvabs[sd]p, xvnabs[sd]p, xvneg[sd]p, xvcpsgn[sd]p +d47a751adab7 target/ppc: Fix xxbrq, xxbrw + +And you can also need: + +899f08ad1d12 tcg: Fix typos in helper_gvec_sar{8,32,64}v + +depending on you host CPU + +@laurent-vivier I just tested the binary built from git master and the error went away. Thanks. + diff --git a/results/classifier/105/mistranslation/1835793 b/results/classifier/105/mistranslation/1835793 new file mode 100644 index 000000000..a2ac98b3b --- /dev/null +++ b/results/classifier/105/mistranslation/1835793 @@ -0,0 +1,34 @@ +mistranslation: 0.729 +graphic: 0.705 +device: 0.644 +instruction: 0.632 +semantic: 0.616 +other: 0.559 +network: 0.430 +socket: 0.406 +vnc: 0.395 +boot: 0.326 +KVM: 0.174 +assembly: 0.135 + +Running an edk2 based bios + +This is not necessarily a bug, however I wasn't sure were to get help. + +I am currently working on using QEMU to run a BIOS my company has developed. In order to see if the software was working correctly, I was able to successfully run the edk2 bios using the following command: + +qemu-system-x86_64.exe -bios "C:\Users\matthew.intriago\Desktop\ovmf.fd" -net none + +However, when running the same command using our personalized bios, QEMU launches stating that “guest has not initialized display”. Theoretically, QEMU should be able to run the bios since it is edk2 based, the only difference between the two is that our bios has more features. + +If anyone has any insight on what the issue might be I would greatly appreciate any help. + +"Guest has not initialized display" simply means that the guest code you're running has not done anything to the display device (VGA in this case). There are two main reasons for this: + + (1) the guest code isn't intended to output to the display -- perhaps it sends its output to the serial port instead. In this case the fix is to use the right QEMU arguments to send the serial port output somewhere you can read it (or to reconfigure the guest code to output where you want it to). + + (2) the guest code is intended to output to the display, but it crashed before it got as far as doing that. In this case, the fix is to debug your guest code. QEMU's gdbstub is usually a good tool to use here. If you control the guest code (ie you can modify and recompile it) you can also add extra debugging to it (like making it output more information earlier, or output debugging trace information to the serial port so you can see how far it has got). + +My guess would be that this is a variation on 2 caused by your BIOS being compiled to assume different hardware from what QEMU is providing -- if the BIOS tries to write to a device that isn't present it will likely crash or go into an infinite loop. + + diff --git a/results/classifier/105/mistranslation/1840646 b/results/classifier/105/mistranslation/1840646 new file mode 100644 index 000000000..5ca94afaf --- /dev/null +++ b/results/classifier/105/mistranslation/1840646 @@ -0,0 +1,31 @@ +mistranslation: 0.900 +other: 0.822 +network: 0.767 +graphic: 0.676 +device: 0.655 +socket: 0.620 +instruction: 0.430 +semantic: 0.430 +vnc: 0.238 +boot: 0.118 +assembly: 0.051 +KVM: 0.020 + +qemu-4.1.0/roms/SLOF/lib/libnet/ping.c:122: logical fault + +qemu-4.1.0/roms/SLOF/lib/libnet/ping.c:122:16: warning: Logical conjunction always evaluates to false: alen <= 0 && alen >= sizeof(args) - 1. [incorrectLogicOperator] + +Source code is + + if (alen <= 0 && alen >= sizeof(args) - 1) { + +Maybe better code: + + if (alen <= 0 || alen >= sizeof(args) - 1) { + +This isn't QEMU code -- it's just the source for third-party ROMs that we ship with QEMU because we also ship the ROM binaries. Please report it to the upstream project. + + +(Anything in a git submodule will be third-party code that's not part of QEMU.) + + diff --git a/results/classifier/105/mistranslation/1840648 b/results/classifier/105/mistranslation/1840648 new file mode 100644 index 000000000..b547c9ae5 --- /dev/null +++ b/results/classifier/105/mistranslation/1840648 @@ -0,0 +1,30 @@ +mistranslation: 0.860 +instruction: 0.754 +other: 0.749 +device: 0.617 +socket: 0.612 +semantic: 0.594 +graphic: 0.577 +network: 0.492 +vnc: 0.260 +boot: 0.255 +assembly: 0.136 +KVM: 0.084 + +qemu-4.1.0/roms/edk2/MdeModulePkg/Universal/Disk/UdfDxe/FileName.c:161: logical fault ? + +qemu-4.1.0/roms/edk2/MdeModulePkg/Universal/Disk/UdfDxe/FileName.c:161:71: warning: Logical disjunction always evaluates to true: EXPR != '\\' || EXPR != '\0'. [incorrectLogicOperator] + +Source code is + + if ((*(FileName - 1) != L'\\') && ((*(FileName + 2) != L'\\') || + (*(FileName + 2) != L'\0'))) { + +Maybe better code: + + if ((*(FileName - 1) != L'\\') && ((*(FileName + 2) != L'\\') && + (*(FileName + 2) != L'\0'))) { + +This isn't QEMU code -- it's just the source for third-party ROMs that we ship with QEMU because we also ship the ROM binaries. Please report it to the upstream project. + + diff --git a/results/classifier/105/mistranslation/1843852 b/results/classifier/105/mistranslation/1843852 new file mode 100644 index 000000000..4bedeee4f --- /dev/null +++ b/results/classifier/105/mistranslation/1843852 @@ -0,0 +1,89 @@ +mistranslation: 0.851 +other: 0.811 +device: 0.810 +socket: 0.809 +graphic: 0.790 +instruction: 0.785 +semantic: 0.780 +assembly: 0.747 +KVM: 0.732 +vnc: 0.717 +boot: 0.716 +network: 0.691 + +QEMU does not express a dependency on perl-Test-Harness + +This is a minor thing; in Fedora you can install most of the developer dependencies by issuing something like `dnf builddep qemu-kvm` and this takes care of just about everything such that you can run ./configure and make. + +For "make check" though, configure doesn't catch that you'll need perl-Test-Harness; so it fails halfway through the check routine, and you'll see this: + +``` +Can't locate TAP/Parser.pm in @INC (you may need to install the TAP::Parser module) (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5) at ./scripts/tap-driver.pl line 30. +BEGIN failed--compilation aborted at ./scripts/tap-driver.pl line 30. +make: *** [/home/jhuston/src/qemu/tests/Makefile.include:905: check-unit] Error 2 +``` + +I'm not sure how we should express this dependency; it shouldn't be a requirement for building, but it IS a dependency for testing. We probably ought not let users skip the qapi tests just because they don't have the perl requirement met. + +(And, separately, the Fedora package should list this as a builddep, but that's not an issue for here.) + +Given we require python perhaps the simplest solution would be to re-write the tap-driver as a python script rather than adding another configure check? + + + +On 9/13/19 4:33 AM, Alex Bennée wrote: +> Given we require python perhaps the simplest solution would be to re- +> write the tap-driver as a python script rather than adding another +> configure check? +> + +Seems a shame to need to after Paolo *just* introduced this perl script +late last year in 9df43317b82; it looks well-written as far as perl goes. + +I think in this case it's less work to just express the dependency. + + + + +On 9/13/19 11:06 AM, Paolo Bonzini wrote: +> On 13/09/19 16:56, John Snow wrote: +>> +>> +>> On 9/13/19 4:33 AM, Alex Bennée wrote: +>>> Given we require python perhaps the simplest solution would be to re- +>>> write the tap-driver as a python script rather than adding another +>>> configure check? +>> +>> Seems a shame to need to after Paolo *just* introduced this perl script +>> late last year in 9df43317b82; it looks well-written as far as perl goes. +> +> Also because I didn't write it most of it (rather, it comes from +> Automake). The new dependency was even documented in the release notes: +> +> Running the QEMU testsuite now requires the Perl Test::Harness module. +> Most Linux and BSD distributions however install it by default +> together with Perl. +> + +Yeah, let's just add a warning(?) to the configure check that you'll be +unable to run `make check` if you're missing this dependency. Easier +than re-writing. + +--js + + +The QEMU project is currently considering to move 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/105/mistranslation/1847861 b/results/classifier/105/mistranslation/1847861 new file mode 100644 index 000000000..a3667050c --- /dev/null +++ b/results/classifier/105/mistranslation/1847861 @@ -0,0 +1,69 @@ +mistranslation: 0.833 +other: 0.824 +KVM: 0.809 +graphic: 0.802 +vnc: 0.800 +instruction: 0.766 +boot: 0.753 +semantic: 0.749 +assembly: 0.737 +device: 0.725 +socket: 0.722 +network: 0.719 + +Guest stuttering under high disk IO (virtio) + +Performing io intensive tasks on virtualized Windows causes the system to visually stutter. I can often reproduce the problem by running fio on windows: + +fio --randrepeat=1 --ioengine=windowsaio --direct=1 --gtod_reduce=1 --name=test --filename=\\.\PhysicalDrive0 --bs=4k --iodepth=128 --size=4G --readwrite=randread + +While the fio command is running, moving the mouse pointer will be be laggy. The stuttering does not appear with iodepth <= 32 . The stuttering also manifests while playing games, the music and video pauses for a fraction of second in a playable but disturbing way. + +Here are my system specs: + +Host OS: archlinux +Guest OS: Windows 10 Enterprise +qemu version: qemu-git 8:v4.1.0.r1378.g98b2e3c9ab-1 (from AUR, compiled with -march=native) +CPU: AMD Ryzen Threadripper 1900X 8-Core Processor +Huge Pages: vm.nr_hugepages=4128 +Disk: nvme type=raw, io=threads bus=virtio +GPU (passthrough): Radeon RX 570 + +Here are some fio test results on my windows guest: + +[size=512M,iodepth=1 -> min=30k,avg=31k,stddev=508] +[size=2G,iodepth=8 -> min=203k,avg=207k,stddev=2.3k] +[size=2G,iodepth=16 -> min=320k,avg=330k,stddev=4.3k] +[size=4G,iodepth=32 -> min=300k,avg=310k,stddev=4.8k] +[size=4G,iodepth=64 -> min=278k,avg=366k,stddev=68.6k] -> STUTTER +[size=4G,iodepth=64 -> min=358k,avg=428k,stddev=52.6k] -> STUTTER +[size=4G,iodepth=128 -> min=92k,avg=217k,stddev=185k] -> STUTTER +[size=4G,iodepth=128 -> min=241k,avg=257k,stddev=14k] -> same config as above, but no stuttering + +The min and avg values are the bandwidth values reported in KB/s by fio. You can see that, when the stuttering occurs, the stardard deviation is high and the minimum bandwidth is way below the average. + +You can find my libvirt XML attached. Here is the full qemu command (taken from the ps output): + +/usr/bin/qemu-system-x86_64 -name guest=win10,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-7-win10/master-key.aes -machine pc-q35-3.1,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu host,topoext=on,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff -drive file=/usr/share/ovmf/x64/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on -drive file=/var/lib/libvirt/qemu/nvram/win10_VARS.fd,if=pflash,format=raw,unit=1 -m 8192 -overcommit mem-lock=off -smp 16,sockets=1,cores=8,threads=2 -object iothread,id=iothread1 -mem-prealloc -mem-path /dev/hugepages/libvirt/qemu/7-win10 -numa node,nodeid=0,cpus=0-7,mem=4096 -numa node,nodeid=1,cpus=8-15,mem=4096 -uuid d1c03f35-3846-4b76-a139-b798b497b95c -display none -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=34,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 strict=on -device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2 -device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 -device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 -device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 -device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4 -device pcie-root-port,port=0x15,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x5 -device pcie-root-port,port=0x16,chassis=7,id=pci.7,bus=pcie.0,addr=0x2.0x6 -device pcie-root-port,port=0x17,chassis=8,id=pci.8,bus=pcie.0,addr=0x2.0x7 -device pcie-root-port,port=0x18,chassis=9,id=pci.9,bus=pcie.0,multifunction=on,addr=0x3 -device pcie-root-port,port=0x19,chassis=10,id=pci.10,bus=pcie.0,addr=0x3.0x1 -device pcie-pci-bridge,id=pci.11,bus=pci.3,addr=0x0 -device qemu-xhci,p2=15,p3=15,id=usb,bus=pci.2,addr=0x0 -device lsi,id=scsi0,bus=pci.11,addr=0x1 -drive file=/dev/nvme0n1p3,format=raw,if=none,id=drive-virtio-disk0,cache=none,aio=threads -device virtio-blk-pci,scsi=off,bus=pci.8,addr=0x0,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on -drive if=none,id=drive-sata0-0-0,readonly=on -device ide-cd,bus=ide.0,drive=drive-sata0-0-0,id=sata0-0-0 -netdev tap,fd=37,id=hostnet0,vhost=on,vhostfd=38 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:7c:10:fc,bus=pci.1,addr=0x0 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -device vfio-pci,host=41:00.0,id=hostdev0,bus=pci.4,addr=0x0 -device vfio-pci,host=41:00.1,id=hostdev1,bus=pci.5,addr=0x0 -device virtio-balloon-pci,id=balloon0,bus=pci.6,addr=0x0 -object input-linux,id=mouse1,evdev=/dev/input/by-path/pci-0000:42:00.3-usb-0:3:1.0-event-mouse -object input-linux,id=kbd1,evdev=/dev/input/by-path/pci-0000:42:00.3-usb-0:4:1.0-event-kbd,grab_all=on,repeat=on -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on + +Additional note: the performance of fio in the linux host is about 2x the one on the guest: + +fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=/dev/nvme0n1 --bs=4k --iodepth=64 --size=512M --readwrite=randread + +read: IOPS=279k, BW=1092MiB/s (1145MB/s)(512MiB/469msec) + +The QEMU project is currently considering to move 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/105/mistranslation/1848556 b/results/classifier/105/mistranslation/1848556 new file mode 100644 index 000000000..c60df7122 --- /dev/null +++ b/results/classifier/105/mistranslation/1848556 @@ -0,0 +1,238 @@ +mistranslation: 0.549 +semantic: 0.373 +graphic: 0.341 +device: 0.301 +assembly: 0.261 +instruction: 0.243 +other: 0.194 +network: 0.181 +boot: 0.163 +vnc: 0.150 +KVM: 0.135 +socket: 0.126 + +qemu-img check failing on remote image in Eoan + +The "qemu-img check" function is failing on remote (HTTP-hosted) images, beginning with Ubuntu 19.10 (qemu-utils version 1:4.0+dfsg-0ubuntu9). With previous versions, through Ubuntu 19.04/qemu-utils version 1:3.1+dfsg-2ubuntu3.5, the following worked: + +$ /usr/bin/qemu-img check http://10.193.37.117/cloud/eoan-server-cloudimg-amd64.img +No errors were found on the image. +19778/36032 = 54.89% allocated, 90.34% fragmented, 89.90% compressed clusters +Image end offset: 514064384 + +The 10.193.37.117 server holds an Apache server that hosts the cloud images on a LAN. Beginning with Ubuntu 19.10/qemu-utils 1:4.0+dfsg-0ubuntu9, the same command never returns. (I've left it for up to an hour with no change.) I'm able to wget the image from the same server and installation on which qemu-img check fails. I've tried several .img files on the server, ranging from Bionic to Eoan, with the same results with all of them. + +Oh, there's no problem checking the file once it's on the local filesystem: + +$ wget http://10.193.37.117/cloud/bionic-server-cloudimg-amd64.img +--2019-10-17 17:51:33-- http://10.193.37.117/cloud/bionic-server-cloudimg-amd64.img +Connecting to 10.193.37.117:80... connected. +HTTP request sent, awaiting response... 200 OK +Length: 344195072 (328M) +Saving to: ‘bionic-server-cloudimg-amd64.img’ + +bionic-server-cloud 100%[===================>] 328.25M 105MB/s in 3.1s + +2019-10-17 17:51:37 (105 MB/s) - ‘bionic-server-cloudimg-amd64.img’ saved [344195072/344195072] + +$ qemu-img check bionic-server-cloudimg-amd64.img +No errors were found on the image. +16651/36032 = 46.21% allocated, 98.92% fragmented, 98.49% compressed clusters +Image end offset: 344195072 + +Hi Rod, +I did try to recreate with the qemu version that you have. + +$ apt install apache2 qemu-system-x86 +$ qemu-img create -f qcow2 /var/www/html/test.img 1G +# local +$ qemu-img check test.img +No errors were found on the image. +# remote +$ qemu-img check http://localhost:80/test.img +No errors were found on the image. +Image end offset: 262144 + +Local check and remote check both work just fine. + +I recognized the image that you have there and then did: +$ cd /var/www/html/ +$ wget https://cloud-images.ubuntu.com/bionic/current/bionic-server-cloudimg-amd64.img +# local +$ qemu-img check bionic-server-cloudimg-amd64.img +No errors were found on the image. +16651/36032 = 46.21% allocated, 98.92% fragmented, 98.49% compressed clusters +Image end offset: 344195072 +# remote +$ qemu-img check http://localhost:80/bionic-server-cloudimg-amd64.img +<hangs> + +Therefore I can confirm the behavior you described. + + + +The stuck poll is at: +#0 0x00007fafb935ad26 in __GI_ppoll (fds=0x560dba615670, nfds=1, timeout=<optimized out>, timeout@entry=0x0, sigmask=sigmask@entry=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:39 +#1 0x0000560db89550b9 in ppoll (__ss=0x0, __timeout=0x0, __nfds=<optimized out>, __fds=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/poll2.h:77 +#2 qemu_poll_ns (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>) at ./util/qemu-timer.c:322 +#3 0x0000560db89570eb in aio_poll (ctx=ctx@entry=0x560dba5e83b0, blocking=blocking@entry=true) at ./util/aio-posix.c:666 +#4 0x0000560db888c21d in bdrv_check (bs=<optimized out>, res=<optimized out>, fix=<optimized out>) at ./block.c:4149 +#5 0x0000560db887e6ab in collect_image_check (bs=0x560dba5ed680, check=0x560dba6143d0, filename=0x7ffe3d7c48d7 "http://localhost:80/bionic-server-cloudimg-amd64.img", fix=<optimized out>, + fmt=<optimized out>) at ./qemu-img.c:615 +#6 0x0000560db88825e1 in img_check (argc=<optimized out>, argv=<optimized out>) at ./qemu-img.c:774 +#7 0x0000560db887bd2e in main (argc=2, argv=<optimized out>) at ./qemu-img.c:4987 + +And from strace we know that the FD is from +260 [pid 20469] 0.000067 eventfd2(0, EFD_CLOEXEC|EFD_NONBLOCK) = 8 <0.000041> + + +Quick checks: +- does not depend on the exact image, e.g. https://cloud-images.ubuntu.com/eoan/current/eoan-server-cloudimg-amd64.img or https://download.fedoraproject.org/pub/fedora/linux/releases/30/Cloud/x86_64/images/Fedora-Cloud-Base-30-1.2.x86_64.qcow2 hang as well +- the former qemu 3.1 based qemu-utils work fine + +Maybe that helps to identify a known patch that might already exist. +Even it if doesn't the simple repro in comment #2 should still help. + +If there is no immediate idea out of the data we have let me know, this seems bisectable to me. + +Since it seemed so easy, while bisecting I found that it hangs with v4.0.0 and v3.1.0 from git and even v3.0.0. + +Since the reported good version was 3.1 I began to wonder if I might have overlooked something. +I wondered if it might be e.g. the apache version providing a different behavior on http. + + +I was trying to access the same apache server with 4.0 and 3.1 and ran it against the download target: +$ qemu-img check https://download.fedoraproject.org/pub/fedora/linux/releases/30/Cloud/x86_64/images/Fedora-Cloud-Base-30-1.2.x86_64.qcow2 + +3.1 ran into a segfault and 4.0 seems to hang on that. +Maybe I should take a break and revisit that later, as people might have an idea already what this might be about. + +Hi, + +Could you try the qemu’s master branch? bfb23b480a49114315877aacf700b49453e0f9d9 has fixed an issue that sounds very much like this. The problem in that case is that libcurl 7.59.0 changed behavior, so bisecting qemu will not produce results. + +Max + +I tried qemu from git, but I get an "unknown protocol" error when I try to access an image via HTTP: + +$ ./qemu-img check http://10.193.37.117/cloud/eoan-server-cloudimg-amd64.img +qemu-img: Could not open 'http://10.193.37.117/cloud/eoan-server-cloudimg-amd64.img': Unknown protocol 'http' + +Is there a development library or ./configure option I need to use to add this support? I didn't see anything obvious in the ./configure output. + +Hi Max, +libcurl 7.65.3-1ubuntu3 and was >7.59 for several releases (more than a year at least) - so there must be something else going on that this triggers now. + +But never the less with the fix from [1] I can again get it to work successfully. + +I think I should backport that to our qemu 4.0 in Ubunutu. +It seems to apply fine (just offset -3, no fuzz) +The former seem not affected e.g. qemu 3.1 along libcurl 7.64.0-2ubuntu1 does not expose the behavior. + +@Max - As the Author, just to check, do you see any issue backporting that to qemu 4.0 + +[1]: https://git.qemu.org/?p=qemu.git;a=commit;h=bfb23b480a49114315877aacf700b49453e0f9d9 + +Hi Christian, + +I don’t see any issue but the fact that the whole series should be backported (0487861685294660b23bc146e1ebd5304aa8bbe0 through bfb23b480a49114315877aacf700b49453e0f9d9, maybe also c34dc07f9f01cf686, but that isn’t strictly necessary). + +Max + +Hi Rod, + +You don’t need to add anything, but maybe there’s some library missing. --enable-curl should force support and then tell you whether there’s something missing. + +Max + +@Rod: Your self built issue seems like at config/make time there were not all build deps available. I have put a test build in PPA [1], could you give that one a try on your end as well? + +[1]: https://launchpad.net/~paelzer/+archive/ubuntu/bug-1848556-qemu-img-curl-hang-eoan + +For me with the version from the PPA works fine on local as well as remote http connections. +Thanks @Max for the fix. + +@Rod: +Waiting for you to test and verify based on the PPA. + + +I managed to check the PPA version just now, and it's working fine. Thanks for the quick fix! + +Now that Focal is open I have opened proper Focal MP replacing the old one and also an Eoan SRU MP right away. +=> https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/374770 +=> https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/374771 + +FYI: uploaded to 20.04 Focal, considering SRUs (Eoan) after this completes + +This bug was fixed in the package qemu - 1:4.0+dfsg-0ubuntu10 + +--------------- +qemu (1:4.0+dfsg-0ubuntu10) focal; urgency=medium + + * d/p/ubuntu/lp-1848556-curl-Handle-success-in-multi_check_completion.patch: + fix a potential hang when qemu or qemu-img where accessing http backed + disks via libcurl (LP: #1848556) + * d/p/u/lp-1848497-virtio-balloon-fix-QEMU-4.0-config-size-migration-in.patch: + fix migration issue from qemu <4.0 when using virtio-balloon (LP: #1848497) + + -- Christian Ehrhardt <email address hidden> Mon, 21 Oct 2019 14:51:45 +0200 + +Focal is complete the MPs reviewed, SRU Teamplates ready and pre-tests done. +Uploading to E-unapproved for the SRU Teams consideration. + +This was tonight first accepted and then immediately rejected as it was surpassed by a security fix. + +=> Rebased and uploaded 1:4.0+dfsg-0ubuntu9.2 to eoan-unapproved again. + +Hello Rod, or anyone else affected, + +Accepted qemu into eoan-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:4.0+dfsg-0ubuntu9.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 and change the tag from verification-needed-eoan to verification-done-eoan. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-eoan. 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. + +All autopkgtests for the newly accepted qemu (1:4.0+dfsg-0ubuntu9.2) for eoan have finished running. +The following regressions have been reported in tests triggered by the package: + +ganeti/2.16.0-5ubuntu1 (ppc64el) + + +Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. + +https://people.canonical.com/~ubuntu-archive/proposed-migration/eoan/update_excuses.html#qemu + +[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions + +Thank you! + + +Eoan - without fix -> hang + +With fix: +qemu-img check http://10.193.37.117/cloud/eoan-server-cloudimg-amd64.img +No errors were found on the image. +19778/36032 = 54.89% allocated, 90.34% fragmented, 89.90% compressed clusters +Image end offset: 514064384 + +Setting verified + +This bug was fixed in the package qemu - 1:4.0+dfsg-0ubuntu9.2 + +--------------- +qemu (1:4.0+dfsg-0ubuntu9.2) eoan; urgency=medium + + * d/p/ubuntu/lp-1848556-curl-Handle-success-in-multi_check_completion.patch: + fix a potential hang when qemu or qemu-img where accessing http backed + disks via libcurl (LP: #1848556) + * d/p/u/lp-1848497-virtio-balloon-fix-QEMU-4.0-config-size-migration-in.patch: + fix migration issue from qemu <4.0 when using virtio-balloon (LP: #1848497) + + -- Christian Ehrhardt <email address hidden> Mon, 21 Oct 2019 14:51:45 +0200 + +The verification of the Stable Release Update for qemu 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. + diff --git a/results/classifier/105/mistranslation/1849234 b/results/classifier/105/mistranslation/1849234 new file mode 100644 index 000000000..2278185b0 --- /dev/null +++ b/results/classifier/105/mistranslation/1849234 @@ -0,0 +1,17 @@ +mistranslation: 0.910 +device: 0.818 +graphic: 0.698 +boot: 0.655 +other: 0.551 +semantic: 0.477 +network: 0.465 +instruction: 0.118 +vnc: 0.054 +socket: 0.050 +assembly: 0.031 +KVM: 0.002 + +Macos Catalina bug + +When I want to boot anything with qemu it just stops responding. + diff --git a/results/classifier/105/mistranslation/1851552 b/results/classifier/105/mistranslation/1851552 new file mode 100644 index 000000000..dd2546b8e --- /dev/null +++ b/results/classifier/105/mistranslation/1851552 @@ -0,0 +1,332 @@ +mistranslation: 0.380 +graphic: 0.306 +network: 0.297 +instruction: 0.296 +other: 0.291 +boot: 0.284 +assembly: 0.277 +semantic: 0.268 +device: 0.255 +socket: 0.194 +vnc: 0.188 +KVM: 0.170 + +since ubuntu 18 bionic release and latest, the ubuntu18 cloud image is unable to boot up on openstack instance + +Openstack Queens release which is running on ubuntu 18 LTS Controller and Compute. +Tried to boot up the instance via horizon dashboard without success. +Nova flow works perfect. +When access to console I discovered that the boot process stuck in the middle. +[[0;1;31m TIME [0m] Timed out waiting for device dev-vdb.device. +[[0;1;33mDEPEND[0m] Dependency failed for /mnt. +[[0;1;33mDEPEND[0m] Dependency failed for File System Check on /dev/vdb. +It receives IP but looks like not get configured at time. +since ubuntu 18 there is netplan feature managing the network interfaces +please advise. + +more details as follow: +https://bugs.launchpad.net/networking-calico/+bug/1851548 + +Hello, + +Could you please elaborate a bit more on how you came to the conclusion that the problem is caused specifically by cloud-init? Without some more context information it's difficult for us to tell if this is actually a bug and to begin working on it. + +If you think this is actually a problem with cloud-init, could you please run `cloud-init collect-logs` and attach the generated tarball to this bug report? The collected logs will help us understand what's going on. + +I'm marking this report as Incomplete for the moment, please change its status back to New after providing additional information. Thanks! + +The instance creation was working until calico configured on controller and compute. Ubuntu 16 and Centos releases are booting up successfully. As known ubuntu began to work with netplan since 18 and all latest releases. Not sure the issue with cloud init or the order or timing of booting process which relates to getting IP in time and properly. + + +the problem is in: + +[[0;32m OK [0m] Started Wait for Network to be Configured. + + +I used the following official latest ubuntu bionic image: +http://cloud-images.ubuntu.com/bionic/current/bionic-server-cloudimg-amd64.img + +And the regular openstack command: +https://docs.openstack.org/mitaka/install-guide-ubuntu/launch-instance-provider.html + +openstack server create --flavor ubuntu-flavor --image ubuntu-bionic-latest \ + --nic net-id=c9d82a5d-e075-4d66-8ecd-1092fa218ad7 --security-group allow_all \ + --key-name cloud-keypair.private ubuntu-bionic-instance + +more details as follow: +https://bugs.launchpad.net/networking-calico/+bug/1851548 + +see full log https://etherpad.openstack.org/p/ubuntu-xenial-log for successful creation of instance with latest ubuntu-xenial cloud image http://cloud-images.ubuntu.com/bionic/current/bionic-server-cloudimg-amd64.img + +see full log https://etherpad.openstack.org/p/ubuntu-bionic-log for successful creation of instance with latest ubuntu-bionic cloud image http://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-disk1.img + +correction: + +see full log https://etherpad.openstack.org/p/ubuntu-xenial-log for successful creation of instance with latest ubuntu-xenial cloud image http://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-disk1.img + +see full log https://etherpad.openstack.org/p/ubuntu-bionic-log for NOT SUCCESSFUL creation of instance with latest ubuntu-bionic cloud image http://cloud-images.ubuntu.com/bionic/current/bionic-server-cloudimg-amd64.img + +Hi. +Please attach the output of 'cloud-init collect-logs'. Ideally from the 18.04 instance, but the 16.04 instance would be fine if you're not able to get it from 18.04. + +Then, set the status of this bug back to New. + +thanks. + + +see attached collected cloud init logs from ubuntu xenial.. + + +Hi Vasili, unfortunately there isn't enough info in the 16.04 logs to help us work out what's going on with 18.04. Do you have any way of accessing an 18.04 instance (serial console, perhaps?) that would allow you to gather more data? + +Moving this back to Incomplete for now, apologies for the round trips! + +> [[0;1;33mDEPEND[0m] Dependency failed for File System Check on /dev/vdb. + +Looking at the bionic log you posted, it never gets a /dev/vdb device. Can you confirm that the VM configuration on the compute node correctly was configured with an ephemeral block device? + + +Here we can see not all of the block devices expected are present... + +[[0;32m OK [0m] Started udev Coldplug all Devices. +[[0m[0;31m* [0m] (1 of 3) A start job is running for���label-UEFI.device (19s / 1min 30s)[K[[0;1;31m*[0m[0;31m* + + +Also, looking at the 16.04 boot, it looks like this is nested virtualization, I can see in the journal that the xenial kernel is hitting this one: + +Nov 24 16:18:43.138019 ubuntu kernel: ------------[ cut here ]------------ +Nov 24 16:18:43.138390 ubuntu kernel: WARNING: CPU: 0 PID: 0 at /build/linux-mU1Buo/linux-4.4.0/arch/x86/kernel/fpu/xstate.c:517 fpu__init_system_xstate+0x37e/0x764() +Nov 24 16:18:43.138624 ubuntu kernel: XSAVE consistency problem, dumping leaves +Nov 24 16:18:43.147521 ubuntu kernel: Modules linked in: +Nov 24 16:18:43.147832 ubuntu kernel: +Nov 24 16:18:43.148048 ubuntu kernel: CPU: 0 PID: 0 Comm: swapper Not tainted 4.4.0-169-generic #198-Ubuntu +Nov 24 16:18:43.148268 ubuntu kernel: 0000000000000086 a2c4204db3cb6ecb ffffffff81e03d80 ffffffff8140c8e1 +Nov 24 16:18:43.148582 ubuntu kernel: ffffffff81e03dc8 ffffffff81cb3c68 ffffffff81e03db8 ffffffff81086492 +Nov 24 16:18:43.148788 ubuntu kernel: 0000000000000008 0000000000000440 0000000000000040 ffffffff81e03e4c +Nov 24 16:18:43.149274 ubuntu kernel: Call Trace: +Nov 24 16:18:43.149480 ubuntu kernel: [<ffffffff8140c8e1>] dump_stack+0x63/0x82 +Nov 24 16:18:43.149687 ubuntu kernel: [<ffffffff81086492>] warn_slowpath_common+0x82/0xc0 +Nov 24 16:18:43.149892 ubuntu kernel: [<ffffffff8108652c>] warn_slowpath_fmt+0x5c/0x80 +Nov 24 16:18:43.150100 ubuntu kernel: [<ffffffff81081f86>] ? xfeature_size+0x59/0x77 +Nov 24 16:18:43.150343 ubuntu kernel: [<ffffffff81f783f1>] fpu__init_system_xstate+0x37e/0x764 +Nov 24 16:18:43.150549 ubuntu kernel: [<ffffffff81f68120>] ? early_idt_handler_array+0x120/0x120 +Nov 24 16:18:43.150756 ubuntu kernel: [<ffffffff81f77dfa>] fpu__init_system+0x1e7/0x28e +Nov 24 16:18:43.159459 ubuntu kernel: [<ffffffff81f790a6>] early_cpu_init+0x2b6/0x2bb +Nov 24 16:18:43.159715 ubuntu kernel: [<ffffffff81f790a6>] ? early_cpu_init+0x2b6/0x2bb +Nov 24 16:18:43.160030 ubuntu kernel: [<ffffffff81f7439d>] setup_arch+0xc0/0xd1f +Nov 24 16:18:43.160240 ubuntu kernel: [<ffffffff81f68120>] ? early_idt_handler_array+0x120/0x120 +Nov 24 16:18:43.160528 ubuntu kernel: [<ffffffff81f68c16>] start_kernel+0xe2/0x4a4 +Nov 24 16:18:43.160737 ubuntu kernel: [<ffffffff81f68120>] ? early_idt_handler_array+0x120/0x120 +Nov 24 16:18:43.160926 ubuntu kernel: [<ffffffff81f682da>] x86_64_start_reservations+0x2a/0x2c +Nov 24 16:18:43.161133 ubuntu kernel: [<ffffffff81f68426>] x86_64_start_kernel+0x14a/0x16d +Nov 24 16:18:43.161624 ubuntu kernel: ---[ end trace 4d5ff9f2f68c4233 ]--- + + +https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1829555 + + + + +Hi, +Thanks for shared investigation details. +According to the setup I use, could you assist to understand where and what I'm missing here that can lead to the issues you mentioned? + +### Working setup details ### + +[1] The Openstack service installed on Controller and Compute with Ubuntu 18.04.2 +With Minimal deployment for Queens: + +Keystone +Glance +Nova +Neutron +Horizon + +Reference: +https://docs.openstack.org/install-guide/openstack-services.html#minimal-deployment-for-queens + +All the configurations done according to the guide (reference I mentioned). + +[2] The add-ons features included to Openstack are: + +Calico driver plugin for Neutron +Calico Bird for BGP Peering +Calico Felix for Security +Calico DHCP Agent instead Neutron DHCP + +Reference: +https://docs.projectcalico.org/v3.10/getting-started/openstack/ + + + +Thanks, +Vasili + +Status changed to 'Confirmed' because the bug affects multiple users. + +Status changed to 'Confirmed' because the bug affects multiple users. + +For your Openstack deployment, are you running on baremetal? +Are you deploying something like devstack or triple-o which enable nested virtualization? + +https://docs.openstack.org/devstack/latest/guides/devstack-with-nested-kvm.html +https://docs.openstack.org/tripleo-quickstart/latest/unprivileged.html +https://tripleo-docs.readthedocs.io/en/latest/environments/virtual.html + +nope, no devstack nor tripleo.. everything straight forward as I mentioned previously.. installed all those services manually on controller and compute and connected to l3 switch with bgp of the bird.. + +mariadb, rabbitmq, memcached, etcd, keystone, glance, neutron, nova, calico-driver, calico-felix, calico-dhcp, nova-api-metadata, bird + +any clue on the issue? + +Thanks, +Vasili + +Unfortunately no; the kernel messages are very much related to nested virtualization, but I don't know where in your software stack it gets configured/enabled. + +I'm marking the cloud-init task invalid as at this time the logs point to a nested virtualization/openstack issue with devices not being present; not related to cloud-init. If further investigation points to an issue with cloud-init you can move the cloud-init task back to New. + +There is no nested virtualization, all the openstack on bare metal with regular installation with regular services, the only thing is running is calico which is eliminate neutron ml2, metadata and dhcp and its running with calico plugin, calico-dhcp and calico felix. As well as on each compute nova-api-metadata is available. + +How the devices can be presented, could you advise with further steps of investigation? + + +Best, +Vasili + + +Sent from iPhone + +> On 9 Jan 2020, at 2:31, Ryan Harper <email address hidden> wrote: +> +> I'm marking the cloud-init task invalid as at this time the logs point +> to a nested virtualization/openstack issue with devices not being +> present; not related to cloud-init. If further investigation points to +> an issue with cloud-init you can move the cloud-init task back to New. +> +> ** Changed in: cloud-init (Ubuntu) +> Status: Incomplete => Invalid +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1851552 +> +> Title: +> since ubuntu 18 bionic release and latest, the ubuntu18 cloud image is +> unable to boot up on openstack instance +> +> Status in cloud-init: +> New +> Status in networking-calico: +> New +> Status in OpenStack Compute (nova): +> New +> Status in OpenStack Community Project: +> New +> Status in qemu-kvm: +> New +> Status in cloud-init package in Ubuntu: +> Invalid +> Status in qemu package in Ubuntu: +> New +> +> Bug description: +> Openstack Queens release which is running on ubuntu 18 LTS Controller and Compute. +> Tried to boot up the instance via horizon dashboard without success. +> Nova flow works perfect. +> When access to console I discovered that the boot process stuck in the middle. +> [[0;1;31m TIME [0m] Timed out waiting for device dev-vdb.device. +> [[0;1;33mDEPEND[0m] Dependency failed for /mnt. +> [[0;1;33mDEPEND[0m] Dependency failed for File System Check on /dev/vdb. +> It receives IP but looks like not get configured at time. +> since ubuntu 18 there is netplan feature managing the network interfaces +> please advise. +> +> more details as follow: +> https://bugs.launchpad.net/networking-calico/+bug/1851548 +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/cloud-init/+bug/1851552/+subscriptions + + +Hi Vasili, + +From a cloud-init perspective, there isn't anything we can do so I'm going to move the upstream task to Invalid too. I'm afraid I don't really have any advice on how to proceed, as this appears to be a hypervisor or cloud issue. + + +Dan + +In Rocky release I’m not experiencing kind of issues. And make sure you use kvm and not qemu, cause qemu is limited on its performance and kvm just born to work with latest hardware :) + +Best, +Vasili + +Sent from iPhone + +> On 14 Jan 2020, at 20:35, Dan Watkins <email address hidden> wrote: +> +> Hi Vasili, +> +>> From a cloud-init perspective, there isn't anything we can do so I'm +> going to move the upstream task to Invalid too. I'm afraid I don't +> really have any advice on how to proceed, as this appears to be a +> hypervisor or cloud issue. +> +> +> Dan +> +> ** Changed in: cloud-init +> Status: New => Invalid +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1851552 +> +> Title: +> since ubuntu 18 bionic release and latest, the ubuntu18 cloud image is +> unable to boot up on openstack instance +> +> Status in cloud-init: +> Invalid +> Status in networking-calico: +> New +> Status in OpenStack Compute (nova): +> New +> Status in OpenStack Community Project: +> New +> Status in qemu-kvm: +> New +> Status in cloud-init package in Ubuntu: +> Invalid +> Status in qemu package in Ubuntu: +> New +> +> Bug description: +> Openstack Queens release which is running on ubuntu 18 LTS Controller and Compute. +> Tried to boot up the instance via horizon dashboard without success. +> Nova flow works perfect. +> When access to console I discovered that the boot process stuck in the middle. +> [[0;1;31m TIME [0m] Timed out waiting for device dev-vdb.device. +> [[0;1;33mDEPEND[0m] Dependency failed for /mnt. +> [[0;1;33mDEPEND[0m] Dependency failed for File System Check on /dev/vdb. +> It receives IP but looks like not get configured at time. +> since ubuntu 18 there is netplan feature managing the network interfaces +> please advise. +> +> more details as follow: +> https://bugs.launchpad.net/networking-calico/+bug/1851548 +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/cloud-init/+bug/1851552/+subscriptions + + +I honestly don't see any evidence of some broken behaviour in Nova if, particularly, other instances with other guest image using cloud-init can boot correctly. + +Please provide us some logs or better trace of a potential Nova problem in order for us to classify the potential root cause and a possible solution, but in the meantime I'll have to close this bug from the Nova point of view. You can reopen this bug by changing its status to New. + +I don't believe this is to do with networking-calico, so will mark as Invalid for networking-calico. + +Tracked in Github Issues as https://github.com/canonical/cloud-init/issues/3491 + diff --git a/results/classifier/105/mistranslation/1853083 b/results/classifier/105/mistranslation/1853083 new file mode 100644 index 000000000..cbb22102a --- /dev/null +++ b/results/classifier/105/mistranslation/1853083 @@ -0,0 +1,165 @@ +mistranslation: 0.827 +semantic: 0.818 +other: 0.815 +graphic: 0.810 +device: 0.777 +boot: 0.748 +instruction: 0.742 +network: 0.737 +assembly: 0.705 +vnc: 0.700 +socket: 0.670 +KVM: 0.426 + +qemu ppc64 4.0 boot AIX5.1 hung + +When boot AIX5.1 from cdrom device, qemu hung there, no further info is displayed and cpu consumption is high. + +Did this ever worked? + +No, this happened when I tried to install the AIX5.1 on qemu ppc64. + +No, I don't think that these old AIX versions ever worked in QEMU. You might be more or less lucky with later versions, though, see e.g.: + + https://bugs.launchpad.net/qemu/+bug/1829682 + +Anyway, when reporting bugs, please always provide the command line that you used to start QEMU, otherwise bugs are hardly reproducible. + +What I don't understand is ppc64 for IBM machine emulation, but qemu ppc64 can't support AIX most of the time, but can support Linux on power very well. + +I'm running this to start the AIX5.1 installation on qemu: +#!/bin/bash +qemu-system-ppc64 -cpu POWER8 -machine pseries -m 2048 -serial mon:stdio -hda aix-hdd.qcow2 -cdrom /Download/AIX5.1/VOLUME1.iso -prom-env boot-command='boot cdrom: -s verbose' + + +and it got: +[root@192 emu]# ./aix51 +VNC server running on ::1:5900 +qemu-system-ppc64: warning: TCG doesn't support requested feature, cap-cfpc=workaround +qemu-system-ppc64: warning: TCG doesn't support requested feature, cap-sbbc=workaround +qemu-system-ppc64: warning: TCG doesn't support requested feature, cap-ibs=workaround + + +SLOF ********************************************************************** +QEMU Starting + Build Date = Jul 3 2019 12:26:14 + FW Version = git-ba1ab360eebe6338 + Press "s" to enter Open Firmware. + +Populating /vdevice methods +Populating /vdevice/vty@71000000 +Populating /vdevice/nvram@71000001 +Populating /vdevice/l-lan@71000002 +Populating /vdevice/v-scsi@71000003 + SCSI: Looking for devices + 8000000000000000 DISK : "QEMU QEMU HARDDISK 2.5+" + 8200000000000000 CD-ROM : "QEMU QEMU CD-ROM 2.5+" +Populating /pci@800000020000000 + 00 0000 (D) : 1234 1111 qemu vga + 00 0800 (D) : 1033 0194 serial bus [ usb-xhci ] +Installing QEMU fb + + + +Scanning USB + XHCI: Initializing + USB Keyboard + USB mouse +No console specified using screen & keyboard + + Welcome to Open Firmware + + Copyright (c) 2004, 2017 IBM Corporation All rights reserved. + This program and the accompanying materials are made available + under the terms of the BSD License available at + http://www.opensource.org/licenses/bsd-license.php + + +Trying to load: -s verbose from: /vdevice/v-scsi@71000003/disk@8200000000000000: ... + +and just hung there, took lots of CPU time, never proceed further. + + +AIX 5.1 is quite a bit older than POWER8, so I don't think that it will run with this processor anymore. You could try "power5" or "970fx" as CPU (maybe even the "40p" machine instead of "pseries"), but I guess it won't make a big difference - the QEMU pseries machine has been written for later operating systems in mind, there was never a big effort to get older operating systems running with it. + +Tried POWER5, but got +[root@192 emu]# ./aix51 +qemu-system-ppc64: unable to find CPU model 'POWER5' + + +[root@192 emu]# qemu-system-ppc64 --version +QEMU emulator version 4.1.0 +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers +[root@192 emu]# + + +With +qemu-system-ppc64 -cpu power5+ -machine pseries -m 2048 -serial mon:stdio -hda aix-hdd.qcow2 -cdrom /Download/AIX5.1/VOLUME1.iso -prom-env boot-command='boot cdrom: -s verbose' + +got: +VNC server running on ::1:5900 + + +SLOF ********************************************************************** +QEMU Starting + Build Date = Jul 3 2019 12:26:14 + FW Version = git-ba1ab360eebe6338 + Press "s" to enter Open Firmware. + +Populating /vdevice methods +Populating /vdevice/vty@71000000 +Populating /vdevice/nvram@71000001 +Populating /vdevice/l-lan@71000002 +Populating /vdevice/v-scsi@71000003 + SCSI: Looking for devices + 8000000000000000 DISK : "QEMU QEMU HARDDISK 2.5+" + 8200000000000000 CD-ROM : "QEMU QEMU CD-ROM 2.5+" +Populating /pci@800000020000000 + 00 0000 (D) : 1234 1111 qemu vga + 00 0800 (D) : 1033 0194 serial bus [ usb-xhci ] +Installing QEMU fb + + + +Scanning USB + XHCI: Initializing + + +( 700 ) Program Exception [ fff ] + + + R0 .. R7 R8 .. R15 R16 .. R23 R24 .. R31 +000000007dbf36f4 000000007e4594a8 0000000000000000 000000007dc06400 +000000007e669dc0 0000000000000100 0000000000000000 000000007dc0ae70 +000000007dc10700 000000007e45c000 000000007e466010 000000007e459488 +000000007e45c000 000000007dc50700 000000007dc0b040 0000200081021000 +0000000000000000 000000007e436000 0000000000008000 0000200081020040 +0000000000000fff 0000000000000000 000000000000f003 0000200081020070 +000000007e466008 0000000000000000 0000000000000006 0000000000000002 +0000000001180000 0000000000000000 000000007e66a050 000000007e459488 + + CR / XER LR / CTR SRR0 / SRR1 DAR / DSISR + 80000408 000000007dbf3650 000000007dbf366c 0000000000000000 +0000000000000000 0000000000000000 8000000000080000 00000000 + + +1 > + +Answering comment #4: +> What I don't understand is ppc64 for IBM machine emulation, but qemu ppc64 +> can't support AIX most of the time, but can support Linux on power very well. + +QEMU doesn't implement the full PAPR specification. Historically we've only +added the bits that are essential for a Linux guest to be happy. + +AIX 5.1 is fairly old and neither IBM, nor the QEMU community invested time +and effort in getting it to work under QEMU. AIX being a closed source OS +certainly didn't help things to go forward. + +Things have changed recently though. IBM added virtio drivers and some +workarounds to AIX, as well some fixes to QEMU. Latest AIX 7.2 releases +should now be able to run under QEMU with a POWER8 or newer CPU model. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1859713 b/results/classifier/105/mistranslation/1859713 new file mode 100644 index 000000000..b6afcbe3e --- /dev/null +++ b/results/classifier/105/mistranslation/1859713 @@ -0,0 +1,70 @@ +mistranslation: 0.936 +instruction: 0.866 +graphic: 0.786 +device: 0.777 +socket: 0.702 +semantic: 0.698 +other: 0.660 +assembly: 0.600 +network: 0.552 +KVM: 0.504 +boot: 0.480 +vnc: 0.336 + +ARM v8.3a pauth not working + +Host: Ubuntu 19.10 - x86_64 machine +QEMU version: 3a63b24a1bbf166e6f455fe43a6bbd8dea413d92 (master) + +ARMV8.3 pauth is not working well. + +With a test code containing two pauth instructions: + - paciasp that sign LR with A key and sp as context; + - autiasp that verify the signature. + +Test: + - Run the program and corrupt LR just before autiasp (ex 0x3e00000400660 instead of 0x3e000000400664) + +Expected: + - autiasp places an invalid pointer in LR + +Result: + - autiasp successfully auth the pointer and places 0x0400660 in LR. + +Further explanations: + Adding traces in qemu code shows that "pauth_computepac" is not robust enough against truncating. + With 0x31000000400664 as input of pauth_auth, we obtain "0x55b1d65b2c138e14" for PAC, "0x30" for bot_bit and "0x38" for top_bit. + With 0x310040008743ec as input of pauth (with same key), we obtain "0x55b1d65b2c138ef4" for PAC, "0x30" for bot_bit and "0x38" for top_bit. + Values of top_bit and bottom_bit are strictly the same and it should not. + +Hi, + +Here is a patch for this bug. The sbox function was using "b+=16" instead of "b+=4". + +Also, you check test vector using : + +```c + uint64_t P = 0xfb623599da6e8127ull; + uint64_t T = 0x477d469dec0b8762ull; + uint64_t w0 = 0x84be85ce9804e94bull; + uint64_t k0 = 0xec2802d4e0a488e9ull; + ARMPACKey key = { .hi = w0, .lo = k0 }; + uint64_t C5 = pauth_computepac(P, T, key); + /* C5 should be 0xc003b93999b33765 */ +``` + +Ooof. Good catch on the sbox error. + +That said, how did you test pauth_computepac? +I still do not get the C5 result above, but 0x99d88f4472f3be39. + +The following test case sets up the parameters. + +Oops again. The test case has the parts of the key the wrong way around. +I'll submit the pair of patches to the mailing list. + +Now upstream as commit de0b1bae6461f67243282555475f88b2384a1eb9. + +Apparently this fixed bug is the official CVE-2020-10702: +https://security-tracker.debian.org/tracker/CVE-2020-10702 + diff --git a/results/classifier/105/mistranslation/1861404 b/results/classifier/105/mistranslation/1861404 new file mode 100644 index 000000000..f905e83ae --- /dev/null +++ b/results/classifier/105/mistranslation/1861404 @@ -0,0 +1,223 @@ +mistranslation: 0.825 +instruction: 0.821 +assembly: 0.797 +other: 0.797 +device: 0.782 +graphic: 0.773 +socket: 0.740 +network: 0.740 +semantic: 0.730 +KVM: 0.709 +boot: 0.708 +vnc: 0.697 + +AVX instruction VMOVDQU implementation error for YMM registers + +Hi, + +Tested with Qemu 4.2.0, and with git version bddff6f6787c916b0e9d63ef9e4d442114257739. + +The x86 AVX instruction VMOVDQU doesn't work properly with YMM registers (32 bytes). +It works with XMM registers (16 bytes) though. + +See the attached test case `ymm.c`: when copying from memory-to-ymm0 and then back from ymm0-to-memory using VMOVDQU, Qemu only copies the first 16 of the total 32 bytes. + +``` +user@ubuntu ~/Qemu % gcc -o ymm ymm.c -Wall -Wextra -Werror + +user@ubuntu ~/Qemu % ./ymm +00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F + +user@ubuntu ~/Qemu % ./x86_64-linux-user/qemu-x86_64 -cpu max ymm +00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +``` + +This seems to be because in `translate.c > gen_sse()`, the case handling the VMOVDQU instruction calls `gen_ldo_env_A0` which always performs a 16 bytes copy using two 8 bytes load and store operations (with `tcg_gen_qemu_ld_i64` and `tcg_gen_st_i64`). + +Instead, the `gen_ldo_env_A0` function should generate a copy with a size corresponding to the used register. + + +``` +static void gen_sse(CPUX86State *env, DisasContext *s, int b, + target_ulong pc_start, int rex_r) +{ + [...] + case 0x26f: /* movdqu xmm, ea */ + if (mod != 3) { + gen_lea_modrm(env, s, modrm); + gen_ldo_env_A0(s, offsetof(CPUX86State, xmm_regs[reg])); + } else { + [...] +``` + +``` +static inline void gen_ldo_env_A0(DisasContext *s, int offset) +{ + int mem_index = s->mem_index; + tcg_gen_qemu_ld_i64(s->tmp1_i64, s->A0, mem_index, MO_LEQ); + tcg_gen_st_i64(s->tmp1_i64, cpu_env, offset + offsetof(ZMMReg, ZMM_Q(0))); + tcg_gen_addi_tl(s->tmp0, s->A0, 8); + tcg_gen_qemu_ld_i64(s->tmp1_i64, s->tmp0, mem_index, MO_LEQ); + tcg_gen_st_i64(s->tmp1_i64, cpu_env, offset + offsetof(ZMMReg, ZMM_Q(1))); +} +``` + + + +Note: Qemu has been built with the following commands: +``` +% ./configure --target-list=x86_64-linux-user && make +OR +% ./configure --target-list=x86_64-linux-user --enable-avx2 && make +``` + +On Friday, January 31, 2020, Alex Bennée <email address hidden> wrote: + +> ** Tags added: tcg testcase +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1861404 +> +> Title: +> AVX instruction VMOVDQU implementation error for YMM registers +> +> +If I remember well, there is no support for AVX instructions in linux-user +mode. + +If that is true, how come handling of unsupported instruction went that far? + +Did you try other AVX instructions? + +Aleksandar + + + + +> Status in QEMU: +> New +> +> Bug description: +> Hi, +> +> Tested with Qemu 4.2.0, and with git version +> bddff6f6787c916b0e9d63ef9e4d442114257739. +> +> The x86 AVX instruction VMOVDQU doesn't work properly with YMM registers +> (32 bytes). +> It works with XMM registers (16 bytes) though. +> +> See the attached test case `ymm.c`: when copying from memory-to-ymm0 +> and then back from ymm0-to-memory using VMOVDQU, Qemu only copies the +> first 16 of the total 32 bytes. +> +> ``` +> user@ubuntu ~/Qemu % gcc -o ymm ymm.c -Wall -Wextra -Werror +> +> user@ubuntu ~/Qemu % ./ymm +> 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 +> 18 19 1A 1B 1C 1D 1E 1F +> +> user@ubuntu ~/Qemu % ./x86_64-linux-user/qemu-x86_64 -cpu max ymm +> 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00 00 00 00 00 00 00 00 +> 00 00 00 00 00 00 00 00 +> ``` +> +> This seems to be because in `translate.c > gen_sse()`, the case +> handling the VMOVDQU instruction calls `gen_ldo_env_A0` which always +> performs a 16 bytes copy using two 8 bytes load and store operations +> (with `tcg_gen_qemu_ld_i64` and `tcg_gen_st_i64`). +> +> Instead, the `gen_ldo_env_A0` function should generate a copy with a +> size corresponding to the used register. +> +> +> ``` +> static void gen_sse(CPUX86State *env, DisasContext *s, int b, +> target_ulong pc_start, int rex_r) +> { +> [...] +> case 0x26f: /* movdqu xmm, ea */ +> if (mod != 3) { +> gen_lea_modrm(env, s, modrm); +> gen_ldo_env_A0(s, offsetof(CPUX86State, xmm_regs[reg])); +> } else { +> [...] +> ``` +> +> ``` +> static inline void gen_ldo_env_A0(DisasContext *s, int offset) +> { +> int mem_index = s->mem_index; +> tcg_gen_qemu_ld_i64(s->tmp1_i64, s->A0, mem_index, MO_LEQ); +> tcg_gen_st_i64(s->tmp1_i64, cpu_env, offset + offsetof(ZMMReg, +> ZMM_Q(0))); +> tcg_gen_addi_tl(s->tmp0, s->A0, 8); +> tcg_gen_qemu_ld_i64(s->tmp1_i64, s->tmp0, mem_index, MO_LEQ); +> tcg_gen_st_i64(s->tmp1_i64, cpu_env, offset + offsetof(ZMMReg, +> ZMM_Q(1))); +> } +> ``` +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1861404/+subscriptions +> +> + + +Because the sse code is sloppy, and it was interpreted +as the sse instruction movdqu. + +AVX support was coded for GSoC last year, + +https://lists.nongnu.org/archive/html/qemu-devel/2019-08/msg05369.html + +but it has not been completely reviewed and committed. + +There is no support for AVX in master. + +Thanks for your answers. + +I thought the fact that there was not any warning/exception meant that VMOVDQU was supported, but if it's mistakenly interpreted as MOVDQU then I understand. + +I read the mailing list messages on the AVX GSoC you point out, but couldn't find any branch where this work is located. Is there a non-released version of this that can be tested? + +If I understand correctly, Qemu (or more precisely TCG) supports x86 SIMD instructions up to SSE4.1, but not AVX/AVX2/AVX-512? + +Thanks. + +Hi, + +I also noticed that the 4.2.0 release changelog mentions support for some AVX512 instructions. + +https://wiki.qemu.org/ChangeLog/4.2#x86 +``` +Support for AVX512 BFloat16 extensions. +``` + +Is this support in TCG or in another component? +If so, it would mean that TCG support some AVX512 instructions but not AVX. + +Also, allow me to ask again, where can I find the work of last year's GSoC on AVX support for TCG? + +> AVX support was coded for GSoC last year, +> https://lists.nongnu.org/archive/html/qemu-devel/2019-08/msg05369.html + +Thanks. + +The "AVX512 BFloat16" patch is for KVM support. + +As for finding the GSoC work, please follow that link, +and the ones buried inside that. There are hundreds +of patches involved. + + +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/132 + + diff --git a/results/classifier/105/mistranslation/1861946 b/results/classifier/105/mistranslation/1861946 new file mode 100644 index 000000000..7312345d9 --- /dev/null +++ b/results/classifier/105/mistranslation/1861946 @@ -0,0 +1,233 @@ +mistranslation: 0.926 +other: 0.913 +instruction: 0.909 +vnc: 0.905 +graphic: 0.901 +device: 0.901 +semantic: 0.895 +boot: 0.887 +socket: 0.884 +assembly: 0.883 +network: 0.879 +KVM: 0.865 + +qemu-4.2.0 qemu-system-i386 not receive scancode 86 of spanish keyboard (ascii chars '<' & '>') + +Hello. + +I am using qemu-4.2.0 for Windows 64 downloaded from https://qemu.weilnetz.de/w64/, +and I use qemu-system-i386.exe for run Minix 3.1.2a: + + C:\Program Files\qemu> qemu-system-i386 minix3hd.qcow + +All is Ok except the keyboard (spanish). + +Actually the Spanish keyboard has always worked well until the version qemu-2.11.0 included. But after that version and until the current version the Spanish keyboard has worked with some very annoying bugs. + +The bugs that I encountered in the current version 4.2.0 on Windows are: + +1) Scancode 86 (ascii '<') is not received from the Spanish keyboard. + +2) Scancode 41 should be interpreted as 39 (41 -> 39). + +3) in the same way: +12 -> 53 +13 -> 27 +26 -> 12 +27 -> 13 +43 -> 41 +53 -> 43 + +4) Finally and very important in Spain is that scancode 39 should produce the national characters 'ñ' and 'Ñ' + +I have checked the scancodes sent by running a floppy disk image with a boot sector that echoed the scancodes sent by pressing the different keys, so the errors are not due in any case to the operating system, but to the virtual machine or at most to the BIOS. + +In Minix 3.1.2a I tried to alleviate the errors by modifying the keymap: /usr/lib/keymaps/spanish.map. I have managed to solve all the errors except the one corresponding to scancode 86 (ascii '<') since when the key is pressed on the Spanish keyboard the scancode 86 is not sent. + +I accompany the modified keymap: https://github.com/Stichting-MINIX-Research-Foundation/minix/blob/R3.1.2/drivers/tty/keymaps/spanish.src for it could be clarifying in any way. + +Thank you very much for qemu and the new version 4.2.0. Apart from these small details, all the improvements that have been included are greatly appreciated. + +Greetings. Pedro Pablo. + +------------------------- spanish.src (modified #if 0 #else #endif) ------------------------- + +/* Keymap for Spanish MF-2 keyboard. */ +/* Modified by Javier Garcia Martin <email address hidden> */ + +u16_t keymap[NR_SCAN_CODES * MAP_COLS] = { + +/* scan-code !Shift Shift Alt AltGr Alt+Sh Ctrl */ +/* +==================================================================== +*/ +/* 00 - none */ 0, 0, 0, 0, 0, 0, +/* 01 - ESC */ C('['), C('['), CA('['),C('['), C('['), C('['), +/* 02 - '1' */ '1', '!', A('1'), '|', '!', C('A'), +/* 03 - '2' */ '2', '"', A('2'), '@', '"', C('@'), +/* 04 - '3' */ '3', 0372, A('3'), '#', 0372, C('C'), +/* 05 - '4' */ '4', '$', A('4'), '4', '$', C('D'), +/* 06 - '5' */ '5', '%', A('5'), '5', '%', C('E'), +/* 07 - '6' */ '6', '&', A('6'), 0252, '&', C('F'), +/* 08 - '7' */ '7', '/', A('7'), '{', '/', C('G'), +/* 09 - '8' */ '8', '(', A('8'), '(', '(', C('H'), +/* 10 - '9' */ '9', ')', A('9'), ')', ')', C('I'), +/* 11 - '0' */ '0', '=', A('0'), '=', '=', C('@'), +#if 0 +/* 12 - '-' */ '\'', '?', A('\''),'?', '?', C('_'), /* debería ser como la (53) */ +#else +/* 53 - '/' */ '-', '_', A('-'), '-', '_', C('@'), +#endif +#if 0 +/* 13 - '=' */ 0255, 0250, A(0255),0250, 0250, C('@'), /* deberia ser como la (27) */ +#else +/* 27 - ']' */ '+', '*', A('+'), ']', '*', C(']'), +#endif +/* 14 - BS */ C('H'), C('H'), CA('H'),C('H'), C('H'), 0177, +/* 15 - TAB */ C('I'), C('I'), CA('I'),C('I'), C('I'), C('I'), +/* 16 - 'q' */ L('q'), 'Q', A('q'), 'q', 'Q', C('Q'), +/* 17 - 'w' */ L('w'), 'W', A('w'), 'w', 'W', C('W'), +/* 18 - 'e' */ L('e'), 'E', A('e'), 'e', 'E', C('E'), +/* 19 - 'r' */ L('r'), 'R', A('r'), 'r', 'R', C('R'), +/* 20 - 't' */ L('t'), 'T', A('t'), 't', 'T', C('T'), +/* 21 - 'y' */ L('y'), 'Y', A('y'), 'y', 'Y', C('Y'), +/* 22 - 'u' */ L('u'), 'U', A('u'), 'u', 'U', C('U'), +/* 23 - 'i' */ L('i'), 'I', A('i'), 'i', 'I', C('I'), +/* 24 - 'o' */ L('o'), 'O', A('o'), 'o', 'O', C('O'), +/* 25 - 'p' */ L('p'), 'P', A('p'), 'p', 'P', C('P'), +#if 0 +/* 26 - '[' */ '`', '^', A('`'),'[', '^', C('['), /* debería ser como la (12) */ +#else +/* 12 - '-' */ '\'', '?', A('\''),'?', '?', C('_'), +#endif +#if 0 +/* 27 - ']' */ '+', '*', A('+'), ']', '*', C(']'), /* deberia ser como la (13) */ +#else +/* 13 - '=' */ 0255, 0250, A(0255),0250, 0250, C('@'), +#endif +/* 28 - CR/LF */ C('M'), C('M'), CA('M'),C('M'), C('M'), C('J'), +/* 29 - Ctrl */ CTRL, CTRL, CTRL, CTRL, CTRL, CTRL, +/* 30 - 'a' */ L('a'), 'A', A('a'), 'a', 'A', C('A'), +/* 31 - 's' */ L('s'), 'S', A('s'), 's', 'S', C('S'), +/* 32 - 'd' */ L('d'), 'D', A('d'), 'd', 'D', C('D'), +/* 33 - 'f' */ L('f'), 'F', A('f'), 'f', 'F', C('F'), +/* 34 - 'g' */ L('g'), 'G', A('g'), 'g', 'G', C('G'), +/* 35 - 'h' */ L('h'), 'H', A('h'), 'h', 'H', C('H'), +/* 36 - 'j' */ L('j'), 'J', A('j'), 'j', 'J', C('J'), +/* 37 - 'k' */ L('k'), 'K', A('k'), 'k', 'K', C('K'), +/* 38 - 'l' */ L('l'), 'L', A('l'), 'l', 'L', C('L'), +#if 0 +/* 39 - ';' */ L(0244),0245, A(0244),0244, 0245, C('@'), /* deberia ser como la (26) */ +#else +/* 26 - '[' */ '`', '^', A('`'),'[', '^', C('['), +#endif +/* 40 - '\'' */ '\'', '"', A('\''),'{', '"', C('@'), +#if 0 +/* 41 - '`' */ 0247, 0246, A(0247),'\\', 0246, C('@'), /* deberia ser como la (ñÑ) */ +#else +/* 39 - ';' */ L(0244),0245, A(0244),0244, 0245, C('@'), +#endif +/* 42 - l. SHIFT*/ SHIFT, SHIFT, SHIFT, SHIFT, SHIFT, SHIFT, +#if 0 +/* 43 - '\\' */ L(0207),0200, A(0207),'}', 0200, C('@'), /* deberia ser como la (41) */ +#elif 0 +/* 41 - '`' */ 0247, 0246, A(0247),'\\', 0246, C('@'), +#else +/* 41 - '`' */ '<', '>', A('<'), '\\', 0246, C('@'), /* añadimos < y > */ +#endif +/* 44 - 'z' */ L('z'), 'Z', A('z'), 'z', 'Z', C('Z'), +/* 45 - 'x' */ L('x'), 'X', A('x'), 'x', 'X', C('X'), +/* 46 - 'c' */ L('c'), 'C', A('c'), 'c', 'C', C('C'), +/* 47 - 'v' */ L('v'), 'V', A('v'), 'v', 'V', C('V'), +/* 48 - 'b' */ L('b'), 'B', A('b'), 'b', 'B', C('B'), +/* 49 - 'n' */ L('n'), 'N', A('n'), 'n', 'N', C('N'), +/* 50 - 'm' */ L('m'), 'M', A('m'), 'm', 'M', C('M'), +/* 51 - ',' */ ',', ';', A(','), ',', ';', C('@'), +/* 52 - '.' */ '.', ':', A('.'), '.', ':', C('@'), +#if 0 +/* 53 - '/' */ '-', '_', A('-'), '-', '_', C('@'), /* deberia ser como la (43) */ +#else +/* 43 - '\\' */ L(0207),0200, A(0207),'}', 0200, C('@'), +#endif +/* 54 - r. SHIFT*/ SHIFT, SHIFT, SHIFT, SHIFT, SHIFT, SHIFT, +/* 55 - '*' */ '*', '*', A('*'), '*', '*', C('M'), +/* 56 - ALT */ ALT, ALT, ALT, ALT, ALT, ALT, +/* 57 - ' ' */ ' ', ' ', A(' '), ' ', ' ', C('@'), +/* 58 - CapsLck */ CALOCK, CALOCK, CALOCK, CALOCK, CALOCK, CALOCK, +/* 59 - F1 */ F1, SF1, AF1, AF1, ASF1, CF1, +/* 60 - F2 */ F2, SF2, AF2, AF2, ASF2, CF2, +/* 61 - F3 */ F3, SF3, AF3, AF3, ASF3, CF3, +/* 62 - F4 */ F4, SF4, AF4, AF4, ASF4, CF4, +/* 63 - F5 */ F5, SF5, AF5, AF5, ASF5, CF5, +/* 64 - F6 */ F6, SF6, AF6, AF6, ASF6, CF6, +/* 65 - F7 */ F7, SF7, AF7, AF7, ASF7, CF7, +/* 66 - F8 */ F8, SF8, AF8, AF8, ASF8, CF8, +/* 67 - F9 */ F9, SF9, AF9, AF9, ASF9, CF9, +/* 68 - F10 */ F10, SF10, AF10, AF10, ASF10, CF10, +/* 69 - NumLock */ NLOCK, NLOCK, NLOCK, NLOCK, NLOCK, NLOCK, +/* 70 - ScrLock */ SLOCK, SLOCK, SLOCK, SLOCK, SLOCK, SLOCK, +/* 71 - Home */ HOME, '7', AHOME, AHOME, '7', CHOME, +/* 72 - CurUp */ UP, '8', AUP, AUP, '8', CUP, +/* 73 - PgUp */ PGUP, '9', APGUP, APGUP, '9', CPGUP, +/* 74 - '-' */ NMIN, '-', ANMIN, ANMIN, '-', CNMIN, +/* 75 - Left */ LEFT, '4', ALEFT, ALEFT, '4', CLEFT, +/* 76 - MID */ MID, '5', AMID, AMID, '5', CMID, +/* 77 - Right */ RIGHT, '6', ARIGHT, ARIGHT, '6', CRIGHT, +/* 78 - '+' */ PLUS, '+', APLUS, APLUS, '+', CPLUS, +/* 79 - End */ END, '1', AEND, AEND, '1', CEND, +/* 80 - Down */ DOWN, '2', ADOWN, ADOWN, '2', CDOWN, +/* 81 - PgDown */ PGDN, '3', APGDN, APGDN, '3', CPGDN, +/* 82 - Insert */ INSRT, '0', AINSRT, AINSRT, '0', CINSRT, +/* 83 - Delete */ 0177, '.', A(0177),0177, '.', 0177, +/* 84 - Enter */ C('M'), C('M'), CA('M'),C('M'), C('M'), C('J'), +/* 85 - ??? */ 0, 0, 0, 0, 0, 0, +/* 86 - ??? */ '<', '>', A('<'), '<', '>', C('@'), +/* 87 - F11 */ F11, SF11, AF11, AF11, ASF11, CF11, +/* 88 - F12 */ F12, SF12, AF12, AF12, ASF12, CF12, +/* 89 - ??? */ 0, 0, 0, 0, 0, 0, +/* 90 - ??? */ 0, 0, 0, 0, 0, 0, +/* 91 - ??? */ 0, 0, 0, 0, 0, 0, +/* 92 - ??? */ 0, 0, 0, 0, 0, 0, +/* 93 - ??? */ 0, 0, 0, 0, 0, 0, +/* 94 - ??? */ 0, 0, 0, 0, 0, 0, +/* 95 - ??? */ 0, 0, 0, 0, 0, 0, +/* 96 - EXT_KEY */ EXTKEY, EXTKEY, EXTKEY, EXTKEY, EXTKEY, EXTKEY, +/* 97 - ??? */ 0, 0, 0, 0, 0, 0, +/* 98 - ??? */ 0, 0, 0, 0, 0, 0, +/* 99 - ??? */ 0, 0, 0, 0, 0, 0, +/*100 - ??? */ 0, 0, 0, 0, 0, 0, +/*101 - ??? */ 0, 0, 0, 0, 0, 0, +/*102 - ??? */ 0, 0, 0, 0, 0, 0, +/*103 - ??? */ 0, 0, 0, 0, 0, 0, +/*104 - ??? */ 0, 0, 0, 0, 0, 0, +/*105 - ??? */ 0, 0, 0, 0, 0, 0, +/*106 - ??? */ 0, 0, 0, 0, 0, 0, +/*107 - ??? */ 0, 0, 0, 0, 0, 0, +/*108 - ??? */ 0, 0, 0, 0, 0, 0, +/*109 - ??? */ 0, 0, 0, 0, 0, 0, +/*110 - ??? */ 0, 0, 0, 0, 0, 0, +/*111 - ??? */ 0, 0, 0, 0, 0, 0, +/*112 - ??? */ 0, 0, 0, 0, 0, 0, +/*113 - ??? */ 0, 0, 0, 0, 0, 0, +/*114 - ??? */ 0, 0, 0, 0, 0, 0, +/*115 - ??? */ 0, 0, 0, 0, 0, 0, +/*116 - ??? */ 0, 0, 0, 0, 0, 0, +/*117 - ??? */ 0, 0, 0, 0, 0, 0, +/*118 - ??? */ 0, 0, 0, 0, 0, 0, +/*119 - ??? */ 0, 0, 0, 0, 0, 0, +/*120 - ??? */ 0, 0, 0, 0, 0, 0, +/*121 - ??? */ 0, 0, 0, 0, 0, 0, +/*122 - ??? */ 0, 0, 0, 0, 0, 0, +/*123 - ??? */ 0, 0, 0, 0, 0, 0, +/*124 - ??? */ 0, 0, 0, 0, 0, 0, +/*125 - ??? */ 0, 0, 0, 0, 0, 0, +/*126 - ??? */ 0, 0, 0, 0, 0, 0, +/*127 - ??? */ 0, 0, 0, 0, 0, 0 +}; + +The qemu 5.1.0 version solved this problem. + +Bug solved. + +Many Thanks to qemu group and Stefan Weil. + diff --git a/results/classifier/105/mistranslation/1862986 b/results/classifier/105/mistranslation/1862986 new file mode 100644 index 000000000..1756fa6a4 --- /dev/null +++ b/results/classifier/105/mistranslation/1862986 @@ -0,0 +1,155 @@ +mistranslation: 0.481 +instruction: 0.448 +graphic: 0.420 +device: 0.412 +other: 0.412 +semantic: 0.359 +assembly: 0.339 +network: 0.281 +KVM: 0.268 +socket: 0.248 +boot: 0.211 +vnc: 0.182 + +qemu-s390x segfaults + +All tested versions (2.11 and 4.2) qemu-s390x crashes with a segfault when run on an aarch64 odroid Ubuntu. + +Steps to reproduce: + +root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-s390x "/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig" +Segmentation fault (core dumped) +root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-s390x --version +qemu-s390x version 4.2.0 +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers +root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-s390x "/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig" +Segmentation fault (core dumped) +root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-s390x --version +qemu-s390x version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.22) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + + +qemu-arm does work on the same machine: + +root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-arm bitcoin-0.19.0.1-armhf/bin/test_bitcoin -t amount_tests +Running 4 test cases... + +*** No errors detected +root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-arm bitcoin-0.19.0.1-armhf/bin/test_bitcoin -t amount_tests +Running 4 test cases... + +*** No errors detected + + +What kind of debug information would be helpful for this issue report? + + +GDB for the self-compiled latest release is not particularly helpful: + +(gdb) run +Starting program: /usr/local/bin/qemu-s390x /root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1". +[New Thread 0x7fb7a2a140 (LWP 28264)] + +Thread 1 "qemu-s390x" received signal SIGSEGV, Segmentation fault. +0x000000555596b218 in __bss_start__ () +(gdb) bt +#0 0x000000555596b218 in __bss_start__ () +#1 0x00000055556120a8 in ?? () +#2 0x00000055579904b0 in ?? () +Backtrace stopped: previous frame inner to this frame (corrupt stack?) + +A bit more information is available in the version shipped by Ubuntu: + +(gdb) run +Starting program: /usr/bin/qemu-s390x /root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1". +[New Thread 0x7fb7a01180 (LWP 28271)] + +Thread 1 "qemu-s390x" received signal SIGSEGV, Segmentation fault. +0x0000005555738f98 in code_gen_buffer () +(gdb) bt +#0 0x0000005555738f98 in code_gen_buffer () +#1 0x00000055555e96c8 in cpu_exec () +#2 0x00000055555ee430 in cpu_loop () +#3 0x00000055555c3328 in main () + +You need to provide the test binary. + +I can run a chroot of s390x ubuntu bionic on aarch64 just fine, +so it must be something specific to your test. + + + +Thanks for taking a look. With the binary I posted, the steps to reproduce are: + +dpkg --add-architecture s390x && apt update && apt install qemu-user wget libc6:s390x libstdc++6:s390x libfontconfig1:s390x libxcb1:s390x -y && wget https://bugs.launchpad.net/qemu/+bug/1862986/+attachment/5331331/+files/test_bitcoin_orig && sha256sum ./test_bitcoin_orig && chmod +x test_bitcoin_orig + +The hash of the file is 193758e2041d49fe90722927ba6b5371506831caf733ee2fe61ef7d61cc894f7 and qemu-user crashes for me: + +$ qemu-s390x ./test_bitcoin_orig +Segmentation fault (core dumped) + + + + +I can also reproduce this in a debian:sid docker container on x86_64, so this might not be related to the host CPU architecture + +Could it be related to https://bugs.launchpad.net/qemu/+bug/1860920 ? + +Could you try latest QEMU source (including "target/s390x/translate: Fix RNSBG instruction")? + +[Expired for QEMU because there has been no activity for 60 days.] + +This still happens on qemu 5.0 + +Steps to reproduce: + +# install packages +dpkg --add-architecture s390x +apt update +apt install qemu-user libc6:s390x libstdc++6:s390x libfontconfig1:s390x libxcb1:s390x +apt install g++-s390x-linux-gnu + +# create dummy binary +echo 'int main(){}'| s390x-linux-gnu-g++ -x c++ - + +# run dummy binary +qemu-s390x ./a.out +Segmentation fault (core dumped) + +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. + + +Fixed in qemu-s390x version 5.2.0 (Debian 1:5.2+dfsg-10) + + diff --git a/results/classifier/105/mistranslation/1863023 b/results/classifier/105/mistranslation/1863023 new file mode 100644 index 000000000..458f622f9 --- /dev/null +++ b/results/classifier/105/mistranslation/1863023 @@ -0,0 +1,71 @@ +mistranslation: 0.638 +KVM: 0.623 +other: 0.494 +vnc: 0.472 +semantic: 0.411 +graphic: 0.400 +boot: 0.388 +network: 0.385 +device: 0.384 +instruction: 0.383 +assembly: 0.378 +socket: 0.344 + +Deadlock in QXL + +This is on qemu 4.2.0 OSX host, running fresh Windows 7 with SPICE guest tools just installed. + +Command line: `qemu-system-x86_64 -qmp tcp:localhost:4444,server,nowait -smp cpus=2 -boot order=d -m 2048 -soundhw hda -drive file=hda.img,if=ide,media=disk -spice port=5930,addr=127.0.0.1,disable-ticketing,image-compression=off,playback-compression=off,streaming-video=off -vga qxl -device rtl8139,netdev=net0 -netdev user,id=net0` + +After the Windows logo, the screen is black. I dump the two vCPU threads: + +``` +* thread #16 + * frame #0: 0x00007fff523b8ce6 libsystem_kernel.dylib`__psynch_cvwait + 10 + frame #1: 0x00007fff52467185 libsystem_pthread.dylib`_pthread_cond_wait + 701 + frame #2: 0x0000000110bf88bd qemu-system-x86_64`qemu_cond_wait_impl(cond=0x000000011121e8d0, mutex=0x000000011120ba48, file="cpus-common.c", line=144) at qemu-thread-posix.c:173:11 [opt] + frame #3: 0x0000000110926a59 qemu-system-x86_64`do_run_on_cpu(cpu=<unavailable>, func=<unavailable>, data=<unavailable>, mutex=0x000000011120ba48) at cpus-common.c:144:9 [opt] + frame #4: 0x000000011080c50a qemu-system-x86_64`memory_region_snapshot_and_clear_dirty at memory.c:2595:5 [opt] + frame #5: 0x000000011080c4d7 qemu-system-x86_64`memory_region_snapshot_and_clear_dirty(mr=<unavailable>, addr=0, size=2359296, client=<unavailable>) at memory.c:2107 [opt] + frame #6: 0x0000000110849fe1 qemu-system-x86_64`vga_update_display [inlined] vga_draw_graphic(s=<unavailable>, full_update=0) at vga.c:1661:16 [opt] + frame #7: 0x000000011084996a qemu-system-x86_64`vga_update_display(opaque=<unavailable>) at vga.c:1785 [opt] + frame #8: 0x00000001109b261d qemu-system-x86_64`qxl_hard_reset(d=0x00007f84f8730000, loadvm=0) at qxl.c:1285:5 [opt] + frame #9: 0x000000011080ac97 qemu-system-x86_64`memory_region_write_accessor(mr=0x00007f84f8741fb0, addr=5, value=<unavailable>, size=1, shift=<unavailable>, mask=<unavailable>, attrs=MemTxAttrs @ 0x000070000786d890) at memory.c:483:5 [opt] + frame #10: 0x000000011080ab31 qemu-system-x86_64`memory_region_dispatch_write [inlined] access_with_adjusted_size(addr=<unavailable>, value=0x00000000015c6100, size=<unavailable>, access_size_min=<unavailable>, access_size_max=<unavailable>, access_fn=<unavailable>, mr=<unavailable>, attrs=<unavailable>) at memory.c:544:18 [opt] + frame #11: 0x000000011080aafd qemu-system-x86_64`memory_region_dispatch_write(mr=<unavailable>, addr=<unavailable>, data=22831360, op=32644, attrs=MemTxAttrs @ 0x000070000786d8c0) at memory.c:1475 [opt] + frame #12: 0x00000001107b080d qemu-system-x86_64`address_space_stb(as=<unavailable>, addr=<unavailable>, val=22831360, attrs=MemTxAttrs @ r12, result=0x0000000000000000) at memory_ldst.inc.c:378:13 [opt] + frame #13: 0x0000000118570230 + +* thread #18 + * frame #0: 0x00007fff523b8ce6 libsystem_kernel.dylib`__psynch_cvwait + 10 + frame #1: 0x00007fff52467185 libsystem_pthread.dylib`_pthread_cond_wait + 701 + frame #2: 0x0000000110bf88bd qemu-system-x86_64`qemu_cond_wait_impl(cond=0x000000011121e860, mutex=0x000000011121e818, file="cpus-common.c", line=196) at qemu-thread-posix.c:173:11 [opt] + frame #3: 0x0000000110926c44 qemu-system-x86_64`start_exclusive at cpus-common.c:196:9 [opt] + frame #4: 0x0000000110837c35 qemu-system-x86_64`cpu_exec_step_atomic(cpu=0x00007f8518290000) at cpu-exec.c:265:9 [opt] + frame #5: 0x00000001107fcf95 qemu-system-x86_64`qemu_tcg_cpu_thread_fn(arg=0x00007f8518290000) at cpus.c:1799:17 [opt] + frame #6: 0x0000000110bf911e qemu-system-x86_64`qemu_thread_start(args=<unavailable>) at qemu-thread-posix.c:519:9 [opt] + frame #7: 0x00007fff52466e65 libsystem_pthread.dylib`_pthread_start + 148 + frame #8: 0x00007fff5246283b libsystem_pthread.dylib`thread_start + 15 +``` + +Seems like thread #16 had a STB to QXL MMIO registers which caused it to call `qxl_hard_reset` and eventually made its way to `do_run_on_cpu` which waits for `qemu_work_cond`. The only way `qemu_work_cond` is set is if one of the two vCPU executes the queued work at the end of the TCG execution. Thread #16 is stuck waiting, so what about thread #18? Thread #18 is waiting for `exclusive_cond` which is set once all the other CPUs are done running (but thread #16 is waiting still). So classic deadlock. + +Any change if you remove the graphic_hw_update() call in qxl_enter_vga_mode()? + +I can't see where the do_run_on_cpu is called in memory.c at 4.2. Is it reproducible on the latest state of master. + +The QEMU project is currently considering to move 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/105/mistranslation/1863025 b/results/classifier/105/mistranslation/1863025 new file mode 100644 index 000000000..bc4ac6384 --- /dev/null +++ b/results/classifier/105/mistranslation/1863025 @@ -0,0 +1,446 @@ +mistranslation: 0.853 +semantic: 0.797 +other: 0.782 +graphic: 0.764 +assembly: 0.709 +instruction: 0.696 +device: 0.696 +vnc: 0.668 +KVM: 0.586 +boot: 0.583 +network: 0.527 +socket: 0.523 + +Use-after-free after flush in TCG accelerator + +I believe I found a UAF in TCG that can lead to a guest VM escape. The security +list informed me "This can not be treated as a security issue." and to post it +here. I am looking at the 4.2.0 source code. The issue requires a race and I +will try to describe it in terms of three concurrent threads. + +I am looking +at the 4.2.0 source code. The issue requires a race and I will try to describe +it in terms of three concurrent threads. + +Thread A: + +A1. qemu_tcg_cpu_thread_fn runs work loop +A2. qemu_wait_io_event => qemu_wait_io_event_common => process_queued_cpu_work +A3. start_exclusive critical section entered +A4. do_tb_flush is called, TB memory freed/re-allocated +A5. end_exclusive exits critical section + +Thread B: + +B1. qemu_tcg_cpu_thread_fn runs work loop +B2. tcg_cpu_exec => cpu_exec => tb_find => tb_gen_code +B3. tcg_tb_alloc obtains a new TB + +Thread C: + +C1. qemu_tcg_cpu_thread_fn runs work loop +C2. cpu_exec_step_atomic executes +C3. TB obtained with tb_lookup__cpu_state or tb_gen_code +C4. start_exclusive critical section entered +C5. cpu_tb_exec executes the TB code +C6. end_exclusive exits critical section + +Consider the following sequence of events: + B2 => B3 => C3 (same TB as B2) => A3 => A4 (TB freed) => A5 => B2 => + B3 (re-allocates TB from B2) => C4 => C5 (freed/reused TB now executing) => C6 + +In short, because thread C uses the TB in the critical section, there is no +guarantee that the pointer has not been "freed" (rather the memory is marked as +re-usable) and therefore a use-after-free occurs. + +Since the TCG generated code can be in the same memory as the TB data structure, +it is possible for an attacker to overwrite the UAF pointer with code generated +from TCG. This can overwrite key pointer values and could lead to code +execution on the host outside of the TCG sandbox. + +The bug describes a race whereby cpu_exec_step_atomic can acquire a TB +which is invalidated by a tb_flush before we execute it. This doesn't +affect the other cpu_exec modes as a tb_flush by it's nature can only +occur on a quiescent system. The race was described as: + + B2. tcg_cpu_exec => cpu_exec => tb_find => tb_gen_code + B3. tcg_tb_alloc obtains a new TB + + C3. TB obtained with tb_lookup__cpu_state or tb_gen_code + (same TB as B2) + + A3. start_exclusive critical section entered + A4. do_tb_flush is called, TB memory freed/re-allocated + A5. end_exclusive exits critical section + + B2. tcg_cpu_exec => cpu_exec => tb_find => tb_gen_code + B3. tcg_tb_alloc reallocates TB from B2 + + C4. start_exclusive critical section entered + C5. cpu_tb_exec executes the TB code that was free in A4 + +The simplest fix is to widen the exclusive period to include the TB +lookup. As a result we can drop the complication of checking we are in +the exclusive region before we end it. + +Signed-off-by: Alex Bennée <email address hidden> +Cc: Yifan <email address hidden> +Cc: Bug 1863025 <email address hidden> +--- + accel/tcg/cpu-exec.c | 21 +++++++++++---------- + 1 file changed, 11 insertions(+), 10 deletions(-) + +diff --git a/accel/tcg/cpu-exec.c b/accel/tcg/cpu-exec.c +index 2560c90eec7..d95c4848a47 100644 +--- a/accel/tcg/cpu-exec.c ++++ b/accel/tcg/cpu-exec.c +@@ -240,6 +240,8 @@ void cpu_exec_step_atomic(CPUState *cpu) + uint32_t cf_mask = cflags & CF_HASH_MASK; + + if (sigsetjmp(cpu->jmp_env, 0) == 0) { ++ start_exclusive(); ++ + tb = tb_lookup__cpu_state(cpu, &pc, &cs_base, &flags, cf_mask); + if (tb == NULL) { + mmap_lock(); +@@ -247,8 +249,6 @@ void cpu_exec_step_atomic(CPUState *cpu) + mmap_unlock(); + } + +- start_exclusive(); +- + /* Since we got here, we know that parallel_cpus must be true. */ + parallel_cpus = false; + cc->cpu_exec_enter(cpu); +@@ -271,14 +271,15 @@ void cpu_exec_step_atomic(CPUState *cpu) + qemu_plugin_disable_mem_helpers(cpu); + } + +- if (cpu_in_exclusive_context(cpu)) { +- /* We might longjump out of either the codegen or the +- * execution, so must make sure we only end the exclusive +- * region if we started it. +- */ +- parallel_cpus = true; +- end_exclusive(); +- } ++ ++ /* ++ * As we start the exclusive region before codegen we must still ++ * be in the region if we longjump out of either the codegen or ++ * the execution. ++ */ ++ g_assert(cpu_in_exclusive_context(cpu)); ++ parallel_cpus = true; ++ end_exclusive(); + } + + struct tb_desc { +-- +2.20.1 + + + +I've attached a variant of the suggested patch which simply expands the exclusive period. It's hard to test extensively as not many things use the EXCP_ATOMIC mechanism. Can I ask how you found the bug and if you can re-test with the suggested patch? + +I found it just by launching Ubuntu 19.10 live cd with QXL driver. I will re-test this weekend. + +The workaround I had is to check the number of TLB flushes and to re-try obtaining the TB if the number changes. There is a penalty for the case where TLB is flushed but should not degrade performance in most cases. I think obtaining the lock earlier will slow down the VM if EXCP_ATOMIC is used often. + +Of course, I am assuming TLB flush is the only way to cause this bug. + +diff --git a/accel/tcg/cpu-exec.c b/accel/tcg/cpu-exec.c +index d1c2b6ea1fd..d83b578299b 100644 +--- a/accel/tcg/cpu-exec.c ++++ b/accel/tcg/cpu-exec.c +@@ -250,8 +250,11 @@ void cpu_exec_step_atomic(CPUState *cpu) + uint32_t flags; + uint32_t cflags = 1; + uint32_t cf_mask = cflags & CF_HASH_MASK; ++ unsigned flush_count; + + if (sigsetjmp(cpu->jmp_env, 0) == 0) { ++retry: ++ flush_count = tb_flush_count(); + tb = tb_lookup__cpu_state(cpu, &pc, &cs_base, &flags, cf_mask); + if (tb == NULL) { + mmap_lock(); +@@ -260,6 +263,11 @@ void cpu_exec_step_atomic(CPUState *cpu) + } + + start_exclusive(); ++ /* do_tb_flush() might run and make tb invalid */ ++ if (flush_count != tb_flush_count()) { ++ end_exclusive(); ++ goto retry; ++ } + + /* Since we got here, we know that parallel_cpus must be true. */ + parallel_cpus = false; +diff --git a/accel/tcg/translate-all.c b/accel/tcg/translate-all.c +index 4ed9d0abaf2..ecf7d3b53ff 100644 +--- a/accel/tcg/translate-all.c ++++ b/accel/tcg/translate-all.c +@@ -2696,6 +2696,11 @@ void tcg_flush_softmmu_tlb(CPUState *cs) + #endif + } + ++unsigned tb_flush_count(void) ++{ ++ return atomic_read(&tb_ctx.tb_flush_count); ++} ++ + #if defined(CONFIG_NO_RWX) + void tb_exec_memory_lock(void) + { +diff --git a/include/exec/exec-all.h b/include/exec/exec-all.h +index 5ccc9485812..1bc61fa6d76 100644 +--- a/include/exec/exec-all.h ++++ b/include/exec/exec-all.h +@@ -584,6 +584,7 @@ void tlb_set_dirty(CPUState *cpu, target_ulong vaddr); + void tb_flush_jmp_cache(CPUState *cpu, target_ulong addr); + + /* translate-all.c */ ++unsigned tb_flush_count(void); + #if defined(CONFIG_NO_RWX) + void tb_exec_memory_lock(void); + bool tb_is_exec(const TranslationBlock *tb); + +Apologies, the patch got messed up. + +diff --git a/accel/tcg/cpu-exec.c b/accel/tcg/cpu-exec.c +index c01f59c743..7a9e8c94bd 100644 +--- a/accel/tcg/cpu-exec.c ++++ b/accel/tcg/cpu-exec.c +@@ -238,8 +238,11 @@ void cpu_exec_step_atomic(CPUState *cpu) + uint32_t flags; + uint32_t cflags = 1; + uint32_t cf_mask = cflags & CF_HASH_MASK; ++ unsigned flush_count; + + if (sigsetjmp(cpu->jmp_env, 0) == 0) { ++retry: ++ flush_count = tb_flush_count(); + tb = tb_lookup__cpu_state(cpu, &pc, &cs_base, &flags, cf_mask); + if (tb == NULL) { + mmap_lock(); +@@ -248,6 +251,11 @@ void cpu_exec_step_atomic(CPUState *cpu) + } + + start_exclusive(); ++ /* do_tb_flush() might run and make tb invalid */ ++ if (flush_count != tb_flush_count()) { ++ end_exclusive(); ++ goto retry; ++ } + + /* Since we got here, we know that parallel_cpus must be true. */ + parallel_cpus = false; +diff --git a/accel/tcg/translate-all.c b/accel/tcg/translate-all.c +index 9f48da9472..2fb7da9b51 100644 +--- a/accel/tcg/translate-all.c ++++ b/accel/tcg/translate-all.c +@@ -2674,3 +2674,8 @@ void tcg_flush_softmmu_tlb(CPUState *cs) + tlb_flush(cs); + #endif + } ++ ++unsigned tb_flush_count(void) ++{ ++ return atomic_read(&tb_ctx.tb_flush_count); ++} +diff --git a/include/exec/exec-all.h b/include/exec/exec-all.h +index d85e610e85..aa3c2d219a 100644 +--- a/include/exec/exec-all.h ++++ b/include/exec/exec-all.h +@@ -579,6 +579,9 @@ void tlb_set_dirty(CPUState *cpu, target_ulong vaddr); + /* exec.c */ + void tb_flush_jmp_cache(CPUState *cpu, target_ulong addr); + ++/* translate-all.c */ ++unsigned tb_flush_count(void); ++ + MemoryRegionSection * + address_space_translate_for_iotlb(CPUState *cpu, int asidx, hwaddr addr, + hwaddr *xlat, hwaddr *plen, + +What race are you thinking of in my patch? The obvious race I can +think of is benign: + +Case 1: +A: does TB flush +B: read tb_flush_count +A: increment tb_flush_count +A: end_exclusive +B: tb_lookup__cpu_state/tb_gen_code +B: start_exclusive +B: read tb_flush_count again (increment seen) +B: retries + +Case 2: +B: read tb_flush_count +A: does TB flush +A: increment tb_flush_count +A: end_exclusive +B: tb_lookup__cpu_state/tb_gen_code +B: start_exclusive +B: read tb_flush_count again (increment seen) +B: retries + +Case 3: +A: does TB flush +A: increment tb_flush_count +A: end_exclusive +B: read tb_flush_count +B: tb_lookup__cpu_state/tb_gen_code +B: start_exclusive +B: read tb_flush_count again (no increment seen) +B: proceeds + +Case 1 is the expected case. Case 2, we thought TB was stale but it +wasn't so we get it again with tb_lookup__cpu_state with minimal extra +overhead. + +Case 3 seems to be bad because we could read tb_flush_count and find +it already incremented. But if so that means thread A is at the end of +do_tb_flush and the lookup tables are already cleared and the TCG +context is already reset. So it should be safe for thread B to call +tb_lookup__cpu_state or tb_gen_code. + +Yifan + +On Fri, Feb 14, 2020 at 3:31 PM Richard Henderson +<email address hidden> wrote: +> +> On 2/14/20 6:49 AM, Alex Bennée wrote: +> > The bug describes a race whereby cpu_exec_step_atomic can acquire a TB +> > which is invalidated by a tb_flush before we execute it. This doesn't +> > affect the other cpu_exec modes as a tb_flush by it's nature can only +> > occur on a quiescent system. The race was described as: +> > +> > B2. tcg_cpu_exec => cpu_exec => tb_find => tb_gen_code +> > B3. tcg_tb_alloc obtains a new TB +> > +> > C3. TB obtained with tb_lookup__cpu_state or tb_gen_code +> > (same TB as B2) +> > +> > A3. start_exclusive critical section entered +> > A4. do_tb_flush is called, TB memory freed/re-allocated +> > A5. end_exclusive exits critical section +> > +> > B2. tcg_cpu_exec => cpu_exec => tb_find => tb_gen_code +> > B3. tcg_tb_alloc reallocates TB from B2 +> > +> > C4. start_exclusive critical section entered +> > C5. cpu_tb_exec executes the TB code that was free in A4 +> > +> > The simplest fix is to widen the exclusive period to include the TB +> > lookup. As a result we can drop the complication of checking we are in +> > the exclusive region before we end it. +> +> I'm not 100% keen on having the tb_gen_code within the exclusive region. It +> implies a much larger delay on (at least) the first execution of the atomic +> operation. +> +> But I suppose until recently we had a global lock around code generation, and +> this is only slightly worse. Plus, it has the advantage of being dead simple, +> and without the races vs tb_ctx.tb_flush_count that exist in Yifan's patch. +> +> Applied to tcg-next. +> +> +> r~ + + +Fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=886cc68943eb + +CVE-2020-24165 was assigned to this: +https://nvd.nist.gov/vuln/detail/CVE-2020-24165 + +I had no involvement in the assignment, posting here for reference only. + +On Thu, Aug 31, 2023 at 03:40:25PM +0200, Philippe Mathieu-Daudé wrote: +> Hi Samuel, +> +> On 31/8/23 14:48, Samuel Henrique wrote: +> > CVE-2020-24165 was assigned to this: +> > https://nvd.nist.gov/vuln/detail/CVE-2020-24165 +> > +> > I had no involvement in the assignment, posting here for reference only. +> > +> > ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-24165 +> +> QEMU 4.2.0 was released in 2019. The issue you report +> has been fixed in commit 886cc68943 ("accel/tcg: fix race +> in cpu_exec_step_atomic (bug 1863025)") which is included +> in QEMU v5.0, released in April 2020, more than 3 years ago. +> +> What do you expect us to do here? I'm not sure whether assigning +> CVE for 3 years old code is a good use of engineering time. + +In any case per our stated security policy, we do not consider TCG to +be providing a security boundary between host and guest, and thus bugs +in TCG aren't considered security flaws: + + https://www.qemu.org/docs/master/system/security.html#non-virtualization-use-case + +With regards, +Daniel +-- +|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| +|: https://libvirt.org -o- https://fstop138.berrange.com :| +|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| + + +On Thu, Aug 31, 2023 at 3:57 PM Daniel P. Berrangé <email address hidden> wrote: +> +> On Thu, Aug 31, 2023 at 03:40:25PM +0200, Philippe Mathieu-Daudé wrote: +> > Hi Samuel, +> > +> > On 31/8/23 14:48, Samuel Henrique wrote: +> > > CVE-2020-24165 was assigned to this: +> > > https://nvd.nist.gov/vuln/detail/CVE-2020-24165 +> > > +> > > I had no involvement in the assignment, posting here for reference only. +> > > +> > > ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-24165 +> > +> > QEMU 4.2.0 was released in 2019. The issue you report +> > has been fixed in commit 886cc68943 ("accel/tcg: fix race +> > in cpu_exec_step_atomic (bug 1863025)") which is included +> > in QEMU v5.0, released in April 2020, more than 3 years ago. +> > +> > What do you expect us to do here? I'm not sure whether assigning +> > CVE for 3 years old code is a good use of engineering time. +> +> In any case per our stated security policy, we do not consider TCG to +> be providing a security boundary between host and guest, and thus bugs +> in TCG aren't considered security flaws: +> +> https://www.qemu.org/docs/master/system/security.html#non-virtualization-use-case + +Right, and it is clearly indicated in the referenced launchpad bug: +'The security list informed me "This can not be treated as a security +issue"'. + +This adds up to CVE-2022-36648, which is also a mystery to me in terms +of CVE assignment and CVSS scoring (rated as Critical). I don't know +what's going on with NVD, there must be something wrong on their side. + +I disputed both CVEs via https://cveform.mitre.org/. + +> With regards, +> Daniel +> -- +> |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| +> |: https://libvirt.org -o- https://fstop138.berrange.com :| +> |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| +> + +-- +Mauro Matteo Cascella +Red Hat Product Security +PGP-Key ID: BB3410B0 + + diff --git a/results/classifier/105/mistranslation/1863200 b/results/classifier/105/mistranslation/1863200 new file mode 100644 index 000000000..d65f36f9e --- /dev/null +++ b/results/classifier/105/mistranslation/1863200 @@ -0,0 +1,105 @@ +mistranslation: 0.913 +vnc: 0.907 +other: 0.892 +KVM: 0.884 +instruction: 0.871 +network: 0.839 +graphic: 0.834 +socket: 0.811 +device: 0.805 +semantic: 0.805 +assembly: 0.801 +boot: 0.761 + +Reconnect failed with loopback virtio1.1 server mode test + +Issue discription： +Packed ring server mode is a new feature to enable the virtio-user or virtio-pmd(in VM) as the server, vhost as the client, then when the vhost-user is killed then re-launched, the vhost-user can connect back to virtio-user/virtio-pmd again. Test with dpdk 20.02 ,virtio-pmd loopback reconnect from vhost-user failed. + +Test Environment: +DPDK version: DPDK v20.02 +Other software versions: virtio1.1 +Qemu versions:4.2.0 +OS: Linux 4.15.0-20-generic +Compiler: gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 +Hardware platform: R2208WFTZSR. + +The reproduce step is : +Test Case: vhost-user/virtio-pmd loopback reconnect from vhost-user +=============================================================== +Flow: Vhost-user --> Virtio --> Vhost-user + +1. Launch vhost-user with client mode by below commands:: + + ./testpmd -c 0x30 -n 4 --socket-mem 1024,1024 --legacy-mem --vdev 'eth_vhost0,iface=/tmp/vhost-net,client=1,queues=1' -- -i --nb-cores=1 + testpmd>set fwd mac + +2. Start VM with 1 virtio device, and set the qemu as server mode:: + + ./qemu-system-x86_64 -name vm2 -enable-kvm -cpu host -smp 100 -m 8G \ + -object memory-backend-file,id=mem,size=8192M,mem-path=/mnt/huge,share=on \ + -numa node,memdev=mem -mem-prealloc -drive file=/home/xuan/dpdk_project/shell/u18.img \ + -chardev socket,path=/tmp/vm2_qga0.sock,server,nowait,id=vm2_qga0 -device virtio-serial \ + -device virtserialport,chardev=vm2_qga0,name=org.qemu.guest_agent.2 -daemonize \ + -monitor unix:/tmp/vm2_monitor.sock,server,nowait -net nic,macaddr=00:00:00:08:e8:aa,addr=1f \ + -net user,hostfwd=tcp:127.0.0.1:6002-:22 \ + -chardev socket,id=char0,path=/tmp/vhost-net,server \ + -netdev type=vhost-user,id=netdev0,chardev=char0,vhostforce \ + -device virtio-net-pci,netdev=netdev0,mac=52:54:00:00:00:01,mrg_rxbuf=on,rx_queue_size=1024,tx_queue_size=1024,packed=on \ + -vnc :10 + +3. On VM, bind virtio net to igb_uio and run testpmd:: + + ./testpmd -c 0x3 -n 4 -- -i --nb-cores=1 --txd=1024 --rxd=1024 + testpmd>set fwd mac + testpmd>start + +4. Send packets by vhost-user, check if packets can be RX/TX with virtio-pmd:: + + testpmd>start tx_first 32 + testpmd>show port stats all + +5. On host, quit vhost-user, then re-launch the vhost-user with below command:: + + testpmd>quit + ./testpmd -c 0x30 -n 4 --socket-mem 1024,1024 --legacy-mem --vdev 'eth_vhost0,iface=/tmp/vhost-net,client=1,queues=1' -- -i --nb-cores=1 + testpmd>set fwd mac + testpmd>start tx_first 32 + +6. Check if the reconnection can work, still send packets by vhost-user, check if packets can be RX/TX with virtio-pmd:: + + testpmd>show port stats all + +Expected result:: + +After the vhost-user is killed then re-launched, the VM can connect back to vhost-user again with throughput. + +Real result:: + +After the vhost-user is killed then re-launched, no throughput with PVP. + +Analysis:: + +QEMU has its own way to handle reconnect function for virtio server mode. However, for packed ring, when reconnecting to virtio, vhost cannot get the status of descriptors via the descriptor ring. This bug is caused since the reconnection for packed ring need additional reset operation. + +The QEMU project is currently considering to move 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. + + + +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/248 + + diff --git a/results/classifier/105/mistranslation/1863445 b/results/classifier/105/mistranslation/1863445 new file mode 100644 index 000000000..14b71e181 --- /dev/null +++ b/results/classifier/105/mistranslation/1863445 @@ -0,0 +1,56 @@ +mistranslation: 0.473 +device: 0.454 +socket: 0.412 +instruction: 0.399 +vnc: 0.378 +network: 0.288 +semantic: 0.272 +other: 0.247 +boot: 0.200 +assembly: 0.192 +KVM: 0.133 +graphic: 0.110 + +assertion failed at translate-all.c:2523 with version 3.1.1 + +I was trying to debug a userspace binary with radare2 and met the following assertion in qemu: + +``` +qemu-mipsel: /builddir/build/BUILD/qemu-3.1.1/accel/tcg/translate-all.c:2523: page_check_range: Assertion `start < ((target_ulong)1 << L1_MAP_ADDR_SPACE_BITS)' failed. +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x7fd1c11c5987 +``` + +``` +# qemu-mipsel --version +qemu-mipsel version 3.1.1 (qemu-3.1.1-2.fc30) +Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers +``` + +not much to add. seems like qemu is not properly checking for valid addresses + + + +in order to reproduce the bug: +``` +qemu-mipsel -g 1234 ch67 +``` + +and then juste launch (after installing r2): + +``` +r2 -a mips -b 32 -d gdb://127.0.0.1:1234 +``` + +qemu will crash + +tested on fedora 30: +``` +uname -a +Linux bigfoot.home.ak42.io 5.4.18-100.fc30.x86_64 #1 SMP Fri Feb 7 14:37:00 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux +``` + +Please try again with 4.2; there have been changes in this function. + +indeed, works fine with 4.2 +thanks + diff --git a/results/classifier/105/mistranslation/1863601 b/results/classifier/105/mistranslation/1863601 new file mode 100644 index 000000000..94c0000b0 --- /dev/null +++ b/results/classifier/105/mistranslation/1863601 @@ -0,0 +1,39 @@ +mistranslation: 0.571 +graphic: 0.531 +semantic: 0.475 +other: 0.406 +device: 0.328 +instruction: 0.216 +network: 0.147 +vnc: 0.127 +socket: 0.126 +boot: 0.065 +assembly: 0.062 +KVM: 0.031 + +unable to type "|" character in french keyboard. + +Unable to type "|" character when using french keyboard. It is displaying "<" instead of pipe. + +Can you provide more information here. What command line have you launched QEMU with ? How are you interacting with QEMU (serial console, GTK UI, VNC, SPICE ?) If VNC/SPICE, what client app are you using ? + +Hi Daniel, Thanks for your response. I am using virt-manager to start with to connect with VNC. + +Can you provide the QEMU command line (/var/log/libvirt/qemu/$GUEST.log) + +Check you have selected the french keymap in virt-manager (see attached picture) + +Actually you explicitly do *NOT* want to select any keymap in virt-manager in general. Picking a keymap disables the VNC protocol extension for raw scancodes. This means that QEMU has to do keymap <-> scancode conversion. In such a setup the host OS desktop keymap, the QEMU keymap and the guest OS keymap all have to match perfectly to avoid bad conversions. + +By *not* selecting a keymap, virt-manager gets raw scancodes on the local host OS desktop and passes them unmodified to QEMU, which then passes them on to the guest OS. In this case, the guest OS keymap is the only thing that has todo conversions & this should be reliable. + +The only reason to select a keymap for QEMU is if you need to use legacy VNC clients which don't support the raw scancode protocol extension. This shouldn't be required if using virt-manager only. Ideally virt-manager should not even show this config option by default. + +Yes, it works without selecting a keyboard on my machine with a french keyboard. + +But perhaps Aditya has explicitly selected another keyboard than "fr" or "Auto"? + +Aditya, does the problem still persist? If so, could you please provide the QEMU command line as requested by Daniel? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1863710 b/results/classifier/105/mistranslation/1863710 new file mode 100644 index 000000000..20bff0ee8 --- /dev/null +++ b/results/classifier/105/mistranslation/1863710 @@ -0,0 +1,33 @@ +mistranslation: 0.741 +graphic: 0.706 +device: 0.691 +semantic: 0.636 +network: 0.548 +instruction: 0.534 +other: 0.471 +socket: 0.409 +boot: 0.296 +vnc: 0.261 +KVM: 0.253 +assembly: 0.124 + +qemu 4.2 does not process discard(trim) commands + +I'm using Arch Linux with qemu 4.2 and blktrace to monitor discard commands as they are sent to the hardware. Blktrace shows nothing as the VM is trimming the SSDs. + +I downgraded to qemu 4.1.1 and blktrace shows lots of discard commands as the VM is trimming. + +Kernel version is 5.5.4. + +Attached is the libvirt xml. + + + + + +How did you start QEMU? Does this still happen with the latest version of QEMU? + +I mean: Please provide the QEMU command line parameters ... is this also reproducible without libvirt? ... otherwise it might also be a problem in libvirt instead... + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1864704 b/results/classifier/105/mistranslation/1864704 new file mode 100644 index 000000000..52c7a4b28 --- /dev/null +++ b/results/classifier/105/mistranslation/1864704 @@ -0,0 +1,65 @@ +mistranslation: 0.713 +other: 0.656 +semantic: 0.563 +assembly: 0.536 +vnc: 0.526 +network: 0.524 +instruction: 0.484 +graphic: 0.478 +KVM: 0.453 +device: 0.441 +boot: 0.356 +socket: 0.326 + +No compatible -machine option in qemu-system-ppc64 for e6500 core + +Hi, + +I'm trying to use qemu-system-ppc64 for emulating a QorIQ T2080 (with e6500 cores). +However, I couldn't find any -machine option that matches -cpu e6500 option, which are listed below: + +C:\Program Files\qemu>qemu-system-ppc64 -machine help +Supported machines are: +40p IBM RS/6000 7020 (40p) +bamboo bamboo +g3beige Heathrow based PowerMAC +mac99 Mac99 based PowerMAC +mpc8544ds mpc8544ds +none empty machine +powernv8 IBM PowerNV (Non-Virtualized) POWER8 +powernv IBM PowerNV (Non-Virtualized) POWER9 (alias of powernv9) +powernv9 IBM PowerNV (Non-Virtualized) POWER9 +ppce500 generic paravirt e500 platform +prep PowerPC PREP platform (deprecated) +pseries-2.1 pSeries Logical Partition (PAPR compliant) +pseries-2.10 pSeries Logical Partition (PAPR compliant) +pseries-2.11 pSeries Logical Partition (PAPR compliant) +pseries-2.12 pSeries Logical Partition (PAPR compliant) +pseries-2.12-sxxm pSeries Logical Partition (PAPR compliant) +pseries-2.2 pSeries Logical Partition (PAPR compliant) +pseries-2.3 pSeries Logical Partition (PAPR compliant) +pseries-2.4 pSeries Logical Partition (PAPR compliant) +pseries-2.5 pSeries Logical Partition (PAPR compliant) +pseries-2.6 pSeries Logical Partition (PAPR compliant) +pseries-2.7 pSeries Logical Partition (PAPR compliant) +pseries-2.8 pSeries Logical Partition (PAPR compliant) +pseries-2.9 pSeries Logical Partition (PAPR compliant) +pseries-3.0 pSeries Logical Partition (PAPR compliant) +pseries-3.1 pSeries Logical Partition (PAPR compliant) +pseries-4.0 pSeries Logical Partition (PAPR compliant) +pseries-4.1 pSeries Logical Partition (PAPR compliant) +pseries pSeries Logical Partition (PAPR compliant) (alias of pseries-4.2) +pseries-4.2 pSeries Logical Partition (PAPR compliant) (default) +ref405ep ref405ep +sam460ex aCube Sam460ex +taihu taihu +virtex-ml507 Xilinx Virtex ML507 reference design + +I am wondering if anyone knows that is if any of them can be selected for such emulation? Thank you! + +Try "-M ppce500 -cpu e6500" + +Thank you very much for your reply, Laurent. Does it mean that we can just use "-M ppce500 -cpu e6500" and for other options, there is no need to change? Is there any approach to verify this setup (for example, with a bare metal elf running in T2080)? Thanks again! + +You could try to build an image for this machine with buildroot (see https://buildroot.org/). Anyway, I'm closing this ticket now since this was not a bug. + diff --git a/results/classifier/105/mistranslation/1864955 b/results/classifier/105/mistranslation/1864955 new file mode 100644 index 000000000..2bb576fac --- /dev/null +++ b/results/classifier/105/mistranslation/1864955 @@ -0,0 +1,65 @@ +mistranslation: 0.957 +other: 0.911 +semantic: 0.897 +graphic: 0.861 +instruction: 0.845 +device: 0.742 +socket: 0.720 +assembly: 0.585 +network: 0.540 +vnc: 0.510 +boot: 0.489 +KVM: 0.346 + +bundle QEMU installer with HAXM accelerator for Windows + +As you probably know HAXM is an accelerator for Windows. + +https://www.qemu.org/2017/11/22/haxm-usage-windows/ + +Currently it is required to first install QEMU and then install HAXM. + +For a better out of the box user experience on the Windows platform it would be nice if QEMU and HAXM would be installed by the same installer. + +Apparently HAXM uses the BSD 3-Clause License with the 3rd clause that "prohibits others from using the name of the project or its contributors to promote derived products without written consent." + +I think licensing is a non-issue. + +That is probably a quote from the github license summary at https://github.com/intel/haxm/blob/master/LICENSE + +> A permissive license similar to the BSD 2-Clause License, but with a 3rd clause that prohibits others from using the name of the project or its contributors to promote derived products without written consent. + +I would ignore whatever github says "This is not legal advice. Learn more about repository licenses." Their summary might have good intentions but cause confusion. Only github mentions "project". The actual license text does not. + +The actual text of the third clause in the license being: + +> Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. + +This should be easy to comply with. + +One could would wrap that clause into quotes (") to put it into a google search engine. + +This clause is OSI approved since included in BSD-3-Clause license: + +https://opensource.org/licenses/BSD-3-Clause + +Debian takes being Free / Libre / Open Source very serious too. Search term: + +> site:debian.org "Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission." + +https://ftp-master.debian.org/licenses/good/bsd/ + +FSF also does not have an issue with it. + +> site:fsf.org "Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission." + +3 authorities don't have an issue with modified BSD license (without advertising clause). + +Rather, the QEMU installer doesn't need to have HAXM in its file name. + +It may or may not be good idea to make HAXM an opt-in or opt-out in the installer. I'd argue opt-out if anything. But ideally for usability there is no need to mention HAXM. Things would just work out of the box. + +As a role model for usability I'd recommend VirtualBox. Their installer also doesn't ask/show "enable acceleration" or "VirtualBox includes QEMU" or other components in prominent places. + +The QEMU project itself does not provide any binaries for Windows, so I'm closing this ticket now. There are several people who provide binaries for Windows, so if you want to get one of these changed, please get in touch with the corresponding person who offers that binary instead. + diff --git a/results/classifier/105/mistranslation/1866870 b/results/classifier/105/mistranslation/1866870 new file mode 100644 index 000000000..83f367608 --- /dev/null +++ b/results/classifier/105/mistranslation/1866870 @@ -0,0 +1,831 @@ +mistranslation: 0.887 +semantic: 0.872 +graphic: 0.835 +other: 0.833 +assembly: 0.790 +instruction: 0.790 +device: 0.783 +boot: 0.774 +socket: 0.759 +KVM: 0.757 +vnc: 0.750 +network: 0.748 + +KVM Guest pauses after upgrade to Ubuntu 20.04 + +As outlined here: https://bugs.launchpad.net/qemu/+bug/1813165/comments/15 + +After upgrade, all KVM guests are in a default pause state. Even after forcing them off via virsh, and restarting them the guests are paused. + +These Guests are not nested. + +A lot of diganostic information are outlined in the previous bug report link provided. The solution mentioned in previous report had been allegedly integrated into the downstream updates. + + + +Hi tstrike, +thanks for the report. +I have slightly modified the description and changed the bug tasks accordingly for you. + +I first checked the related known fixes from the old case that is linked. +Just in case if we might miss one in Ubuntu 20.04 that you are using. + + +Kernel: +=> https://marc.info/?l=kvm&m=155085391830663&w=2 +Tested and verified https://bugs.launchpad.net/qemu/+bug/1813165/comments/13 +This got upstream and is in: +$ git describe --contains ad7dc69aeb231 +v5.0-rc8~1^2~2 +That we'd clearly have in Focal being on 5.4 + +qemu +https://git.qemu.org/?p=qemu.git;a=commit;h=9c1f8f4493e8355d0e48f7d1eebdf86893ba082d +Other fixes related to the topic are in qemu 2.8 + +On seabios disabling of SMM +- https://bugzilla.redhat.com/show_bug.cgi?id=1378006 +- https://bugzilla.redhat.com/show_bug.cgi?id=1464654#c21 +The following is from >=1.12.0-1 (was enabled by default before) +There is a small (for old qemu) and large binary (new qemu): + 42 build/bios.bin: + 43 # A stripped-down version of bios, to fit in 128Kb, for qemu <= 1.7 + 44 »···$(call build-bios,bios,QEMU=y ROM_SIZE=128 PVSCSI=n BOOTSPLASH=n XEN=n USB_OHCI=n USB_XHCI=n USB_UAS=n SDCARD=n TCGBIOS=n MPT_SCSI=n NVME=n USE_SMM=n VGAHOOKS=n) + 45 build/bios-256k.bin: + 46 »···$(call build-bios,bios,QEMU=y ROM_SIZE=256) + +Note: if we are out of options we could try testing to set USE_SMM=n here, but lets check other details first. + +But as already explained on the linked bug 1813165: +"If you're seeing "KVM internal error. Suberror: 1" it can be multiple things, not necessarily the same bug." + +Copied here from the other bug about the system setup that is in use: + +L0 DistroRelease: Ubuntu 20.04 on Kernel Linux 5.4.0-14-generic x86_64 +L1 3 guests Windows 10, Centos 8 +No L2s +No guests are enabled for UEFI Boot + +libvirt: 6.0.0-0ubuntu4 +qemu 1:4.2-3ubuntu1 + +Issue triggers without nesting (ensured via modprobe kvm_intel nested=) + +@tstrike - can you trigger the same issue with all your guests? +You list Windows and Centos guests, does it triggers with Centos as well or only the Windows guests? +Also if you have a chance (just to be sure) does it trigger with an Ubuntu guest as well? This would help for people retrying not using a case that doesn't even trigger in your setup. + +@tstrike - you seem to hit this while starting your guest through libvirt. +Could you please attach your guest XML so that we can try to recreate this case? + $ virsh dumpxml <guestname> +That will help when trying to recreate your case. + +@tstrike +It would also be helpful to get your qemu commandline as well as any further messages qemu might have reported. +You'll find that in the per guest log file at: + $ cat /var/log/libvirt/qemu/<guestname>.log + +If you could report all that here that should be useful for everyone tracking this bug. + +@tstrike: finally for the sake of apparmor denials or any other odd error that might be mentioned in there attaching the output of `dmesg` on your host might be useful as well. + +Christian, + +Thanks for getting my report in the proper syntax. I would be extremely happy to follow through on the tasks you laid out to me. Give me about 3 hours and I will update the report with the items requested. + + + + + + + + + + + + + +Thank you @tstrike: + +In your logs I see a bunch of qemu warnings right at the beginning: +2020-02-12T15:09:37.773025Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48FH).vmx-exit-load-perf-global-ctrl [bit 12] +2020-02-12T15:09:37.773107Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(490H).vmx-entry-load-perf-global-ctrl [bit 13] +2020-02-12T15:09:37.774800Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48FH).vmx-exit-load-perf-global-ctrl [bit 12] +2020-02-12T15:09:37.774821Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(490H).vmx-entry-load-perf-global-ctrl [bit 13] +2020-02-12T15:09:38.024821Z qemu-system-x86_64: warning: Unknown firmware file in legacy mode: etc/msr_feature_control + +And then a crash like: +KVM internal error. Suberror: 1 +emulation failure +EAX=00000000 EBX=00000000 ECX=000086d4 EDX=00000000 +ESI=00000000 EDI=00000000 EBP=000086d4 ESP=00006d7c +EIP=00007acf EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0000 00000000 ffffffff 00809300 +CS =f000 000f0000 ffffffff 00809b00 +SS =0000 00000000 ffffffff 00809300 +DS =0000 00000000 ffffffff 00809300 +FS =0000 00000000 ffffffff 00809300 +GS =0000 00000000 ffffffff 00809300 +LDT=0000 00000000 0000ffff 00008200 +TR =0000 00000000 0000ffff 00008b00 +GDT= 000f6200 00000037 +IDT= 00000000 000003ff +CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000000 +Code=b8 90 d9 00 00 66 e8 6b f7 ff ff 66 b8 0a 00 00 00 e9 61 f2 <f3> 0f 1e fb 66 57 66 56 66 53 66 53 66 89 c7 67 66 89 14 24 66 89 ce 66 e8 15 f8 ff ff 88 + +Reproduced via attempt to install KVM Guest F31 Server on Ubuntu 20.04 (bare metal) + +I tried with a guest XML matching yours (other than disk setup). +I didn't get those errors you reported even when using your config. + + +Notable differences to my default - your guest has: +- a rather old chip type (Penryn is a 2007 chip) +- a rather old machine type (uses xenial which matches ~pc-i440fx-2.5) +This probably based on when the system was created. +But since you also have the same issues on the windows guest which has the modern: + <type arch='x86_64' machine='pc-q35-4.2'>hvm</type> + <cpu mode='host-model' check='partial'/> +So this isn't a route we need to go down... + + +Note: I tried this on kernel 5.4.0-14-generic with some common not too old & not too new chips +- Intel(R) Xeon(R) CPU E5-2620 +- AMD Opteron(tm) Processor 4226 + +Then I remembered that you followed to disable nesting and after all vmx-* you see in the warnings could be related. + +I ran this and restarted my guests: +# sudo rmmod kvm_intel +# sudo modprobe kvm_intel nested=0 +or +# sudo rmmod kvm_amd +# sudo modprobe kvm_amd nested=0 + +Even then I didn't get the same warnings or crashes you got. + +FYI: maybe related (similar symptom - which could be anything as we know, but still worth a link): https://bugzilla.redhat.com/show_bug.cgi?id=1718584 + +Thanks Boris for chiming in! +Maybe it is something in the guest (or the way virt-manager sets things up) after all - will install an F31 via virt-manager as well ... + +I've got the same issue starting guest via virt-install even with serial console. + +I fetched +https://download.fedoraproject.org/pub/fedora/linux/releases/31/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-31-1.9.iso + +And installed it on Ubuntu 20.04 via virt-manager (keeping all things on its default). + +- New +- Local Media +- select ISO (Autodetects F31) +- Forward, Forward, Forward, Finish + +Now warnings: +sudo cat /var/log/libvirt/qemu/fedora31.log | grep warning +<empty> + +And it just works, the installer is on the graphical UI and waiting for me. + +@Boris - in your log I've seen that you also got the Penryn cpu which I find odd. +"-cpu Penryn,vme=on,vmx=on,x2apic=on,tsc-deadline=on,xsave=on,hypervisor=on,arat=on,tsc-adjust=on,arch-capabilities=on,skip-l1dfl-vmentry=on \" +Assuming you also only used default I wonder how it got to that, maybe the reason for that is the same reason that eventually triggers the error. +But virt-manager/libvirt would usually just do a best-fit (for me Haswell-noTSX-IBRS). + + +@Boris and @tstrike Could you both please report: +$ virsh capabilities +$ virsh domcapabilities +$ sudo qemu-system-x86_64 --enable-kvm --nographic --nodefaults -S -qmp-pretty stdio +{"execute":"qmp_capabilities"} +{"execute":"query-cpu-definitions"} +Note: the command seems to hang as you are on QMP, then just enter the two commands below one by one. This will add "qemu's explanation why a given cpu is usable or not" + + + + + +This particular command seems to hang on: + +qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5] +qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2] + +I tried to execute (thinking I was in a shell): + +{"execute":"qmp_capabilities"} +{"execute":"query-cpu-definitions"} + + +I might have misinterpreted what you wanted me to do. + +Thanks a lot . I will do it at my earliest convenience this night. Haswell i4770 is installed on small server 32 GB. Department's policy doesn't allow me to test Ubuntu whichever release on bare metal. I could test only on outdated CPU's box and it seems to be a core reason. + +Done on Penryn's box + +Thanks Boris! + +@tstrike - is your system also "really an old penryn" or is it something newer? +Maybe share /proc/cpuinfo? + +tstrike39@islandhealthcenter-media:~$ sudo cat /proc/cpuinfo +processor : 0 +vendor_id : GenuineIntel +cpu family : 6 +model : 23 +model name : Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz +stepping : 10 +microcode : 0xa0b +cpu MHz : 2416.548 +cache size : 3072 KB +physical id : 0 +siblings : 4 +core id : 0 +cpu cores : 4 +apicid : 0 +initial apicid : 0 +fpu : yes +fpu_exception : yes +cpuid level : 13 +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 ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm pti tpr_shadow vnmi flexpriority dtherm +bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit +bogomips : 5303.23 +clflush size : 64 +cache_alignment : 64 +address sizes : 36 bits physical, 48 bits virtual +power management: + +processor : 1 +vendor_id : GenuineIntel +cpu family : 6 +model : 23 +model name : Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz +stepping : 10 +microcode : 0xa0b +cpu MHz : 2010.620 +cache size : 3072 KB +physical id : 0 +siblings : 4 +core id : 2 +cpu cores : 4 +apicid : 2 +initial apicid : 2 +fpu : yes +fpu_exception : yes +cpuid level : 13 +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 ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm pti tpr_shadow vnmi flexpriority dtherm +bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit +bogomips : 5303.23 +clflush size : 64 +cache_alignment : 64 +address sizes : 36 bits physical, 48 bits virtual +power management: + +processor : 2 +vendor_id : GenuineIntel +cpu family : 6 +model : 23 +model name : Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz +stepping : 10 +microcode : 0xa0b +cpu MHz : 2419.534 +cache size : 3072 KB +physical id : 0 +siblings : 4 +core id : 1 +cpu cores : 4 +apicid : 1 +initial apicid : 1 +fpu : yes +fpu_exception : yes +cpuid level : 13 +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 ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm pti tpr_shadow vnmi flexpriority dtherm +bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit +bogomips : 5303.23 +clflush size : 64 +cache_alignment : 64 +address sizes : 36 bits physical, 48 bits virtual +power management: + +processor : 3 +vendor_id : GenuineIntel +cpu family : 6 +model : 23 +model name : Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz +stepping : 10 +microcode : 0xa0b +cpu MHz : 1988.790 +cache size : 3072 KB +physical id : 0 +siblings : 4 +core id : 3 +cpu cores : 4 +apicid : 3 +initial apicid : 3 +fpu : yes +fpu_exception : yes +cpuid level : 13 +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 ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm pti tpr_shadow vnmi flexpriority dtherm +bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit +bogomips : 5303.23 +clflush size : 64 +cache_alignment : 64 +address sizes : 36 bits physical, 48 bits virtual +power management: + + + +It detects host as Penryn as well for @tstrike. +Which is fine if it is a chip of around that era. +He reported to have an "Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz" +And for that chip the detection and chip used might be correct. + +So to summarize all repro fails, but on Penryn ERA chips 2/2 cases trigger the bug. + +I wonder if one that wants to reproduce needs a system with such a chip as well then to test and trigger this. + +There should be plenty of people on CC as this is mirrored to qemu-devel due to the upstream qemu task. Is there an microarchitectural x86 specialist that knows if the chips of that generation have some special issues in regard to VMX that might explain what we see here? + +It would be great if everyone could ask around for more systems with chips of that era. +Maybe we can further bisect which work and which will fail. + +I tried launching a focal vm on a focal host, and the vm launched but is in a paused state. + +Attached is its log. + +This is on an old E660 intel core system. + +/proc/cpuinfo + + +I also have these two apparmor denied messages in dmesg: +[ 1380.529549] audit: type=1400 audit(1584023445.093:139): apparmor="DENIED" operation="open" profile="libvirt-aa346a1d-8caa-4c55-bef9-c3acbe17bdac" name="/" pid=19712 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=64055 ouid=0 +[ 1380.529856] audit: type=1400 audit(1584023445.093:140): apparmor="DENIED" operation="open" profile="libvirt-aa346a1d-8caa-4c55-bef9-c3acbe17bdac" name="/sys/bus/nd/devices/" pid=19712 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=64055 ouid=0 + + +And one last bit of info, this system booted with mitigations=off. + +virsh capabilities + +virsh domcapabilities + +AppArmor is completely disabled on my server. + +After changing cpu to <cpu mode='host-model'/>: + + +I got this log (still in a paused state): +char device redirected to /dev/pts/3 (label charserial0) +2020-03-12T15:06:22.560159Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48EH).vmx-vnmi-pending [bit 22] +2020-03-12T15:06:22.560708Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48EH).vmx-secondary-ctls [bit 31] +2020-03-12T15:06:22.560971Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48BH).vmx-apicv-xapic [bit 0] +2020-03-12T15:06:22.561208Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48DH).vmx-vnmi [bit 5] +2020-03-12T15:06:22.561392Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(480H).vmx-ins-outs [bit 54] +KVM internal error. Suberror: 1 +emulation failure +EAX=00000000 EBX=00000000 ECX=000086d4 EDX=00000000 +ESI=00000000 EDI=00000000 EBP=000086d4 ESP=00006d7c +EIP=00007acf EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0000 00000000 ffffffff 00809300 +CS =f000 000f0000 ffffffff 00809b00 +SS =0000 00000000 ffffffff 00809300 +DS =0000 00000000 ffffffff 00809300 +FS =0000 00000000 ffffffff 00809300 +GS =0000 00000000 ffffffff 00809300 +LDT=0000 00000000 0000ffff 00008200 +TR =0000 00000000 0000ffff 00008b00 +GDT= 000f6200 00000037 +IDT= 00000000 000003ff +CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000000 +Code=b8 90 d9 00 00 66 e8 6b f7 ff ff 66 b8 0a 00 00 00 e9 61 f2 <f3> 0f 1e fb 66 57 66 56 66 53 66 53 66 89 c7 67 66 89 14 24 66 89 ce 66 e8 15 f8 ff ff 88 + + +By using host-model Andreas also was able to get the same signature: + +2020-03-12T15:06:22.560159Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48EH).vmx-vnmi-pending [bit 22] +2020-03-12T15:06:22.560708Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48EH).vmx-secondary-ctls [bit 31] +2020-03-12T15:06:22.560971Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48BH).vmx-apicv-xapic [bit 0] +2020-03-12T15:06:22.561208Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48DH).vmx-vnmi [bit 5] +2020-03-12T15:06:22.561392Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(480H).vmx-ins-outs [bit 54] +KVM internal error. Suberror: 1 +emulation failure +EAX=00000000 EBX=00000000 ECX=000086d4 EDX=00000000 +ESI=00000000 EDI=00000000 EBP=000086d4 ESP=00006d7c +EIP=00007acf EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0000 00000000 ffffffff 00809300 +CS =f000 000f0000 ffffffff 00809b00 +SS =0000 00000000 ffffffff 00809300 +DS =0000 00000000 ffffffff 00809300 +FS =0000 00000000 ffffffff 00809300 +GS =0000 00000000 ffffffff 00809300 +LDT=0000 00000000 0000ffff 00008200 +TR =0000 00000000 0000ffff 00008b00 +GDT= 000f6200 00000037 +IDT= 00000000 000003ff +CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000000 +Code=b8 90 d9 00 00 66 e8 6b f7 ff ff 66 b8 0a 00 00 00 e9 61 f2 <f3> 0f 1e fb 66 57 66 56 66 53 66 53 66 89 c7 67 66 89 14 24 66 89 ce 66 e8 15 f8 ff ff 88 + +So the warnings seem to depend a bit on which chip type we try to be to the guest. +We can ignore them for now. + +What stays is the emulation error on this kind of chip. +I'll try to write up some tests to check different qemu and kernel levels to further corner what we are looking at. + +Penryn's architecture confirmed + + +Seems to work fine on i4790 (Haswell) box. + +Yeah @Boris - it really seems to be an issue bound to the Merom/Penryn processor generation. + +I asked Andreas to check through some kernels and qemu versions so that we maybe eventually can consider bisecting something. But that will take a bit of time. + +Of course everyone able to spend some time can consider checking a few kernels of [1] as well (probably the easiest test to begin with). + +Still if there is an x86-microarchitecture expert out there that say "ah penryn, I know we added/dropped ... " please speak up :-) + +[1]: https://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D + +The vmx things make me wonder about a fix Paolo did a while ago for enabling inidivudal vmx features rather than vmx as a whole; but I can't remember if that was a kernel or qemu fix. + +One thing I notice, that may be a red-herring, all of the machine code in the errors are 'f3 0f 1e fb' which is the new 'endbr32' security instruction - but that's really a rep nop, that I thought old instructions can handle anyway?? + +Andreas was so kind to try kenels 4.4, 4.15 and 5.6 all fail (with qemu 4.2) +He then tried Eoan (qemu 4.0) and Focal (qemu 4.2). +4.0 worked and 4.2 failed. + +We will set up a bisect run on Monday and hopefully find the offending change. + +@David - I agree that the messages might be a red-herring, but to be sure was that fix between 4.0 and 4.2? + +I think the one I was thinking of is 0723cc8a5558c94388db75ae1f4991314914edd3 which is in a 4.2.0 rc +and there was 2605188240f939fa9ae9353f53a0985620b34769 - but that's a different crash to what you have. + +So hmm. + + +Thanks David! + +While bisecting on upstream git with just "-cpu Penryn" we have seen that it always works there. +So it might be an interaction with some Ubuntu build/packaging/configure detail together with these old chips. + +While we still can't be sure if the VMX warnings are a red-herring chances are that only "-cpu Penryn,vmx=on" will trigger the issue - Andreas will test and bisect with that once he is back online - we will see if that is any different. + +I'll also build a Ubuntu'esque 4.2 with the Penryn changes of [1] reverted just to complete the interim picture of our testing. That is available for testing at [2]. Further I added a Ubuntu build with rather crude reverts of almost all VMX related 4.2 changes. + +[1]: https://git.qemu.org/?p=qemu.git;a=commit;h=0723cc8a5558c94388db75ae1f4991314914edd3 +[2]: https://launchpad.net/~paelzer/+archive/ubuntu/bug-1866870-qemu-penryn-crash +[3]: https://launchpad.net/~paelzer/+archive/ubuntu/bug-1866870-qemu-penryn-crash-fullreverts + +No luck when testing [2]. Reports are attached + +Log file for f31wks guest + +Verification new packages to be installed + + + +The package from the PPA failed the same way for me: + +ubuntu@f1:~$ qemu-system-x86_64 --enable-kvm -cpu Penryn,vmx=on -m 512 --nodefaults --nographic +qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.01H:ECX.sse4.1 [bit 19] +KVM internal error. Suberror: 1 +emulation failure +EAX=00000000 EBX=00000000 ECX=000086d4 EDX=00000000 +ESI=00000000 EDI=00000000 EBP=000086d4 ESP=00006d7c +EIP=00007acf EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0000 00000000 ffffffff 00809300 +CS =f000 000f0000 ffffffff 00809b00 +SS =0000 00000000 ffffffff 00809300 +DS =0000 00000000 ffffffff 00809300 +FS =0000 00000000 ffffffff 00809300 +GS =0000 00000000 ffffffff 00809300 +LDT=0000 00000000 0000ffff 00008200 +TR =0000 00000000 0000ffff 00008b00 +GDT= 000f6200 00000037 +IDT= 00000000 000003ff +CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000000 +Code=b8 90 d9 00 00 66 e8 6b f7 ff ff 66 b8 0a 00 00 00 e9 61 f2 <f3> 0f 1e fb 66 57 66 56 66 53 66 53 66 89 c7 67 66 89 14 24 66 89 ce 66 e8 15 f8 ff ff 88 +^Cqemu-system-x86_64: terminating on signal 2 + +ubuntu@f1:~$ qemu-system-x86_64 --help 2>&1|head -n 1 +QEMU emulator version 4.2.0 (Debian 1:4.2-3ubuntu3~ppa1) +ubuntu@f1:~$ + + +Also crashed with the packages from the other ppa: + +ubuntu@f1:~$ qemu-system-x86_64 --help 2>&1|head -n 1 +QEMU emulator version 4.2.0 (Debian 1:4.2-3ubuntu3~exp1) + +ubuntu@f1:~$ qemu-system-x86_64 --enable-kvm -cpu Penryn,vmx=on -m 512 --nodefaults --nographic +qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.01H:ECX.sse4.1 [bit 19] +KVM internal error. Suberror: 1 +emulation failure +EAX=00000000 EBX=00000000 ECX=000086d4 EDX=00000000 +ESI=00000000 EDI=00000000 EBP=000086d4 ESP=00006d7c +EIP=00007acf EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0000 00000000 ffffffff 00809300 +CS =f000 000f0000 ffffffff 00809b00 +SS =0000 00000000 ffffffff 00809300 +DS =0000 00000000 ffffffff 00809300 +FS =0000 00000000 ffffffff 00809300 +GS =0000 00000000 ffffffff 00809300 +LDT=0000 00000000 0000ffff 00008200 +TR =0000 00000000 0000ffff 00008b00 +GDT= 000f6200 00000037 +IDT= 00000000 000003ff +CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000000 +Code=b8 90 d9 00 00 66 e8 6b f7 ff ff 66 b8 0a 00 00 00 e9 61 f2 <f3> 0f 1e fb 66 57 66 56 66 53 66 53 66 89 c7 67 66 89 14 24 66 89 ce 66 e8 15 f8 ff ff 88 + + +ubuntu@f1:~$ apt-cache policy qemu-kvm +qemu-kvm: + Installed: 1:4.2-3ubuntu3~exp1 + Candidate: 1:4.2-3ubuntu3~exp1 + Version table: + *** 1:4.2-3ubuntu3~exp1 500 + 500 http://ppa.launchpad.net/paelzer/bug-1866870-qemu-penryn-crash-fullreverts/ubuntu focal/main amd64 Packages + 100 /var/lib/dpkg/status + 1:4.2-3ubuntu2 500 + 500 http://br.archive.ubuntu.com/ubuntu focal/main amd64 Packages + + +Ok, upstream tag v4.2.0 and these configure options reproduced the crash: + +export LDFLAGS="-Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m64 -g -Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,--as-needed" +export CFLAGS="-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g" + +Full configure output: https://paste.ubuntu.com/p/Tzq6pDWD9R/ + +$ ./x86_64-softmmu/qemu-system-x86_64 --enable-kvm -cpu Penryn,vmx=on -m 512 --nodefaults --nographic +qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.01H:ECX.sse4.1 [bit 19] +qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48EH).vmx-vnmi-pending [bit 22] +qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48EH).vmx-secondary-ctls [bit 31] +qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48BH).vmx-apicv-xapic [bit 0] +qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48BH).vmx-wbinvd-exit [bit 6] +qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48DH).vmx-vnmi [bit 5] +qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48FH).vmx-exit-load-perf-global-ctrl [bit 12] +qemu-system-x86_64: warning: host doesn't support requested feature: MSR(490H).vmx-entry-load-perf-global-ctrl [bit 13] +qemu-system-x86_64: warning: host doesn't support requested feature: MSR(480H).vmx-ins-outs [bit 54] +KVM internal error. Suberror: 1 +emulation failure +EAX=00000000 EBX=00000000 ECX=000086d4 EDX=00000000 +ESI=00000000 EDI=00000000 EBP=000086d4 ESP=00006d7c +EIP=00007acf EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0000 00000000 ffffffff 00809300 +CS =f000 000f0000 ffffffff 00809b00 +SS =0000 00000000 ffffffff 00809300 +DS =0000 00000000 ffffffff 00809300 +FS =0000 00000000 ffffffff 00809300 +GS =0000 00000000 ffffffff 00809300 +LDT=0000 00000000 0000ffff 00008200 +TR =0000 00000000 0000ffff 00008b00 +GDT= 000f6200 00000037 +IDT= 00000000 000003ff +CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000000 +Code=b8 90 d9 00 00 66 e8 6b f7 ff ff 66 b8 0a 00 00 00 e9 61 f2 <f3> 0f 1e fb 66 57 66 56 66 53 66 53 66 89 c7 67 66 89 14 24 66 89 ce 66 e8 15 f8 ff ff 88 +^Cqemu-system-x86_64: terminating on signal 2 + + +I've tested smoe more cmbinations and found that I van have v4.2 work on focal. +Eventually I have realized that when I install start the qemu from Ubuntu not only that but also the formerly working build of v4.2.0 from git start to fail (without rebuilding). + +A bit of package bisect later I found seabios to be related. +Focal is at 1.13.0-1 +Eoan is at 1.12.0-1 + +After I knew that I verified and found it really only triggers on seabios 1.13.0. + +With 1.13 I was also able to break the qemu v4.0.0 git build on eoan. +As well as the packaged qemu in Eoan. + +So it seems we are actually looking for a problem of seabios (instead of qemu) with the Penryn chip. + +I'll look at their changelog and bisect that tomorrow as time permits + +I wanted to make sure why different qemu configs make it trigger or not, and after finding seabios to be related the candidates were obvious. + +Default config gets us: +BIOS directory /usr/local/share/qemu + +The long conf had: +--firmwarepath=/usr/share/qemu:/usr/share/seabios:/usr/lib/ipxe/qemu + +Adding that to the short config which had most things disabled made it break as well. +Since it has much less moving parts having most other features disabled I'll continue to use that. + + +With that confirmed I checked if I can just point to a bios to break it, and indeed adding + -bios /root/seabios_1.12.0-1/usr/share/seabios/bios.bin + -bios /root/seabios_1.13.0-1/usr/share/seabios/bios.bin +respectively is a make or break change. + + + +As a next step I reproduced the error with seabios rel-1.13.0 from https://review.coreboot.org/seabios.git. +It crashes as well. + +But to make this puzzle even more interesting rel-1.12.0 from the same git crashes as well. +I wonder where this trip might end, from qemu to seabios to ... compiler? + +Turns out 1.12 is a fairly old build and the working version in Ubuntu was from in Disco, therefore about a year ago. +=> https://launchpad.net/ubuntu/+source/seabios/1.12.0-1/+build/16284605 + +Therefore I built it in Eoan and even Disco. +As an overview: +Disco: gcc 4:8.3.0-1ubuntu3 binutils 2.32-7ubuntu4 +Eoan: gcc 4:9.2.1-3.1ubuntu1 binutils 2.33-2ubuntu1.2 +Focal: gcc 4:9.2.1-3.1ubuntu1 binutils 2.34-4ubuntu1 + +I ended up with these binaries to test: +./git-built-in-eoan/rel-1.12/bios.bin Breaks +./git-built-in-eoan/rel-1.13/bios.bin Breaks +./git-built-in-disco/rel-1.13/bios.bin Works +./git-built-in-disco/rel-1.12/bios.bin Works +./git-built-in-focal/head/bios.bin Breaks +./git-built-in-focal/rel-1.12/bios.bin Breaks +./git-built-in-focal/rel-1.13/bios.bin Breaks +./packaging/disco-seabios_1.12.0-1/bios.bin Works +./packaging/focal-seabios_1.13.0-1/bios.bin Breaks + +To summarize: +- qemu breaks on chips of the Penryn generation +- it only breaks if the seabios bios is executed +- does not really depend on seabios or qemu version +- but it depends on seabios build environment + +That's getting more fun :-) +You could look at whether seabios's config works out hte same in the two environments, or whether something makes use of new build flags - try looking at the gcc lines that are invoked in the good/bad cases and see if they're passing any options that the other doesn't. + + +Starting from the Disco build env that I had I changed the packages + +Step #1 binutils: +Unpacking binutils-x86-64-linux-gnu (2.33-2ubuntu1.2) over (2.32-7ubuntu4) ... +Unpacking libbinutils:amd64 (2.33-2ubuntu1.2) over (2.32-7ubuntu4) ... +Unpacking binutils (2.33-2ubuntu1.2) over (2.32-7ubuntu4) ... +Unpacking binutils-common:amd64 (2.33-2ubuntu1.2) over (2.32-7ubuntu4) ... + +=> Still working + +Step #2 gcc: +Unpacking libubsan1:amd64 (9.2.1-9ubuntu2) over (9.1.0-2ubuntu2~19.04) ... +Unpacking libtsan0:amd64 (9.2.1-9ubuntu2) over (9.1.0-2ubuntu2~19.04) ... +Unpacking gcc-9-base:amd64 (9.2.1-9ubuntu2) over (9.1.0-2ubuntu2~19.04) ... +Unpacking libstdc++6:amd64 (9.2.1-9ubuntu2) over (9.1.0-2ubuntu2~19.04) ... +Unpacking libquadmath0:amd64 (9.2.1-9ubuntu2) over (9.1.0-2ubuntu2~19.04) ... +Unpacking liblsan0:amd64 (9.2.1-9ubuntu2) over (9.1.0-2ubuntu2~19.04) ... +Unpacking libitm1:amd64 (9.2.1-9ubuntu2) over (9.1.0-2ubuntu2~19.04) ... +Unpacking libgomp1:amd64 (9.2.1-9ubuntu2) over (9.1.0-2ubuntu2~19.04) ... +Unpacking libcc1-0:amd64 (9.2.1-9ubuntu2) over (9.1.0-2ubuntu2~19.04) ... +Unpacking libatomic1:amd64 (9.2.1-9ubuntu2) over (9.1.0-2ubuntu2~19.04) ... +Unpacking libasan5:amd64 (9.2.1-9ubuntu2) over (9.1.0-2ubuntu2~19.04) ... +Unpacking libgcc1:amd64 (1:9.2.1-9ubuntu2) over (1:9.1.0-2ubuntu2~19.04) ... +Unpacking libisl21:amd64 (0.21-2) ... +Unpacking cpp-9 (9.2.1-9ubuntu2) ... +Unpacking libgcc-9-dev:amd64 (9.2.1-9ubuntu2) ... +Unpacking gcc-9 (9.2.1-9ubuntu2) ... +Unpacking libstdc++-9-dev:amd64 (9.2.1-9ubuntu2) ... +Unpacking g++-9 (9.2.1-9ubuntu2) ... +Unpacking g++ (4:9.2.1-3.1ubuntu1) over (4:8.3.0-1ubuntu3) ... +Unpacking gcc (4:9.2.1-3.1ubuntu1) over (4:8.3.0-1ubuntu3) ... +Unpacking cpp (4:9.2.1-3.1ubuntu1) over (4:8.3.0-1ubuntu3) ... + +=> now it is breaking + +One thing that we have seen to cause breakage in other cases was the new default to enable: + -fcf-protection + +The code already carries quite a bunch of similar "no" rules: +COMMONCFLAGS += $(call cc-option,$(CC),-nopie,) +COMMONCFLAGS += $(call cc-option,$(CC),-fno-pie,) +COMMONCFLAGS += $(call cc-option,$(CC),-fno-stack-protector,) +COMMONCFLAGS += $(call cc-option,$(CC),-fno-stack-protector-all,) +COMMONCFLAGS += $(call cc-option,$(CC),-fstack-check=no,) +COMMONCFLAGS += $(call cc-option,$(CC),-Wno-address-of-packed-member,) + +Lets add to that: +COMMONCFLAGS += $(call cc-option,$(CC),-fcf-protection=none,) + +=> That made it work \o/ ! + +I *think* it's the cf-protection that's adding the endbr32 instructions that I spotted as being the failing instruction each time; but I don't understand why they would be CPU type specific. + +Sent to seabios for their consideration: +=> https://<email address hidden>/thread/IXAWMA2HWW75LSR3NBBYQKWT3TI5WVVP/ + +I deleted the experimental PPAs that we had and created a new one with a new seabios: +=> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3982 + +An MP is open to fix this in Focal: +=> https://code.launchpad.net/~paelzer/ubuntu/+source/seabios/+git/seabios/+merge/380881 + +This bug was fixed in the package seabios - 1.13.0-1ubuntu1 + +--------------- +seabios (1.13.0-1ubuntu1) focal; urgency=medium + + * d/p/lp-1866870-build-use-fcf-protection-none-when-available.patch + fix breakage on older chips due to fcf-protection (LP: #1866870) + + -- Christian Ehrhardt <email address hidden> Thu, 19 Mar 2020 13:10:10 +0100 + +Can I just apt update && apt upgrade to get this fix or do I need to patch? + +apt-get will be enough once it's published, and looks like it just was published. + +Works for me. F31 KVM guest is installing on Q9550 box. + +I can confirm that this bug has been fixed (zapped). Thank you all for your hard work and determination. A job well done indeed! As a former programmer I love you all's zeal for attacking this bug. + +As a side note, knowing what you all go through, I always look things up, walk through at least level 1 stuff and provide logfiles. I hope what little I did, help you all resolve this. + +Again my thanks, and I believe is this is where we say, "Please close the bug marked SOLVED". + +Thank you Boris and Tstrike for the report and your help. +It was a great bug to identify and fix before the release of 20.04, I appreciate you using (and hereby testing) it ahead of time! + +Hello! +Unfortunately the bug has apparently reappeared. I have a Windows 10 running in a VM, which after my today's "apt upgrade" goes into pause mode after a few seconds of running time. + +Tail output of my /var/log/libvirt/qemu/win10.log +char device redirected to /dev/pts/1 (label charserial0) +2020-05-05T08:53:23.733051Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48FH).vmx-exit-load-perf-global-ctrl [bit 12] +2020-05-05T08:53:23.733122Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(490H).vmx-entry-load-perf-global-ctrl [bit 13] +2020-05-05T08:53:23.736093Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48FH).vmx-exit-load-perf-global-ctrl [bit 12] +2020-05-05T08:53:23.736110Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(490H).vmx-entry-load-perf-global-ctrl [bit 13] +2020-05-05T08:54:04.912098Z qemu-system-x86_64: terminating on signal 15 from pid 1593 (/usr/sbin/libvirtd) +2020-05-05 08:54:05.112+0000: shutting down, reason=destroyed + + +Apt upgraded packages (from /var/log/apt/history.log): +Start-Date: 2020-05-05 09:32:02 +Commandline: apt upgrade +Requested-By: andreas (1000) +Install: linux-image-5.4.0-29-generic:amd64 (5.4.0-29.33, automatic), linux-modules-extra-5.4.0-29-generic:amd64 (5.4.0-29.33, automatic), linux-headers-5.4.0-29-generic:amd64 (5.4.0-29.33, automatic), linux-modules-5.4.0-29-generic:amd64 (5.4.0-29.33, automatic), linux-headers-5.4.0-29:amd64 (5.4.0-29.33, automatic) +Upgrade: linux-headers-generic:amd64 (5.4.0.28.33, 5.4.0.29.34), linux-libc-dev:amd64 (5.4.0-28.32, 5.4.0-29.33), linux-image-generic:amd64 (5.4.0.28.33, 5.4.0.29.34), linux-generic:amd64 (5.4.0.28.33, 5.4.0.29.34) +End-Date: 2020-05-05 09:33:11 + + +Kind regards, + Andreas + +Hi Andreas, +so the only upgrade you did to trigger this for you was to bump the kernel from 5.4.0-28.33 to 5.4.0-29.34 - nothing else? I have not (yet?) heard other similar reports, but it might be just too early? +At least on my system for now things still work with the new kernel like before. + +I'd recommend filing a new bug, refer to this one as maybe being related and adding the following right away: +- kernel version (you have this here I know) +- qemu/libvirt/seabios/ovmf version (if you don't mind just attach `dpkg -l`) +- guest XML (if using libvirt) otherwise the qemu command-line +- add a cross check and report what happens with other guests configs (e.g. non windows, using + another bios as the former issue was tied to seabios, use different guest CPU types) +- the full /var/log/apt/history.log +- a date when you last started the VM successfully (not just still-had-it-running, but started it) + and the date when it started to fail (probably yesterday then I guess) + +Hi Christian. + +Just filed bug: #1877052 + +Same issue here. I've upgraded my IBM Power ppc64le system to ubuntu 20.04. Now I'm trying to create KVM VMs and whatever I'm doing, the VM is created but before any installation step starts, it's falling into "paused" mode. When trying to resume it, I get: +" +Error unpausing domain: internal error: unable to execute QEMU command 'cont': Resetting the Virtual Machine is required +" + +Any workaround ? Do I need to reinstall Ubuntu 18.04 ? + +Fabrice: That's probably a different error given that this lp seems to be with x86 vmx flags. +Check your /var/log/libvirt/qemu/ on the host to see if there's a particular error shown in the destination qemu after migration. + +David: Indeed ! How stupid I am. I missed the root cause inside QUEMU log file. This was clear enough... +error: kvm run failed Device or resource busy +This is probably because your SMT is enabled. + +So I switch SMT (Power Simultaneous Multi-Threading) off and now it's OK; VMs are running and installing. + +It had been years since I last touched KVM on Power and I lost my reflexes. +So please forget my precedent comment telling I had the same issue on Power platform. It was similar symptoms but not the same problem. + diff --git a/results/classifier/105/mistranslation/1867072 b/results/classifier/105/mistranslation/1867072 new file mode 100644 index 000000000..1ee7e80b4 --- /dev/null +++ b/results/classifier/105/mistranslation/1867072 @@ -0,0 +1,89 @@ +mistranslation: 0.690 +graphic: 0.395 +instruction: 0.320 +semantic: 0.304 +device: 0.297 +other: 0.284 +network: 0.239 +assembly: 0.212 +socket: 0.185 +vnc: 0.175 +boot: 0.127 +KVM: 0.114 + +ARM: tag bits cleared in FAR_EL1 + +The ARM Architecture Reference Manual provides the following for FAR_EL1: + +"For a Data Abort or Watchpoint exception, if address tagging is enabled for the address accessed by the data access that caused the exception, then this field includes the tag." + +However, I have found that the tag bits in FAR_EL1 are always clear, even if the tag bits were set in the original access. + +I can reproduce the problem on both 4.1.1 and master (6e8a73e911f066527e775e04b98f31ebd19db600). + +As it happens, I posted some cleanups for this last week: +https://<email address hidden>/ + +Some of them have been queued to Peter's target-arm.next branch, +but that hasn't made it to master yet. + +Actually, I take that back: Peter has merged my TBI patch set, +and is included in 6e8a73e911f066. + +Do you have a test case? + +Ho hum, I must have been asleep last night. +Peter only merged 7 of 9 patches. The final 2 were re-posted: +https://<email address hidden>/ + +which includes the critical change that affects FAR_ELx. + +With those two patches applied I can no longer reproduce the problem, thanks! + +For posterity, this is how I've been reproducing the problem: + +1. Build a Linux kernel with this patch applied: https://patchwork.kernel.org/patch/11435077/ +2. Run this program under the kernel: + +#include <stdint.h> +#include <stdio.h> +#include <signal.h> + +void handler(int signo, siginfo_t *siginfo, void *context) { + uint32_t *begin = (uint32_t *)context; + uint32_t *end = ((uint32_t *)context) + (sizeof(ucontext_t)/4); + for (uint32_t *i = begin; i != end; ++i) { + printf("%08p %08x\n", i, *i); + } + _exit(0); +} + +int main() { + struct sigaction sa; + sa.sa_sigaction = handler; + sa.sa_flags = SA_SIGINFO; + sigaction(SIGSEGV, &sa, 0); + + return *(int *)((1ULL << 56) + 0x123456); +} + +I would expect this program's output to include something like the following: + +0xffffd5869bd0 46415201 +0xffffd5869bd4 00000010 +0xffffd5869bd8 00123456 +0xffffd5869bdc 01000000 + +But the output that I was seeing with the bad qemu looked like this: + +0xffffd5869bd0 46415201 +0xffffd5869bd4 00000010 +0xffffd5869bd8 00123456 +0xffffd5869bdc 00000000 + +Fix now in master. + +Fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=38d931687fa1 + + diff --git a/results/classifier/105/mistranslation/1868617 b/results/classifier/105/mistranslation/1868617 new file mode 100644 index 000000000..9612de1ed --- /dev/null +++ b/results/classifier/105/mistranslation/1868617 @@ -0,0 +1,51 @@ +mistranslation: 0.884 +other: 0.852 +device: 0.817 +instruction: 0.801 +semantic: 0.793 +graphic: 0.753 +socket: 0.717 +network: 0.671 +boot: 0.582 +vnc: 0.577 +assembly: 0.561 +KVM: 0.505 + +multiseat: route different spice tablet events to distinct vdagents + +docs/multiseat.txt says: + +> Note on spice: Spice handles multihead just fine. But it can't do +> multiseat. For tablet events the event source is sent to the spice +> agent. But qemu can't figure it, so it can't do input routing. +> Fixing this needs a new or extended input interface between +> libspice-server and qemu. For keyboard events it is even worse: The +> event source isn't included in the spice protocol, so the wire +> protocol must be extended to support this. + +I'm not sure exactly what "can't figure it" means, but it looks to me like qemu can't route incoming tablet events from a spice client to distinct vdagent channels. + +I think this part of the process can be fixed within qemu. I've reported https://gitlab.freedesktop.org/spice/spice-gtk/issues/121 to address the issues with the keyboard interface at the protocol level. + +Here are two different ways i can think of to potentially solve this (i'm not qemu hacker, feel free to correct me or propose a better solution): + + - the spicevmc chardev's "name" parameter could be used to identify the agent numerically (e.g. "vdagent:1" instead of "vdagent") + + - the -device virtserialport could identify whether it is connected via a multiseat PCI bridge (pci-bridge-seat) and group it with the other monitor from there. + +Is one of these approaches preferable? + +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/105/mistranslation/1873 b/results/classifier/105/mistranslation/1873 new file mode 100644 index 000000000..08cefdf90 --- /dev/null +++ b/results/classifier/105/mistranslation/1873 @@ -0,0 +1,97 @@ +mistranslation: 0.859 +other: 0.857 +semantic: 0.828 +device: 0.755 +graphic: 0.742 +network: 0.741 +socket: 0.736 +instruction: 0.727 +KVM: 0.720 +assembly: 0.713 +boot: 0.634 +vnc: 0.628 + +igb driver failed to change MTU +Description of problem: +I am using the new IGB model to test sriov inside a virtual machine. + +and when the operator tries to configure MTU of 9000 on the VF I get a kernel crash and the node goes into reboot + +``` +virsh console virt-cluster-worker-0 +Connected to domain 'virt-cluster-worker-0' +Escape character is ^] (Ctrl + ]) +[ 486.776188] kernel BUG at include/linux/skbuff.h:2420! +[ 486.779661] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI +[ 486.781938] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.14.0-284.16.1.el9_2.x86_64 #1 +[ 486.783847] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 +[ 486.785681] RIP: 0010:eth_type_trans+0xd3/0x140 +[ 486.787051] Code: 80 00 00 00 eb c1 8b 47 70 2b 47 74 48 8b 97 c8 00 00 00 83 f8 01 7e 1b 48 85 d2 74 06 66 83 3a ff 74 09 b8 00 04 00 00 eb a5 <0f> 0b b8 00 01 00 00 eb 9c 48 85 ff 74 eb 31 f6 b9 02 00 00 00 48 +[ 486.790542] RSP: 0018:ffffaef200114e30 EFLAGS: 00010283 +[ 486.791726] RAX: 000000000000002e RBX: ffffaef206a38000 RCX: 0000000000000028 +[ 486.793086] RDX: ffff90bb7767a840 RSI: ffff90bc7d6a0000 RDI: ffff90bb413bc600 +[ 486.794430] RBP: ffff90bb413bc600 R08: 0000000000000000 R09: ffff90bc7d6a0980 +[ 486.795779] R10: 000000000000003c R11: 00000001a8be8000 R12: 0000000000000001 +[ 486.797132] R13: 0000000000000003 R14: ffff90bd3b94e400 R15: ffff90bdcbc8c000 +[ 486.798499] FS: 0000000000000000(0000) GS:ffff90beafc40000(0000) knlGS:0000000000000000 +[ 486.800325] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[ 486.801520] CR2: 00007faf740ec058 CR3: 000000010a40c004 CR4: 0000000000770ee0 +[ 486.802856] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +[ 486.804171] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 +[ 486.805459] PKRU: 55555554 +[ 486.806291] Call Trace: +[ 486.807083] <IRQ> +[ 486.807822] igbvf_clean_rx_irq.constprop.0.isra.0+0x1b4/0x600 [igbvf] +[ 486.809027] igbvf_poll+0x3d/0x210 [igbvf] +[ 486.809981] __napi_poll+0x27/0x170 +[ 486.810886] net_rx_action+0x233/0x2f0 +[ 486.811777] __do_softirq+0xc7/0x2ac +[ 486.812644] __irq_exit_rcu+0xb5/0xe0 +[ 486.813515] common_interrupt+0x80/0xa0 +[ 486.814404] </IRQ> +[ 486.815113] <TASK> +[ 486.815800] asm_common_interrupt+0x22/0x40 +[ 486.816710] RIP: 0010:default_idle+0x10/0x20 +[ 486.817631] Code: cc 0f ae f0 0f ae 38 0f ae f0 eb b5 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 0f 1f 44 00 00 66 90 0f 00 2d 7e 3e 4d 00 fb f4 <c3> cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 0f 1f 44 00 00 65 +[ 486.820523] RSP: 0018:ffffaef2000afed0 EFLAGS: 00000246 +[ 486.821705] RAX: ffffffff99f36ea0 RBX: ffff90bb4032a300 RCX: ffff90bd581f2430 +[ 486.822936] RDX: 000000000013bd13 RSI: 0000000000000001 RDI: 000000000013bd14 +[ 486.824165] RBP: 0000000000000000 R08: 0000007155e9e493 R09: ffff90bb437f4800 +[ 486.825374] R10: 0000000000000232 R11: 0000000000000000 R12: 0000000000000000 +[ 486.826581] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 +[ 486.827777] ? mwait_idle+0x80/0x80 +[ 486.828593] default_idle_call+0x33/0xe0 +[ 486.829479] cpuidle_idle_call+0x15d/0x1c0 +[ 486.830381] ? kvm_sched_clock_read+0x14/0x40 +[ 486.831289] do_idle+0x7b/0xe0 +[ 486.832035] cpu_startup_entry+0x19/0x20 +[ 486.833076] start_secondary+0x116/0x140 +[ 486.834527] secondary_startup_64_no_verify+0xe5/0xeb +[ 486.835953] </TASK> +[ 486.836991] Modules linked in: igbvf veth ipt_REJECT nf_reject_ipv4 xt_nat xt_CT vhost_net vhost vhost_iotlb tap tun nf_conntrack_netlink tls xt_MASQUERADE nft_chain_nat xt_mark xt_conntrack xt_comment nft_compat nft_counter nf_tables rfkill geneve ip6_udp_tunnel udp_tunnel nfnetlink_cttimeout nfnetlink openvswitch nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 overlay ext4 mbcache jbd2 intel_rapl_msr intel_rapl_common isst_if_common nfit libnvdimm kvm_intel kvm irqbypass rapl iTCO_wdt iTCO_vendor_support cirrus drm_shmem_helper drm_kms_helper pcspkr i2c_i801 syscopyarea sysfillrect i2c_smbus sysimgblt virtio_balloon lpc_ich fb_sys_fops joydev ip_tables drm xfs libcrc32c dm_multipath sr_mod cdrom sg igb nvme_tcp ahci nvme_fabrics nvme libahci nvme_core virtio_net crct10dif_pclmul libata i2c_algo_bit crc32_pclmul dca virtio_console net_failover nvme_common virtio_blk t10_pi crc32c_intel failover ghash_clmulni_intel serio_raw dm_mirror dm_region_hash dm_log dm_mod fuse +[ 486.852907] ---[ end trace d1f9cdb1a6c92411 ]--- +[ 486.854263] RIP: 0010:eth_type_trans+0xd3/0x140 +[ 486.855234] Code: 80 00 00 00 eb c1 8b 47 70 2b 47 74 48 8b 97 c8 00 00 00 83 f8 01 7e 1b 48 85 d2 74 06 66 83 3a ff 74 09 b8 00 04 00 00 eb a5 <0f> 0b b8 00 01 00 00 eb 9c 48 85 ff 74 eb 31 f6 b9 02 00 00 00 48 +[ 486.858732] RSP: 0018:ffffaef200114e30 EFLAGS: 00010283 +[ 486.859777] RAX: 000000000000002e RBX: ffffaef206a38000 RCX: 0000000000000028 +[ 486.861020] RDX: ffff90bb7767a840 RSI: ffff90bc7d6a0000 RDI: ffff90bb413bc600 +[ 486.862238] RBP: ffff90bb413bc600 R08: 0000000000000000 R09: ffff90bc7d6a0980 +[ 486.863478] R10: 000000000000003c R11: 00000001a8be8000 R12: 0000000000000001 +[ 486.864718] R13: 0000000000000003 R14: ffff90bd3b94e400 R15: ffff90bdcbc8c000 +[ 486.865969] FS: 0000000000000000(0000) GS:ffff90beafc40000(0000) knlGS:0000000000000000 +[ 486.867317] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[ 486.868458] CR2: 00007faf740ec058 CR3: 000000010a40c004 CR4: 0000000000770ee0 +[ 486.869705] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +[ 486.870959] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 +[ 486.872212] PKRU: 55555554 +[ 486.873040] Kernel panic - not syncing: Fatal exception in interrupt +[ 486.875441] Kernel Offset: 0x18400000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) +[ 486.877044] Rebooting in 10 seconds.. +``` +Steps to reproduce: +1. create a vm using igb driver for the network interface +2. change the MTU of the PF to 9000 +3. allocate virtual functions +4. change the MTU on the virtual function (vm crash) +Additional information: + diff --git a/results/classifier/105/mistranslation/1873769 b/results/classifier/105/mistranslation/1873769 new file mode 100644 index 000000000..849c72967 --- /dev/null +++ b/results/classifier/105/mistranslation/1873769 @@ -0,0 +1,101 @@ +mistranslation: 0.876 +semantic: 0.850 +instruction: 0.847 +device: 0.820 +other: 0.817 +network: 0.813 +assembly: 0.802 +graphic: 0.791 +vnc: 0.757 +boot: 0.695 +socket: 0.677 +KVM: 0.633 + +SB16 audio playback freezes emulation in Windows 95 guest + +- QEMU 4.2.93 (v5.0.0-rc3) built from latest git master 20038cd7a8412feeb49c01f6ede89e36c8995472 using MSYS2 on Windows 10 and launched on same Windows 10 + +- Launched using "qemu-system-i386.exe -drive format=raw,file=hdd-2gb.img -soundhw pcspk,sb16 -m 16 -cpu pentium -vga std -cdrom Windows_95.iso -boot c" + +- I have attached video screen capture of the issue + +--- + +I decided to make my first ever QEMU build after encountering the dsound issues using the latest 4.2.0 binary from https://qemu.weilnetz.de/w64/. In my 5.0.0-rc3 build the sound playback is working correctly, however the whole Windows 95 UI freezes while sound is playing. + + + +This is with GTK UI? Do you still have the same problem if you use Spice and remote-viewer instead? + +(GTK UI and Sound Blaster 16 emulation don't play well together. GTK UI does screen updates only when the main event loop becomes idle, but it never becomes idle when SB16 audio is playing due to the way hw/dma/i8257 works. The combination of GTK UI screen updates + SB16 DMA transfer additionally causes i8257_dma_run() getting called at a very rapid rate.) + + +Hi Allan, +I've hit EXACTLY the same problem, while writing a SB16 driver. + +Reproducing the bug +---------------------- +I've tried to QEMU 4 in several scenarios (GTK UI, text mode with the -curses option, +just serial console with -nographic and with virt-manager which uses Spice). It works +as expected in all the cases EXCEPT for the GTK UI: in that case, the video freezes +while playing the sound, exactly as in the video posted by Marko; even QEMU's menu +doesn't respond while the audio is playing (the bug affects the whole QEMU UI). + +Regression +--------------------- +I've also tried the same test with QEMU 2.11, on another machine with Ubuntu 18.04 (LTS) +and there the problem simply does *not* exist. QEMU's UI (does QEMU 2.x uses GTK?), +works GREAT while playing SB16 audio. + +Conclusion +---------------- +Is there any chance this bug could be fixed easily, or a fix would necessarily require +a (partial) re-design of the way the GTK UI works? In particular, why on QEMU 2.11 the +problem does not exist? + + +Thanks in advance, +Vlad + +P.S.: sorry for the terribly broken lines. I didn't expect launchpad to add additional line breaks that way :-( + +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. + + +[Expired for QEMU because there has been no activity for 60 days.] + + +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/469 + + diff --git a/results/classifier/105/mistranslation/1874504 b/results/classifier/105/mistranslation/1874504 new file mode 100644 index 000000000..3472ed3f0 --- /dev/null +++ b/results/classifier/105/mistranslation/1874504 @@ -0,0 +1,45 @@ +mistranslation: 0.908 +graphic: 0.762 +semantic: 0.639 +device: 0.584 +other: 0.432 +instruction: 0.325 +network: 0.186 +socket: 0.119 +assembly: 0.086 +boot: 0.080 +vnc: 0.056 +KVM: 0.018 + +VFIO passthrough spits out thousands of messages + +started qemu as: +sudo qemu-system-sparc64 -device vfio-pci,host=0b:05.0,x-no-mmap=on,bus=pciB + +messages received thousands of times: + +qemu-system-sparc64: -device vfio-pci,host=0b:05.0,x-no-mmap=on,bus=pciB: iommu has granularity incompatible with target AS +qemu-system-sparc64: -device vfio-pci,host=0b:05.0,x-no-mmap=on,bus=pciB: iommu map to non memory area 4079c000 + +qemu version (think telling a lie as sure its 5.0) +QEMU emulator version 4.2.92 +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + +pci device being passed through: + +0b:05.0 Display controller [0380]: 3DLabs Permedia II 2D+3D [3d3d:0009] (rev 01) + Subsystem: Tech-Source Permedia II 2D+3D [1227:0006] + Flags: medium devsel, IRQ 11 + Memory at 83000000 (32-bit, non-prefetchable) [disabled] [size=128K] + Memory at 82800000 (32-bit, non-prefetchable) [disabled] [size=8M] + Memory at 82000000 (32-bit, non-prefetchable) [disabled] [size=8M] + Expansion ROM at 83020000 [disabled] [size=64K] + Capabilities: <access denied> + Kernel driver in use: vfio-pci + + + +Is this a regression? Can you please bisect to the first commit where it happened? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1875012 b/results/classifier/105/mistranslation/1875012 new file mode 100644 index 000000000..b30ef1fcc --- /dev/null +++ b/results/classifier/105/mistranslation/1875012 @@ -0,0 +1,138 @@ +mistranslation: 0.903 +graphic: 0.900 +semantic: 0.899 +instruction: 0.874 +device: 0.853 +assembly: 0.847 +boot: 0.846 +other: 0.842 +KVM: 0.822 +vnc: 0.808 +socket: 0.737 +network: 0.721 + +UC20 running in OVMF triggers qemu emulation error (cloudimage works fine on the same) + +Trying to boot a core20 amd64 image on an amd64 Eoan or Focal host via libvirt leads to: + +KVM internal error. Suberror: 1 +emulation failure +RAX=0000000000000000 RBX=000000003bdcd5c0 RCX=000000003ff1d030 RDX=00000000000019a0 +RSI=00000000000000ff RDI=000000003bd73ee0 RBP=000000003bd73e40 RSP=000000003ff1d1f8 +R8 =000000003df52168 R9 =0000000000000000 R10=ffffffffffffffff R11=000000003bd44c40 +R12=000000003bd76500 R13=000000003bd73e00 R14=0000000000020002 R15=000000003df4b483 +RIP=00000000000b0000 RFL=00210246 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0030 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] +CS =0038 0000000000000000 ffffffff 00a09b00 DPL=0 CS64 [-RA] +SS =0030 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] +DS =0030 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] +FS =0030 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] +GS =0030 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] +LDT=0000 0000000000000000 0000ffff 00008200 DPL=0 LDT +TR =0000 0000000000000000 0000ffff 00008b00 DPL=0 TSS64-busy +GDT= 000000003fbee698 00000047 +IDT= 000000003f2d8018 00000fff +CR0=80010033 CR2=0000000000000000 CR3=000000003fc01000 CR4=00000668 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000d00 +Code=00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <ff> ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff + + + + + +Core20 image: http://cdimage.ubuntu.com/ubuntu-core/20/beta/pending/ubuntu-core-20-amd64.img.xz + + +Hmm, +we had a similar issue but that would not affect things back until Bionic as you reported it. +That was in bug 1866870 and fixed by a change in seabios. Also you reported Focal as affected wherer I fixed this particular one for sure. + +In general the error messages we have so far are not usually very helpful. That is more of a "class of errors" than a specific one to look at. Thanks for attaching the XML and image right away. + +In the past this also was dependent on the reporters CPU, so let's see if we can reproduce this for debugging. + +Ok I can reproduce + +One sees just quickly the bootloader flying by: + BdsDxe: loading Boot0001 "UEFI QEMU HARDDISK QM00005 " from + PciRoot(0x0)/Pci(0x4,0x0)/Sata(0x0,0xFFFF,0x0) + BdsDxe: starting Boot0001 "UEFI QEMU HARDDISK QM00005 " from + PciRoot(0x0)/Pci(0x4,0x0)/Sata(0x0,0xFFFF,0x0) + error: no such device: ubuntu-boot. +... and then it crashes. + +I was probing the major conditions to trigger - it seems to be only happening with the efi / ovmf boot. + +Changing the machine= or cpu model= had no impact, neither had a i440fx/q35 change. +But dropping from Efi to the default loader avoided the crash. There it also only worked to some extend - I mean it starts and does not crash. But the guest seems to insist/require UEFI as it doesn't go much further. I first thought the ovmf build might have a similar problem to what we have had in seabios, but then I tested non UC20. + +I also wanted to know if there is anything special in the UC20 image that is needed to trigger this and therefore booted a cloud image with OVMF. + +So I took a usual cloud-image based focal guest and added: + <loader readonly='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.fd</loader> + <nvram template='/usr/share/OVMF/OVMF_VARS.fd'/> + +And that works like a charm. So the issues seems to be triggered by something set up int hat UC20 image that you linked. It must do/trigger something that a cloud-image would not do on the same setup. + +The early boot messages differ - but that might be a red herring. +BdsDxe: loading Boot0001 "UEFI Misc Device" from PciRoot(0x0)/Pci(0x2,0x3)/Pci(0x0,0x0) +BdsDxe: starting Boot0001 "UEFI Misc Device" from PciRoot(0x0)/Pci(0x2,0x3)/Pci(0x0,0x0) +error: can't find command `hwmatch'. + +I don't even see the UC20 kernel initializing. +The next step is to know/learn what this image does differently. +How is this UC20 image special, what does it do special on init that other images don't do? +@Juergh do you now or do we need to reach out to mvo and others? + +Can someone help to dissect the UC20 image and what it does differently here? +The cloud-image boots with the same OVMF/Uefi based config, but UC20 runs into a crash. + +Understanding what the UC20 boot does differently and any chance to build that piece by piece (e.g. be able to skip some steps until we find the trigger) would be awesome. + +I subscribed MVO to help, but feel free to pull in others as you see fit. + +Until we got any further on this side I'm unsure what to do about Ubuntu unless you already know much more to help getting this forward. For now this is a bit like "I throw in this blob and it crashes", so helping to un-blobify seems to be the next step to me. Marking qemu task incomplete until we got a hold on this. + +The first thing that grub does when booting is: +loopback /snaps/pc-kernel_461.snap +which kills QEMU. + +In core20 that snap is on an 'EFI System' partition (vfat) whereas in core18 it's on a regular Linux (ext4) partition. + + +That should be: +loopback loop /snaps/pc-kernel_461.snap +in the previous commit #7. + +Ok it seems the kernel snap is causing this. Core20 grub can loopmount pc-kernel_455.snap (from a core18 image) just fine but kills QEMU when loopmounting pc-kernel_461.snap (the original core20 snap). + +Hrm. The core20 kernel snap is bigger than the core18 snap and increasing the VM memory to 2G seems to 'fix' this. I guess the question is is there a way to handle this more gracefully than killing QEMU? + + +I can confirm that with 2G the guest seems to start up now. + +I agree that this should be more graceful, but it has to be triggered by the guest. +So might the error path in the guest run into a dead-end if unable to load the kernel that then is like a illegal instruction to the host or something like that? + +Right now we don't know yet if it unpacks and then execute garbage OR fails even earlier. +We discussed this on IRC if grub might be placing it at a wrong offset making it need more memory, or some padding, or at unsquashing already ... + +We ended for now with: +[09:55] <juergh> cpaelzer, will dig into some more and let you know/update the ticket. +[09:56] <juergh> cpaelzer, maybe it's the unsquashing that kills it already + +Thanks in advance @Juergh for that! + +Maybe adding a bug task for the kernel snap and/or grub would be right, but let us find out more first. + +I've setup a UEFI core18 VM and dialed the memory all the way down to 256M but the loop mounting and loading of the kernel still works fine. + +Then I've copied grubx64.efi from the core18 image to the core20 image and now QEMU no longer crashes. So it looks like a change in grub between 2.02 and 2.04 in combination with UEFI and 'low' memory is causing this issue. + + +The Eoan Ermine has reached end of life, so this bug will not be fixed for that release + +The Eoan Ermine has reached end of life, so this bug will not be fixed for that release + diff --git a/results/classifier/105/mistranslation/1875819 b/results/classifier/105/mistranslation/1875819 new file mode 100644 index 000000000..786e1b89c --- /dev/null +++ b/results/classifier/105/mistranslation/1875819 @@ -0,0 +1,21 @@ +mistranslation: 0.953 +other: 0.634 +semantic: 0.604 +graphic: 0.566 +network: 0.546 +device: 0.541 +instruction: 0.402 +socket: 0.205 +boot: 0.149 +vnc: 0.049 +assembly: 0.033 +KVM: 0.013 + +[Feature request] prebuilt testing docker images + +Instead of building qemu:docker images locally, we should pull the one built from Travis/Shippable/GitLab by default, and build it only when manually requested. + +GitLab has ability to host container images per project and also can build them during CI runs. So I'd suggest that we create GitLab CI jobs that build & publish each of the images under tests/docker on the master branch. + +I think this has been done now, so I'm closing this ticket. + diff --git a/results/classifier/105/mistranslation/1877781 b/results/classifier/105/mistranslation/1877781 new file mode 100644 index 000000000..da4f9ecff --- /dev/null +++ b/results/classifier/105/mistranslation/1877781 @@ -0,0 +1,75 @@ +mistranslation: 0.790 +other: 0.777 +instruction: 0.745 +semantic: 0.717 +graphic: 0.707 +assembly: 0.669 +device: 0.638 +network: 0.597 +boot: 0.590 +socket: 0.587 +vnc: 0.517 +KVM: 0.355 + +TCG does not support x2APIC emulation + +This is not a bug so much as a feature request. + +It would be great if there was a pure-software emulation of the x2APIC on x86_64, so that it could be used on systems that don't support such providing a thing on via a host-based solution (e.g., KVM etc). KVM provides this, but that doesn't help if you're working on a machine that doesn't support KVM. + +If I may be so free: + +It seems that QEMU has stopped emphasizing the EMU part of the name, and is too much focused on virtualization. + +My interest is at running legacy operating systems, and as such, they must run on foreign CPU platforms. m68 on intel, intel on ARM, etc. +Time doesn't stand still, and reliance on KVM and similar x86-on-x86 tricks, which allow the delegation of certain CPU features to the host CPU is going to not work going forward. + +If the rumored transition of Apple to ARM is going to take place, people will want to e.g. emulate for testing or legacy purposes a variety of operating systems, incl. earlier versions of MacOS. + +Testing that scenario, i.e. macOS on an ARM board with the lowest possible CPU capable of running modern macOS, results in these problems (and of course utter failure achieving the goal): + +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.fma [bit 12] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.avx [bit 28] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.07H:EBX.avx2 [bit 5] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.80000007H:EDX.invtsc [bit 8] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.0DH:EAX.xsavec [bit 1] + +And this is emulating a lowly Penryn CPU with the required CPU flags for macOS: +-cpu Penryn,vendor=GenuineIntel,+sse3,+sse4.2,+aes,+xsave,+avx,+xsaveopt,+xsavec,+xgetbv1,+avx2,+bmi2,+smep,+bmi1,+fma,+movbe,+invtsc + +Attempting to emulate a more feature laden intel CPU results in even more issues. + +I would propose that no CPU should be considered supported unless it can be fully handled by TCG on a non-native host. KVM, native-on-native etc. are nice to have, but peripheral to qEMUlation when it boils down to 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. + + +This ticket has been moved here (thanks, Dan!): +https://gitlab.com/qemu-project/qemu/-/issues/330 +... so I'm closing this on Launchpad now. + diff --git a/results/classifier/105/mistranslation/1878641 b/results/classifier/105/mistranslation/1878641 new file mode 100644 index 000000000..57478bcd6 --- /dev/null +++ b/results/classifier/105/mistranslation/1878641 @@ -0,0 +1,74 @@ +mistranslation: 0.814 +other: 0.806 +KVM: 0.745 +vnc: 0.733 +graphic: 0.700 +semantic: 0.658 +device: 0.620 +instruction: 0.613 +assembly: 0.599 +socket: 0.573 +boot: 0.564 +network: 0.495 + +Abort() in mch_update_pciexbar + +Hello, +I found an input which triggers an abort() in mch_update_pciexbar: + +#0 0x00007ffff686d761 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:50 +#1 0x00007ffff685755b in __GI_abort () at abort.c:79 +#2 0x000055555705c7ae in mch_update_pciexbar (mch=0x629000005920) at /home/alxndr/Development/qemu/hw/pci-host/q35.c:324 +#3 0x000055555705bb6a in mch_write_config (d=0x629000005920, address=0x60, val=0x8400056e, len=0x4) at /home/alxndr/Development/qemu/hw/pci-host/q35.c:480 +#4 0x00005555570954fb in pci_host_config_write_common (pci_dev=0x629000005920, addr=0x60, limit=0x100, val=0x8400056e, len=0x4) at /home/alxndr/Development/qemu/hw/pci/pci_host.c:81 +#5 0x000055555709606e in pci_data_write (s=0x61d000096080, addr=0xf2000060, val=0x8400056e, len=0x4) at /home/alxndr/Development/qemu/hw/pci/pci_host.c:118 +#6 0x00005555570967d0 in pci_host_data_write (opaque=0x629000005200, addr=0x0, val=0x8400056e, len=0x4) at /home/alxndr/Development/qemu/hw/pci/pci_host.c:165 +#7 0x00005555564938b5 in memory_region_write_accessor (mr=0x629000005610, addr=0x0, value=0x7fffffff9c70, size=0x4, shift=0x0, mask=0xffffffff, attrs=...) at /home/alxndr/Development/qemu/memory.c:483 +#8 0x000055555649328a in access_with_adjusted_size (addr=0x0, value=0x7fffffff9c70, size=0x4, access_size_min=0x1, access_size_max=0x4, access_fn=0x555556493360 <memory_region_write_accessor>, mr=0x629000005610, attrs=...) at /home/alxndr/Development/qemu/memory.c:544 +#9 0x0000555556491df6 in memory_region_dispatch_write (mr=0x629000005610, addr=0x0, data=0x8400056e, op=MO_32, attrs=...) at /home/alxndr/Development/qemu/memory.c:1476 +#10 0x00005555562cbbf4 in flatview_write_continue (fv=0x606000033b00, addr=0xcfc, attrs=..., ptr=0x7fffffffa4e0, len=0x4, addr1=0x0, l=0x4, mr=0x629000005610) at /home/alxndr/Development/qemu/exec.c:3137 +#11 0x00005555562bbad9 in flatview_write (fv=0x606000033b00, addr=0xcfc, attrs=..., buf=0x7fffffffa4e0, len=0x4) at /home/alxndr/Development/qemu/exec.c:3177 +#12 0x00005555562bb609 in address_space_write (as=0x55555968f940 <address_space_io>, addr=0xcfc, attrs=..., buf=0x7fffffffa4e0, len=0x4) at /home/alxndr/Development/qemu/exec.c:3268 +#13 0x0000555556478c0a in cpu_outl (addr=0xcfc, val=0x8400056e) at /home/alxndr/Development/qemu/ioport.c:80 +#14 0x000055555648166f in qtest_process_command (chr=0x555559691d00 <qtest_chr>, words=0x60300009ebf0) at /home/alxndr/Development/qemu/qtest.c:396 +#15 0x000055555647f187 in qtest_process_inbuf (chr=0x555559691d00 <qtest_chr>, inbuf=0x61900000f680) at /home/alxndr/Development/qemu/qtest.c:710 +#16 0x000055555647e8b4 in qtest_read (opaque=0x555559691d00 <qtest_chr>, buf=0x7fffffffca40 "outl 0xcf8 0xf2000060\noutl 0xcfc 0x8400056e\n-M pc-q35-5.0 -device intel-hda,id=hda0 -device hda-output,bus=hda0.0 -device hda-micro,bus=hda0.0 -device hda-duplex,bus=hda0.0 -display none -nodefaults -nographic\n\377\377\377\177", size=0xd2) at /home/alxndr/Development/qemu/qtest.c:722 +#17 0x00005555579c260c in qemu_chr_be_write_impl (s=0x60f000001f30, buf=0x7fffffffca40 "outl 0xcf8 0xf2000060\noutl 0xcfc 0x8400056e\n-M pc-q35-5.0 -device intel-hda,id=hda0 -device hda-output,bus=hda0.0 -device hda-micro,bus=hda0.0 -device hda-duplex,bus=hda0.0 -display none -nodefaults -nographic\n\377\377\377\177", len=0xd2) at /home/alxndr/Development/qemu/chardev/char.c:183 +#18 0x00005555579c275b in qemu_chr_be_write (s=0x60f000001f30, buf=0x7fffffffca40 "outl 0xcf8 0xf2000060\noutl 0xcfc 0x8400056e\n-M pc-q35-5.0 -device intel-hda,id=hda0 -device hda-output,bus=hda0.0 -device hda-micro,bus=hda0.0 -device hda-duplex,bus=hda0.0 -display none -nodefaults -nographic\n\377\377\377\177", len=0xd2) at /home/alxndr/Development/qemu/chardev/char.c:195 +#19 0x00005555579cb97a in fd_chr_read (chan=0x6080000026a0, cond=G_IO_IN, opaque=0x60f000001f30) at /home/alxndr/Development/qemu/chardev/char-fd.c:68 +#20 0x0000555557a530ea in qio_channel_fd_source_dispatch (source=0x60c00002ef00, callback=0x5555579cb540 <fd_chr_read>, user_data=0x60f000001f30) at /home/alxndr/Development/qemu/io/channel-watch.c:84 +#21 0x00007ffff7ca8898 in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +#22 0x0000555557c10b85 in glib_pollfds_poll () at /home/alxndr/Development/qemu/util/main-loop.c:219 +#23 0x0000555557c0f57e in os_host_main_loop_wait (timeout=0x0) at /home/alxndr/Development/qemu/util/main-loop.c:242 +#24 0x0000555557c0f177 in main_loop_wait (nonblocking=0x0) at /home/alxndr/Development/qemu/util/main-loop.c:518 +#25 0x000055555689fd1e in qemu_main_loop () at /home/alxndr/Development/qemu/softmmu/vl.c:1664 +#26 0x0000555557a6a29d in main (argc=0x17, argv=0x7fffffffe148, envp=0x7fffffffe208) at /home/alxndr/Development/qemu/softmmu/main.c:49 + + +I can reproduce this in qemu 5.0 built using these qtest commands: + +cat << EOF | ./qemu-system-i386 \ +-qtest stdio -nographic -monitor none -serial none \ +-M pc-q35-5.0 +outl 0xcf8 0xf2000060 +outl 0xcfc 0x8400056e +EOF + +Please let me know if I can provide any further info. +-Alex + +Proposed fix: +https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg05612.html + +Confirmed, this is not fixed yet. Philippe, what happened to your patch? + +On 5/26/21 1:06 PM, Thomas Huth wrote: +> Confirmed, this is not fixed yet. Philippe, what happened to your patch? + +I was waiting someone suggest me how to propagate error from +PCIConfigWriteFunc. Probably not very important. + + +Fix has been included here: +https://gitlab.com/qemu-project/qemu/-/commit/9b0ca75e0196a725232 + diff --git a/results/classifier/105/mistranslation/1879175 b/results/classifier/105/mistranslation/1879175 new file mode 100644 index 000000000..4efd50a99 --- /dev/null +++ b/results/classifier/105/mistranslation/1879175 @@ -0,0 +1,163 @@ +mistranslation: 0.926 +KVM: 0.873 +graphic: 0.841 +other: 0.822 +vnc: 0.803 +device: 0.770 +assembly: 0.761 +semantic: 0.756 +instruction: 0.755 +socket: 0.724 +boot: 0.704 +network: 0.676 + +GVTd not working (black screen) after upgrade to qemu-5.0.0 + +Hi QEMU team, + + +=== Problem Summary === + +I have recently upgraded from QEMU-3.1.0 to to QEMU-5.0.0 on Debian Unstable. Unfortunately GVTd (legacy passthrough of the integrated intel gpu) stopped working correctly. The guest can still see and loads the driver for the GPU, but the screen stays black. + +The following is the version used: + +$ /usr/bin/qemu-system-x86_64 --version +QEMU emulator version 5.0.0 (Debian 1:5.0-5) +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + + + +=== Investigation/Triage done so far === + +Running QEMU with trace flags enabled shows the following behavior change for the same VM (left: 3.1.0, right: 5.0.0): + +vfio_realize (0000:00:02.0) group 1 vfio_realize (0000:00:02.0) group 1 +vfio_listener_region_add_ram region_add [ram] 0x0 - 0xbffff [0x7f5b41e00000] | vfio_listener_region_add_ram region_add [ram] 0x0 - 0xbffff [0x7f2bb1e00000] +vfio_listener_region_add_ram region_add [ram] 0xc0000 - 0xdffff [0x7f5d1d400000] | vfio_listener_region_add_ram region_add [ram] 0xc0000 - 0xdffff [0x7f2d7c800000] +vfio_listener_region_add_ram region_add [ram] 0xe0000 - 0xfffff [0x7f5d1d620000] | vfio_listener_region_add_ram region_add [ram] 0xe0000 - 0xfffff [0x7f2d84220000] +vfio_listener_region_add_ram region_add [ram] 0x100000 - 0xbfffffff [0x7f5b41f00000] | vfio_listener_region_add_ram region_add [ram] 0x100000 - 0xbfffffff [0x7f2bb1f00000] +vfio_listener_region_add_skip SKIPPING region_add 0xfec00000 - 0xfec00fff vfio_listener_region_add_skip SKIPPING region_add 0xfec00000 - 0xfec00fff +vfio_listener_region_add_skip SKIPPING region_add 0xfee00000 - 0xfeefffff vfio_listener_region_add_skip SKIPPING region_add 0xfee00000 - 0xfeefffff +vfio_listener_region_add_ram region_add [ram] 0xfffc0000 - 0xffffffff [0x7f5d1d600000] | vfio_listener_region_add_ram region_add [ram] 0xfffc0000 - 0xffffffff [0x7f2d84200000] +vfio_listener_region_add_ram region_add [ram] 0x100000000 - 0x201ffffff [0x7f5c01e00000] | vfio_listener_region_add_ram region_add [ram] 0x100000000 - 0x201ffffff [0x7f2c71e00000] +vfio_mdev (0000:00:02.0) is_mdev 0 vfio_mdev (0000:00:02.0) is_mdev 0 +vfio_get_device Device 0000:00:02.0 flags: 3, regions: 12, irqs: 5 vfio_get_device Device 0000:00:02.0 flags: 3, regions: 12, irqs: 5 +vfio_region_setup Device 0000:00:02.0, region 0 "0000:00:02.0 BAR 0", flags: 0x7, offset: 0x0, s vfio_region_setup Device 0000:00:02.0, region 0 "0000:00:02.0 BAR 0", flags: 0x7, offset: 0x0, s +vfio_region_setup Device 0000:00:02.0, region 1 "0000:00:02.0 BAR 1", flags: 0x0, offset: 0x1000 vfio_region_setup Device 0000:00:02.0, region 1 "0000:00:02.0 BAR 1", flags: 0x0, offset: 0x1000 +vfio_region_setup Device 0000:00:02.0, region 2 "0000:00:02.0 BAR 2", flags: 0x7, offset: 0x2000 vfio_region_setup Device 0000:00:02.0, region 2 "0000:00:02.0 BAR 2", flags: 0x7, offset: 0x2000 +vfio_region_setup Device 0000:00:02.0, region 3 "0000:00:02.0 BAR 3", flags: 0x0, offset: 0x3000 vfio_region_setup Device 0000:00:02.0, region 3 "0000:00:02.0 BAR 3", flags: 0x0, offset: 0x3000 +vfio_region_setup Device 0000:00:02.0, region 4 "0000:00:02.0 BAR 4", flags: 0x3, offset: 0x4000 vfio_region_setup Device 0000:00:02.0, region 4 "0000:00:02.0 BAR 4", flags: 0x3, offset: 0x4000 +vfio_region_setup Device 0000:00:02.0, region 5 "0000:00:02.0 BAR 5", flags: 0x0, offset: 0x5000 vfio_region_setup Device 0000:00:02.0, region 5 "0000:00:02.0 BAR 5", flags: 0x0, offset: 0x5000 +vfio_populate_device_config Device 0000:00:02.0 config: vfio_populate_device_config Device 0000:00:02.0 config: + 0x1000, offset: 0x70000000000, flags: 0x3 0x1000, offset: 0x70000000000, flags: 0x3 +vfio_region_mmap Region 0000:00:02.0 BAR 0 mmaps[0] [0x0 - 0xffffff] vfio_region_mmap Region 0000:00:02.0 BAR 0 mmaps[0] [0x0 - 0xffffff] +vfio_region_mmap Region 0000:00:02.0 BAR 2 mmaps[0] [0x0 - 0xfffffff] vfio_region_mmap Region 0000:00:02.0 BAR 2 mmaps[0] [0x0 - 0xfffffff] +vfio_check_pm_reset 0000:00:02.0 Supports PM reset vfio_check_pm_reset 0000:00:02.0 Supports PM reset +vfio_msi_setup 0000:00:02.0 PCI MSI CAP @0xac vfio_msi_setup 0000:00:02.0 PCI MSI CAP @0xac +vfio_check_pcie_flr 0000:00:02.0 Supports FLR via PCIe cap vfio_check_pcie_flr 0000:00:02.0 Supports FLR via PCIe cap +vfio_get_dev_region 0000:00:02.0 index 9, 80008086/18 < +vfio_get_dev_region 0000:00:02.0 index 9, 80008086/18 < +vfio_get_dev_region 0000:00:02.0 index 10, 80008086/28 < +vfio_get_dev_region 0000:00:02.0 index 9, 80008086/18 < +vfio_get_dev_region 0000:00:02.0 index 10, 80008086/28 < +vfio_get_dev_region 0000:00:02.0 index 11, 80008086/38 < +vfio_listener_region_del region_del 0x0 - 0xbffff < +vfio_listener_region_add_ram region_add [ram] 0x0 - 0x9ffff [0x7f5b41e00000] < +vfio_listener_region_add_skip SKIPPING region_add 0xa0000 - 0xbffff < +vfio_pci_igd_lpc_bridge_enabled 0000:00:02.0 < +vfio_pci_igd_host_bridge_enabled 0000:00:02.0 < +vfio_pci_igd_opregion_enabled 0000:00:02.0 < +vfio_pci_igd_bdsm_enabled 0000:00:02.0 40MB < +vfio_intx_enable_kvm (0000:00:02.0) KVM INTx accel enabled vfio_intx_enable_kvm (0000:00:02.0) KVM INTx accel enabled +vfio_intx_enable (0000:00:02.0) vfio_intx_enable (0000:00:02.0) + 0x100, offset: 0x70000000000, flags: 0x3 0x100, offset: 0x70000000000, flags: 0x3 +vfio_populate_device_get_irq_info_failure VFIO_DEVICE_GET_IRQ_INFO failure: Invalid argument vfio_populate_device_get_irq_info_failure VFIO_DEVICE_GET_IRQ_INFO failure: Invalid argument +vfio_pci_reset (0000:00:02.0) vfio_pci_reset (0000:00:02.0) +vfio_intx_disable_kvm (0000:00:02.0) KVM INTx accel disabled vfio_intx_disable_kvm (0000:00:02.0) KVM INTx accel disabled +vfio_region_mmaps_set_enabled Region 0000:00:02.0 BAR 0 mmaps enabled: 1 vfio_region_mmaps_set_enabled Region 0000:00:02.0 BAR 0 mmaps enabled: 1 +vfio_region_mmaps_set_enabled Region 0000:00:02.0 BAR 2 mmaps enabled: 1 vfio_region_mmaps_set_enabled Region 0000:00:02.0 BAR 2 mmaps enabled: 1 +vfio_region_mmaps_set_enabled Region 0000:00:02.0 BAR 4 mmaps enabled: 1 vfio_region_mmaps_set_enabled Region 0000:00:02.0 BAR 4 mmaps enabled: 1 +vfio_intx_disable (0000:00:02.0) vfio_intx_disable (0000:00:02.0) +vfio_pci_write_config (0000:00:02.0, @0x4, 0x0, len=0x2) vfio_pci_write_config (0000:00:02.0, @0x4, 0x0, len=0x2) +vfio_listener_region_del region_del 0x0 - 0x9ffff < +vfio_listener_region_del_skip SKIPPING region_del 0xa0000 - 0xbffff < +vfio_listener_region_add_ram region_add [ram] 0x0 - 0xbffff [0x7f5b41e00000] < +vfio_pci_reset_flr 0000:00:02.0 FLR/VFIO_DEVICE_RESET vfio_pci_reset_flr 0000:00:02.0 FLR/VFIO_DEVICE_RESET +vfio_intx_enable (0000:00:02.0) vfio_intx_enable (0000:00:02.0) +vfio_listener_region_del region_del 0x0 - 0xbffff vfio_listener_region_del region_del 0x0 - 0xbffff +vfio_listener_region_del region_del 0xc0000 - 0xdffff vfio_listener_region_del region_del 0xc0000 - 0xdffff +vfio_listener_region_del region_del 0xe0000 - 0xfffff vfio_listener_region_del region_del 0xe0000 - 0xfffff +vfio_listener_region_del region_del 0x100000 - 0xbfffffff vfio_listener_region_del region_del 0x100000 - 0xbfffffff +vfio_listener_region_add_ram region_add [ram] 0x0 - 0xcffff [0x7f5b41e00000] | vfio_listener_region_add_ram region_add [ram] 0x0 - 0xcffff [0x7f2bb1e00000] + +We can see here, the following key lines are not printed in 5.0.0: + +vfio_pci_igd_lpc_bridge_enabled 0000:00:02.0 < +vfio_pci_igd_host_bridge_enabled 0000:00:02.0 < +vfio_pci_igd_opregion_enabled 0000:00:02.0 < +vfio_pci_igd_bdsm_enabled 0000:00:02.0 40MB < + +Looking through the code and bisecting the problem (I can provide more detail if helpful), shows the following ifdef statement lines introduce the problem: + +https://github.com/qemu/qemu/blob/master/hw/vfio/pci-quirks.c#L1253 + + 1246 void vfio_bar_quirk_setup(VFIOPCIDevice *vdev, int nr) + 1247 { + 1248 vfio_probe_ati_bar4_quirk(vdev, nr); + 1249 vfio_probe_ati_bar2_quirk(vdev, nr); + 1250 vfio_probe_nvidia_bar5_quirk(vdev, nr); + 1251 vfio_probe_nvidia_bar0_quirk(vdev, nr); + 1252 vfio_probe_rtl8168_bar2_quirk(vdev, nr); + 1253 #ifdef CONFIG_VFIO_IGD + 1254 vfio_probe_igd_bar4_quirk(vdev, nr); + 1255 #endif + 1256 } + +This was added by the following commits: + +https://github.com/qemu/qemu/commit/29d62771c81d8fd244a67c14a1d968c268d3fb19#diff-38093e21794c7a4987feb71e498dbdc6 + +Reading through the commit message, I suspect the something may be happening with the Kconfig switches mentioned there. + + + +=== Validation/Workaround === + +I have rebuilt the package with the following two changes: + +root@debian:/home/test/src# diff debian_*/qemu-5.0/hw/vfio/pci-quirks.c +0a1 +> #define CONFIG_VFIO_IGD y +root@debian:/home/test/src# diff debian_*/qemu-5.0/hw/vfio/Kconfig +42c42 +< default y if PC_PCI +--- +> default y +root@debian:/home/test/src# + +GVTd started working fine again (Screen shows output again). + +I have tried with either change alone: + +- with only the ifdef in pci-quirks.c compilation fails with linker errors +- with only the Kconfig it compiles, but GVTd still does not work (black screen) + + + +Please take a look and thank you very much for a fantastic product! + +TheCatFelix + +I've also posted the bug and fix here: + +https://bugs.launchpad.net/qemu/+bug/1882784 + +I may be wrong but Legacy IGD assignment doesn't use GVT-g or GVT-d, which is why I missed this ticket when reporting my own. + +No problem, thanks for getting the issue resolved! + +As a note, i've been going by this guide here from Intel. They seem to describe as that GVT-d refers to the concept of attaching a "whole" GPU to a single VM through PCI PT and it has two modes of operation, "Legacy" and "UPT". + +https://github.com/intel/gvt-linux/wiki/GVTd_Setup_Guide#561-create-gvt-d-kvm-vm + diff --git a/results/classifier/105/mistranslation/1879227 b/results/classifier/105/mistranslation/1879227 new file mode 100644 index 000000000..c56a5a103 --- /dev/null +++ b/results/classifier/105/mistranslation/1879227 @@ -0,0 +1,82 @@ +mistranslation: 0.516 +vnc: 0.474 +KVM: 0.463 +other: 0.403 +graphic: 0.368 +device: 0.326 +assembly: 0.321 +semantic: 0.320 +instruction: 0.318 +network: 0.308 +socket: 0.304 +boot: 0.241 + +Assertion failure in e1000e_write_lgcy_rx_descr + +Hello, +While fuzzing, I found an input which triggers an assertion failure in +e1000e_write_lgcy_rx_descr: + +qemu-system-i386: /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1283: void e1000e_write_lgcy_rx_descr(E1000ECore *, uint8_t *, struct NetRxPkt *, const E1000E_RSSInfo *, uint16_t): Assertion `!rss_info->enabled' failed. +Aborted +#3 0x00007ffff684d092 in __GI___assert_fail (assertion=0x5555583704c0 <str> "!rss_info->enabled", file=0x555558361080 <str> "/home/alxndr/Development/qemu/hw/net/e1000e_core.c", line=0x503, function=0x555558370500 <__PRETTY_FUNCTION__.e1000e_write_lgcy_rx_descr> "void e1000e_write_lgcy_rx_descr(E1000ECore *, uint8_t *, struct NetRxPkt *, const E1000E_RSSInfo *, uint16_t)") at assert.c:101 +#4 0x0000555557209937 in e1000e_write_lgcy_rx_descr (core=0x7fffee0dd4e0, desc=0x7fffffff8720 "}}}}}}\253?", pkt=0x61100004b900, rss_info=0x7fffffff8c50, length=0xcb) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1283 +#5 0x0000555557206b0b in e1000e_write_rx_descr (core=0x7fffee0dd4e0, desc=0x7fffffff8720 "}}}}}}\253?", pkt=0x61100004b900, rss_info=0x7fffffff8c50, ps_hdr_len=0x0, written=0x7fffffff87c0) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1360 +#6 0x00005555571f8507 in e1000e_write_packet_to_guest (core=0x7fffee0dd4e0, pkt=0x61100004b900, rxr=0x7fffffff8c30, rss_info=0x7fffffff8c50) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1607 +#7 0x00005555571f5670 in e1000e_receive_iov (core=0x7fffee0dd4e0, iov=0x61900004e780, iovcnt=0x4) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1709 +#8 0x00005555571f1afc in e1000e_nc_receive_iov (nc=0x614000007460, iov=0x61900004e780, iovcnt=0x4) at /home/alxndr/Development/qemu/hw/net/e1000e.c:213 +#9 0x00005555571d5977 in net_tx_pkt_sendv (pkt=0x631000028800, nc=0x614000007460, iov=0x61900004e780, iov_cnt=0x4) at /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:544 +#10 0x00005555571d50e4 in net_tx_pkt_send (pkt=0x631000028800, nc=0x614000007460) at /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:620 +#11 0x00005555571d638f in net_tx_pkt_send_loopback (pkt=0x631000028800, nc=0x614000007460) at /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:633 +#12 0x000055555722b600 in e1000e_tx_pkt_send (core=0x7fffee0dd4e0, tx=0x7fffee0fd748, queue_index=0x0) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:664 +#13 0x0000555557229ca6 in e1000e_process_tx_desc (core=0x7fffee0dd4e0, tx=0x7fffee0fd748, dp=0x7fffffff9440, queue_index=0x0) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:743 +#14 0x0000555557228ea5 in e1000e_start_xmit (core=0x7fffee0dd4e0, txr=0x7fffffff9640) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:934 +#15 0x000055555721c70f in e1000e_set_tdt (core=0x7fffee0dd4e0, index=0xe06, val=0xcb) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:2451 +#16 0x00005555571fa436 in e1000e_core_write (core=0x7fffee0dd4e0, addr=0x438, val=0xcb, size=0x4) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:3261 +#17 0x00005555571ed11c in e1000e_mmio_write (opaque=0x7fffee0da800, addr=0x438, val=0xcb, size=0x4) at /home/alxndr/Development/qemu/hw/net/e1000e.c:109 +#18 0x00005555565e78b2 in memory_region_write_accessor (mr=0x7fffee0dd110, addr=0x438, value=0x7fffffff9cb0, size=0x4, shift=0x0, mask=0xffffffff, attrs=...) at /home/alxndr/Development/qemu/memory.c:483 +#19 0x00005555565e7212 in access_with_adjusted_size (addr=0x438, value=0x7fffffff9cb0, size=0x1, access_size_min=0x4, access_size_max=0x4, access_fn=0x5555565e72e0 <memory_region_write_accessor>, mr=0x7fffee0dd110, attrs=...) at /home/alxndr/Development/qemu/memory.c:544 +#20 0x00005555565e5c31 in memory_region_dispatch_write (mr=0x7fffee0dd110, addr=0x438, data=0xcb, op=MO_8, attrs=...) at /home/alxndr/Development/qemu/memory.c:1476 +#21 0x00005555563f04b9 in flatview_write_continue (fv=0x606000037880, addr=0xe1020438, attrs=..., ptr=0x61900009ba80, len=0x1, addr1=0x438, l=0x1, mr=0x7fffee0dd110) at /home/alxndr/Development/qemu/exec.c:3137 +#22 0x00005555563df2dd in flatview_write (fv=0x606000037880, addr=0xe10200a8, attrs=..., buf=0x61900009ba80, len=0x391) at /home/alxndr/Development/qemu/exec.c:3177 + + +I can reproduce this in qemu 5.0 using these qtest commands: + +cat << EOF | ./qemu-system-i386 \ +-qtest stdio -nographic -monitor none -serial none \ +-M pc-q35-5.0 +outl 0xcf8 0x80001010 +outl 0xcfc 0xe1020000 +outl 0xcf8 0x80001014 +outl 0xcf8 0x80001004 +outw 0xcfc 0x7 +outl 0xcf8 0x800010a2 +write 0xe1025008 0x4 0xfbffa3fa +write 0xed040c 0x3 0x080047 +write 0xe1020077 0x3c2 0xce0004ed0000000000cb008405120002e100000000ff000801ffff02ce0004ed0000000000cb008405120002e100000000ff000a01ffff02ce0004ed0000000000cb008405120002e100000000ff000c01ffff02ce0004ed0000000000cb008405120002e100000000ff000e01ffff02ce0004ed0000000000cb008405120002e100000000ff001001ffff02ce0004ed0000000000cb008405120002e100000000ff001201ffff02ce0004ed0000000000cb008405120002e100000000ff001401ffff02ce0004ed0000000000cb008405120002e100000000ff001601ffff02ce0004ed0000000000cb008405120002e100000000ff001801ffff02ce0004ed0000000000cb008405120002e100000000ff001a01ffff02ce0004ed0000000000cb008405120002e100000000ff001c01ffff02ce0004ed0000000000cb008405120002e100000000ff001e01ffff02ce0004ed0000000000cb008405120002e100000000ff002001ffff02ce0004ed0000000000cb008405120002e100000000ff002201ffff02ce0004ed0000000000cb008405120002e100000000ff002401ffff02ce0004ed0000000000cb008405120002e100000000ff002601ffff02ce0004ed0000000000cb008405120002e100000000ff002801ffff02ce0004ed0000000000cb008405120002e100000000ff002a01ffff02ce0004ed0000000000cb008405120002e100000000ff002c01ffff02ce0004ed0000000000cb008405120002e100000000ff002e01ffff02ce0004ed0000000000cb008405120002e100000000ff003001ffff02ce0004ed0000000000cb008405120002e100000000ff003201ffff02ce0004ed0000000000cb008405120002e100000000ff003401ffff02ce0004ed0000000000cb008405120002e100000000ff003601ffff02ce0004ed0000000000cb008405120002e100000000ff003801ffff02ce0004ed0000000000cb008405120002e100000000ff003a01ffff02ce0004ed0000000000cb008405120002e100000000ff003c01ffff02ce0004ed0000000000cb008405120002e100000000ff003e01ffff02ce0004ed0000000000cb008405120002e100000000ff004001ffff02ce0004ed0000000000cb008405120002e100000000ff004201ffff02ce0004ed0000000000cb008405120002e100000000ff004401ffff02ce0004ed0000000000cb008405120002e100000000ff004601ffff02ce0004ed0000000000cb008405120002e100000000ff004801ffff02ce0004ed0000000000cb008405120002e100000000ff004a01ffff02ce0004ed0000000000cb +EOF + +Also attaching them to this report, in case they are formatted incorrectly: +./qemu-system-i386 \ +-qtest stdio -nographic -monitor none -serial none \ +-M pc-q35-5.0 < attachment + +Please let me know if I can provide any further info. +-Alex + + + +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? + +OSS-Fuzz never saw it. It was probably fixed + +According to some automatic bisecting, it seems like this was fixed by this commit here: + + commit c2cb511634012344e3d0fe49a037a33b12d8a98a + hw/net/e1000e: advance desc_offset in case of null descriptor + + diff --git a/results/classifier/105/mistranslation/1880287 b/results/classifier/105/mistranslation/1880287 new file mode 100644 index 000000000..7f3a1f625 --- /dev/null +++ b/results/classifier/105/mistranslation/1880287 @@ -0,0 +1,40 @@ +mistranslation: 0.735 +graphic: 0.725 +semantic: 0.607 +instruction: 0.576 +device: 0.539 +socket: 0.453 +network: 0.439 +boot: 0.364 +vnc: 0.340 +assembly: 0.314 +KVM: 0.290 +other: 0.262 + +gcc crashes in hppa emulation + +There seems to be a translation bug in the qemu-hppa (qemu v5.0.0) emulation: +A stripped down testcase (taken from Linux kernel build) is attached. + +In there is "a.sh", a shell script which calls gcc-9 (fails with both debian gcc-9.3.0-11 or gcc-9.3.0-12). and "a.iii", the preprocessed source. + +When starting a.sh, in the emulation gcc crashes with segfault. +On real hardware gcc succeeds to compile the source. + +In a hppa-user chroot running "apt update && apt install gcc-9" should be sufficient to get the needed reproducer environment. + + + +Test still crashes the VM and chroot with up-to-date debian chroot, including updated gcc-9.3.0-14. + +Sven Schnelle (<email address hidden>) noticed that increasing +-#define TCG_MAX_TEMPS 512 ++#define TCG_MAX_TEMPS 1024 +in include/tcg/tcg.h prevents fixes that crash. + +Thanks for the debugging. Failure to free temporaries. + +Fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=79826f99feb7 + + diff --git a/results/classifier/105/mistranslation/1881648 b/results/classifier/105/mistranslation/1881648 new file mode 100644 index 000000000..b894fe605 --- /dev/null +++ b/results/classifier/105/mistranslation/1881648 @@ -0,0 +1,44 @@ +mistranslation: 0.848 +semantic: 0.819 +graphic: 0.816 +device: 0.767 +network: 0.688 +other: 0.660 +socket: 0.593 +instruction: 0.581 +boot: 0.544 +vnc: 0.519 +KVM: 0.414 +assembly: 0.271 + +`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/105/mistranslation/1884507 b/results/classifier/105/mistranslation/1884507 new file mode 100644 index 000000000..de0423fdb --- /dev/null +++ b/results/classifier/105/mistranslation/1884507 @@ -0,0 +1,49 @@ +mistranslation: 0.890 +other: 0.885 +semantic: 0.875 +device: 0.636 +instruction: 0.596 +graphic: 0.469 +boot: 0.282 +vnc: 0.258 +network: 0.202 +socket: 0.196 +assembly: 0.194 +KVM: 0.139 + +'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/105/mistranslation/1884719 b/results/classifier/105/mistranslation/1884719 new file mode 100644 index 000000000..01b9b8fa9 --- /dev/null +++ b/results/classifier/105/mistranslation/1884719 @@ -0,0 +1,593 @@ +mistranslation: 0.845 +instruction: 0.746 +device: 0.736 +assembly: 0.716 +graphic: 0.713 +other: 0.707 +semantic: 0.626 +vnc: 0.550 +boot: 0.462 +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/105/mistranslation/1885175 b/results/classifier/105/mistranslation/1885175 new file mode 100644 index 000000000..499bef3f2 --- /dev/null +++ b/results/classifier/105/mistranslation/1885175 @@ -0,0 +1,95 @@ +mistranslation: 0.905 +other: 0.862 +graphic: 0.832 +device: 0.822 +instruction: 0.820 +semantic: 0.818 +network: 0.812 +KVM: 0.808 +vnc: 0.807 +assembly: 0.803 +boot: 0.800 +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/105/mistranslation/1886097 b/results/classifier/105/mistranslation/1886097 new file mode 100644 index 000000000..ecaa2ff92 --- /dev/null +++ b/results/classifier/105/mistranslation/1886097 @@ -0,0 +1,84 @@ +mistranslation: 0.806 +other: 0.780 +semantic: 0.774 +graphic: 0.769 +assembly: 0.713 +network: 0.673 +instruction: 0.672 +vnc: 0.670 +device: 0.661 +KVM: 0.571 +socket: 0.547 +boot: 0.514 + +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/105/mistranslation/1886306 b/results/classifier/105/mistranslation/1886306 new file mode 100644 index 000000000..4077b8475 --- /dev/null +++ b/results/classifier/105/mistranslation/1886306 @@ -0,0 +1,27 @@ +mistranslation: 0.894 +graphic: 0.795 +device: 0.668 +semantic: 0.584 +instruction: 0.497 +other: 0.445 +network: 0.415 +socket: 0.345 +vnc: 0.291 +assembly: 0.173 +boot: 0.161 +KVM: 0.083 + +qemu running slow when the window is in background + +Reported by <jedinix> on IRC: + +QEMU almost freezes when running with `GDK_BACKEND=x11` set and the parameter `gl=on` added to the `-display` option. + +GDK_BACKEND=x11 qemu-system-x86_64 -nodefaults -no-user-config -enable-kvm -machine q35 -cpu host -m 4G -display gtk,gl=on -vga std -usb -device usb-kbd -drive file=/tmp/Win10.qcow2,media=disk,format=qcow2 -drive file=~/Downloads/Win10_2004_EnglishInternational_x64.iso,media=cdrom + +Leaving out `GDK_BACKEND=x11` or `gl=on` fixes the issue. + +I think there is quite a bit of information missing here? Which host OS / distribution are we talking about here? Which parameters were used for "configure"? Which QEMU version has been used? Is it still reproducible with the latest version? ... thus I wonder whether this should get closed, or whether it's worth the effort to move this to the new tracker at Gitlab? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1886318 b/results/classifier/105/mistranslation/1886318 new file mode 100644 index 000000000..b2ae572a7 --- /dev/null +++ b/results/classifier/105/mistranslation/1886318 @@ -0,0 +1,308 @@ +mistranslation: 0.645 +instruction: 0.620 +semantic: 0.560 +other: 0.556 +graphic: 0.541 +vnc: 0.463 +device: 0.455 +assembly: 0.444 +KVM: 0.411 +socket: 0.391 +network: 0.365 +boot: 0.344 + +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/105/mistranslation/1887309 b/results/classifier/105/mistranslation/1887309 new file mode 100644 index 000000000..89a68385c --- /dev/null +++ b/results/classifier/105/mistranslation/1887309 @@ -0,0 +1,325 @@ +mistranslation: 0.711 +other: 0.696 +KVM: 0.620 +instruction: 0.613 +graphic: 0.603 +device: 0.592 +boot: 0.549 +vnc: 0.531 +semantic: 0.522 +assembly: 0.491 +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/105/mistranslation/1887318 b/results/classifier/105/mistranslation/1887318 new file mode 100644 index 000000000..f44befdeb --- /dev/null +++ b/results/classifier/105/mistranslation/1887318 @@ -0,0 +1,97 @@ +mistranslation: 0.915 +semantic: 0.779 +socket: 0.725 +device: 0.691 +network: 0.680 +graphic: 0.652 +instruction: 0.494 +other: 0.493 +vnc: 0.430 +boot: 0.406 +assembly: 0.369 +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/105/mistranslation/1888492 b/results/classifier/105/mistranslation/1888492 new file mode 100644 index 000000000..1bf75f119 --- /dev/null +++ b/results/classifier/105/mistranslation/1888492 @@ -0,0 +1,82 @@ +mistranslation: 0.800 +instruction: 0.800 +device: 0.796 +other: 0.735 +boot: 0.709 +graphic: 0.694 +socket: 0.681 +semantic: 0.675 +network: 0.668 +vnc: 0.642 +assembly: 0.615 +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/105/mistranslation/1888818 b/results/classifier/105/mistranslation/1888818 new file mode 100644 index 000000000..ffacedb09 --- /dev/null +++ b/results/classifier/105/mistranslation/1888818 @@ -0,0 +1,100 @@ +mistranslation: 0.570 +semantic: 0.508 +other: 0.476 +KVM: 0.415 +graphic: 0.403 +device: 0.361 +instruction: 0.357 +assembly: 0.343 +network: 0.339 +socket: 0.315 +boot: 0.309 +vnc: 0.295 + +Multi-queue vhost-user fails to reconnect with qemu version >=4.2 + +Test Environment: +DPDK version: DPDK v20.08 +Other software versions: qemu4.2, qemu5.0. +OS: Linux 4.15.0-20-generic +Compiler: gcc (Ubuntu 7.3.0-16ubuntu3) 8.4.0 +Hardware platform: Purley. +Test Setup +Steps to reproduce +List the steps to reproduce the issue. + +Test flow +========= +1. Launch vhost-user testpmd as port0 with 2 queues: + +./x86_64-native-linuxapp-gcc/app/testpmd -l 2-4 -n 4 \ + --file-prefix=vhost --vdev 'net_vhost0,iface=vhost-net,queues=2,client=1' -- -i --txd=1024 --rxd=1024 --txq=2 --rxq=2 +testpmd>start + +3. Launch qemu with virtio-net: + + taskset -c 13 \ + qemu-system-x86_64 -name us-vhost-vm1 \ + -cpu host -enable-kvm -m 2048 -object memory-backend-file,id=mem,size=2048M,mem-path=/mnt/huge,share=on \ + -numa node,memdev=mem \ + -mem-prealloc -monitor unix:/tmp/vm2_monitor.sock,server,nowait -netdev user,id=yinan,hostfwd=tcp:127.0.0.1:6005-:22 -device e1000,netdev=yinan \ + -smp cores=1,sockets=1 -drive file=/home/osimg/ubuntu16.img \ + -chardev socket,id=char0,path=./vhost-net,server \ + -netdev type=vhost-user,id=mynet1,chardev=char0,vhostforce,queues=2 \ + -device virtio-net-pci,mac=52:54:00:00:00:01,netdev=mynet1,mrg_rxbuf=on,csum=on,gso=on,host_tso4=on,guest_tso4=on,mq=on,vectors=15 \ + -vnc :10 -daemonize + +6. Quit testpmd and restart vhost-user : + +testpmd>quit +./x86_64-native-linuxapp-gcc/app/testpmd -l 2-4 -n 4 \ + --file-prefix=vhost --vdev 'net_vhost0,iface=vhost-net,queues=2,client=1' -- -i --txd=1024 --rxd=1024 --txq=2 --rxq=2 + + +Expected Result: +After the vhost-user is killed then re-launched, the virtio-net can connect back to vhost-user again. + +Actual Result: +Vhost-user relaunch failed with continous log printed"VHOST_CONFIG: Processing VHOST_USER_SET_FEATURES failed. + +Analysis: +This is a regression bug, bad commit: c6beefd674f +When vhost-user quits, QEMU doesnot save acked features for each virtio-net after vhost-user quits. When vhost-user reconnects to QEMU, QEMU sends two different features(one is the true acked feature while the another is 0x40000000) to vhost-user successively which causing vhost-user exits abnormally. + +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/277 + + diff --git a/results/classifier/105/mistranslation/1888923 b/results/classifier/105/mistranslation/1888923 new file mode 100644 index 000000000..4a8f8be4a --- /dev/null +++ b/results/classifier/105/mistranslation/1888923 @@ -0,0 +1,401 @@ +mistranslation: 0.766 +other: 0.751 +graphic: 0.736 +semantic: 0.729 +instruction: 0.712 +assembly: 0.671 +device: 0.634 +KVM: 0.623 +boot: 0.600 +vnc: 0.595 +network: 0.579 +socket: 0.573 + +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/105/mistranslation/1891748 b/results/classifier/105/mistranslation/1891748 new file mode 100644 index 000000000..94593f7b2 --- /dev/null +++ b/results/classifier/105/mistranslation/1891748 @@ -0,0 +1,118 @@ +mistranslation: 0.866 +semantic: 0.864 +other: 0.815 +boot: 0.811 +device: 0.807 +instruction: 0.791 +assembly: 0.756 +socket: 0.754 +KVM: 0.753 +graphic: 0.727 +vnc: 0.683 +network: 0.589 + +qemu-arm-static 5.1 can't run gcc + +Issue discovered while trying to build pikvm (1) + +Long story short: when using qemu-arm-static 5.1, gcc exits whith message: + +Allocating guest commpage: Operation not permitted + + +when using qemu-arm-static v5.0, gcc "works" + +Steps to reproduce will follow + +(1) https://github.com/pikvm/pikvm/blob/master/pages/building_os.md + +Steps to reproduce + +1. Download and extract attached tarball. + +$ make # will build the docker container + +$ make run # will enter the container + +# once in the container, run + +# /qemu-arm-static-50 /bin/bash /runme.sh + + + + +Additional info, + +error message text ( "Allocating guest commpage" ) found in this commit: + + +https://fossies.org/diffs/qemu/5.0.0_vs_5.1.0-rc0/linux-user/elfload.c-diff.html + +Anyone? Seriously, the problem really exists and we even made a case that reproduces it. Someone please take a look at this. + +Plz take a look at this issue please. + +This has been fixed in mainline, probably commit +8ef618859c379fdce81c91bc93e0574e36ea76ff. + + +Released with QEMU v5.2.0. + +I'm still seeing this with qemu 5.2.0 + +armv7a-softfp-linux-gnueabi-gcc -O2 -pipe -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=softfp -Wl,-O1 -Wl,--as-needed glibc-test.c -o glibc-test +Allocating guest commpage: Operation not permitted + + + +$ qemu-arm --version +qemu-arm version 5.2.0 (Debian 1:5.2+dfsg-6) +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + +I’m seeing this error on a totally different file: + +I’ve made a short test program (hello world-ish) and compiled it with the OpenWrt toolchain but added -static so I can run it on the host using qemu-user-arm: + +$ STAGING_DIR=$PWD/staging_dir PATH=staging_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-7.5.0_musl_eabi/bin:$PATH arm-openwrt-linux-muslgnueabi-gcc -Os -pipe -g3 -fno-caller-saves -fno-plt -fhonour-copts -mfloat-abi=hard -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -static x.c +$ ./a.out +Allocating guest commpage: Operation not permitted + + +Heh, even if I omit -static … + +It works with sudo, but that can’t be the fix… + +Could you check the result of "sysctl vm.mmap_min_addr" + +65536 is the value that works for me. + +@aurent-vivier Checked. +This value does not affect the bug, after changing it, I still get an error. + +Anyone? + +I've been unable to replicate the crash with any of the instructions here. Certainly all the statically compiled unit tests work and I've just done a build of QEMU in an emulated Debian Buster (Armel) docker image. + +Okay, what do you think this problem might be related to? I'm glad your tests are working, but I'm definitely not the only one with this problem. + +I think the output of "sysctl vm" could help to identify which parameter is involved in the problem. You can also compare the output of "sudo sysctl vm" and "sysctl vm" + +In my case, sudo does not affect this bug. My output in attachements. + +Sup? + +Okay, it was found experimentally that the problem is reproduced if vm.mmap_min_addr is greater than 53249. If from 0 to 53249 - everything works. What can this be related to? + +I mean [0...52348] is working. + +Sorry, an error in previous message. + +Fixed and detailed diagnostics: + +[0 ... 53248] - working +[53249 ... 61440] - Cannot allocate memory +[61441 ... 65536 and higher] - Operation not permitted + +Can confirm this bug on fresh Linux Arch and Debian Linux installation. +I need just nothing to reproduce it: Just install fresh arch and do steps described in comment #1 + diff --git a/results/classifier/105/mistranslation/1891749 b/results/classifier/105/mistranslation/1891749 new file mode 100644 index 000000000..789085e0c --- /dev/null +++ b/results/classifier/105/mistranslation/1891749 @@ -0,0 +1,21 @@ +mistranslation: 0.995 +graphic: 0.898 +device: 0.822 +other: 0.675 +instruction: 0.574 +semantic: 0.552 +network: 0.528 +vnc: 0.370 +socket: 0.346 +boot: 0.308 +assembly: 0.186 +KVM: 0.093 + +CGA Mode 6 is only 100 pixels tall, when it's supposed to be 200 + +I have written a program that used CGA Mode 6 (640x200 black and white). However qemu-system-i386 only displays the first 100 pixels, effectively limiting the resolution of mode 6 to 640x100. When running the same program on a real computer it uses the whole 640x200 pixels. + +Could you please provide a test program for this issue? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1892960 b/results/classifier/105/mistranslation/1892960 new file mode 100644 index 000000000..a9301e575 --- /dev/null +++ b/results/classifier/105/mistranslation/1892960 @@ -0,0 +1,342 @@ +mistranslation: 0.445 +other: 0.411 +device: 0.331 +KVM: 0.319 +socket: 0.290 +semantic: 0.261 +boot: 0.250 +graphic: 0.250 +vnc: 0.234 +instruction: 0.217 +network: 0.186 +assembly: 0.186 + +Heap-overflow in flatview_read through sdhci_data_transfer + +Hello, +Reproducer: +cat << EOF | ./qemu-system-i386 -nodefaults \ +-device sdhci-pci,sd-spec-version=3 \ +-device sd-card,drive=mydrive \ +-drive if=sd,index=0,file=null-co://,format=raw,id=mydrive \ +-nographic -qtest stdio -accel qtest +outl 0xcf8 0x80001010 +outl 0xcfc 0xd7055dba +outl 0xcf8 0x80001003 +outl 0xcfc 0x86b1d733 +writeq 0xd7055d2b 0x84126e0ed7d7355e +writeq 0xd7055d23 0x13bd7d7346e0129 +writeq 0xd7055d05 0x615bfb845e05c42c +write 0x0 0x1 0x39 +write 0x5 0x1 0x06 +write 0x6 0x1 0x35 +write 0x7 0x1 0x01 +write 0x1350600 0x1 0x39 +writew 0xd7055d0e 0x846e +write 0x1350600 0x1 0x29 +write 0x1350602 0x1 0x1a +write 0x1350608 0x1 0x39 +clock_step +writeq 0xd7055d03 0x6d00000026000000 +clock_step +EOF + +The trace: + +[R +0.077745] outl 0xcf8 0x80001010 +OK +[S +0.077773] OK +[R +0.077792] outl 0xcfc 0xd7055dba +OK +[S +0.077813] OK +[R +0.077826] outl 0xcf8 0x80001003 +OK +[S +0.077835] OK +[R +0.077846] outl 0xcfc 0x86b1d733 +OK +[S +0.080186] OK +[R +0.080204] writeq 0xd7055d2b 0x84126e0ed7d7355e +752161@1598405049.572123:sdhci_access wr8: addr[0x002b] <- 0x0000005e (94) +752161@1598405049.572133:sdhci_access wr32: addr[0x002c] <- 0x0ed7d735 (249026357) +752161@1598405049.572142:sdhci_access wr16: addr[0x0030] <- 0x0000126e (4718) +752161@1598405049.572150:sdhci_access wr8: addr[0x0032] <- 0x00000084 (132) +OK +[S +0.080255] OK +[R +0.080267] writeq 0xd7055d23 0x13bd7d7346e0129 +752161@1598405049.572176:sdhci_error Non-sequential access to Buffer Data Port registeris prohibited + +752161@1598405049.572181:sdhci_access wr8: addr[0x0023] <- 0x00000029 (41) +752161@1598405049.572187:sdhci_access wr32: addr[0x0024] <- 0xd7346e01 (3610537473) +752161@1598405049.572193:sdhci_access wr16: addr[0x0028] <- 0x00003bd7 (15319) +752161@1598405049.572200:sdhci_access wr8: addr[0x002a] <- 0x00000001 (1) +OK +[S +0.080303] OK +[R +0.080316] writeq 0xd7055d05 0x615bfb845e05c42c +752161@1598405049.572226:sdhci_access wr8: addr[0x0005] <- 0x0000002c (44) +752161@1598405049.572233:sdhci_access wr16: addr[0x0006] <- 0x000005c4 (1476) +752161@1598405049.572240:sdhci_access wr32: addr[0x0008] <- 0x5bfb845e (1543210078) +752161@1598405049.572247:sdhci_access wr8: addr[0x000c] <- 0x00000061 (97) +OK +[S +0.080350] OK +[R +0.080362] write 0x0 0x1 0x39 +OK +[S +0.080606] OK +[R +0.080617] write 0x5 0x1 0x06 +OK +[S +0.080629] OK +[R +0.080639] write 0x6 0x1 0x35 +OK +[S +0.080648] OK +[R +0.080657] write 0x7 0x1 0x01 +OK +[S +0.080665] OK +[R +0.080675] write 0x1350600 0x1 0x39 +OK +[S +0.080863] OK +[R +0.080875] writew 0xd7055d0e 0x846e +752161@1598405049.572786:sdhci_send_command CMD132 ARG[0x5bfb845e] +752161@1598405049.572810:sdhci_error timeout waiting for command response +752161@1598405049.572822:sdhci_adma_loop addr=0x01350600, len=0, attr=0x39 +752161@1598405049.572827:sdhci_adma link: admasysaddr=0x1350600 +752161@1598405049.572833:sdhci_adma_loop addr=0x00000000, len=0, attr=0x39 +752161@1598405049.572837:sdhci_adma link: admasysaddr=0x0 +752161@1598405049.572842:sdhci_adma_loop addr=0x01350600, len=0, attr=0x39 +752161@1598405049.572845:sdhci_adma link: admasysaddr=0x1350600 +752161@1598405049.572851:sdhci_adma_loop addr=0x00000000, len=0, attr=0x39 +752161@1598405049.572854:sdhci_adma link: admasysaddr=0x0 +752161@1598405049.572859:sdhci_adma_loop addr=0x01350600, len=0, attr=0x39 +752161@1598405049.572862:sdhci_adma link: admasysaddr=0x1350600 +752161@1598405049.572875:sdhci_access wr16: addr[0x000e] <- 0x0000846e (33902) +OK +[S +0.080979] OK +[R +0.080991] write 0x1350600 0x1 0x29 +OK +[S +0.081001] OK +[R +0.081011] write 0x1350602 0x1 0x1a +OK +[S +0.081019] OK +[R +0.081029] write 0x1350608 0x1 0x39 +OK +[S +0.081037] OK +[R +0.081045] clock_step +752161@1598405049.572962:sdhci_adma_loop addr=0x00000000, len=26, attr=0x29 +752161@1598405049.572972:sdhci_adma_loop addr=0x00000000, len=0, attr=0x39 +752161@1598405049.572977:sdhci_adma link: admasysaddr=0x0 +752161@1598405049.572981:sdhci_adma_loop addr=0x01350600, len=0, attr=0x39 +752161@1598405049.572985:sdhci_adma link: admasysaddr=0x1350600 +752161@1598405049.572989:sdhci_adma_loop addr=0x00000000, len=26, attr=0x29 +752161@1598405049.572997:sdhci_adma_loop addr=0x00000000, len=0, attr=0x39 +752161@1598405049.573001:sdhci_adma link: admasysaddr=0x0 +OK 100 +[S +0.081112] OK 100 +[R +0.081126] writeq 0xd7055d03 0x6d00000026000000 +752161@1598405049.573038:sdhci_access wr8: addr[0x0003] <- 0x00000000 (0) +752161@1598405049.573045:sdhci_access wr32: addr[0x0004] <- 0x00260000 (2490368) +752161@1598405049.573051:sdhci_access wr16: addr[0x0008] <- 0x00000000 (0) +752161@1598405049.573057:sdhci_access wr8: addr[0x000a] <- 0x0000006d (109) +OK +[S +0.081162] OK +[R +0.081171] clock_step +752161@1598405049.573085:sdhci_adma_loop addr=0x01350600, len=0, attr=0x39 +752161@1598405049.573090:sdhci_adma link: admasysaddr=0x1350600 +752161@1598405049.573096:sdhci_adma_loop addr=0x00000000, len=26, attr=0x29 +================================================================= +==752161==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61500001e500 at pc 0x5651bce1a940 bp 0x7fff16a81f50 sp 0x7fff16a81718 +WRITE of size 786432 at 0x61500001e500 thread T0 + #0 0x5651bce1a93f in __asan_memcpy (/home/alxndr/Development/qemu/general-fuzz/build/qemu-system-i386+0x2d2893f) + #1 0x5651bf4197ce in flatview_read_continue /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3246:13 + #2 0x5651bf41bff3 in flatview_read /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3279:12 + #3 0x5651bf41bb48 in address_space_read_full /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3292:18 + #4 0x5651bf41cce8 in address_space_rw /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3320:16 + #5 0x5651bd623b67 in dma_memory_rw_relaxed /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:87:18 + #6 0x5651bd623585 in dma_memory_rw /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:110:12 + #7 0x5651bd6227b7 in dma_memory_read /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:116:12 + #8 0x5651bd61b052 in sdhci_do_adma /home/alxndr/Development/qemu/general-fuzz/build/../hw/sd/sdhci.c:792:21 + #9 0x5651bd60d3c4 in sdhci_data_transfer /home/alxndr/Development/qemu/general-fuzz/build/../hw/sd/sdhci.c:887:13 + #10 0x5651c0c4d917 in timerlist_run_timers /home/alxndr/Development/qemu/general-fuzz/build/../util/qemu-timer.c:572:9 + #11 0x5651c0c4de51 in qemu_clock_run_timers /home/alxndr/Development/qemu/general-fuzz/build/../util/qemu-timer.c:586:12 + #12 0x5651bf562a13 in qtest_clock_warp /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/cpus.c:507:9 + #13 0x5651bf74f5d8 in qtest_process_command /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/qtest.c:665:9 + #14 0x5651bf73d63e in qtest_process_inbuf /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/qtest.c:710:9 + #15 0x5651bf73c3e3 in qtest_read /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/qtest.c:722:5 + #16 0x5651c0842762 in qemu_chr_be_write_impl /home/alxndr/Development/qemu/general-fuzz/build/../chardev/char.c:188:9 + #17 0x5651c08428aa in qemu_chr_be_write /home/alxndr/Development/qemu/general-fuzz/build/../chardev/char.c:200:9 + #18 0x5651c0868514 in fd_chr_read /home/alxndr/Development/qemu/general-fuzz/build/../chardev/char-fd.c:68:9 + #19 0x5651c0754736 in qio_channel_fd_source_dispatch /home/alxndr/Development/qemu/general-fuzz/build/../io/channel-watch.c:84:12 + #20 0x7fac88fad4cd in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x504cd) + #21 0x5651c0cdfc67 in glib_pollfds_poll /home/alxndr/Development/qemu/general-fuzz/build/../util/main-loop.c:217:9 + #22 0x5651c0cdd567 in os_host_main_loop_wait /home/alxndr/Development/qemu/general-fuzz/build/../util/main-loop.c:240:5 + #23 0x5651c0cdcf47 in main_loop_wait /home/alxndr/Development/qemu/general-fuzz/build/../util/main-loop.c:516:11 + #24 0x5651bf4bb08d in qemu_main_loop /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/vl.c:1676:9 + #25 0x5651bce4d51c in main /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/main.c:50:5 + #26 0x7fac887b6cc9 in __libc_start_main csu/../csu/libc-start.c:308:16 + #27 0x5651bcda2cf9 in _start (/home/alxndr/Development/qemu/general-fuzz/build/qemu-system-i386+0x2cb0cf9) + +0x61500001e500 is located 0 bytes to the right of 512-byte region [0x61500001e300,0x61500001e500) +allocated by thread T0 here: + #0 0x5651bce1b5b2 in calloc (/home/alxndr/Development/qemu/general-fuzz/build/qemu-system-i386+0x2d295b2) + #1 0x7fac88fb3210 in g_malloc0 (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x56210) + #2 0x5651bd8cd222 in sdhci_pci_realize /home/alxndr/Development/qemu/general-fuzz/build/../hw/sd/sdhci-pci.c:36:5 + #3 0x5651bd88c228 in pci_qdev_realize /home/alxndr/Development/qemu/general-fuzz/build/../hw/pci/pci.c:2114:9 + #4 0x5651c07a4ec9 in device_set_realized /home/alxndr/Development/qemu/general-fuzz/build/../hw/core/qdev.c:864:13 + #5 0x5651bfe384b8 in property_set_bool /home/alxndr/Development/qemu/general-fuzz/build/../qom/object.c:2202:5 + #6 0x5651bfe2c1cf in object_property_set /home/alxndr/Development/qemu/general-fuzz/build/../qom/object.c:1349:5 + #7 0x5651bfe49471 in object_property_set_qobject /home/alxndr/Development/qemu/general-fuzz/build/../qom/qom-qobject.c:28:10 + #8 0x5651bfe2d890 in object_property_set_bool /home/alxndr/Development/qemu/general-fuzz/build/../qom/object.c:1416:15 + #9 0x5651c078cc64 in qdev_realize /home/alxndr/Development/qemu/general-fuzz/build/../hw/core/qdev.c:379:12 + #10 0x5651bd8bd8cc in qdev_device_add /home/alxndr/Development/qemu/general-fuzz/build/../qdev-monitor.c:676:10 + #11 0x5651bf4e3e43 in device_init_func /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/vl.c:2101:11 + #12 0x5651c0af71e4 in qemu_opts_foreach /home/alxndr/Development/qemu/general-fuzz/build/../util/qemu-option.c:1172:14 + #13 0x5651bf4cd04b in qemu_init /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/vl.c:4384:5 + #14 0x5651bce4d517 in main /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/main.c:49:5 + #15 0x7fac887b6cc9 in __libc_start_main csu/../csu/libc-start.c:308:16 + +SUMMARY: AddressSanitizer: heap-buffer-overflow (/home/alxndr/Development/qemu/general-fuzz/build/qemu-system-i386+0x2d2893f) in __asan_memcpy +Shadow bytes around the buggy address: + 0x0c2a7fffbc50: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c2a7fffbc60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0x0c2a7fffbc70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0x0c2a7fffbc80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0x0c2a7fffbc90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +=>0x0c2a7fffbca0:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c2a7fffbcb0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c2a7fffbcc0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c2a7fffbcd0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c2a7fffbce0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c2a7fffbcf0: 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 +==752161==ABORTING + +-Alex + +Proposed patch + -> https://lists.nongnu.org/archive/html/qemu-devel/2020-08/msg07968.html + +The 'Transfer Block Size' field is 12-bit wide. + +See section '2.2.2. Block Size Register (Offset 004h)' in datasheet. + +Cc: <email address hidden> +Cc: Igor Mitsyanko <email address hidden> +Buglink: https://bugs.launchpad.net/qemu/+bug/1892960 +Fixes: d7dfca0807a ("hw/sdhci: introduce standard SD host controller") +Reported-by: Alexander Bulekov <email address hidden> +Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +--- +Cc: <email address hidden> +--- + hw/sd/sdhci.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c +index 60f083b84c1..beb7b7ea092 100644 +--- a/hw/sd/sdhci.c ++++ b/hw/sd/sdhci.c +@@ -1104,7 +1104,7 @@ sdhci_write(void *opaque, hwaddr offset, uint64_t val, unsigned size) + break; + case SDHC_BLKSIZE: + if (!TRANSFERRING_DATA(s->prnsts)) { +- MASKED_WRITE(s->blksize, mask, value); ++ MASKED_WRITE(s->blksize, mask, extract32(s->blksize, 0, 12)); + MASKED_WRITE(s->blkcnt, mask >> 16, value >> 16); + } + +-- +2.26.2 + + + +On 9/1/20 4:01 PM, Philippe Mathieu-Daudé wrote: +> The 'Transfer Block Size' field is 12-bit wide. +> +> See section '2.2.2. Block Size Register (Offset 004h)' in datasheet. +> +> Cc: <email address hidden> +> Cc: Igor Mitsyanko <email address hidden> +> Buglink: https://bugs.launchpad.net/qemu/+bug/1892960 +> Fixes: d7dfca0807a ("hw/sdhci: introduce standard SD host controller") +> Reported-by: Alexander Bulekov <email address hidden> +> Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +> --- +> Cc: <email address hidden> +> --- +> hw/sd/sdhci.c | 2 +- +> 1 file changed, 1 insertion(+), 1 deletion(-) +> +> diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c +> index 60f083b84c1..beb7b7ea092 100644 +> --- a/hw/sd/sdhci.c +> +++ b/hw/sd/sdhci.c +> @@ -1104,7 +1104,7 @@ sdhci_write(void *opaque, hwaddr offset, uint64_t val, unsigned size) +> break; +> case SDHC_BLKSIZE: +> if (!TRANSFERRING_DATA(s->prnsts)) { +> - MASKED_WRITE(s->blksize, mask, value); +> + MASKED_WRITE(s->blksize, mask, extract32(s->blksize, 0, 12)); + +Beh change unstaged, sorry, will repost. + +> MASKED_WRITE(s->blkcnt, mask >> 16, value >> 16); +> } +> +> + + + +The 'Transfer Block Size' field is 12-bit wide. + +See section '2.2.2. Block Size Register (Offset 004h)' in datasheet. + +Cc: <email address hidden> +Cc: Igor Mitsyanko <email address hidden> +Buglink: https://bugs.launchpad.net/qemu/+bug/1892960 +Fixes: d7dfca0807a ("hw/sdhci: introduce standard SD host controller") +Reported-by: Alexander Bulekov <email address hidden> +Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +--- +Cc: <email address hidden> +--- + hw/sd/sdhci.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c +index 60f083b84c1..ecbf84e9d3f 100644 +--- a/hw/sd/sdhci.c ++++ b/hw/sd/sdhci.c +@@ -1104,7 +1104,7 @@ sdhci_write(void *opaque, hwaddr offset, uint64_t val, unsigned size) + break; + case SDHC_BLKSIZE: + if (!TRANSFERRING_DATA(s->prnsts)) { +- MASKED_WRITE(s->blksize, mask, value); ++ MASKED_WRITE(s->blksize, mask, extract32(value, 0, 12)); + MASKED_WRITE(s->blkcnt, mask >> 16, value >> 16); + } + +-- +2.26.2 + + + +Fixed in commit dfba99f17feb6d4a129da19d38df1bcd8579d1c3. + +Released with QEMU v5.2.0. + diff --git a/results/classifier/105/mistranslation/1896263 b/results/classifier/105/mistranslation/1896263 new file mode 100644 index 000000000..75fb78307 --- /dev/null +++ b/results/classifier/105/mistranslation/1896263 @@ -0,0 +1,598 @@ +mistranslation: 0.685 +other: 0.651 +vnc: 0.634 +KVM: 0.608 +device: 0.588 +instruction: 0.562 +semantic: 0.553 +graphic: 0.545 +assembly: 0.542 +socket: 0.536 +boot: 0.520 +network: 0.517 + +The bios-tables-test test causes QEMU to crash (Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed) on AMD processors + +QEMU release version: Any recent version (5.0.0, 5.1.0, git master) +Host CPU: AMD Ryzen 3900X + +The following backtrace is from commit e883b492c221241d28aaa322c61536436090538a. + +QTEST_QEMU_BINARY=./build/qemu-system-x86_64 gdb ./build/tests/qtest/bios-tables-test +GNU gdb (GDB) 9.2 +Copyright (C) 2020 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. +Type "show copying" and "show warranty" for details. +This GDB was configured as "x86_64-unknown-linux-gnu". +Type "show configuration" for configuration details. +For bug reporting instructions, please see: +<http://www.gnu.org/software/gdb/bugs/>. +Find the GDB manual and other documentation resources online at: + <http://www.gnu.org/software/gdb/documentation/>. + +For help, type "help". +Type "apropos word" to search for commands related to "word"... +Reading symbols from ./build/tests/qtest/bios-tables-test... +(gdb) run +Starting program: /home/mcournoyer/src/qemu/build/tests/qtest/bios-tables-test +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libthread_db.so.1". +[New Thread 0x7ffff7af6700 (LWP 18955)] +# random seed: R02S5106b7afa2fd84a0353605795c04ab7d +1..19 +# Start of x86_64 tests +# Start of acpi tests +# starting QEMU: exec ./build/qemu-system-x86_64 -qtest unix:/tmp/qtest-18951.sock -qtest-log /dev/null -chardev socket,path=/tmp/qtest-18951.qmp,id=char0 -mon chardev=char0,mode=control -display none -machine pc,kernel-irqchip=off -accel kvm -accel tcg -net none -display none -drive id=hd0,if=none,file=tests/acpi-test-disk-R3kbyc,format=raw -device ide-hd,drive=hd0 -accel qtest +[Attaching after Thread 0x7ffff7af7900 (LWP 18951) fork to child process 18956] +[New inferior 2 (process 18956)] +[Detaching after fork from parent process 18951] +[Inferior 1 (process 18951) detached] +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libthread_db.so.1". +[New Thread 0x7ffff7af6700 (LWP 18957)] +[Thread 0x7ffff7af6700 (LWP 18957) exited] +process 18956 is executing new program: /gnu/store/87kif0bpf0anwbsaw0jvg8fyciw4sz67-bash-5.0.16/bin/bash +process 18956 is executing new program: /home/mcournoyer/src/qemu/build/qemu-system-x86_64 +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libthread_db.so.1". +[New Thread 0x7ffff48ed700 (LWP 18958)] +[New Thread 0x7fffeffff700 (LWP 18960)] +[New Thread 0x7fffef61c700 (LWP 18961)] +[New Thread 0x7fffed5ff700 (LWP 18962)] +qemu-system-x86_64: error: failed to set MSR 0x4b564d02 to 0x0 +qemu-system-x86_64: ../target/i386/kvm.c:2714: kvm_buf_set_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. + +Thread 2.5 "qemu-system-x86" received signal SIGABRT, Aborted. +[Switching to Thread 0x7fffef61c700 (LWP 18961)] +0x00007ffff65dbaba in raise () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6 +(gdb) taas bt + +Thread 2.6 (Thread 0x7fffed5ff700 (LWP 18962)): +#0 0x00007ffff6770c4d in pthread_cond_timedwait@@GLIBC_2.3.2 () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libpthread.so.0 +#1 0x0000555555cc8a0e in qemu_sem_timedwait (sem=sem@entry=0x55555662f758, ms=ms@entry=10000) at ../util/qemu-thread-posix.c:282 +#2 0x0000555555cd91b5 in worker_thread (opaque=opaque@entry=0x55555662f6e0) at ../util/thread-pool.c:91 +#3 0x0000555555cc7e86 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:521 +#4 0x00007ffff6769f64 in start_thread () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libpthread.so.0 +#5 0x00007ffff669b9af in clone () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6 + +Thread 2.5 (Thread 0x7fffef61c700 (LWP 18961)): +#0 0x00007ffff65dbaba in raise () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6 +#1 0x00007ffff65dcbf5 in abort () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6 +#2 0x00007ffff65d470a in __assert_fail_base () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6 +#3 0x00007ffff65d4782 in __assert_fail () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6 +#4 0x0000555555a3e979 in kvm_buf_set_msrs (cpu=0x555556688a20) at ../target/i386/kvm.c:2714 +#5 0x0000555555a438cc in kvm_put_msrs (level=3, cpu=0x555556688a20) at ../target/i386/kvm.c:3005 +#6 kvm_arch_put_registers (cpu=cpu@entry=0x555556688a20, level=level@entry=3) at ../target/i386/kvm.c:3989 +#7 0x0000555555af7b0e in do_kvm_cpu_synchronize_post_init (cpu=0x555556688a20, arg=...) at ../accel/kvm/kvm-all.c:2355 +#8 0x00005555558ef8e2 in process_queued_cpu_work (cpu=cpu@entry=0x555556688a20) at ../cpus-common.c:343 +#9 0x0000555555b6ac25 in qemu_wait_io_event_common (cpu=cpu@entry=0x555556688a20) at ../softmmu/cpus.c:1117 +#10 0x0000555555b6ac84 in qemu_wait_io_event (cpu=cpu@entry=0x555556688a20) at ../softmmu/cpus.c:1157 +#11 0x0000555555b6aec8 in qemu_kvm_cpu_thread_fn (arg=arg@entry=0x555556688a20) at ../softmmu/cpus.c:1193 +#12 0x0000555555cc7e86 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:521 +#13 0x00007ffff6769f64 in start_thread () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libpthread.so.0 +#14 0x00007ffff669b9af in clone () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6 + +Thread 2.4 (Thread 0x7fffeffff700 (LWP 18960)): +#0 0x00007ffff66919d9 in poll () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6 +#1 0x00007ffff78f0051 in g_main_context_iterate.isra () from /gnu/store/n1mx1dp0hcrzm1akf8qdqa9gmybzazs2-profile/lib/libglib-2.0.so.0 +#2 0x00007ffff78f0392 in g_main_loop_run () from /gnu/store/n1mx1dp0hcrzm1akf8qdqa9gmybzazs2-profile/lib/libglib-2.0.so.0 +#3 0x000055555584b5a1 in iothread_run (opaque=opaque@entry=0x555556557720) at ../iothread.c:80 +#4 0x0000555555cc7e86 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:521 +#5 0x00007ffff6769f64 in start_thread () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libpthread.so.0 +#6 0x00007ffff669b9af in clone () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6 + +Thread 2.3 (Thread 0x7ffff48ed700 (LWP 18958)): +#0 0x00007ffff66657a1 in clock_nanosleep@GLIBC_2.2.5 () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6 +#1 0x00007ffff666ac03 in nanosleep () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6 +#2 0x00007ffff7919cdf in g_usleep () from /gnu/store/n1mx1dp0hcrzm1akf8qdqa9gmybzazs2-profile/lib/libglib-2.0.so.0 +#3 0x0000555555cb3b04 in call_rcu_thread (opaque=opaque@entry=0x0) at ../util/rcu.c:250 +#4 0x0000555555cc7e86 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:521 +#5 0x00007ffff6769f64 in start_thread () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libpthread.so.0 +#6 0x00007ffff669b9af in clone () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6 + +Thread 2.1 (Thread 0x7ffff48f2c80 (LWP 18956)): +#0 0x00007ffff677094c in pthread_cond_wait@@GLIBC_2.3.2 () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libpthread.so.0 +#1 0x0000555555cc854f in qemu_cond_wait_impl (cond=0x5555563b0020 <qemu_work_cond>, mutex=0x5555563cd620 <qemu_global_mutex>, file=0x555555dbad06 "../cpus-common.c", line=154) at ../util/qemu-thread-posix.c:174 +#2 0x00005555558ef484 in do_run_on_cpu (cpu=cpu@entry=0x555556688a20, func=func@entry=0x555555af7b00 <do_kvm_cpu_synchronize_post_init>, data=..., mutex=mutex@entry=0x5555563cd620 <qemu_global_mutex>) at ../cpus-common.c:154 +#3 0x0000555555b6aa7c in run_on_cpu (cpu=cpu@entry=0x555556688a20, func=func@entry=0x555555af7b00 <do_kvm_cpu_synchronize_post_init>, data=..., data@entry=...) at ../softmmu/cpus.c:1085 +#4 0x0000555555af8d4e in kvm_cpu_synchronize_post_init (cpu=cpu@entry=0x555556688a20) at ../accel/kvm/kvm-all.c:2361 +#5 0x0000555555b6a94a in cpu_synchronize_post_init (cpu=0x555556688a20) at /home/mcournoyer/src/qemu/include/sysemu/hw_accel.h:55 +#6 cpu_synchronize_all_post_init () at ../softmmu/cpus.c:953 +#7 0x0000555555b0dca7 in qemu_init (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../softmmu/vl.c:4387 +#8 0x0000555555840609 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../softmmu/main.c:49 + +On Fri, Sep 18, 2020 at 6:18 PM Apteryx <email address hidden> wrote: +> Host CPU: AMD Ryzen 3900X + +I also hit this test failure. + +Host CPU: Intel(R) Core(TM) i7-8665U CPU @ 1.90GHz +Host kernel: Linux 5.8.6-201.fc32.x86_64 + +qemu-system-x86_64: error: failed to set MSR 0x4b564d02 to 0x0 +qemu-system-x86_64: ../target/i386/kvm.c:2714: kvm_buf_set_msrs: +Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. + + +I've reproduced the problem with HEAD of master, qemu-4.2.0 and qemu-4.0.0. + +I think the problem comes from the the kernel. + +Host CPU: Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz +Host kernel: 5.8.4-200.fc32.x86_64 + + +Le 21/09/2020 à 15:50, Laurent Vivier a écrit : +> I've reproduced the problem with HEAD of master, qemu-4.2.0 and +> qemu-4.0.0. +> +> I think the problem comes from the the kernel. +> + +This is reproducible with vanilla kernel v5.8.0 but fixed in v5.9.0-rc5+. + + +Le 22/09/2020 à 11:05, Laurent Vivier a écrit : +> Le 21/09/2020 à 15:50, Laurent Vivier a écrit : +>> I've reproduced the problem with HEAD of master, qemu-4.2.0 and +>> qemu-4.0.0. +>> +>> I think the problem comes from the the kernel. +>> +> +> This is reproducible with vanilla kernel v5.8.0 but fixed in +> v5.9.0-rc5+. +> + +It seems to be fixed in 5.9 kernel by: + +commit d831de177217cd494bfb99f2c849a0d40c2a7890 +Author: Vitaly Kuznetsov <email address hidden> +Date: Fri Sep 11 11:31:47 2020 +0200 + + KVM: x86: always allow writing '0' to MSR_KVM_ASYNC_PF_EN + + Even without in-kernel LAPIC we should allow writing '0' to + MSR_KVM_ASYNC_PF_EN as we're not enabling the mechanism. In + particular, QEMU with 'kernel-irqchip=off' fails to start + a guest with + + qemu-system-x86_64: error: failed to set MSR 0x4b564d02 to 0x0 + + Fixes: 9d3c447c72fb2 ("KVM: X86: Fix async pf caused null-ptr-deref") + Reported-by: Dr. David Alan Gilbert <email address hidden> + Signed-off-by: Vitaly Kuznetsov <email address hidden> + Message-Id: <email address hidden> + [Actually commit the version proposed by Sean Christopherson. - Paolo] + Signed-off-by: Paolo Bonzini <email address hidden> + + +This addresses the following crash when running Linux v5.8 +with kernel-irqchip=off: + + qemu-system-x86_64: error: failed to set MSR 0x4b564d02 to 0x0 + qemu-system-x86_64: ../target/i386/kvm.c:2714: kvm_buf_set_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. + +There is a kernel-side fix for the issue too (kernel commit +d831de177217 "KVM: x86: always allow writing '0' to +MSR_KVM_ASYNC_PF_EN"), but it's nice to simply not trigger +the bug if running an older kernel. + +Fixes: https://bugs.launchpad.net/bugs/1896263 +Signed-off-by: Eduardo Habkost <email address hidden> +--- + target/i386/kvm.c | 7 ++++++- + 1 file changed, 6 insertions(+), 1 deletion(-) + +diff --git a/target/i386/kvm.c b/target/i386/kvm.c +index 9efb07e7c83..1492f41349f 100644 +--- a/target/i386/kvm.c ++++ b/target/i386/kvm.c +@@ -2818,7 +2818,12 @@ static int kvm_put_msrs(X86CPU *cpu, int level) + kvm_msr_entry_add(cpu, MSR_IA32_TSC, env->tsc); + kvm_msr_entry_add(cpu, MSR_KVM_SYSTEM_TIME, env->system_time_msr); + kvm_msr_entry_add(cpu, MSR_KVM_WALL_CLOCK, env->wall_clock_msr); +- if (env->features[FEAT_KVM] & (1 << KVM_FEATURE_ASYNC_PF)) { ++ /* ++ * Some kernel versions (v5.8) won't let MSR_KVM_ASYNC_PF_EN to be set ++ * at all if kernel-irqchip=off, so don't try to set it in that case. ++ */ ++ if (env->features[FEAT_KVM] & (1 << KVM_FEATURE_ASYNC_PF) && ++ kvm_irqchip_in_kernel()) { + kvm_msr_entry_add(cpu, MSR_KVM_ASYNC_PF_EN, env->async_pf_en_msr); + } + if (env->features[FEAT_KVM] & (1 << KVM_FEATURE_PV_EOI)) { +-- +2.26.2 + + + +Eduardo Habkost <email address hidden> writes: + +> This addresses the following crash when running Linux v5.8 +> with kernel-irqchip=off: +> +> qemu-system-x86_64: error: failed to set MSR 0x4b564d02 to 0x0 +> qemu-system-x86_64: ../target/i386/kvm.c:2714: kvm_buf_set_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. +> +> There is a kernel-side fix for the issue too (kernel commit +> d831de177217 "KVM: x86: always allow writing '0' to +> MSR_KVM_ASYNC_PF_EN"), but it's nice to simply not trigger +> the bug if running an older kernel. +> +> Fixes: https://bugs.launchpad.net/bugs/1896263 +> Signed-off-by: Eduardo Habkost <email address hidden> +> --- +> target/i386/kvm.c | 7 ++++++- +> 1 file changed, 6 insertions(+), 1 deletion(-) +> +> diff --git a/target/i386/kvm.c b/target/i386/kvm.c +> index 9efb07e7c83..1492f41349f 100644 +> --- a/target/i386/kvm.c +> +++ b/target/i386/kvm.c +> @@ -2818,7 +2818,12 @@ static int kvm_put_msrs(X86CPU *cpu, int level) +> kvm_msr_entry_add(cpu, MSR_IA32_TSC, env->tsc); +> kvm_msr_entry_add(cpu, MSR_KVM_SYSTEM_TIME, env->system_time_msr); +> kvm_msr_entry_add(cpu, MSR_KVM_WALL_CLOCK, env->wall_clock_msr); +> - if (env->features[FEAT_KVM] & (1 << KVM_FEATURE_ASYNC_PF)) { +> + /* +> + * Some kernel versions (v5.8) won't let MSR_KVM_ASYNC_PF_EN to be set +> + * at all if kernel-irqchip=off, so don't try to set it in that case. +> + */ +> + if (env->features[FEAT_KVM] & (1 << KVM_FEATURE_ASYNC_PF) && +> + kvm_irqchip_in_kernel()) { +> kvm_msr_entry_add(cpu, MSR_KVM_ASYNC_PF_EN, env->async_pf_en_msr); +> } +> if (env->features[FEAT_KVM] & (1 << KVM_FEATURE_PV_EOI)) { + +I'm not sure kvm_irqchip_in_kernel() was required before we switched to +interrupt-based APF (as we were always injecting #PF) but with +kernel-5.8+ this should work. We'll need to merge this with + +https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg02963.html +(queued by Paolo) and +https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg06196.html +which fixes a bug in it. + +as kvm_irqchip_in_kernel() should go around both KVM_FEATURE_ASYNC_PF +and KVM_FEATURE_ASYNC_PF_INT I believe. + +-- +Vitaly + + + +On Tue, Sep 22, 2020 at 05:38:12PM +0200, Vitaly Kuznetsov wrote: +> Eduardo Habkost <email address hidden> writes: +> +> > This addresses the following crash when running Linux v5.8 +> > with kernel-irqchip=off: +> > +> > qemu-system-x86_64: error: failed to set MSR 0x4b564d02 to 0x0 +> > qemu-system-x86_64: ../target/i386/kvm.c:2714: kvm_buf_set_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. +> > +> > There is a kernel-side fix for the issue too (kernel commit +> > d831de177217 "KVM: x86: always allow writing '0' to +> > MSR_KVM_ASYNC_PF_EN"), but it's nice to simply not trigger +> > the bug if running an older kernel. +> > +> > Fixes: https://bugs.launchpad.net/bugs/1896263 +> > Signed-off-by: Eduardo Habkost <email address hidden> +> > --- +> > target/i386/kvm.c | 7 ++++++- +> > 1 file changed, 6 insertions(+), 1 deletion(-) +> > +> > diff --git a/target/i386/kvm.c b/target/i386/kvm.c +> > index 9efb07e7c83..1492f41349f 100644 +> > --- a/target/i386/kvm.c +> > +++ b/target/i386/kvm.c +> > @@ -2818,7 +2818,12 @@ static int kvm_put_msrs(X86CPU *cpu, int level) +> > kvm_msr_entry_add(cpu, MSR_IA32_TSC, env->tsc); +> > kvm_msr_entry_add(cpu, MSR_KVM_SYSTEM_TIME, env->system_time_msr); +> > kvm_msr_entry_add(cpu, MSR_KVM_WALL_CLOCK, env->wall_clock_msr); +> > - if (env->features[FEAT_KVM] & (1 << KVM_FEATURE_ASYNC_PF)) { +> > + /* +> > + * Some kernel versions (v5.8) won't let MSR_KVM_ASYNC_PF_EN to be set +> > + * at all if kernel-irqchip=off, so don't try to set it in that case. +> > + */ +> > + if (env->features[FEAT_KVM] & (1 << KVM_FEATURE_ASYNC_PF) && +> > + kvm_irqchip_in_kernel()) { +> > kvm_msr_entry_add(cpu, MSR_KVM_ASYNC_PF_EN, env->async_pf_en_msr); +> > } +> > if (env->features[FEAT_KVM] & (1 << KVM_FEATURE_PV_EOI)) { +> +> I'm not sure kvm_irqchip_in_kernel() was required before we switched to +> interrupt-based APF (as we were always injecting #PF) but with +> kernel-5.8+ this should work. [...] + +Were guests able to set MSR_KVM_ASYNC_PF_EN to non-zero with +kernel-irqchip=off on hosts running Linux <= 5.7? I am assuming +kvm-asyncpf never worked with kernel-irqchip=off (and enabling it +by default with kernel-irqchip=off was a mistake). + + +> [...] We'll need to merge this with +> +> https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg02963.html +> (queued by Paolo) and +> https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg06196.html +> which fixes a bug in it. +> +> as kvm_irqchip_in_kernel() should go around both KVM_FEATURE_ASYNC_PF +> and KVM_FEATURE_ASYNC_PF_INT I believe. + +Shouldn't we just disallow kvm-asyncpf-int=on if kernel-irqchip=off? + +-- +Eduardo + + + +Eduardo Habkost <email address hidden> writes: + +> On Tue, Sep 22, 2020 at 05:38:12PM +0200, Vitaly Kuznetsov wrote: +>> Eduardo Habkost <email address hidden> writes: +>> +>> > This addresses the following crash when running Linux v5.8 +>> > with kernel-irqchip=off: +>> > +>> > qemu-system-x86_64: error: failed to set MSR 0x4b564d02 to 0x0 +>> > qemu-system-x86_64: ../target/i386/kvm.c:2714: kvm_buf_set_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. +>> > +>> > There is a kernel-side fix for the issue too (kernel commit +>> > d831de177217 "KVM: x86: always allow writing '0' to +>> > MSR_KVM_ASYNC_PF_EN"), but it's nice to simply not trigger +>> > the bug if running an older kernel. +>> > +>> > Fixes: https://bugs.launchpad.net/bugs/1896263 +>> > Signed-off-by: Eduardo Habkost <email address hidden> +>> > --- +>> > target/i386/kvm.c | 7 ++++++- +>> > 1 file changed, 6 insertions(+), 1 deletion(-) +>> > +>> > diff --git a/target/i386/kvm.c b/target/i386/kvm.c +>> > index 9efb07e7c83..1492f41349f 100644 +>> > --- a/target/i386/kvm.c +>> > +++ b/target/i386/kvm.c +>> > @@ -2818,7 +2818,12 @@ static int kvm_put_msrs(X86CPU *cpu, int level) +>> > kvm_msr_entry_add(cpu, MSR_IA32_TSC, env->tsc); +>> > kvm_msr_entry_add(cpu, MSR_KVM_SYSTEM_TIME, env->system_time_msr); +>> > kvm_msr_entry_add(cpu, MSR_KVM_WALL_CLOCK, env->wall_clock_msr); +>> > - if (env->features[FEAT_KVM] & (1 << KVM_FEATURE_ASYNC_PF)) { +>> > + /* +>> > + * Some kernel versions (v5.8) won't let MSR_KVM_ASYNC_PF_EN to be set +>> > + * at all if kernel-irqchip=off, so don't try to set it in that case. +>> > + */ +>> > + if (env->features[FEAT_KVM] & (1 << KVM_FEATURE_ASYNC_PF) && +>> > + kvm_irqchip_in_kernel()) { +>> > kvm_msr_entry_add(cpu, MSR_KVM_ASYNC_PF_EN, env->async_pf_en_msr); +>> > } +>> > if (env->features[FEAT_KVM] & (1 << KVM_FEATURE_PV_EOI)) { +>> +>> I'm not sure kvm_irqchip_in_kernel() was required before we switched to +>> interrupt-based APF (as we were always injecting #PF) but with +>> kernel-5.8+ this should work. [...] +> +> Were guests able to set MSR_KVM_ASYNC_PF_EN to non-zero with +> kernel-irqchip=off on hosts running Linux <= 5.7? + +lapic_in_kernel() check appeared in kernel with the following commit: + +commit 9d3c447c72fb2337ca39f245c6ae89f2369de216 +Author: Wanpeng Li <email address hidden> +Date: Mon Jun 29 18:26:31 2020 +0800 + + KVM: X86: Fix async pf caused null-ptr-deref + +which was post-interrupt-based-APF. I *think* it was OK to enable APF +with !lapic_in_kernel() before (at least I don't see what would not +allow that). + +> I am assuming +> kvm-asyncpf never worked with kernel-irqchip=off (and enabling it +> by default with kernel-irqchip=off was a mistake). +> +> +>> [...] We'll need to merge this with +>> +>> https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg02963.html +>> (queued by Paolo) and +>> https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg06196.html +>> which fixes a bug in it. +>> +>> as kvm_irqchip_in_kernel() should go around both KVM_FEATURE_ASYNC_PF +>> and KVM_FEATURE_ASYNC_PF_INT I believe. +> +> Shouldn't we just disallow kvm-asyncpf-int=on if kernel-irqchip=off? + +(Sarcasm: if disallowing 'kernel-irqchip=off' is not an option, then) +yes, we probably can, but kvm-asyncpf-int=on is the default we have so +we can't just implicitly change it underneath or migration will break... + +-- +Vitaly + + + +On Tue, Sep 22, 2020 at 06:42:17PM +0200, Vitaly Kuznetsov wrote: +> Eduardo Habkost <email address hidden> writes: +> +> > On Tue, Sep 22, 2020 at 05:38:12PM +0200, Vitaly Kuznetsov wrote: +> >> Eduardo Habkost <email address hidden> writes: +> >> +> >> > This addresses the following crash when running Linux v5.8 +> >> > with kernel-irqchip=off: +> >> > +> >> > qemu-system-x86_64: error: failed to set MSR 0x4b564d02 to 0x0 +> >> > qemu-system-x86_64: ../target/i386/kvm.c:2714: kvm_buf_set_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. +> >> > +> >> > There is a kernel-side fix for the issue too (kernel commit +> >> > d831de177217 "KVM: x86: always allow writing '0' to +> >> > MSR_KVM_ASYNC_PF_EN"), but it's nice to simply not trigger +> >> > the bug if running an older kernel. +> >> > +> >> > Fixes: https://bugs.launchpad.net/bugs/1896263 +> >> > Signed-off-by: Eduardo Habkost <email address hidden> +> >> > --- +> >> > target/i386/kvm.c | 7 ++++++- +> >> > 1 file changed, 6 insertions(+), 1 deletion(-) +> >> > +> >> > diff --git a/target/i386/kvm.c b/target/i386/kvm.c +> >> > index 9efb07e7c83..1492f41349f 100644 +> >> > --- a/target/i386/kvm.c +> >> > +++ b/target/i386/kvm.c +> >> > @@ -2818,7 +2818,12 @@ static int kvm_put_msrs(X86CPU *cpu, int level) +> >> > kvm_msr_entry_add(cpu, MSR_IA32_TSC, env->tsc); +> >> > kvm_msr_entry_add(cpu, MSR_KVM_SYSTEM_TIME, env->system_time_msr); +> >> > kvm_msr_entry_add(cpu, MSR_KVM_WALL_CLOCK, env->wall_clock_msr); +> >> > - if (env->features[FEAT_KVM] & (1 << KVM_FEATURE_ASYNC_PF)) { +> >> > + /* +> >> > + * Some kernel versions (v5.8) won't let MSR_KVM_ASYNC_PF_EN to be set +> >> > + * at all if kernel-irqchip=off, so don't try to set it in that case. +> >> > + */ +> >> > + if (env->features[FEAT_KVM] & (1 << KVM_FEATURE_ASYNC_PF) && +> >> > + kvm_irqchip_in_kernel()) { +> >> > kvm_msr_entry_add(cpu, MSR_KVM_ASYNC_PF_EN, env->async_pf_en_msr); +> >> > } +> >> > if (env->features[FEAT_KVM] & (1 << KVM_FEATURE_PV_EOI)) { +> >> +> >> I'm not sure kvm_irqchip_in_kernel() was required before we switched to +> >> interrupt-based APF (as we were always injecting #PF) but with +> >> kernel-5.8+ this should work. [...] +> > +> > Were guests able to set MSR_KVM_ASYNC_PF_EN to non-zero with +> > kernel-irqchip=off on hosts running Linux <= 5.7? +> +> lapic_in_kernel() check appeared in kernel with the following commit: +> +> commit 9d3c447c72fb2337ca39f245c6ae89f2369de216 +> Author: Wanpeng Li <email address hidden> +> Date: Mon Jun 29 18:26:31 2020 +0800 +> +> KVM: X86: Fix async pf caused null-ptr-deref +> +> which was post-interrupt-based-APF. I *think* it was OK to enable APF +> with !lapic_in_kernel() before (at least I don't see what would not +> allow that). + +If it was possible, did KVM break live migration of +kernel-irqchip=off guests that enabled APF? This would mean my +patch is replacing a crash with a silent migration bug. Not nice +either way. + +> +> > I am assuming +> > kvm-asyncpf never worked with kernel-irqchip=off (and enabling it +> > by default with kernel-irqchip=off was a mistake). +> > +> > +> >> [...] We'll need to merge this with +> >> +> >> https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg02963.html +> >> (queued by Paolo) and +> >> https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg06196.html +> >> which fixes a bug in it. +> >> +> >> as kvm_irqchip_in_kernel() should go around both KVM_FEATURE_ASYNC_PF +> >> and KVM_FEATURE_ASYNC_PF_INT I believe. +> > +> > Shouldn't we just disallow kvm-asyncpf-int=on if kernel-irqchip=off? +> +> (Sarcasm: if disallowing 'kernel-irqchip=off' is not an option, then) + +I'm working on it. :-) + +> yes, we probably can, but kvm-asyncpf-int=on is the default we have so +> we can't just implicitly change it underneath or migration will break... + +kvm-asyncpf-int wasn't merged yet, was it? This means we don't +have compatibility issues to care about. + +-- +Eduardo + + + +On Tue, Sep 22, 2020 at 07:26:42PM +0200, Paolo Bonzini wrote: +> On 22/09/20 19:22, Eduardo Habkost wrote: +> > If it was possible, did KVM break live migration of +> > kernel-irqchip=off guests that enabled APF? This would mean my +> > patch is replacing a crash with a silent migration bug. Not nice +> > either way. +> +> Let's drop kernel-irqchip=off completely so migration is not broken. :) +> +> I'm actually serious, I don't think we need a deprecation period even. + +I wasn't sure about this, but then I've noticed the man page says +"disabling the in-kernel irqchip completely is not recommended +except for debugging purposes." + +Does this note apply to all architectures? + +-- +Eduardo + + + +We don't need to use kernel-irqchip=off for irq0 override if IRQ +routing is supported by the host, which is the case since 2009 +(IRQ routing was added to KVM in Linux v2.6.30). + +This is a more straightforward fix for Launchpad bug #1896263, as +it doesn't require increasing the complexity of the MSR code. +kernel-irqchip=off is for debugging only and there's no need to +increase the complexity of the code just to work around an issue +that was already fixed in the kernel. + +Fixes: https://bugs.launchpad.net/bugs/1896263 +Signed-off-by: Eduardo Habkost <email address hidden> +--- + tests/qtest/bios-tables-test.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +diff --git a/tests/qtest/bios-tables-test.c b/tests/qtest/bios-tables-test.c +index a9c8d478aee..27e8f0a1cb7 100644 +--- a/tests/qtest/bios-tables-test.c ++++ b/tests/qtest/bios-tables-test.c +@@ -663,8 +663,7 @@ static void test_acpi_one(const char *params, test_data *data) + data->uefi_fl1, data->uefi_fl2, data->cd, params ? params : ""); + + } else { +- /* Disable kernel irqchip to be able to override apic irq0. */ +- args = g_strdup_printf("-machine %s,kernel-irqchip=off %s -accel tcg " ++ args = g_strdup_printf("-machine %s %s -accel tcg " + "-net none -display none %s " + "-drive id=hd0,if=none,file=%s,format=raw " + "-device %s,drive=hd0 ", +-- +2.26.2 + + + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=d1e2d46467b95b03279 + +Released with QEMU v5.2.0. + diff --git a/results/classifier/105/mistranslation/1898883 b/results/classifier/105/mistranslation/1898883 new file mode 100644 index 000000000..c985e9ac9 --- /dev/null +++ b/results/classifier/105/mistranslation/1898883 @@ -0,0 +1,61 @@ +mistranslation: 0.535 +device: 0.512 +other: 0.501 +semantic: 0.441 +vnc: 0.407 +network: 0.379 +instruction: 0.360 +graphic: 0.335 +socket: 0.315 +assembly: 0.289 +KVM: 0.276 +boot: 0.248 + +qemu-system-riscv64 failed to load binary kernel into memory + +QEMU Version: 5.1.0 +Compiled in Ubuntu 20.04 for riscv64, following the guide https://risc-v-getting-started-guide.readthedocs.io/en/latest/linux-qemu.html. + +In qemu-system-riscv64, code at 0x80000000 will be executed by virtual CPU. +For example, using `qemu-system-riscv64 -nographic -machine virt -bios none -kernel vmlinux -S -s`, my homebrew kernel(ELF file) will load at 0x80000000. If I strip the kernel using `riscv64-linux-gnu-objcopy -O binary vmlinux Image`, qemu-system-riscv64 will not load the binary machine code into the riscv64 load address, but `-bios Image` will. + +In `qemu-system-aarch64` compiled by Ubuntu team, I can use `qemu-system-aarch64 -M raspi3 -kernel Image_aarch64 -S -s` to load a specific machine code binary into 0x80000. And the elf kernel can be loaded to that address, too. + +On Wed, Oct 7, 2020 at 10:37 PM Azuk 443 <email address hidden> wrote: +> +> Public bug reported: +> +> QEMU Version: 5.1.0 +> Compiled in Ubuntu 20.04 for riscv64, following the guide https://risc-v-getting-started-guide.readthedocs.io/en/latest/linux-qemu.html. +> +> In qemu-system-riscv64, code at 0x80000000 will be executed by virtual CPU. +> For example, using `qemu-system-riscv64 -nographic -machine virt -bios none -kernel vmlinux -S -s`, my homebrew kernel(ELF file) will load at 0x80000000. If I strip the kernel using `riscv64-linux-gnu-objcopy -O binary vmlinux Image`, qemu-system-riscv64 will not load the binary machine code into the riscv64 load address, but `-bios Image` will. + +This is not a bug. As you said, please use `-bios Image` for your +special purpose. + +> +> In `qemu-system-aarch64` compiled by Ubuntu team, I can use `qemu- +> system-aarch64 -M raspi3 -kernel Image_aarch64 -S -s` to load a specific +> machine code binary into 0x80000. And the elf kernel can be loaded to +> that address, too. +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> + +Regards, +Bin + + +As per Bin Meng, closing as not-a-bug. + +Just an update on this. + +You can use -bios to load your image, which will load it to address 0x80000000. + +In QEMU 5.1 `-bios none -kernel Image` will load the Image to 0x80020000/0x80040000 depending on XLEN. + +QEMU 5.2 will now correctly load the above mentioned Image to address 0x80000000 if you don't load a firmware (`-bios none`). + diff --git a/results/classifier/105/mistranslation/1900918 b/results/classifier/105/mistranslation/1900918 new file mode 100644 index 000000000..977a3091f --- /dev/null +++ b/results/classifier/105/mistranslation/1900918 @@ -0,0 +1,31 @@ +mistranslation: 0.991 +instruction: 0.835 +device: 0.834 +semantic: 0.820 +other: 0.737 +graphic: 0.642 +assembly: 0.569 +network: 0.458 +socket: 0.416 +KVM: 0.281 +boot: 0.278 +vnc: 0.277 + +PXB devices + +release: 4c41341af76cfc85b5a6c0f87de4838672ab9f89 + +qdev_device_add() will search for the "closest" bus possible, and bail out early if that bus is a root bus. pxb devices are considered root buses and so if you either +1. Add a PCI device on the QEMU command line *after* a pxb device, or +2. Add an integrated PCI device (like a watchdog) + +#1: -device pxb-pcie,id=cxl.0,bus=pcie.0,bus_nr=52 -device ahci,id=sata0,addr=0x8 +#2: -watchdog i6300esb -device pxb-pcie,id=cxl.0,bus=pcie.0,bus_nr=52 + +The PXB will get selected as the bus (instead of the real root bus) and this will cause an assertion failure with the message like "qemu-system-x86_64: -device ahci,id=sata0,addr=0x8: PCI: Only PCI/PCIe bridges can be plugged into pxb-pcie" + +I think this is relatively solvable in the code base by determining if a bus is an expander, and skipping it if so. However, I wonder if it makes more sense to just allow expanders to have endpoint devices. + +I accidentally double submitted this, and this one has the wrong description. Please close and use +#1900919 instead. + diff --git a/results/classifier/105/mistranslation/1900919 b/results/classifier/105/mistranslation/1900919 new file mode 100644 index 000000000..01ab86dd6 --- /dev/null +++ b/results/classifier/105/mistranslation/1900919 @@ -0,0 +1,60 @@ +mistranslation: 0.906 +other: 0.884 +graphic: 0.874 +device: 0.853 +semantic: 0.843 +instruction: 0.837 +network: 0.729 +assembly: 0.674 +socket: 0.541 +vnc: 0.536 +boot: 0.447 +KVM: 0.408 + +PXB selected as root bus incorrectly + +release: 4c41341af76cfc85b5a6c0f87de4838672ab9f89 + +qdev_device_add() will search for the "closest" bus possible, and bail out early if that bus is a root bus. pxb devices are considered root buses and so if you either +1. Add a PCI device on the QEMU command line *after* a pxb device, or +2. Add an integrated PCI device (like a watchdog) + +#1: -device pxb-pcie,id=cxl.0,bus=pcie.0,bus_nr=52 -device ahci,id=sata0,addr=0x8 +#2: -watchdog i6300esb -device pxb-pcie,id=cxl.0,bus=pcie.0,bus_nr=52 + +The PXB will get selected as the bus (instead of the real root bus) and this will cause an assertion failure with the message like "qemu-system-x86_64: -device ahci,id=sata0,addr=0x8: PCI: Only PCI/PCIe bridges can be plugged into pxb-pcie" + +I think this is relatively solvable in the code base by determining if a bus is an expander, and skipping it if so. However, I wonder if it makes more sense to just allow expanders to have endpoint devices. + +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. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1901359 b/results/classifier/105/mistranslation/1901359 new file mode 100644 index 000000000..b5690e5fb --- /dev/null +++ b/results/classifier/105/mistranslation/1901359 @@ -0,0 +1,71 @@ +mistranslation: 0.969 +other: 0.810 +device: 0.790 +instruction: 0.763 +graphic: 0.762 +semantic: 0.752 +network: 0.658 +vnc: 0.633 +socket: 0.564 +assembly: 0.441 +KVM: 0.412 +boot: 0.412 + +ignore bit 0 in pci CONFIG_ADDRESS register write for Type 1 access + +I'v recently stumbled upon a bug in the Plan9 PCI config space access routines for config mode #1. + +The code used to set bit 0 in the CONFIG_ADDRESS register for a Type 1 access. + +This was most likely a misreading of the PCI local bus specification on our side. + +However, in the PCI local bus specification 3.0, it states the following: + +> 3.2.2.3.2 Software Generation of Configuration Transactions +> ... +> For Type 1 translations, the host bridge directly copies the contents of the +> CONFIG_ADDRESS register (excluding bits 31 and 0) onto the PCI AD lines during the +> address phase of a configuration transaction making sure that AD[1::0] is "01". + +note the: "excluding bits 31 and 0" + +What happens in qemu instead is that it uses bit 0 of the CONFIG_ADDRESS +register as part of the register offset (when it probably should ignore it) +when translating from Type 1 to Type 0 address. So once it reaches the device +behind the bridge the register address is off by one. + +is anybody home? + +Yeah, the bug tracker here on Launchpad is somewhat neglected ... Therefore: +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. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1902394 b/results/classifier/105/mistranslation/1902394 new file mode 100644 index 000000000..1a56b6336 --- /dev/null +++ b/results/classifier/105/mistranslation/1902394 @@ -0,0 +1,121 @@ +mistranslation: 0.918 +KVM: 0.799 +other: 0.777 +network: 0.776 +socket: 0.762 +instruction: 0.756 +graphic: 0.747 +device: 0.743 +assembly: 0.738 +semantic: 0.730 +boot: 0.702 +vnc: 0.686 + +Guest stuck in Paused state right after created It + +Im using Centos 8 . I have try to use many Distribution such as : Centos, Ubuntum, Debian,.. on the guest but still all the the VM get into paused state immidiately after using virt-install ( I have tried using virt-manager too ) + +CPU INFO : +Architecture: x86_64 +CPU op-mode(s): 32-bit, 64-bit +Byte Order: Little Endian +CPU(s): 8 +On-line CPU(s) list: 0-7 +Thread(s) per core: 1 +Core(s) per socket: 1 +Socket(s): 8 +NUMA node(s): 1 +Vendor ID: GenuineIntel +CPU family: 6 +Model: 85 +Model name: Intel(R) Xeon(R) Silver 4214 CPU @ 2.20GHz +Stepping: 7 +CPU MHz: 2199.998 +BogoMIPS: 4399.99 +Virtualization: VT-x +Hypervisor vendor: KVM +Virtualization type: full +L1d cache: 32K +L1i cache: 32K +L2 cache: 4096K +L3 cache: 16384K +NUMA node0 CPU(s): 0-7 +Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single pti ssbd ibrs ibpb tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx avx512f rdseed adx smap clflushopt clwb avx512cd xsaveopt xsavec xgetbv1 arat + +VM Log : + +2020-10-31 08:29:51.737+0000: starting up libvirt version: 4.5.0, package: 42.module_el8.2.0+320+13f867d7 (CentOS Buildsys <email address hidden>, 2020-05-28-17:13:31, ), qemu version: 2.12.0qemu-kvm-2.12.0-99.module_el8.2.0+524+f765f7e0.4, kernel: 4.18.0-193.28.1.el8_2.x86_64, hostname: interns.novalocal +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=spice /usr/libexec/qemu-kvm -name guest=cirros,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-18-cirros/master-key.aes -machine pc-i440fx-rhel7.6.0,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu Cascadelake-Server,ss=on,hypervisor=on,tsc-adjust=on,arch-capabilities=on,ibpb=on,skip-l1dfl-vmentry=on,invpcid=off,avx512dq=off,avx512bw=off,avx512vl=off,pku=off,avx512vnni=off,pdpe1gb=off -m 1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid ef9573a3-a02d-4ef0-86cb-e38da7b7b20d -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=29,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/home/kvm/cirros-0.3.0-x86_64-disk.img,format=qcow2,if=none,id=drive-ide0-0-0 -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -netdev tap,fd=31,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=52:54:00:c3:32:b0,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0,bus=usb.0,port=1 -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on +2020-10-31T08:29:51.815604Z qemu-kvm: -chardev pty,id=charserial0: char device redirected to /dev/pts/1 (label charserial0) +KVM: exception 0 exit (error code 0x0) +EAX=00000000 EBX=00000000 ECX=00000000 EDX=00050656 +ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 +EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0000 00000000 0000ffff 00009300 +CS =f000 ffff0000 0000ffff 00009b00 +SS =0000 00000000 0000ffff 00009300 +DS =0000 00000000 0000ffff 00009300 +FS =0000 00000000 0000ffff 00009300 +GS =0000 00000000 0000ffff 00009300 +LDT=0000 00000000 0000ffff 00008200 +TR =0000 00000000 0000ffff 00008b00 +GDT= 00000000 0000ffff +IDT= 00000000 0000ffff +CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000000 +Code=06 66 05 00 00 01 00 8e c1 26 66 a3 74 f0 66 5b 66 5e 66 c3 <ea> 5b e0 00 f0 30 36 2f 32 33 2f 39 39 00 fc 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + +The Error I have when try to resume the Guest with Virt Manager : + +Error unpausing domain: internal error: unable to execute QEMU command 'cont': Resetting the Virtual Machine is required + +Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 75, in cb_wrapper + callback(asyncjob, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 111, in tmpcb + callback(*args, **kwargs) + File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 66, in newfn + ret = fn(self, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/object/domain.py", line 1311, in resume + self._backend.resume() + File "/usr/lib64/python3.6/site-packages/libvirt.py", line 2012, in resume + if ret == -1: raise libvirtError ('virDomainResume() failed', dom=self) +libvirt.libvirtError: internal error: unable to execute QEMU command 'cont': Resetting the Virtual Machine is required + + +Any help would be so helpful cause I stuck in this case for like 4 days already. + +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. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1902975 b/results/classifier/105/mistranslation/1902975 new file mode 100644 index 000000000..154fed4ec --- /dev/null +++ b/results/classifier/105/mistranslation/1902975 @@ -0,0 +1,25 @@ +mistranslation: 0.690 +graphic: 0.605 +semantic: 0.582 +device: 0.503 +network: 0.332 +other: 0.272 +vnc: 0.218 +socket: 0.209 +instruction: 0.200 +boot: 0.156 +assembly: 0.112 +KVM: 0.101 + +qemu.org/docs/ contains some old docs + +When I searched for QEMU docs in a search engine I ended up on this page: + +https://www.qemu.org/docs/master/qemu-doc.html + +That is 4.2.50 documentation. It took me some time to realize that there is actually 5.1.50 documentation under https://www.qemu.org/docs/master/ and that the 4.2 documentation is out of date. + +Presumably this file is cruft that was left over from a previous build of the website and something like a `make clean` is required? + +Thanks the stale files have been removed. + diff --git a/results/classifier/105/mistranslation/1903493 b/results/classifier/105/mistranslation/1903493 new file mode 100644 index 000000000..412590a85 --- /dev/null +++ b/results/classifier/105/mistranslation/1903493 @@ -0,0 +1,21 @@ +mistranslation: 0.964 +semantic: 0.867 +KVM: 0.756 +network: 0.749 +device: 0.719 +graphic: 0.693 +other: 0.594 +vnc: 0.360 +socket: 0.359 +instruction: 0.313 +boot: 0.286 +assembly: 0.261 + +About wireless network card bridging + +As a rookie, I don’t know if I should ask this question here. If it’s not right, I hope people who see it can help submit it to the right place. Qemu-kvm can add wireless network card bridging, after all, now you see that vbox and vmware can directly choose wireless network card bridging, and even hyper-v can be easily set up, arp proxy is too difficult for us rookies . I hope that qemu or other links can add a function to bridge the wireless network card, which can be directly set in virt-manager (for so many years, it seems that I can only use bridge-utils to bridge the Ethernet) + +Sorry, but at least I have a hard time to understand what you exactly are requesting here? Why should bridging via a wireless card on the host be much different to bridging via an ethernet interface on the host? Or do you expect to see a wireless network card in the guest? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1905521 b/results/classifier/105/mistranslation/1905521 new file mode 100644 index 000000000..0e72b0d1c --- /dev/null +++ b/results/classifier/105/mistranslation/1905521 @@ -0,0 +1,158 @@ +mistranslation: 0.809 +vnc: 0.808 +device: 0.789 +KVM: 0.773 +other: 0.764 +graphic: 0.744 +instruction: 0.713 +boot: 0.696 +semantic: 0.683 +assembly: 0.666 +network: 0.632 +socket: 0.623 + +assert issue locates in hw/scsi/lsi53c895a.c:624: lsi_do_dma: Assertion `s->current' failed + +Hello, + +I found an assertion failure in hw/scsi/lsi53c895a.c:624 + +This was found in latest version 5.2.0. + + +my reproduced environment is as follows: + Host: ubuntu 18.04 + Guest: ubuntu 18.04 + + + +QEMU boot command line: +qemu-system-x86_64 -enable-kvm -boot c -m 4G -drive format=qcow2,file=./ubuntu.img -nic user,hostfwd=tcp:0.0.0.0:5555-:22 -display none -device lsi53c895a -trace lsi\* + +Backtrace is as follows: +#0 0x00007f845c6eff47 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 +#1 0x00007f845c6f18b1 in __GI_abort () at abort.c:79 +#2 0x00007f845c6e142a in __assert_fail_base (fmt=0x7f845c868a38 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x55a1034486a0 "s->current", file=file@entry=0x55a103448360 "../hw/scsi/lsi53c895a.c", line=line@entry=624, function=function@entry=0x55a10344ae60 <__PRETTY_FUNCTION__.31674> "lsi_do_dma") at assert.c:92 +#3 0x00007f845c6e14a2 in __GI___assert_fail (assertion=0x55a1034486a0 "s->current", file=0x55a103448360 "../hw/scsi/lsi53c895a.c", line=624, function=0x55a10344ae60 <__PRETTY_FUNCTION__.31674> "lsi_do_dma") at assert.c:101 +#4 0x000055a102049c65 in lsi_do_dma (s=0x62600000c100, out=1) at ../hw/scsi/lsi53c895a.c:624 +#5 0x000055a102051573 in lsi_execute_script (s=0x62600000c100) at ../hw/scsi/lsi53c895a.c:1250 +#6 0x000055a10205b05d in lsi_reg_writeb (s=0x62600000c100, offset=47, val=178 '\262') at ../hw/scsi/lsi53c895a.c:1984 +#7 0x000055a10205fef8 in lsi_io_write (opaque=0x62600000c100, addr=47, val=178, size=1) at ../hw/scsi/lsi53c895a.c:2146 +#8 0x000055a102d1b791 in memory_region_write_accessor (mr=0x62600000cbe0, addr=47, value=0x7f8349dfe2f8, size=1, shift=0, mask=255, attrs=...) at ../softmmu/memory.c:484 +#9 0x000055a102d1bba8 in access_with_adjusted_size (addr=47, value=0x7f8349dfe2f8, size=1, access_size_min=1, access_size_max=1, access_fn=0x55a102d1b4de <memory_region_write_accessor>, mr=0x62600000cbe0, attrs=...) at ../softmmu/memory.c:545 +#10 0x000055a102d261ef in memory_region_dispatch_write (mr=0x62600000cbe0, addr=47, data=178, op=MO_8, attrs=...) at ../softmmu/memory.c:1494 +#11 0x000055a102b57c3c in flatview_write_continue (fv=0x6060000ea920, addr=49199, attrs=..., ptr=0x7f8449efb000, len=1, addr1=47, l=1, mr=0x62600000cbe0) at ../softmmu/physmem.c:2767 +#12 0x000055a102b57f07 in flatview_write (fv=0x6060000ea920, addr=49199, attrs=..., buf=0x7f8449efb000, len=1) at ../softmmu/physmem.c:2807 +#13 0x000055a102b587cb in address_space_write (as=0x55a105ebca80 <address_space_io>, addr=49199, attrs=..., buf=0x7f8449efb000, len=1) at ../softmmu/physmem.c:2899 +#14 0x000055a102b58878 in address_space_rw (as=0x55a105ebca80 <address_space_io>, addr=49199, attrs=..., buf=0x7f8449efb000, len=1, is_write=true) at ../softmmu/physmem.c:2909 +#15 0x000055a102ad4d50 in kvm_handle_io (port=49199, attrs=..., data=0x7f8449efb000, direction=1, size=1, count=1) at ../accel/kvm/kvm-all.c:2283 +#16 0x000055a102ad6a0f in kvm_cpu_exec (cpu=0x62e000000400) at ../accel/kvm/kvm-all.c:2529 +#17 0x000055a102c26fbb in kvm_vcpu_thread_fn (arg=0x62e000000400) at ../accel/kvm/kvm-cpus.c:49 +#18 0x000055a1032c08f8 in qemu_thread_start (args=0x603000082780) at ../util/qemu-thread-posix.c:521 +#19 0x00007f845caa96db in start_thread (arg=0x7f8349dff700) at pthread_create.c:463 +#20 0x00007f845c7d2a3f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + + +The poc is attached. + + + +Cc'ing Fam directly because his launchpad account +contact points to invalid email address. + +On 11/25/20 8:22 AM, Gaoning Pan wrote: +> Public bug reported: +> +> Hello, +> +> I found an assertion failure in hw/scsi/lsi53c895a.c:624 +> +> This was found in latest version 5.2.0. +> +> +> my reproduced environment is as follows: +> Host: ubuntu 18.04 +> Guest: ubuntu 18.04 +> +> +> QEMU boot command line: +> qemu-system-x86_64 -enable-kvm -boot c -m 4G -drive format=qcow2,file=./ubuntu.img -nic user,hostfwd=tcp:0.0.0.0:5555-:22 -display none -device lsi53c895a -trace lsi\* +> +> Backtrace is as follows: +> #0 0x00007f845c6eff47 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 +> #1 0x00007f845c6f18b1 in __GI_abort () at abort.c:79 +> #2 0x00007f845c6e142a in __assert_fail_base (fmt=0x7f845c868a38 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x55a1034486a0 "s->current", file=file@entry=0x55a103448360 "../hw/scsi/lsi53c895a.c", line=line@entry=624, function=function@entry=0x55a10344ae60 <__PRETTY_FUNCTION__.31674> "lsi_do_dma") at assert.c:92 +> #3 0x00007f845c6e14a2 in __GI___assert_fail (assertion=0x55a1034486a0 "s->current", file=0x55a103448360 "../hw/scsi/lsi53c895a.c", line=624, function=0x55a10344ae60 <__PRETTY_FUNCTION__.31674> "lsi_do_dma") at assert.c:101 +> #4 0x000055a102049c65 in lsi_do_dma (s=0x62600000c100, out=1) at ../hw/scsi/lsi53c895a.c:624 +> #5 0x000055a102051573 in lsi_execute_script (s=0x62600000c100) at ../hw/scsi/lsi53c895a.c:1250 +> #6 0x000055a10205b05d in lsi_reg_writeb (s=0x62600000c100, offset=47, val=178 '\262') at ../hw/scsi/lsi53c895a.c:1984 +> #7 0x000055a10205fef8 in lsi_io_write (opaque=0x62600000c100, addr=47, val=178, size=1) at ../hw/scsi/lsi53c895a.c:2146 +> #8 0x000055a102d1b791 in memory_region_write_accessor (mr=0x62600000cbe0, addr=47, value=0x7f8349dfe2f8, size=1, shift=0, mask=255, attrs=...) at ../softmmu/memory.c:484 +> #9 0x000055a102d1bba8 in access_with_adjusted_size (addr=47, value=0x7f8349dfe2f8, size=1, access_size_min=1, access_size_max=1, access_fn=0x55a102d1b4de <memory_region_write_accessor>, mr=0x62600000cbe0, attrs=...) at ../softmmu/memory.c:545 +> #10 0x000055a102d261ef in memory_region_dispatch_write (mr=0x62600000cbe0, addr=47, data=178, op=MO_8, attrs=...) at ../softmmu/memory.c:1494 +> #11 0x000055a102b57c3c in flatview_write_continue (fv=0x6060000ea920, addr=49199, attrs=..., ptr=0x7f8449efb000, len=1, addr1=47, l=1, mr=0x62600000cbe0) at ../softmmu/physmem.c:2767 +> #12 0x000055a102b57f07 in flatview_write (fv=0x6060000ea920, addr=49199, attrs=..., buf=0x7f8449efb000, len=1) at ../softmmu/physmem.c:2807 +> #13 0x000055a102b587cb in address_space_write (as=0x55a105ebca80 <address_space_io>, addr=49199, attrs=..., buf=0x7f8449efb000, len=1) at ../softmmu/physmem.c:2899 +> #14 0x000055a102b58878 in address_space_rw (as=0x55a105ebca80 <address_space_io>, addr=49199, attrs=..., buf=0x7f8449efb000, len=1, is_write=true) at ../softmmu/physmem.c:2909 +> #15 0x000055a102ad4d50 in kvm_handle_io (port=49199, attrs=..., data=0x7f8449efb000, direction=1, size=1, count=1) at ../accel/kvm/kvm-all.c:2283 +> #16 0x000055a102ad6a0f in kvm_cpu_exec (cpu=0x62e000000400) at ../accel/kvm/kvm-all.c:2529 +> #17 0x000055a102c26fbb in kvm_vcpu_thread_fn (arg=0x62e000000400) at ../accel/kvm/kvm-cpus.c:49 +> #18 0x000055a1032c08f8 in qemu_thread_start (args=0x603000082780) at ../util/qemu-thread-posix.c:521 +> #19 0x00007f845caa96db in start_thread (arg=0x7f8349dff700) at pthread_create.c:463 +> #20 0x00007f845c7d2a3f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 +> +> +> The poc is attached. +> +> ** Affects: qemu +> Importance: Undecided +> Assignee: Gaoning Pan (hades0506) +> Status: New +> +> ** Attachment added: "lsi-assert.c" +> https://bugs.launchpad.net/bugs/1905521/+attachment/5437756/+files/lsi-assert.c +> +> ** Changed in: qemu +> Assignee: (unassigned) => Gaoning Pan (hades0506) +> + + + +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. + + + +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/552 + + diff --git a/results/classifier/105/mistranslation/1907 b/results/classifier/105/mistranslation/1907 new file mode 100644 index 000000000..39adebda7 --- /dev/null +++ b/results/classifier/105/mistranslation/1907 @@ -0,0 +1,70 @@ +mistranslation: 0.823 +other: 0.808 +KVM: 0.770 +semantic: 0.747 +graphic: 0.730 +vnc: 0.724 +instruction: 0.690 +assembly: 0.665 +boot: 0.657 +device: 0.651 +network: 0.638 +socket: 0.622 + +QEMU LoongArch regression after merging LASX changes +Description of problem: +After enabling LASX in qemu (@gaosong), booting Gentoo Linux with latest glibc master (w/ LSX & LASX optimized libc routines) will fail in systemd: + +``` +[ 10.350207] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000085 +[ 10.350557] CPU: 5 PID: 1 Comm: systemd Not tainted 6.5.2-gentoo #2 +[ 10.350655] Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 +[ 10.350961] Stack : 0072617764726148 0000000000000000 9000000000223440 90000001000e4000 +[ 10.351181] 90000001000e7990 90000001000e7998 0000000000000000 90000001000e7ad8 +[ 10.351294] 90000001000e7ad0 90000001000e7ad0 90000001000e7900 0000000000000001 +[ 10.351406] 0000000000000001 90000001000e7998 ec94a2e1446052e6 9000000100438140 +[ 10.351519] 0000000000000001 0000000000000003 0000000000000000 0000000000000030 +[ 10.351630] 0000000000000000 00000000000559bf 00000000056e0000 0000000000000004 +[ 10.351745] 0000000000000000 0000000000000000 900000000162b438 900000000177e000 +[ 10.351856] 00000000400004d8 0000000000000001 0000000000000018 90000001000e7c84 +[ 10.351968] 0000000000020000 0000000000000000 9000000000223458 00007ffff0341af0 +[ 10.352081] 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c +[ 10.352196] ... +[ 10.352277] Call Trace: +[ 10.352482] [<9000000000223458>] show_stack+0x5c/0x180 +[ 10.353518] [<9000000001178d4c>] dump_stack_lvl+0x60/0x88 +[ 10.353592] [<900000000115cd7c>] panic+0x13c/0x308 +[ 10.353670] [<900000000024244c>] do_exit+0x860/0x868 +[ 10.353735] [<900000000024261c>] do_group_exit+0x34/0x94 +[ 10.353803] [<9000000000250514>] get_signal+0x75c/0x804 +[ 10.353869] [<90000000002254c4>] arch_do_signal_or_restart+0x74/0xae0 +[ 10.353944] [<90000000002c738c>] exit_to_user_mode_loop.isra.0+0x90/0x10c +[ 10.354041] [<9000000001179ff0>] irqentry_exit_to_user_mode+0x1c/0x28 +[ 10.354119] [<90000000011792f8>] do_bp+0xcc/0x2ac +[ 10.354222] [<90000001005a1924>] 0x90000001005a1924 +[ 10.354522] [<00007ffff0341af0>] 0x7ffff0341af0 +``` + +Full log: + +[stderr](/uploads/61b9870ae2441c9a25f44791c67889b8/stderr) + +Instruction trace `-d in_asm,out_asm,op` (very large): + +[log.tar.zstd](https://cloud.tsinghua.edu.cn/f/a83eac6d44694ede8cb1/?dl=1) + +I also tried to boot LoongArchLinux whose glibc does not have LSX/LASX optimized C routines, and it can boot without problems. If I chroot from LoongArchLinux into Gentoo Linux, running `emerge` command will SIGSEGV. + +If I disable LASX in CPUCFG2, the problem is gone: + +```cpp +// data = FIELD_DP32(data, CPUCFG2, LASX, 1), +``` + +I guess the bug is related to LASX assemblies in [glibc](https://github.com/bminor/glibc/tree/master/sysdeps/loongarch/lp64/multiarch). +Steps to reproduce: +1. Launch qemu +2. Wait for systemd to be killed +3. Collect logs +Additional information: + diff --git a/results/classifier/105/mistranslation/1907953 b/results/classifier/105/mistranslation/1907953 new file mode 100644 index 000000000..a86b38fc3 --- /dev/null +++ b/results/classifier/105/mistranslation/1907953 @@ -0,0 +1,19 @@ +mistranslation: 0.999 +vnc: 0.737 +device: 0.724 +semantic: 0.713 +other: 0.695 +instruction: 0.550 +graphic: 0.439 +network: 0.315 +assembly: 0.277 +boot: 0.263 +socket: 0.139 +KVM: 0.029 + +pkg install qemu-system-x86_64 não funciona qemu 5.2.0 + +A qemu funcionava mais quando atualizei para 5.2.0 não iniciar o Windows só fica tela preta quero voltar para anterior mais não consigo + +Sorry, please write bug reports in proper English. + diff --git a/results/classifier/105/mistranslation/1908450 b/results/classifier/105/mistranslation/1908450 new file mode 100644 index 000000000..9be6728bd --- /dev/null +++ b/results/classifier/105/mistranslation/1908450 @@ -0,0 +1,102 @@ +mistranslation: 0.909 +instruction: 0.819 +semantic: 0.810 +other: 0.808 +graphic: 0.802 +device: 0.770 +socket: 0.769 +assembly: 0.745 +vnc: 0.701 +KVM: 0.570 +boot: 0.559 +network: 0.523 + +ide/core.c ATA Major Version reporting incorrect + +@@ -165,7 +165,7 @@ static void ide_identify(IDEState *s) + put_le16(p + 76, (1 << 8)); + } + + put_le16(p + 80, 0xf0); /* ata3 -> ata6 supported */ +- put_le16(p + 80, 0xf0); /* ata3 -> ata6 supported */ ++ put_le16(p + 80, ((1 << 6) | (1 << 5) (1 << 4) (1 << 3)); /* ata3 -> ata6 supported */ + put_le16(p + 81, 0x16); /* conforms to ata5 */ + /* 14=NOP supported, 5=WCACHE supported, 0=SMART supported */ + put_le16(p + 82, (1 << 14) | (1 << 5) | 1); + + +This field Major Version Number field is presently reporting support for ATA-4 through ATA-7. +Bitfield[80] is defined in the ATA-6 specification below. + +0xF0 = (1<<7) | (1<<6) | (1 << 5) | (1 << 4) // 4-7 - current settings +0x78 = (1<<6) | (1<<5) | (1 << 4) | (1 << 3) // 3-6 - new settings + +Either the comment is wrong, or the field is wrong. If the field is wrong it can cause errors in drivers that check support vs conformity. This will not break most guests, since the conformity field is set to ATA-5. + +I'm not sure whether this component supports ATA-7, but since it's commented as if it supports up through 6, correcting the field assignment seems more correct. + +ATA/ATAPI-6 Specification +https://web.archive.org/web/20200124094822/https://www.t13.org/Documents/UploadedDocuments/project/d1410r3b-ATA-ATAPI-6.pdf + +Page 116 +80 - M Major version number +0000h or FFFFh = device does not report version +F 15 Reserved +F 14 Reserved for ATA/ATAPI-14 +F 13 Reserved for ATA/ATAPI-13 +F 12 Reserved for ATA/ATAPI-12 +F 11 Reserved for ATA/ATAPI-11 +F 10 Reserved for ATA/ATAPI-10 +F 9 Reserved for ATA/ATAPI-9 +F 8 Reserved for ATA/ATAPI-8 +F 7 Reserved for ATA/ATAPI-7 +F 6 1 = supports ATA/ATAPI-6 +F 5 1 = supports ATA/ATAPI-5 +F 4 1 = supports ATA/ATAPI-4 +F 3 1 = supports ATA-3 +X 2 Obsolete +X 1 Obsolete +F 0 Reserved + +John, could you please have a look? + +I doubt we truly implement *any* standard precisely correctly, but if we are advertising support for ATA7 and it works, I'd rather just fix the comment to keep behavior the same. + +It probably was a mistake in the original commit from ... sometime before 2006, but if nothing is observably broken, maybe it shouldn't be changed. + +for what it's worth, i have yet to see a driver actually check this field. + +I have seen a ton of code (OVMF and others) detect other information and just straight up say "I'm in QEMU" and YOLO a bunch of things like assuming DMA is available and such, so I somewhat doubt anyone *actually* checks these fields. + +That's probably the single most reasonable thing to do, truth be told! + +I don't have the time to audit these fields properly; I don't know which versions we truly ought to advertise support for. I know I looked at ATA8-AC3 at some point fairly recently and concluded that we don't support all of the "must-support" features of that spec, because we don't implement any of the logging features whatsoever. + +I often consult ATA8-ACS3 to take advantage of clarifications made in later revisions and cross-correlate with ATA7; but I don't know what the most modern specification we can be said to support the minimum feature set from truly is. + +Patches (and reviewers) always welcome; but generally I am afraid of touching too many things because I don't want to break legacy operating systems that might not have an awareness of QEMU. Our testing for older operating systems is not particularly robust, here. + +I think I am still leaning towards just fixing the comment, but if you are aware of some ATA7 thing we are required to support but don't, I'll remove the bit. + +I would just fix the comment for now, likewise I don't have the time to audit +whether the emulation provides full coverage of the standard. + +Really there's two cases here +1) We report ATA4-7 (current status), someone discovers missing bits feature +Response: They file a ticket on the missing feature. + +2) We report ATA3-6 (changed status), legacy stuff checking this bit suddenly break +Response: Rabid screeching somewhere in the depths of the internets. + +Fixing the comment is more risk averse and more likely to produce the desirable +outcome (some reads the comment, and discovers a missing ATA feature for the +reported standard). + + +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/59 + + diff --git a/results/classifier/105/mistranslation/1908626 b/results/classifier/105/mistranslation/1908626 new file mode 100644 index 000000000..7a4a807ad --- /dev/null +++ b/results/classifier/105/mistranslation/1908626 @@ -0,0 +1,175 @@ +mistranslation: 0.800 +graphic: 0.786 +other: 0.756 +vnc: 0.747 +assembly: 0.716 +device: 0.714 +KVM: 0.707 +semantic: 0.675 +network: 0.649 +instruction: 0.635 +socket: 0.570 +boot: 0.545 + +Atomic test-and-set instruction does not work on qemu-user + +I try to compile and run PostgreSQL/Greenplum database inside docker container/qemu-aarch64-static: +``` + host: CentOS7 x86_64 + container: centos:centos7.9.2009 --platform linux/arm64/v8 + qemu-user-static: https://github.com/multiarch/qemu-user-static/releases/ +``` + +However, GP/PG's spinlock always gets stuck and reports PANIC errors. It seems its spinlock +has something wrong. +``` +https://github.com/greenplum-db/gpdb/blob/master/src/include/storage/s_lock.h +https://github.com/greenplum-db/gpdb/blob/master/src/backend/storage/lmgr/s_lock.c +``` + +So I extract its spinlock implementation into one test C source file (see attachment file), +and get reprodcued: + +``` +$ gcc spinlock_qemu.c +$ ./a.out +C -- slock inited, lock value is: 0 +parent 139642, child 139645 +P -- slock lock before, lock value is: 0 +P -- slock locked, lock value is: 1 +P -- slock unlock after, lock value is: 0 +C -- slock lock before, lock value is: 1 +P -- slock lock before, lock value is: 1 +C -- slock locked, lock value is: 1 +C -- slock unlock after, lock value is: 0 +C -- slock lock before, lock value is: 1 +P -- slock locked, lock value is: 1 +P -- slock unlock after, lock value is: 0 +P -- slock lock before, lock value is: 1 +C -- slock locked, lock value is: 1 +C -- slock unlock after, lock value is: 0 +P -- slock locked, lock value is: 1 +C -- slock lock before, lock value is: 1 +P -- slock unlock after, lock value is: 0 +C -- slock locked, lock value is: 1 +P -- slock lock before, lock value is: 1 +C -- slock unlock after, lock value is: 0 +P -- slock locked, lock value is: 1 +C -- slock lock before, lock value is: 1 +P -- slock unlock after, lock value is: 0 +C -- slock locked, lock value is: 1 +P -- slock lock before, lock value is: 1 +C -- slock unlock after, lock value is: 0 +P -- slock locked, lock value is: 1 +C -- slock lock before, lock value is: 1 +P -- slock unlock after, lock value is: 0 +P -- slock lock before, lock value is: 1 +spin timeout, lock value is 1 (pid 139642) +spin timeout, lock value is 1 (pid 139645) +spin timeout, lock value is 1 (pid 139645) +spin timeout, lock value is 1 (pid 139642) +spin timeout, lock value is 1 (pid 139645) +spin timeout, lock value is 1 (pid 139642) +... +... +... +``` + +NOTE: this code always works on PHYSICAL ARM64 server. + + + +Interestingly, the spinlock test works after I change tas() implementation +FROM + __sync_lock_test_and_set(lock, 1); +TO + __sync_val_compare_and_swap(lock, 0, 1); + +## gcc (GCC) 8.3.1 20190311 (Red Hat 8.3.1-3) + +==== +__sync_lock_test_and_set(lock, 1) disassembly: + +``` +objdump -S a.out + +000000000040073c <tas>: + 40073c: d10043ff sub sp, sp, #0x10 + 400740: f90007e0 str x0, [sp, #8] + 400744: f94007e0 ldr x0, [sp, #8] + 400748: 52800021 mov w1, #0x1 // #1 + 40074c: 885f7c02 ldxr w2, [x0] + 400750: 88037c01 stxr w3, w1, [x0] + 400754: 35ffffc3 cbnz w3, 40074c <tas+0x10> + 400758: d5033bbf dmb ish + 40075c: 2a0203e0 mov w0, w2 + 400760: 910043ff add sp, sp, #0x10 + 400764: d65f03c0 ret +``` + +==== +__sync_val_compare_and_swap(lock, 0, 1); disassembly: + +``` +objdump -S a.out + +000000000040073c <tas>: + 40073c: d10043ff sub sp, sp, #0x10 + 400740: f90007e0 str x0, [sp, #8] + 400744: f94007e0 ldr x0, [sp, #8] + 400748: 52800021 mov w1, #0x1 // #1 + 40074c: 885f7c02 ldxr w2, [x0] + 400750: 35000062 cbnz w2, 40075c <tas+0x20> + 400754: 8803fc01 stlxr w3, w1, [x0] + 400758: 35ffffa3 cbnz w3, 40074c <tas+0x10> + 40075c: 7100005f cmp w2, #0x0 + 400760: d5033bbf dmb ish + 400764: 2a0203e0 mov w0, w2 + 400768: 910043ff add sp, sp, #0x10 + 40076c: d65f03c0 ret +``` + +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. + + +[Expired for QEMU because there has been no activity for 60 days.] + + +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/509 + + +Hi taos! Could you please check whether this has been fixed already in QEMU v6.1.0-rc1 ? + +Thanks. Tested, the problem is gone. + diff --git a/results/classifier/105/mistranslation/191 b/results/classifier/105/mistranslation/191 new file mode 100644 index 000000000..120018762 --- /dev/null +++ b/results/classifier/105/mistranslation/191 @@ -0,0 +1,14 @@ +mistranslation: 0.948 +other: 0.492 +graphic: 0.454 +device: 0.383 +semantic: 0.275 +instruction: 0.210 +network: 0.077 +boot: 0.061 +vnc: 0.030 +assembly: 0.029 +socket: 0.016 +KVM: 0.007 + +qemu64 CPU model is incorrect diff --git a/results/classifier/105/mistranslation/1910540 b/results/classifier/105/mistranslation/1910540 new file mode 100644 index 000000000..d4ea3f0d6 --- /dev/null +++ b/results/classifier/105/mistranslation/1910540 @@ -0,0 +1,23 @@ +mistranslation: 0.832 +graphic: 0.808 +device: 0.784 +network: 0.782 +instruction: 0.700 +semantic: 0.697 +socket: 0.544 +vnc: 0.532 +other: 0.376 +boot: 0.308 +KVM: 0.189 +assembly: 0.120 + +where the trace file "trace-*" + +I compile qemu-system-aarch64 with --enable-trace-backends=simple option, then start qemu with -trace nvme* , qemu start successful but I cann't find the trace file "trace-*" at qemu started directory. + +I tested qemu.git/master on Linux x86_64 to confirm that the simple trace backend works. trace-$pid files are written to the current working directory. + +If QEMU prints a warning that the trace event name does not exist, try escaping the asterisk on your command-line: -trace nvme\* + +You can find the trace-event files in the source tree, if you were talking about those. Anyway, this does not really sound like a bug, so I'm closing this ticket now. If you need general help, please use the qemu-discuss mailing list or the #qemu channel on OFTC IRC instead. + diff --git a/results/classifier/105/mistranslation/1911 b/results/classifier/105/mistranslation/1911 new file mode 100644 index 000000000..836ae1b0c --- /dev/null +++ b/results/classifier/105/mistranslation/1911 @@ -0,0 +1,53 @@ +mistranslation: 0.901 +other: 0.861 +graphic: 0.848 +KVM: 0.836 +semantic: 0.791 +vnc: 0.787 +assembly: 0.743 +device: 0.723 +instruction: 0.682 +boot: 0.629 +socket: 0.523 +network: 0.512 + +abnormal segfaults inside qemu-system-riscv64 +Description of problem: +3 tests of Cockatrice segfaults in qemu-system-riscv64 emulator. This is similar to a regression of qemu-riscv64-static I reported: #1908. +But for qemu-system-riscv64, it doesn't looks like a recent regression because qemu 7.2.1 also fails. +Steps to reproduce: +To save the time on reproducing this bug, [I uploaded the zstd compressed qcow2 image to google drive](https://drive.google.com/file/d/1-2Wtmq4MlGvTLjmQ7P5vAvNlWg8--jjT/view?usp=sharing). It contains the whole environment, cockatrice source code and built tests. + +The password of the root user is `archriscv`. + +1. Setup Arch Linux riscv environment: https://github.com/CoelacanthusHex/archriscv-scriptlet https://github.com/felixonmars/archriscv-packages/wiki/Setup-Arch-Linux-RISC-V-using-qemu-system +2. Start it(with the commandline above, in the boot menu, choose `2: Linux linux (fallback initramfs)`) and building cockatrice with tests in it. +3. Run tests (/root/Cockatrice/build/tests/loading_from_clipboard/loading_from_clipboard_test, /root/Cockatrice/build/tests/carddatabase/filter_string_test, /root/Cockatrice/build/tests/carddatabase/carddatabase_test) +4. The tests segfault, which is unexpected. +Additional information: +The tests segfault at exactly the same instruction as in #1908: + +``` +┌──────────────────────────────────────────────────────────────────────────────┐ +│ > 0x7ffff2cba928 lhu a2,1248(a2) │ +│ 0x7ffff2cba92c and a0,a0,127 │ +│ 0x7ffff2cba930 sll a2,a2,0x7 │ +│ 0x7ffff2cba934 add a0,a0,a2 │ +│ 0x7ffff2cba938 lui t2,0xf8000 │ +│ 0x7ffff2cba93c lui a2,0xf5de2 │ +│ 0x7ffff2cba940 add a2,a2,-1824 │ +│ 0x7ffff2cba944 sll t2,t2,0x14 │ +│ 0x7ffff2cba948 xor a2,a2,t2 │ +│ 0x7ffff2cba94c sll t2,a0,0x1 │ +│ 0x7ffff2cba950 add a2,a2,t2 │ +│ 0x7ffff2cba954 lhu a2,0(a2) │ +│ 0x7ffff2cba958 sll a0,a2,0x3 │ +└──────────────────────────────────────────────────────────────────────────────┘ +multi-thre Thread 0x7ffff2cbe0 In: L?? PC: 0x7ffff2cba928 +(gdb) bt +#0 0x00007ffff2cba928 in () +``` + +It might suggest that 2d708164e0475064e0e2167bd73e8570e22df1e0 is not the true cause of #1908 and this bug shares the same underlying cause with #1908. + +Commit 2d708164e0475064e0e2167bd73e8570e22df1e0 LGTM, although it seems that it is copied from the loongarch one and the author forgot to update [the file header](https://gitlab.com/qemu-project/qemu/-/blob/2d708164e0475064e0e2167bd73e8570e22df1e0/linux-user/riscv/target_mman.h#L1-6). diff --git a/results/classifier/105/mistranslation/1911666 b/results/classifier/105/mistranslation/1911666 new file mode 100644 index 000000000..22a196fbb --- /dev/null +++ b/results/classifier/105/mistranslation/1911666 @@ -0,0 +1,91 @@ +mistranslation: 0.842 +device: 0.838 +vnc: 0.829 +other: 0.825 +KVM: 0.821 +instruction: 0.816 +assembly: 0.806 +graphic: 0.790 +semantic: 0.787 +network: 0.760 +boot: 0.727 +socket: 0.726 + +ZDI-CAN-10904: QEMU Plan 9 File System TOCTOU Privilege Escalation Vulnerability + +-- CVSS ----------------------------------------- + +7.5: AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H + +-- ABSTRACT ------------------------------------- + +Trend Micro's Zero Day Initiative has identified a vulnerability affecting the following products: +QEMU - QEMU + +-- VULNERABILITY DETAILS ------------------------ + +Version tested:5.0.0-rc3 +Installer file:qemu-5.0.0-rc3.tar.xz +Platform tested:ubuntu 18.04 x64 desktop +Analysis Basically v9fs* functions called from guest kernel are executed under specific thread(I call it main thread later). But when it calls some file related system calls, qemu uses its own coroutine thread(worker thread). Then it returns(yield return) without waiting result of system call and start to execute next v9fs* function. + +In v9fsmarkfidsunreclaim() function, it stores fidlist member (head of singly linked list) to its stack. + + -> https://github.com/qemu/qemu/blob/f3bac27cc1e303e1860cc55b9b6889ba39dee587/hw/9pfs/9p.c#L506 + +And if it uses coroutine, it restore fid_list from stack and restart whole loop. + + -> https://github.com/qemu/qemu/blob/f3bac27cc1e303e1860cc55b9b6889ba39dee587/hw/9pfs/9p.c#L526 + +v9fsclunk() function calls clunkfid() which unlink fid from list, and free it. + + -> https://github.com/qemu/qemu/blob/f3bac27cc1e303e1860cc55b9b6889ba39dee587/hw/9pfs/9p.c#L2060-L2091 + +So if v9fsclunk() is called while v9fsmarkfidsunreclaim()'s coroutine is being executed, it restores "FREED" fidp from stack and use it. + +it can be reproduced with the qemu binary, which is given +it can also be reproduced with own ASAN build (5.0.0-rc3 and 4.2.0 are tested) + +../qemu-5.0.0-rc3/x86_64-softmmu/qemu-system-x86_64 -M pc -kernel ./bzImage -initrd ./rootfs.cpio -append "root=/dev/ram console=tty1 console=ttyS0 rdinit=/bin/sh" -nographic -enable-kvm -fsdev local,id=test_dev,path=/home/xxx/sandbox,security_model=none -device virtio-9p-pci,fsdev=test_dev,mount_tag=victim_tag + +$ ./do.sh +expected ASAN report is printed +the race is in coroutine, so the threads are the same one + +================================================================= + ==46645==ERROR: AddressSanitizer: heap-use-after-free on address 0x610000047948 at pc 0x5563d8c28f0f bp0 +READ of size 2 at 0x610000047948 thread T0 + + #0 0x5563d8c28f0e in v9fs_mark_fids_unreclaim hw/9pfs/9p.c:508 + #1 0x5563d8c3e9e3 in v9fs_remove hw/9pfs/9p.c:2988 + #2 0x5563d98d310d in coroutine_trampoline util/coroutine-ucontext.c:115 + #3 0x7fadac6396af (/lib/x86_64-linux-gnu/libc.so.6+0x586af) + + 0x610000047948 is located 8 bytes inside of 192-byte region [0x610000047940,0x610000047a00) freed by thread T0 here: + + #0 0x7fadafa5f7a8 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xde7a8) + #1 0x5563d8c27a60 in free_fid hw/9pfs/9p.c:371 + #2 0x5563d8c27fcc in put_fid hw/9pfs/9p.c:396 + #3 0x5563d8c37267 in v9fs_clunk hw/9pfs/9p.c:2085 + #4 0x5563d98d310d in coroutine_trampoline util/coroutine-ucontext.c:115 + #5 0x7fadac6396af (/lib/x86_64-linux-gnu/libc.so.6+0x586af) + +previously allocated by thread T0 here: + #0 0x7fadafa5fd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) + #1 0x7fadaf0c8b10 in g_malloc0 (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51b10) + #2 0x5563d8c30ecc in v9fs_attach hw/9pfs/9p.c:1412 + #3 0x5563d98d310d in coroutine_trampoline util/coroutine-ucontext.c:115 + #4 0x7fadac6396af (/lib/x86_64-linux-gnu/libc.so.6+0x586af) + + +This vulnerability was discovered by: + +Ryota Shiga(@Garyo) of Flatt Security working with Trend Micro Zero Day Initiative + +Requesting a CVE... + +'CVE-2021-20181' is assigned to this issue by Red Hat Inc. + +Fixed by commit 89fbea8737e ("9pfs: Fully restart unreclaim loop (CVE-2021-20181)"). + + diff --git a/results/classifier/105/mistranslation/1913315 b/results/classifier/105/mistranslation/1913315 new file mode 100644 index 000000000..fa33fc602 --- /dev/null +++ b/results/classifier/105/mistranslation/1913315 @@ -0,0 +1,94 @@ +mistranslation: 0.891 +semantic: 0.873 +graphic: 0.841 +device: 0.762 +other: 0.753 +assembly: 0.749 +instruction: 0.674 +socket: 0.670 +KVM: 0.660 +vnc: 0.640 +network: 0.609 +boot: 0.600 + +qemu-system-x86_64 crash: in memory_region_access_valid+0x13 + +Recently we started to get intermittent qemu crashes. There is catchsegv report: + +``` ++ qemu-system-x86_64 -m 77766M -smp 8 -nodefaults -nographic -no-reboot -fsdev local,id=root,path=/,security_model=none,multidevs=remap -device virtio-9p-pci,fsdev=root,mount_tag=/dev/root -device virtio-rng-pci -serial mon:stdio -kernel /usr/src/tmp/kernel-image-rt-buildroot/boot/vmlinuz-4.19.165-rt-alt1.rt70 -initrd /usr/src/tmp/initramfs-4.19.165-rt-alt1.rt70.img -bios bios.bin -append 'console=ttyS0 mitigations=off nokaslr quiet panic=-1 no_timer_check' +*** signal 11 +Register dump: + + RAX: 0000000000000000 RBX: 0000034000000340 RCX: 0000000000000001 + RDX: 0000000000000004 RSI: 0000000000000300 RDI: 0000034000000340 + RBP: 0000000000000300 R8 : 0000000000000000 R9 : 0000034000000340 + R10: 0000000000000370 R11: 0000000000000002 R12: 0000000000000004 + R13: 0000000000000004 R14: 000055b473fef5e0 R15: 0000000000000002 + RSP: 00007fd7edffae90 + + RIP: 000055b4717ef653 EFLAGS: 00010206 + + CS: 0033 FS: 0000 GS: 0000 + + Trap: 0000000e Error: 00000004 OldMask: 7ffbfa77 CR2: 00000388 + + FPUCW: 0000037f FPUSW: 00000000 TAG: 00000000 + RIP: 00000000 RDP: 00000000 + + ST(0) 0000 0000000000000000 ST(1) 0000 0000000000000000 + ST(2) 0000 0000000000000000 ST(3) 0000 0000000000000000 + ST(4) 0000 0000000000000000 ST(5) 0000 0000000000000000 + ST(6) 0000 0000000000000000 ST(7) 0000 0000000000000000 + mxcsr: 1fa0 + XMM0: 00000000000000000000000000000000 XMM1: 00000000000000000000000000000000 + XMM2: 00000000000000000000000000000000 XMM3: 00000000000000000000000000000000 + XMM4: 00000000000000000000000000000000 XMM5: 00000000000000000000000000000000 + XMM6: 00000000000000000000000000000000 XMM7: 00000000000000000000000000000000 + XMM8: 00000000000000000000000000000000 XMM9: 00000000000000000000000000000000 + XMM10: 00000000000000000000000000000000 XMM11: 00000000000000000000000000000000 + XMM12: 00000000000000000000000000000000 XMM13: 00000000000000000000000000000000 + XMM14: 00000000000000000000000000000000 XMM15: 00000000000000000000000000000000 + +Backtrace: +qemu-system-x86_64(memory_region_access_valid+0x13)[0x55b4717ef653] +qemu-system-x86_64(memory_region_dispatch_write+0x48)[0x55b4717ef8c8] +qemu-system-x86_64(+0x69fdfc)[0x55b471851dfc] +qemu-system-x86_64(helper_le_stl_mmu+0x2c5)[0x55b471858995] +[0x7feaed070925] + +``` +QEMU release 5.2.0. + +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. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1913619 b/results/classifier/105/mistranslation/1913619 new file mode 100644 index 000000000..fe70ae7c9 --- /dev/null +++ b/results/classifier/105/mistranslation/1913619 @@ -0,0 +1,27 @@ +mistranslation: 0.784 +other: 0.751 +instruction: 0.735 +device: 0.719 +graphic: 0.698 +semantic: 0.673 +boot: 0.637 +KVM: 0.592 +network: 0.513 +vnc: 0.419 +socket: 0.398 +assembly: 0.175 + +qemu-system-x86_64 -cdrom -nographic gives no output + +Running 'sudo qemu-system-x86_64 -m 2048M -cpu host -cdrom github/xvisor-bootable.iso -boot d -enable-kvm' will create a qemu window, boot to a grub prompt and then boot the xvisor binary correctly. + +Once I append -nographic to the command - after the user has selected the grub boot binary, there is no further output. + +I've tried various permutations with qemu options, but to no avail. It would be great to have this working as it will permit scrolling back up into the command history for reference and large data output. + +QEMU emulator version 5.2.50 (v5.2.0-925-g7b09f12773) + +The vga-to-serial redirection activated by -nographics works only for vgabios calls, +not for direct vga hardware access. grub2 uses the vgabios, the linux kernel doesn't. +You can edit the menu entry in grub and add "console=ttyS0" to the linux command line. + diff --git a/results/classifier/105/mistranslation/1915063 b/results/classifier/105/mistranslation/1915063 new file mode 100644 index 000000000..a7d41cd2c --- /dev/null +++ b/results/classifier/105/mistranslation/1915063 @@ -0,0 +1,718 @@ +mistranslation: 0.924 +other: 0.880 +semantic: 0.833 +instruction: 0.828 +vnc: 0.819 +device: 0.766 +graphic: 0.763 +boot: 0.757 +network: 0.755 +socket: 0.741 +assembly: 0.734 +KVM: 0.680 + +Windows 10 wil not install using qemu-system-x86_64 + +Steps to reproduce +install virt-manager and ovmf if nopt already there +copy windows and virtio iso files to /var/lib/libvirt/images + +Use virt-manager from local machine to create your VMs with the disk, CPUs and memory required + Select customize configuration then select OVMF(UEFI) instead of seabios + set first CDROM to the windows installation iso (enable in boot options) + add a second CDROM and load with the virtio iso + change spice display to VNC + + Always get a security error from windows and it fails to launch the installer (works on RHEL and Fedora) +I tried updating the qemu version from Focals 4.2 to Groovy 5.0 which was of no help + +This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window: + +apport-collect 1915063 + +and then change the status of the bug to 'Confirmed'. + +If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'. + +This change has been made by an automated script, maintained by the Ubuntu Kernel Team. + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +We believe that the latest version of Windows doesn't play nice with the older version of QEMU - it seems Windows is broken somewhere between 4.2.0-2 and 5.0.0-6 on AMD Ryzen based processors (which is what we have on the P620). + +What are the recommendations for the best way for a Ubuntu customer to get going again, with an updated version of QEMU? + + +I'm subscribing Christian to this bug, who is our QEMU expert. + +Hi, +I was just recently for a different case installing a Win10 guest and had the ISOs available. +So I was trying to install an OVMF based one through virt-manager as you asked. + +ISOs +- win10 20H2_v2 +- virtio iso 0.1.190 + +I used the default "new guest" of virt-manager and then went into "customize before install" to also add the virtio drivers and select the OVMF mode. + +BTW I'd not expect that providing the virtio ISO is related to triggering (or not triggering the bug). If you could confirm that it happens without that as well it would make reproducing this a little bit easier. The default config uses SATA. + +Info: +If the ISO is not auto-boointg (depends on some setup detail e.g. how you add your extra CD images) you can still manually load the Windows EFI loader like: +FS0: +cd EFI +cd BOOT +BOOTX64.EFI + +I started my tests on 21.04 Hirsute as that is what I had around. +qemu 1:5.2+dfsg-6ubuntu2 virt-manager 1:3.2.0-3 ovmf 2020.11-2 +That started up the installer just fine no matter if I used SATA or virtio for the root disk. + +Next I tried Focal (as reported) +qemu 1:4.2-3ubuntu6.14 virt-manager 1:2.2.1-3ubuntu2.1 ovmf 0~20191122.bd85bf54-2ubuntu3.1 +That also started the windows installer without an error. + + +Therefore I can't confirm your issue (yet) and will set this to incomplete. +Have you in the meantime found more details about what exactly makes the issue trigger/pass for you? + +In regard your further comments and for clarification: +- @Mark: I don't have a Ryzen based processor thou, so your case could still be absolutely + valid, yet I can't confirm/deny at the time. Do you have any more data showing that it is + processor dependent? +- David said 5.0 didn't help while Mark said between .2.0-2 and 5.0.0-6 it is fixed. Are + we sure you all talk about the same bug? + For those that want/can try a new version give the virt-stack from [1] a try, if that + resolves it for you we can look fox fixes in between those versions. +- David you said "get a security error from windows" can you be more specific about the error + that you get? That will also help to check if you two are facing the same issue. + +[1]: https://launchpad.net/~canonical-server/+archive/ubuntu/server-backports + +I am not using a virtio based drive so that should not be par of the issue, I normally do not use the virtio iso until windows is installed to clear errors in the device manager +I tried using even the version 5.2 from the hirsute release and that also is not working +As a test I tried doing this from an Intel based machine and it does install correctly using even the default version of qemu-system_x64 from focal +Attaching a screen show of the error I get when installing on an AMD Ryzen Threadripper processor + + + +Thanks David, +I have no threadripper around atm, I think I can next week get hands on an EPYC Rome, but that isn't 100% the same. + +But gladly you tried this on the latest qemu 5.2 and since it is failing there as well it might be worth to also report it upstream. That is a great community which might have ran things on a threadripper already and be able to point us to a qemu/kernel fix - or at least an existing discussions abut it. +For now I'm adding a qemu task here which will mirror this case to the mailing list. + +I was playing around with this and find that if I change the Configuration under CPUs from the default (uncheck "Copy host CPU configuration") and select qemu64 in the Model drop down box I can get it to work + +That is awesome David, +qemu64 is like a very low common denominator with only very basic CPU features. +While "copy host" means "enable all you can". + +We can surely work with that a bit, but until I get access to the same HW I need you to do it. + + +If you run in a console `$virsh domcapabilities` it will spew some XML at you. One of the sections will be for "host-model". In my case that looks like + + <mode name='host-model' supported='yes'> + <model fallback='forbid'>Skylake-Client-IBRS</model> + <vendor>Intel</vendor> + <feature policy='require' name='ss'/> + <feature policy='require' name='vmx'/> + <feature policy='require' name='hypervisor'/> +... + </mode> + + +That means a names CPU type (the one that is closest to what you have) and some feature additionally enabled/disabled. + +If you could please post the full output you have, that can be useful. +From there you could go two steps. +1. as you see in my example it will list some cpu features on top of the named type. + If you remove them one by one you might be able to identify the single-cpu featute + that breaks in your case. +2. The named CPU that you have also has a representation, it can be found in + /usr/share/libvirt/cpu_map... + That ill list all the CPU features that make up the named type. + If #1 wasn't sufficient, you can now add those to your guest definition one by one in disabled + state, example + <feature policy='disable' name='ss'/> + +A description of the underlying mechanism is here https://libvirt.org/formatdomain.html#cpu-model-and-topology + +<domainCapabilities> + <path>/usr/bin/qemu-system-x86_64</path> + <domain>kvm</domain> + <machine>pc-i440fx-hirsute</machine> + <arch>x86_64</arch> + <vcpu max='255'/> + <iothreads supported='yes'/> + <os supported='yes'> + <enum name='firmware'> + <value>efi</value> + </enum> + <loader supported='yes'> + <value>/usr/share/OVMF/OVMF_CODE_4M.fd</value> + <enum name='type'> + <value>rom</value> + <value>pflash</value> + </enum> + <enum name='readonly'> + <value>yes</value> + <value>no</value> + </enum> + <enum name='secure'> + <value>no</value> + </enum> + </loader> + </os> + <cpu> + <mode name='host-passthrough' supported='yes'/> + <mode name='host-model' supported='yes'> + <model fallback='forbid'>EPYC-Rome</model> + <vendor>AMD</vendor> + <feature policy='require' name='x2apic'/> + <feature policy='require' name='tsc-deadline'/> + <feature policy='require' name='hypervisor'/> + <feature policy='require' name='tsc_adjust'/> + <feature policy='require' name='stibp'/> + <feature policy='require' name='arch-capabilities'/> + <feature policy='require' name='ssbd'/> + <feature policy='require' name='xsaves'/> + <feature policy='require' name='cmp_legacy'/> + <feature policy='require' name='invtsc'/> + <feature policy='require' name='amd-ssbd'/> + <feature policy='require' name='virt-ssbd'/> + <feature policy='require' name='rdctl-no'/> + <feature policy='require' name='skip-l1dfl-vmentry'/> + <feature policy='require' name='mds-no'/> + <feature policy='require' name='pschange-mc-no'/> + </mode> + <mode name='custom' supported='yes'> + <model usable='yes'>qemu64</model> + <model usable='yes'>qemu32</model> + <model usable='no'>phenom</model> + <model usable='yes'>pentium3</model> + <model usable='yes'>pentium2</model> + <model usable='yes'>pentium</model> + <model usable='no'>n270</model> + <model usable='yes'>kvm64</model> + <model usable='yes'>kvm32</model> + <model usable='no'>coreduo</model> + <model usable='no'>core2duo</model> + <model usable='no'>athlon</model> + <model usable='no'>Westmere-IBRS</model> + <model usable='yes'>Westmere</model> + <model usable='no'>Skylake-Server-noTSX-IBRS</model> + <model usable='no'>Skylake-Server-IBRS</model> + <model usable='no'>Skylake-Server</model> + <model usable='no'>Skylake-Client-noTSX-IBRS</model> + <model usable='no'>Skylake-Client-IBRS</model> + <model usable='no'>Skylake-Client</model> + <model usable='no'>SandyBridge-IBRS</model> + <model usable='yes'>SandyBridge</model> + <model usable='yes'>Penryn</model> + <model usable='no'>Opteron_G5</model> + <model usable='no'>Opteron_G4</model> + <model usable='yes'>Opteron_G3</model> + <model usable='yes'>Opteron_G2</model> + <model usable='yes'>Opteron_G1</model> + <model usable='no'>Nehalem-IBRS</model> + <model usable='yes'>Nehalem</model> + <model usable='no'>IvyBridge-IBRS</model> + <model usable='no'>IvyBridge</model> + <model usable='no'>Icelake-Server-noTSX</model> + <model usable='no'>Icelake-Server</model> + <model usable='no'>Icelake-Client-noTSX</model> + <model usable='no'>Icelake-Client</model> + <model usable='no'>Haswell-noTSX-IBRS</model> + <model usable='no'>Haswell-noTSX</model> + <model usable='no'>Haswell-IBRS</model> + <model usable='no'>Haswell</model> + <model usable='yes'>EPYC-Rome</model> + <model usable='yes'>EPYC-IBPB</model> + <model usable='yes'>EPYC</model> + <model usable='yes'>Dhyana</model> + <model usable='yes'>Conroe</model> + <model usable='no'>Cascadelake-Server-noTSX</model> + <model usable='no'>Cascadelake-Server</model> + <model usable='no'>Broadwell-noTSX-IBRS</model> + <model usable='no'>Broadwell-noTSX</model> + <model usable='no'>Broadwell-IBRS</model> + <model usable='no'>Broadwell</model> + <model usable='yes'>486</model> + </mode> + </cpu> + <devices> + <disk supported='yes'> + <enum name='diskDevice'> + <value>disk</value> + <value>cdrom</value> + <value>floppy</value> + <value>lun</value> + </enum> + <enum name='bus'> + <value>ide</value> + <value>fdc</value> + <value>scsi</value> + <value>virtio</value> + <value>usb</value> + <value>sata</value> + </enum> + <enum name='model'> + <value>virtio</value> + <value>virtio-transitional</value> + <value>virtio-non-transitional</value> + </enum> + </disk> + <graphics supported='yes'> + <enum name='type'> + <value>sdl</value> + <value>vnc</value> + <value>spice</value> + </enum> + </graphics> + <video supported='yes'> + <enum name='modelType'> + <value>vga</value> + <value>cirrus</value> + <value>vmvga</value> + <value>qxl</value> + <value>virtio</value> + <value>none</value> + <value>bochs</value> + <value>ramfb</value> + </enum> + </video> + <hostdev supported='yes'> + <enum name='mode'> + <value>subsystem</value> + </enum> + <enum name='startupPolicy'> + <value>default</value> + <value>mandatory</value> + <value>requisite</value> + <value>optional</value> + </enum> + <enum name='subsysType'> + <value>usb</value> + <value>pci</value> + <value>scsi</value> + </enum> + <enum name='capsType'/> + <enum name='pciBackend'> + <value>default</value> + <value>vfio</value> + </enum> + </hostdev> + <rng supported='yes'> + <enum name='model'> + <value>virtio</value> + <value>virtio-transitional</value> + <value>virtio-non-transitional</value> + </enum> + <enum name='backendModel'> + <value>random</value> + <value>egd</value> + </enum> + </rng> + </devices> + <features> + <gic supported='no'/> + <vmcoreinfo supported='yes'/> + <genid supported='yes'/> + <backingStoreInput supported='yes'/> + <backup supported='no'/> + <sev supported='no'/> + </features> +</domainCapabilities> + +Ok, so you should be able to drop these lines one by one: + + <feature policy='require' name='x2apic'/> + <feature policy='require' name='tsc-deadline'/> + <feature policy='require' name='hypervisor'/> + <feature policy='require' name='tsc_adjust'/> + <feature policy='require' name='stibp'/> + <feature policy='require' name='arch-capabilities'/> + <feature policy='require' name='ssbd'/> + <feature policy='require' name='xsaves'/> + <feature policy='require' name='cmp_legacy'/> + <feature policy='require' name='invtsc'/> + <feature policy='require' name='amd-ssbd'/> + <feature policy='require' name='virt-ssbd'/> + <feature policy='require' name='rdctl-no'/> + <feature policy='require' name='skip-l1dfl-vmentry'/> + <feature policy='require' name='mds-no'/> + <feature policy='require' name='pschange-mc-no'/> + +If that does not yet make it work, add those one by one (removing the features of the named type) + <feature policy='disable' name='3dnowprefetch'/> + <feature policy='disable' name='abm'/> + <feature policy='disable' name='adx'/> + <feature policy='disable' name='aes'/> + <feature policy='disable' name='amd-stibp'/> + <feature policy='disable' name='apic'/> + <feature policy='disable' name='arat'/> + <feature policy='disable' name='avx'/> + <feature policy='disable' name='avx2'/> + <feature policy='disable' name='bmi1'/> + <feature policy='disable' name='bmi2'/> + <feature policy='disable' name='clflush'/> + <feature policy='disable' name='clflushopt'/> + <feature policy='disable' name='clwb'/> + <feature policy='disable' name='clzero'/> + <feature policy='disable' name='cmov'/> + <feature policy='disable' name='cr8legacy'/> + <feature policy='disable' name='cx16'/> + <feature policy='disable' name='cx8'/> + <feature policy='disable' name='de'/> + <feature policy='disable' name='f16c'/> + <feature policy='disable' name='fma'/> + <feature policy='disable' name='fpu'/> + <feature policy='disable' name='fsgsbase'/> + <feature policy='disable' name='fxsr'/> + <feature policy='disable' name='fxsr_opt'/> + <feature policy='disable' name='ibpb'/> + <feature policy='disable' name='lahf_lm'/> + <feature policy='disable' name='lm'/> + <feature policy='disable' name='mca'/> + <feature policy='disable' name='mce'/> + <feature policy='disable' name='misalignsse'/> + <feature policy='disable' name='mmx'/> + <feature policy='disable' name='mmxext'/> + <feature policy='disable' name='movbe'/> + <feature policy='disable' name='msr'/> + <feature policy='disable' name='mtrr'/> + <feature policy='disable' name='npt'/> + <feature policy='disable' name='nrip-save'/> + <feature policy='disable' name='nx'/> + <feature policy='disable' name='osvw'/> + <feature policy='disable' name='pae'/> + <feature policy='disable' name='pat'/> + <feature policy='disable' name='pclmuldq'/> + <feature policy='disable' name='pdpe1gb'/> + <feature policy='disable' name='perfctr_core'/> + <feature policy='disable' name='pge'/> + <feature policy='disable' name='pni'/> + <feature policy='disable' name='popcnt'/> + <feature policy='disable' name='pse'/> + <feature policy='disable' name='pse36'/> + <feature policy='disable' name='rdpid'/> + <feature policy='disable' name='rdrand'/> + <feature policy='disable' name='rdseed'/> + <feature policy='disable' name='rdtscp'/> + <feature policy='disable' name='sep'/> + <feature policy='disable' name='sha-ni'/> + <feature policy='disable' name='smap'/> + <feature policy='disable' name='smep'/> + <feature policy='disable' name='sse'/> + <feature policy='disable' name='sse2'/> + <feature policy='disable' name='sse4.1'/> + <feature policy='disable' name='sse4.2'/> + <feature policy='disable' name='sse4a'/> + <feature policy='disable' name='ssse3'/> + <feature policy='disable' name='svm'/> + <feature policy='disable' name='syscall'/> + <feature policy='disable' name='tsc'/> + <feature policy='disable' name='umip'/> + <feature policy='disable' name='vme'/> + <feature policy='disable' name='wbnoinvd'/> + <feature policy='disable' name='xgetbv1'/> + <feature policy='disable' name='xsave'/> + <feature policy='disable' name='xsavec'/> + <feature policy='disable' name='xsaveerptr'/> + <feature policy='disable' name='xsaveopt'/> + +Eventually I'd hope you identify one feature (re add everything but this to verify) that breaks it. Any chance to do this iterative test? You could also "bisect" this list if you want to save some time. + +On Sat, 03 Apr 2021 16:52:13 -0000 +Christian Ehrhardt <email address hidden> wrote: + +> That is awesome David, +> qemu64 is like a very low common denominator with only very basic CPU features. +> While "copy host" means "enable all you can". + +Also it's worth to try setting real CPU topology for if EPYC cpu model is used. +i.e. use -smp with options that resemble a real EPYC cpu +(for number of core complexes is configured with 'dies' option in QEMU) + + +> We can surely work with that a bit, but until I get access to the same +> HW I need you to do it. +> +> +> If you run in a console `$virsh domcapabilities` it will spew some XML at you. One of the sections will be for "host-model". In my case that looks like +> +> <mode name='host-model' supported='yes'> +> <model fallback='forbid'>Skylake-Client-IBRS</model> +> <vendor>Intel</vendor> +> <feature policy='require' name='ss'/> +> <feature policy='require' name='vmx'/> +> <feature policy='require' name='hypervisor'/> +> ... +> </mode> +> +> +> That means a names CPU type (the one that is closest to what you have) and some feature additionally enabled/disabled. +> +> If you could please post the full output you have, that can be useful. +> >From there you could go two steps. +> 1. as you see in my example it will list some cpu features on top of the named type. +> If you remove them one by one you might be able to identify the single-cpu featute +> that breaks in your case. +> 2. The named CPU that you have also has a representation, it can be found in +> /usr/share/libvirt/cpu_map... +> That ill list all the CPU features that make up the named type. +> If #1 wasn't sufficient, you can now add those to your guest definition one by one in disabled +> state, example +> <feature policy='disable' name='ss'/> +> +> A description of the underlying mechanism is here +> https://libvirt.org/formatdomain.html#cpu-model-and-topology +> + + + +I have not done any of what you are asking so not exactly sure how to change those values, been looking and reading but not finding what I want so thought it might be better to just ask how to do what yo are asking. I did try CPU type EPYC and that did get past the error I am seeing on install + +On Wed, 07 Apr 2021 13:00:23 -0000 +David Ober <email address hidden> wrote: + +> I have not done any of what you are asking so not exactly sure how to +> change those values, been looking and reading but not finding what I +> want so thought it might be better to just ask how to do what yo are +> asking. + +see https://libvirt.org/formatdomain.html#cpu-model-and-topology +for the way to describe topology in domain xml. +Pick a real AMD CPU for cpu model you're are having problem with, +and use its config to define topology. + +> I did try CPU type EPYC and that did get past the error I am +> seeing on install +So it works with EPYC but not with ECPY-Rome, then probably topology +is not issue. + +CCing Babu, +who added EPYC-Rome cpu model, maybe he can help + + + + +I remember seeing something similar before. This was supposed to be fixed by the linux kernel commit. + +commit 841c2be09fe4f495fe5224952a419bd8c7e5b455 +Author: Maxim Levitsky <email address hidden> +Date: Wed Jul 8 14:57:31 2020 +0300 + +kvm: x86: replace kvm_spec_ctrl_test_value with runtime test on the host + +# git describe --contains 841c2be09fe4f495fe5224952a419bd8c7e5b455 +v5.9-rc1~121^2~67 + +Problem seems to happen with EPYC-Rome model which exposes the feature STIBP but not IBRS. + +Did you guys try "-cpu host"? It might work. + + +Thanks Babu/Igor for chiming in! + +@Babu +That exposed STIBP but not IBRS - isn't that what you tried to solve (for userspace) in qemu via a v2 for the Rome chips? +=> https://lists.gnu.org/archive/html/qemu-devel/2021-03/msg01020.html + +I was recently pinging that, as it wasn't merged into the qemu 6.0-rc +Do you have any more insight why this is held back still? + +If I might ask - how does the kernel fix you referenced interact with this proposed qemu change? +Assumptions (please correct me): +1. with the qemu change and using that Rome-v2 it would ask to expose both features and no more crash (even on unfixed kernels) +2. with the kernel fix it will no more crash, even with an unfixed qemu? + +Finally I'm able to test on a Threadripper myself now. + +Note: In regard to the commit that Babu identified - I'm on kernel 5.10.0-1020-oem so that patch would be applied already. I need to find an older kernel to retry with that as well + +(on that new kernel) I did a full Win10 install and it worked fine for me. + +In regard to CPU types (for comparison) I got + +qemu 1:4.2-3ubuntu6.15 / libvirt 6.0.0-0ubuntu8.8: + <mode name='host-model' supported='yes'> + <model fallback='forbid'>EPYC-Rome</model> + <vendor>AMD</vendor> + <feature policy='require' name='x2apic'/> + <feature policy='require' name='tsc-deadline'/> + <feature policy='require' name='hypervisor'/> + <feature policy='require' name='tsc_adjust'/> + <feature policy='require' name='stibp'/> + <feature policy='require' name='arch-capabilities'/> + <feature policy='require' name='ssbd'/> + <feature policy='require' name='xsaves'/> + <feature policy='require' name='cmp_legacy'/> + <feature policy='require' name='invtsc'/> + <feature policy='require' name='amd-ssbd'/> + <feature policy='require' name='virt-ssbd'/> + <feature policy='require' name='rdctl-no'/> + <feature policy='require' name='skip-l1dfl-vmentry'/> + <feature policy='require' name='mds-no'/> + <feature policy='require' name='pschange-mc-no'/> + </mode> + +With a more recent qemu/libvirt it isn't much different for this chip (there recently were some Milan changes, but those seem not to matter for this chip). + +qemu 1:5.2+dfsg-9ubuntu1 / libvirt 7.0.0-2ubuntu1 + + <mode name='host-model' supported='yes'> + <model fallback='forbid'>EPYC-Rome</model> + <vendor>AMD</vendor> + <feature policy='require' name='x2apic'/> + <feature policy='require' name='tsc-deadline'/> + <feature policy='require' name='hypervisor'/> + <feature policy='require' name='tsc_adjust'/> + <feature policy='require' name='stibp'/> + <feature policy='require' name='arch-capabilities'/> + <feature policy='require' name='ssbd'/> + <feature policy='require' name='xsaves'/> + <feature policy='require' name='cmp_legacy'/> + <feature policy='require' name='invtsc'/> + <feature policy='require' name='amd-ssbd'/> + <feature policy='require' name='virt-ssbd'/> + <feature policy='require' name='rdctl-no'/> + <feature policy='require' name='skip-l1dfl-vmentry'/> + <feature policy='require' name='mds-no'/> + <feature policy='require' name='pschange-mc-no'/> + </mode> + + +I wasn't able to crash this setup with an old (18.04) nor a new 21.04) Ubuntu guest. +Installing Win10 worked fine for a while and didn't break as reported. But the setup I have goes through triple ssh-tunnels and around the globe - that slows things down a lot :-/ +This is how far I've got: +1. start up the install +2. select no license key -> custom install -> it started copying files +3. it goes into the first reboot + +After this the latency kills me and virt-manager starts to abort the installation. +So far I did not hit (https://launchpadlibrarian.net/529734412/security.png) as reported by David. +@David - did this already pass the critical step for you, how early or late in the install did you hit the issues. + + +As I said I'll probably need to find an older kernel anyway (to be before the commit that Babu referenced) + +@Christian, +Yes. This following patch fixes the problem + https://lists.gnu.org/archive/html/qemu-devel/2021-03/msg01020.html + +I saw your ping on the patch. I am not sure why it is not picked up. I am going ping them today. + +>If I might ask - how does the kernel fix you referenced interact with this proposed qemu change? +>Assumptions (please correct me): +Problem seem to happen when guest tries to access the SPEC_CTRL register to with the wrong settings. The kernel fix avoids writing those values and avoids #GP fault. + +>1. with the qemu change and using that Rome-v2 it would ask to expose both features and no more crash (even >on unfixed kernels) +Yes. With Qemu patch EPYC-Rome v2 this issue will be fixed. + +>2. with the kernel fix it will no more crash, even with an unfixed qemu? +Yes, That is correct. We need at lease one of these patches to fix this problem. + + + +David used "5.6.0-1042.46-oem", the closest I had was "5.6.0-1052-oem" so I tried that one. + +With that my win10 install immediately crashed into the reported issue. + +So to summarize: +1. I can reproduce it +2. Chances are high that it is fixed by kernel commit 841c2be0 "kvm: x86: replace kvm_spec_ctrl_test_value with runtime test on the host" +3. there are some qemu changes which might be related, but we need Babu to reply about if/how those are related + +I need to get myself updated on Ubuntu oem kernels. +If there is a 5.6 series that is supposed to work on that, then this patch needs to be backported. +But if OTOH it is a valid upgrade path that you'll get the 5.10.0-1020-oem that I had or later as part of your 20.04 OEM then that "is the fix" for you @David. + + + + + +This change was made by a bot. + +Thanks @Babu for the clarifications! +I really hope that the qemu patch makes it in v6.0 - then I can better consider picking it up as backport for qemu (already have a bug about that in bug 1921754 - therefore I'm setting the qemu task here as invalid) + +The last step I can provide for the kernel bug that this one here is (before the rest of the work is with the kernel Team) is to verify/falsify if that also affects the non-oem linux-generic kernel. +There the latest was 5.4.0.71.74 from focal-proposed and the latest already released one is 5.4.0.70.73. + +5.4.0.70.73 - failing +5.4.0.71.74 - failing + +So while the almost-released oem kernel based on 5.10 will cover this - the patch should indeed also be backported to linux-generic and all the other flavours - otherwise Windows (and potentially more) will no more be usable as KVM guest on such Chips (threadrippers, but maybe more AMD chips that are not yet known as well) + +The commit in question is marked for stable: + + commit 841c2be09fe4f495fe5224952a419bd8c7e5b455 + Author: Maxim Levitsky <email address hidden> + Date: Wed Jul 8 14:57:31 2020 +0300 + + kvm: x86: replace kvm_spec_ctrl_test_value with runtime test on the host + + To avoid complex and in some cases incorrect logic in + kvm_spec_ctrl_test_value, just try the guest's given value on the host + processor instead, and if it doesn't #GP, allow the guest to set it. + + One such case is when host CPU supports STIBP mitigation + but doesn't support IBRS (as is the case with some Zen2 AMD cpus), + and in this case we were giving guest #GP when it tried to use STIBP + + The reason why can can do the host test is that IA32_SPEC_CTRL msr is + passed to the guest, after the guest sets it to a non zero value + for the first time (due to performance reasons), + and as as result of this, it is pointless to emulate #GP condition on + this first access, in a different way than what the host CPU does. + + This is based on a patch from Sean Christopherson, who suggested this idea. + + Fixes: 6441fa6178f5 ("KVM: x86: avoid incorrect writes to host MSR_IA32_SPEC_CTRL") + Cc: <email address hidden> + Suggested-by: Sean Christopherson <email address hidden> + Signed-off-by: Maxim Levitsky <email address hidden> + Message-Id: <email address hidden> + Signed-off-by: Paolo Bonzini <email address hidden> + +It appears to be in `v5.4.102` which is currently queued up for the cycle following the one just starting. + +The patch for QEMU that has been mentioned in comment #38 has been merged already, so I'm marking this as Fix-Released there. + diff --git a/results/classifier/105/mistranslation/1915682 b/results/classifier/105/mistranslation/1915682 new file mode 100644 index 000000000..dcdbd9727 --- /dev/null +++ b/results/classifier/105/mistranslation/1915682 @@ -0,0 +1,160 @@ +mistranslation: 0.756 +other: 0.684 +graphic: 0.678 +semantic: 0.675 +instruction: 0.657 +assembly: 0.650 +device: 0.648 +vnc: 0.592 +KVM: 0.563 +boot: 0.536 +socket: 0.520 +network: 0.456 + +i386-linux-user wine exception regression tests fail + +When trying to run wine (latest devel from git) regression tests for ntdll in a statically linked qemu-i386 (commit 392b9a74b9b621c52d05e37bc6f41f1bbab5c6f8) on arm32 (raspberry pi 4) in a debian buster chroot, the exception tests fail at the first test with an infinite exception loop. + +WINEDEBUG=+seh wine wine/dlls/ntdll/tests/ntdll_test.exe exception + + +Working x86_64 system running 32-bit code + +0024:warn:seh:dispatch_exception EXCEPTION_ACCESS_VIOLATION exception (code=c0000005) raised +0024:trace:seh:dispatch_exception eax=00000000 ebx=7ffc2000 ecx=004e0ef4 edx=003c0004 esi=003c0000 edi=00000000 +0024:trace:seh:dispatch_exception ebp=0085fa08 esp=0085f9ac cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010246 +0024:trace:seh:call_vectored_handlers calling handler at 7B00B460 code=c0000005 flags=0 +0024:trace:seh:call_vectored_handlers handler at 7B00B460 returned 0 +0024:trace:seh:call_stack_handlers calling handler at 004178B0 code=c0000005 flags=0 +0024:trace:seh:call_stack_handlers handler at 004178B0 returned 0 +0024:trace:seh:dispatch_exception call_stack_handlers continuing +0024:trace:seh:NtGetContextThread 0xfffffffe: dr0=42424240 dr1=00000000 dr2=126bb070 dr3=0badbad0 dr6=00000000 dr7=ffff0115 + + +Non-working qemu + +0024:warn:seh:dispatch_exception EXCEPTION_ACCESS_VIOLATION exception (code=c0000005) raised +0024:trace:seh:dispatch_exception eax=00000000 ebx=3ffe2000 ecx=004e0ef4 edx=003c0004 esi=003c0000 edi=00000000 +0024:trace:seh:dispatch_exception ebp=0085fa08 esp=0085f9ac cs=0023 ds=002b es=002b fs=003b gs=0033 flags=00000246 +0024:trace:seh:call_vectored_handlers calling handler at 7B00B460 code=c0000005 flags=0 +0024:trace:seh:call_vectored_handlers handler at 7B00B460 returned 0 +0024:trace:seh:call_stack_handlers calling handler at 004178B0 code=c0000005 flags=0 +0024:trace:seh:call_stack_handlers handler at 004178B0 returned 0 +0024:trace:seh:dispatch_exception call_stack_handlers continuing +0024:trace:seh:dispatch_exception call_stack_handlers ret status = 0 +0024:trace:seh:dispatch_exception code=0 flags=1 addr=7BC2389C ip=7bc2389c tid=0024 + +The non-working verion is never managing to set the CPU context using NtContinue/SetContextThread back to the correct running thread stack and IP. It executes as if the context restore just returns to the function that called NtContinue() (dispatch_exception(), not the function that raised the exception or one of its parent exception handlers). + +It looks like NtSetContextThread(), specifically the asm function set_full_cpu_context() is being handled incorrectly. + +wine code below. note interesting use of iret with no previous interrupt call. The exception handler is called with a jmp. + +/*********************************************************************** + * set_full_cpu_context + * + * Set the new CPU context. + */ +extern void set_full_cpu_context( const CONTEXT *context ); +__ASM_GLOBAL_FUNC( set_full_cpu_context, + "movl $0,%fs:0x1f8\n\t" /* x86_thread_data()->syscall_frame = NULL */ + "movl 4(%esp),%ecx\n\t" + "movw 0x8c(%ecx),%gs\n\t" /* SegGs */ + "movw 0x90(%ecx),%fs\n\t" /* SegFs */ + "movw 0x94(%ecx),%es\n\t" /* SegEs */ + "movl 0x9c(%ecx),%edi\n\t" /* Edi */ + "movl 0xa0(%ecx),%esi\n\t" /* Esi */ + "movl 0xa4(%ecx),%ebx\n\t" /* Ebx */ + "movl 0xb4(%ecx),%ebp\n\t" /* Ebp */ + "movw %ss,%ax\n\t" + "cmpw 0xc8(%ecx),%ax\n\t" /* SegSs */ + "jne 1f\n\t" + /* As soon as we have switched stacks the context structure could + * be invalid (when signal handlers are executed for example). Copy + * values on the target stack before changing ESP. */ + "movl 0xc4(%ecx),%eax\n\t" /* Esp */ + "leal -4*4(%eax),%eax\n\t" + "movl 0xc0(%ecx),%edx\n\t" /* EFlags */ + ".byte 0x36\n\t" + "movl %edx,3*4(%eax)\n\t" + "movl 0xbc(%ecx),%edx\n\t" /* SegCs */ + ".byte 0x36\n\t" + "movl %edx,2*4(%eax)\n\t" + "movl 0xb8(%ecx),%edx\n\t" /* Eip */ + ".byte 0x36\n\t" + "movl %edx,1*4(%eax)\n\t" + "movl 0xb0(%ecx),%edx\n\t" /* Eax */ + ".byte 0x36\n\t" + "movl %edx,0*4(%eax)\n\t" + "pushl 0x98(%ecx)\n\t" /* SegDs */ + "movl 0xa8(%ecx),%edx\n\t" /* Edx */ + "movl 0xac(%ecx),%ecx\n\t" /* Ecx */ + "popl %ds\n\t" + "movl %eax,%esp\n\t" + "popl %eax\n\t" + "iret\n" + /* Restore the context when the stack segment changes. We can't use + * the same code as above because we do not know if the stack segment + * is 16 or 32 bit, and 'movl' will throw an exception when we try to + * access memory above the limit. */ + "1:\n\t" + "movl 0xa8(%ecx),%edx\n\t" /* Edx */ + "movl 0xb0(%ecx),%eax\n\t" /* Eax */ + "movw 0xc8(%ecx),%ss\n\t" /* SegSs */ + "movl 0xc4(%ecx),%esp\n\t" /* Esp */ + "pushl 0xc0(%ecx)\n\t" /* EFlags */ + "pushl 0xbc(%ecx)\n\t" /* SegCs */ + "pushl 0xb8(%ecx)\n\t" /* Eip */ + "pushl 0x98(%ecx)\n\t" /* SegDs */ + "movl 0xac(%ecx),%ecx\n\t" /* Ecx */ + "popl %ds\n\t" + "iret" ) + +Be aware that most of the regression test failures are caused by lack of ptrace() support. + +The wine traces above show one of these cases. I will provide traces of an actual relevant failure. + +However the failure to restart the correct thread is in some way related to the use of iret in set_full_cpu_context(). + +That was a complete misdiaagnsis. The IRET works fine in user space, at the lowest privlege level. + +The wrong thread is not restarted. The correct thread continues execution, at the correct address, but with the wrong thread-local data. + +Thread-local data is accessed via the segment loaded in the fs register in wine. The segment selector is set the same in each thread, but each thread should have a unique GDT entry pointing to its thread-local data. + +The issue is that clone() copies the pointer reference to the process's GDT without creating a new GDT area. All threads wind up sharing the same GDT. As the selector is the same, all threads share the same threa-local data. Oddly enough, this has fewer ill effects than excpected. Unless SEH (Structured Exception Handling) is invoked, at which point threads start unwinding the stack frames of other threads... + +Copying the GDT during clone() results in a workig system with correct exception handling. + +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. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1915925 b/results/classifier/105/mistranslation/1915925 new file mode 100644 index 000000000..03d5a1b59 --- /dev/null +++ b/results/classifier/105/mistranslation/1915925 @@ -0,0 +1,904 @@ +mistranslation: 0.905 +vnc: 0.894 +other: 0.885 +device: 0.884 +instruction: 0.880 +assembly: 0.874 +socket: 0.862 +semantic: 0.860 +KVM: 0.854 +network: 0.842 +boot: 0.834 +graphic: 0.828 + +ARM semihosting HEAPINFO results wrote to wrong address + +This affects latest development branch of QEMU. + +According to the ARM spec of the HEAPINFO semihosting call: + +https://developer.arm.com/documentation/100863/0300/Semihosting-operations/SYS-HEAPINFO--0x16-?lang=en + +> the PARAMETER REGISTER contains the address of a pointer to a four-field data block. + +However, QEMU treated the PARAMETER REGISTER as pointing to a four-field data block directly. + +Here is a simple program that can demonstrate this problem: https://github.com/iNvEr7/qemu-learn/tree/newlib-bug/semihosting-newlib + +This code links with newlib with semihosting mode, which will call the HEAPINFO SVC during crt0 routine. When running in QEMU (make run), it may crash the program either because of invalid write or memory curruption, depending on the compiled program structure. + +Also refer to my discussion with newlib folks: https://sourceware.org/pipermail/newlib/2021/018260.html + +Broken in commit 3c37cfe0b1e8a49, I think. + + +I'm not sure this every worked properly and it's certainly not +exercised by check-tcg or Peter's semihosting tests. Hoist it into +it's own helper function and attempt to validate the results in the +linux-user semihosting test at the least. + +Bug: https://bugs.launchpad.net/bugs/1915925 +Cc: Bug 1915925 <email address hidden> +Cc: Keith Packard <email address hidden> +Signed-off-by: Alex Bennée <email address hidden> +--- + tests/tcg/arm/semicall.h | 1 + + semihosting/arm-compat-semi.c | 129 +++++++++++++++++++--------------- + tests/tcg/arm/semihosting.c | 34 ++++++++- + 3 files changed, 107 insertions(+), 57 deletions(-) + +diff --git a/tests/tcg/arm/semicall.h b/tests/tcg/arm/semicall.h +index d4f6818192..676a542be5 100644 +--- a/tests/tcg/arm/semicall.h ++++ b/tests/tcg/arm/semicall.h +@@ -9,6 +9,7 @@ + + #define SYS_WRITE0 0x04 + #define SYS_READC 0x07 ++#define SYS_HEAPINFO 0x16 + #define SYS_REPORTEXC 0x18 + + uintptr_t __semi_call(uintptr_t type, uintptr_t arg0) +diff --git a/semihosting/arm-compat-semi.c b/semihosting/arm-compat-semi.c +index 94950b6c56..a8fdbceb5f 100644 +--- a/semihosting/arm-compat-semi.c ++++ b/semihosting/arm-compat-semi.c +@@ -822,6 +822,78 @@ static const GuestFDFunctions guestfd_fns[] = { + put_user_utl(val, args + (n) * sizeof(target_ulong)) + #endif + ++/* ++ * SYS_HEAPINFO is a little weird: "On entry, the PARAMETER REGISTER ++ * contains the address of a pointer to a four-field data block" which ++ * we then fill in. The PARAMETER REGISTER is unchanged. ++ */ ++ ++struct HeapInfo { ++ target_ulong heap_base; ++ target_ulong heap_limit; ++ target_ulong stack_base; ++ target_ulong stack_limit; ++}; ++ ++static bool do_heapinfo(CPUState *cs, target_long arg0) ++{ ++ target_ulong limit; ++ struct HeapInfo info = {}; ++#ifdef CONFIG_USER_ONLY ++ TaskState *ts = cs->opaque; ++#else ++ target_ulong rambase = common_semi_rambase(cs); ++#endif ++ ++#ifdef CONFIG_USER_ONLY ++ /* ++ * Some C libraries assume the heap immediately follows .bss, so ++ * allocate it using sbrk. ++ */ ++ if (!ts->heap_limit) { ++ abi_ulong ret; ++ ++ ts->heap_base = do_brk(0); ++ limit = ts->heap_base + COMMON_SEMI_HEAP_SIZE; ++ /* Try a big heap, and reduce the size if that fails. */ ++ for (;;) { ++ ret = do_brk(limit); ++ if (ret >= limit) { ++ break; ++ } ++ limit = (ts->heap_base >> 1) + (limit >> 1); ++ } ++ ts->heap_limit = limit; ++ } ++ ++ info.heap_base = ts->heap_base; ++ info.heap_limit = ts->heap_limit; ++ info.stack_base = ts->stack_base; ++ info.stack_limit = 0; /* Stack limit. */ ++ ++ if (copy_to_user(arg0, &info, sizeof(info))) { ++ errno = EFAULT; ++ return set_swi_errno(cs, -1); ++ } ++#else ++ limit = current_machine->ram_size; ++ /* TODO: Make this use the limit of the loaded application. */ ++ info.heap_base = rambase + limit / 2; ++ info.heap_limit = rambase + limit; ++ info.stack_base = rambase + limit; /* Stack base */ ++ info.stack_limit = rambase; /* Stack limit. */ ++ ++ if (cpu_memory_rw_debug(cs, arg0, &info, sizeof(info), true)) { ++ errno = EFAULT; ++ return set_swi_errno(cs, -1); ++ } ++ ++#endif ++ ++ return 0; ++} ++ ++ + /* + * Do a semihosting call. + * +@@ -1184,63 +1256,8 @@ target_ulong do_common_semihosting(CPUState *cs) + } + case TARGET_SYS_HEAPINFO: + { +- target_ulong retvals[4]; +- target_ulong limit; +- int i; +-#ifdef CONFIG_USER_ONLY +- TaskState *ts = cs->opaque; +-#else +- target_ulong rambase = common_semi_rambase(cs); +-#endif +- + GET_ARG(0); +- +-#ifdef CONFIG_USER_ONLY +- /* +- * Some C libraries assume the heap immediately follows .bss, so +- * allocate it using sbrk. +- */ +- if (!ts->heap_limit) { +- abi_ulong ret; +- +- ts->heap_base = do_brk(0); +- limit = ts->heap_base + COMMON_SEMI_HEAP_SIZE; +- /* Try a big heap, and reduce the size if that fails. */ +- for (;;) { +- ret = do_brk(limit); +- if (ret >= limit) { +- break; +- } +- limit = (ts->heap_base >> 1) + (limit >> 1); +- } +- ts->heap_limit = limit; +- } +- +- retvals[0] = ts->heap_base; +- retvals[1] = ts->heap_limit; +- retvals[2] = ts->stack_base; +- retvals[3] = 0; /* Stack limit. */ +-#else +- limit = current_machine->ram_size; +- /* TODO: Make this use the limit of the loaded application. */ +- retvals[0] = rambase + limit / 2; +- retvals[1] = rambase + limit; +- retvals[2] = rambase + limit; /* Stack base */ +- retvals[3] = rambase; /* Stack limit. */ +-#endif +- +- for (i = 0; i < ARRAY_SIZE(retvals); i++) { +- bool fail; +- +- fail = SET_ARG(i, retvals[i]); +- +- if (fail) { +- /* Couldn't write back to argument block */ +- errno = EFAULT; +- return set_swi_errno(cs, -1); +- } +- } +- return 0; ++ return do_heapinfo(cs, arg0); + } + case TARGET_SYS_EXIT: + case TARGET_SYS_EXIT_EXTENDED: +diff --git a/tests/tcg/arm/semihosting.c b/tests/tcg/arm/semihosting.c +index 33faac9916..fd5780ec3c 100644 +--- a/tests/tcg/arm/semihosting.c ++++ b/tests/tcg/arm/semihosting.c +@@ -7,7 +7,13 @@ + * SPDX-License-Identifier: GPL-3.0-or-later + */ + ++#define _GNU_SOURCE /* asprintf is a GNU extension */ ++ + #include <stdint.h> ++#include <stdlib.h> ++#include <stdio.h> ++#include <string.h> ++#include <unistd.h> + #include "semicall.h" + + int main(int argc, char *argv[argc]) +@@ -18,8 +24,34 @@ int main(int argc, char *argv[argc]) + uintptr_t exit_block[2] = {0x20026, 0}; + uintptr_t exit_code = (uintptr_t) &exit_block; + #endif ++ struct { ++ void *heap_base; ++ void *heap_limit; ++ void *stack_base; ++ void *stack_limit; ++ } info; ++ void *ptr_to_info = (void *) &info; ++ char *heap_info, *stack_info; ++ void *brk = sbrk(0); ++ ++ __semi_call(SYS_WRITE0, (uintptr_t) "Hello World\n"); ++ ++ memset(&info, 0, sizeof(info)); ++ __semi_call(SYS_HEAPINFO, (uintptr_t) &ptr_to_info); ++ ++ asprintf(&heap_info, "heap: %p -> %p\n", info.heap_base, info.heap_limit); ++ __semi_call(SYS_WRITE0, (uintptr_t) heap_info); ++ if (info.heap_base != brk) { ++ sprintf(heap_info, "heap mismatch: %p\n", brk); ++ __semi_call(SYS_WRITE0, (uintptr_t) heap_info); ++ return -1; ++ } ++ ++ asprintf(&stack_info, "stack: %p -> %p\n", info.stack_base, info.stack_limit); ++ __semi_call(SYS_WRITE0, (uintptr_t) stack_info); ++ free(heap_info); ++ free(stack_info); + +- __semi_call(SYS_WRITE0, (uintptr_t) "Hello World"); + __semi_call(SYS_REPORTEXC, exit_code); + /* if we get here we failed */ + return -1; +-- +2.20.1 + + + +On Fri, 5 Mar 2021 at 13:54, Alex Bennée <email address hidden> wrote: +> +> I'm not sure this every worked properly and it's certainly not +> exercised by check-tcg or Peter's semihosting tests. Hoist it into +> it's own helper function and attempt to validate the results in the +> linux-user semihosting test at the least. +> +> Bug: https://bugs.launchpad.net/bugs/1915925 +> Cc: Bug 1915925 <email address hidden> +> Cc: Keith Packard <email address hidden> +> Signed-off-by: Alex Bennée <email address hidden> +> --- +> tests/tcg/arm/semicall.h | 1 + +> semihosting/arm-compat-semi.c | 129 +++++++++++++++++++--------------- +> tests/tcg/arm/semihosting.c | 34 ++++++++- +> 3 files changed, 107 insertions(+), 57 deletions(-) +> +#else +> + limit = current_machine->ram_size; +> + /* TODO: Make this use the limit of the loaded application. */ +> + info.heap_base = rambase + limit / 2; +> + info.heap_limit = rambase + limit; +> + info.stack_base = rambase + limit; /* Stack base */ +> + info.stack_limit = rambase; /* Stack limit. */ +> + +> + if (cpu_memory_rw_debug(cs, arg0, &info, sizeof(info), true)) { + +Blatting a C struct into guest memory has endianness and padding +problems. Why not just do things the way the old Arm code did it ? + +Also, you don't seem to have the correct "is the CPU in +32-bit or 64-bit mode" test here: you cannot rely on target_ulong +being the right size, you must make a runtime check. + +I suggested in the other email the way I think we should fix this. + +thanks +-- PMM + + +Alex Bennée <email address hidden> writes: + +> I'm not sure this every worked properly and it's certainly not +> exercised by check-tcg or Peter's semihosting tests. Hoist it into +> it's own helper function and attempt to validate the results in the +> linux-user semihosting test at the least. + +The patch is mostly code motion, moving the existing heapinfo stuff into +a separate function. That makes it really hard to see how you've +changed the values being returned. I'd love to see a two patch series, +one of which moves the code as-is and a second patch which fixes +whatever bugs you've found. + +-- +-keith + + +Peter Maydell <email address hidden> writes: + +> Also, you don't seem to have the correct "is the CPU in +> 32-bit or 64-bit mode" test here: you cannot rely on target_ulong +> being the right size, you must make a runtime check. + +Do you mean whether a dual aarch64/arm core is in arm or aarch64 mode, +or whether an aarch64 is running a 32-bit ABI? + +-- +-keith + + +On Fri, 5 Mar 2021 at 20:22, Keith Packard <email address hidden> wrote: +> +> Peter Maydell <email address hidden> writes: +> +> > Also, you don't seem to have the correct "is the CPU in +> > 32-bit or 64-bit mode" test here: you cannot rely on target_ulong +> > being the right size, you must make a runtime check. +> +> Do you mean whether a dual aarch64/arm core is in arm or aarch64 mode, +> or whether an aarch64 is running a 32-bit ABI? + +For semihosting for Arm what matters is "what state is the core +in at the point where it makes the semihosting SVC/HLT/etc insn?". + +How does RISCV specify it? + +thanks +-- PMM + + +Peter Maydell <email address hidden> writes: + +> For semihosting for Arm what matters is "what state is the core +> in at the point where it makes the semihosting SVC/HLT/etc insn?". + +Ok, that means we *aren't* talking about -mabi=ilp32, which is good -- +in my current picolibc implementation, the semihosting code uses a pure +64-bit interface for aarch64 targets, even when using ilp32 ABI. + +> How does RISCV specify it? + +Because the ISA is identical between 64- and 32- bit (and 128-bit) +execution modes, the only difference between the two is the Machine XLEN +value which encodes the native base integer ISA width. You switch modes +by modifying this value. + +I don't know of any implementation in hardware or software that supports +modifying this value. I'm not sure we need to support this in the +semihosting code for qemu as I'm pretty sure getting qemu to support +dynamic XLEN values would be a large project (a project which I don't +personally feel would offer much value). + +-- +-keith + + +On Fri, 5 Mar 2021 at 23:54, Keith Packard <email address hidden> wrote: +> +> Peter Maydell <email address hidden> writes: +> +> > For semihosting for Arm what matters is "what state is the core +> > in at the point where it makes the semihosting SVC/HLT/etc insn?". +> +> Ok, that means we *aren't* talking about -mabi=ilp32, which is good -- +> in my current picolibc implementation, the semihosting code uses a pure +> 64-bit interface for aarch64 targets, even when using ilp32 ABI. + +ILP32 for AArch64 is a zombie target -- it is kinda-sorta +supported in some toolchains but has no support in eg +the Linux syscall ABI. The semihosting ABI does not implement +any kind of ILP32 variant -- you can have A32/T32 (AArch32) +semihosting, where register and field sizes are 32 bit, or +you can have A64 (AArch64) semihosting, where register and +field sizes are 64 bit. + +> > How does RISCV specify it? +> +> Because the ISA is identical between 64- and 32- bit (and 128-bit) +> execution modes, the only difference between the two is the Machine XLEN +> value which encodes the native base integer ISA width. You switch modes +> by modifying this value. + +I meant, how does the RISCV semihosting ABI specify what +the field size is? To answer my own question, I just looked at +the spec doc and it says "depends on whether the caller is +32-bit or 64-bit", which implies that we need to look at the +current state of the CPU in some way. + +> I don't know of any implementation in hardware or software that supports +> modifying this value. I'm not sure we need to support this in the +> semihosting code for qemu as I'm pretty sure getting qemu to support +> dynamic XLEN values would be a large project (a project which I don't +> personally feel would offer much value). + +Part of why I asked is that the current RISCV implementation +is just looking at sizeof(target_ulong); but the qemu-system-riscv64 +executable AIUI now supports emulating both "this is a 64 bit +guest CPU" and "this is a 32 bit host CPU", and so looking at +a QEMU-compile-time value like "sizeof(target_ulong)" will +produce the wrong answer for 32-bit CPUs emulated in +the qemu-system-riscv64 binary. My guess is maybe +it should be looking at the result of riscv_cpu_is_32bit() instead. + +thanks +-- PMM + + +Peter Maydell <email address hidden> writes: + +> ILP32 for AArch64 is a zombie target -- it is kinda-sorta +> supported in some toolchains but has no support in eg +> the Linux syscall ABI. The semihosting ABI does not implement +> any kind of ILP32 variant -- you can have A32/T32 (AArch32) +> semihosting, where register and field sizes are 32 bit, or +> you can have A64 (AArch64) semihosting, where register and +> field sizes are 64 bit. + +Yeah, I did ILP32 support for Picolibc; all of the aarch64 asm support +needed fixing as ilp32 doesn't specify that register arguments clear the +top 32 bits. Seems pretty obvious that it's little used. + +For semihosting, as the ABI isn't visible to the hardware/emulator, the +only reasonable answer that I could come up with was to treat ILP32 the +same as the LP64 and pass 64 bit parameters. + +As picolibc is designed for bare-metal environments, it's pretty easy to +support ilp32 otherwise. + +> I meant, how does the RISCV semihosting ABI specify what +> the field size is? To answer my own question, I just looked at +> the spec doc and it says "depends on whether the caller is +> 32-bit or 64-bit", which implies that we need to look at the +> current state of the CPU in some way. + +Yes. As qemu currently fixes that value based on compilation parameters, +we can use the relevant native types directly and ignore the CPU +state. Adding dynamic XLEN support to qemu would involve a bunch of work +as the same code can be run in both 64- and 32- bit modes, so you'd have +to translate it twice and select which to execute based on the CPU +state. + +> Part of why I asked is that the current RISCV implementation +> is just looking at sizeof(target_ulong); but the qemu-system-riscv64 +> executable AIUI now supports emulating both "this is a 64 bit +> guest CPU" and "this is a 32 bit host CPU", and so looking at +> a QEMU-compile-time value like "sizeof(target_ulong)" will +> produce the wrong answer for 32-bit CPUs emulated in +> the qemu-system-riscv64 binary. My guess is maybe +> it should be looking at the result of riscv_cpu_is_32bit() instead. + +Wow. I read through the code and couldn't find anything that looked like +it supported that, sounds like I must have missed something? + +-- +-keith + + +On Sat, 6 Mar 2021 at 16:54, Keith Packard <email address hidden> wrote: +> +> Peter Maydell <email address hidden> writes: +> > Part of why I asked is that the current RISCV implementation +> > is just looking at sizeof(target_ulong); but the qemu-system-riscv64 +> > executable AIUI now supports emulating both "this is a 64 bit +> > guest CPU" and "this is a 32 bit host CPU", and so looking at +> > a QEMU-compile-time value like "sizeof(target_ulong)" will +> > produce the wrong answer for 32-bit CPUs emulated in +> > the qemu-system-riscv64 binary. My guess is maybe +> > it should be looking at the result of riscv_cpu_is_32bit() instead. +> +> Wow. I read through the code and couldn't find anything that looked like +> it supported that, sounds like I must have missed something? + +I thought Alistair had done that work (which brings riscv into +line with the other 32/64 bit QEMU targets, which all support +the 32-bit CPU types in the 64-bit-capable executable). But maybe +it hasn't landed in master yet? + +thanks +-- PMM + + +Alistair Francis <email address hidden> writes: + +> I have started on the effort, but I have not finished yet. Adding +> riscv_cpu_is_32bit() was the first step there and I have some more +> patches locally but I don't have anything working yet. + +That's awesome. I think waiting until we see what APIs you're developing +for detecting and operating in 32-bit mode on a 64-bit capable processor +seems like a good idea for now. + +-- +-keith + + +As per the spec: + + the PARAMETER REGISTER contains the address of a pointer to a + four-field data block. + +So we need to follow the pointer and place the results of SYS_HEAPINFO +there. + +Bug: https://bugs.launchpad.net/bugs/1915925 +Cc: Bug 1915925 <email address hidden> +Cc: Keith Packard <email address hidden> +Signed-off-by: Alex Bennée <email address hidden> +--- + semihosting/arm-compat-semi.c | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/semihosting/arm-compat-semi.c b/semihosting/arm-compat-semi.c +index 733eea1e2d..2ac9226d29 100644 +--- a/semihosting/arm-compat-semi.c ++++ b/semihosting/arm-compat-semi.c +@@ -1210,6 +1210,8 @@ target_ulong do_common_semihosting(CPUState *cs) + retvals[2] = rambase + limit; /* Stack base */ + retvals[3] = rambase; /* Stack limit. */ + #endif ++ /* The result array is pointed to by arg0 */ ++ args = arg0; + + for (i = 0; i < ARRAY_SIZE(retvals); i++) { + bool fail; +-- +2.20.1 + + + +On Tue, 9 Mar 2021 at 14:23, Alex Bennée <email address hidden> wrote: +> +> As per the spec: +> +> the PARAMETER REGISTER contains the address of a pointer to a +> four-field data block. +> +> So we need to follow the pointer and place the results of SYS_HEAPINFO +> there. +> +> Bug: https://bugs.launchpad.net/bugs/1915925 +> Cc: Bug 1915925 <email address hidden> +> Cc: Keith Packard <email address hidden> +> Signed-off-by: Alex Bennée <email address hidden> +> --- +> semihosting/arm-compat-semi.c | 2 ++ +> 1 file changed, 2 insertions(+) +> +> diff --git a/semihosting/arm-compat-semi.c b/semihosting/arm-compat-semi.c +> index 733eea1e2d..2ac9226d29 100644 +> --- a/semihosting/arm-compat-semi.c +> +++ b/semihosting/arm-compat-semi.c +> @@ -1210,6 +1210,8 @@ target_ulong do_common_semihosting(CPUState *cs) +> retvals[2] = rambase + limit; /* Stack base */ +> retvals[3] = rambase; /* Stack limit. */ +> #endif +> + /* The result array is pointed to by arg0 */ +> + args = arg0; +> +> for (i = 0; i < ARRAY_SIZE(retvals); i++) { +> bool fail; +> -- + +No, 'args' is the argument array. That's not the same thing +as the data block we're writing, and we shouldn't reassign +that variable here. + +What was wrong with the old arm-semi.c code, which just did +appropriate loads and stores here, and worked fine and was +not buggy ? + +thanks +-- PMM + + + +Peter Maydell <email address hidden> writes: + +> On Tue, 9 Mar 2021 at 14:23, Alex Bennée <email address hidden> wrote: +>> +>> As per the spec: +>> +>> the PARAMETER REGISTER contains the address of a pointer to a +>> four-field data block. +>> +>> So we need to follow the pointer and place the results of SYS_HEAPINFO +>> there. +>> +>> Bug: https://bugs.launchpad.net/bugs/1915925 +>> Cc: Bug 1915925 <email address hidden> +>> Cc: Keith Packard <email address hidden> +>> Signed-off-by: Alex Bennée <email address hidden> +>> --- +>> semihosting/arm-compat-semi.c | 2 ++ +>> 1 file changed, 2 insertions(+) +>> +>> diff --git a/semihosting/arm-compat-semi.c b/semihosting/arm-compat-semi.c +>> index 733eea1e2d..2ac9226d29 100644 +>> --- a/semihosting/arm-compat-semi.c +>> +++ b/semihosting/arm-compat-semi.c +>> @@ -1210,6 +1210,8 @@ target_ulong do_common_semihosting(CPUState *cs) +>> retvals[2] = rambase + limit; /* Stack base */ +>> retvals[3] = rambase; /* Stack limit. */ +>> #endif +>> + /* The result array is pointed to by arg0 */ +>> + args = arg0; +>> +>> for (i = 0; i < ARRAY_SIZE(retvals); i++) { +>> bool fail; +>> -- +> +> No, 'args' is the argument array. That's not the same thing +> as the data block we're writing, and we shouldn't reassign +> that variable here. +> +> What was wrong with the old arm-semi.c code, which just did +> appropriate loads and stores here, and worked fine and was +> not buggy ? + +I was just trying avoid repeating too much verbiage. But OK I've +reverted to the original code with the new helper: + + for (i = 0; i < ARRAY_SIZE(retvals); i++) { + bool fail; + + if (is_64bit_semihosting(env)) { + fail = put_user_u64(retvals[i], arg0 + i * 8); + } else { + fail = put_user_u32(retvals[i], arg0 + i * 4); + } + + if (fail) { + /* Couldn't write back to argument block */ + errno = EFAULT; + return set_swi_errno(cs, -1); + } + } + return 0; + + +> +> thanks +> -- PMM + + +-- +Alex Bennée + + +As per the spec: + + the PARAMETER REGISTER contains the address of a pointer to a + four-field data block. + +So we need to follow arg0 and place the results of SYS_HEAPINFO there. + +Fixes: 3c37cfe0b1 ("semihosting: Change internal common-semi interfaces to use CPUState *") +Bug: https://bugs.launchpad.net/bugs/1915925 +Cc: Bug 1915925 <email address hidden> +Cc: Keith Packard <email address hidden> +Signed-off-by: Alex Bennée <email address hidden> + +--- +v3 + - just revert the old behaviour +--- + semihosting/arm-compat-semi.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +diff --git a/semihosting/arm-compat-semi.c b/semihosting/arm-compat-semi.c +index 0f0e129a7c..fe079ca93a 100644 +--- a/semihosting/arm-compat-semi.c ++++ b/semihosting/arm-compat-semi.c +@@ -1214,7 +1214,11 @@ target_ulong do_common_semihosting(CPUState *cs) + for (i = 0; i < ARRAY_SIZE(retvals); i++) { + bool fail; + +- fail = SET_ARG(i, retvals[i]); ++ if (is_64bit_semihosting(env)) { ++ fail = put_user_u64(retvals[i], arg0 + i * 8); ++ } else { ++ fail = put_user_u32(retvals[i], arg0 + i * 4); ++ } + + if (fail) { + /* Couldn't write back to argument block */ +-- +2.20.1 + + + +As per the spec: + + the PARAMETER REGISTER contains the address of a pointer to a + four-field data block. + +So we need to follow arg0 and place the results of SYS_HEAPINFO there. + +Fixes: 3c37cfe0b1 ("semihosting: Change internal common-semi interfaces to use CPUState *") +Bug: https://bugs.launchpad.net/bugs/1915925 +Cc: Bug 1915925 <email address hidden> +Cc: Keith Packard <email address hidden> +Signed-off-by: Alex Bennée <email address hidden> + +--- +v3 + - just revert the old behaviour +--- + semihosting/arm-compat-semi.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +diff --git a/semihosting/arm-compat-semi.c b/semihosting/arm-compat-semi.c +index 0f0e129a7c..fe079ca93a 100644 +--- a/semihosting/arm-compat-semi.c ++++ b/semihosting/arm-compat-semi.c +@@ -1214,7 +1214,11 @@ target_ulong do_common_semihosting(CPUState *cs) + for (i = 0; i < ARRAY_SIZE(retvals); i++) { + bool fail; + +- fail = SET_ARG(i, retvals[i]); ++ if (is_64bit_semihosting(env)) { ++ fail = put_user_u64(retvals[i], arg0 + i * 8); ++ } else { ++ fail = put_user_u32(retvals[i], arg0 + i * 4); ++ } + + if (fail) { + /* Couldn't write back to argument block */ +-- +2.20.1 + + + +On Fri, 12 Mar 2021 at 10:29, Alex Bennée <email address hidden> wrote: +> +> As per the spec: +> +> the PARAMETER REGISTER contains the address of a pointer to a +> four-field data block. +> +> So we need to follow arg0 and place the results of SYS_HEAPINFO there. +> +> Fixes: 3c37cfe0b1 ("semihosting: Change internal common-semi interfaces to use CPUState *") +> Bug: https://bugs.launchpad.net/bugs/1915925 +> Cc: Bug 1915925 <email address hidden> +> Cc: Keith Packard <email address hidden> +> Signed-off-by: Alex Bennée <email address hidden> +> +> --- +> v3 +> - just revert the old behaviour + +Reviewed-by: Peter Maydell <email address hidden> + +thanks +-- PMM + + +As per the spec: + + the PARAMETER REGISTER contains the address of a pointer to a + four-field data block. + +So we need to follow arg0 and place the results of SYS_HEAPINFO there. + +Fixes: 3c37cfe0b1 ("semihosting: Change internal common-semi interfaces to use CPUState *") +Signed-off-by: Alex Bennée <email address hidden> +Reviewed-by: Peter Maydell <email address hidden> +Cc: Bug 1915925 <email address hidden> +Cc: Keith Packard <email address hidden> +Bug: https://bugs.launchpad.net/bugs/1915925 +Message-Id: <email address hidden> +--- + semihosting/arm-compat-semi.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +diff --git a/semihosting/arm-compat-semi.c b/semihosting/arm-compat-semi.c +index 0f0e129a7c..fe079ca93a 100644 +--- a/semihosting/arm-compat-semi.c ++++ b/semihosting/arm-compat-semi.c +@@ -1214,7 +1214,11 @@ target_ulong do_common_semihosting(CPUState *cs) + for (i = 0; i < ARRAY_SIZE(retvals); i++) { + bool fail; + +- fail = SET_ARG(i, retvals[i]); ++ if (is_64bit_semihosting(env)) { ++ fail = put_user_u64(retvals[i], arg0 + i * 8); ++ } else { ++ fail = put_user_u32(retvals[i], arg0 + i * 4); ++ } + + if (fail) { + /* Couldn't write back to argument block */ +-- +2.20.1 + + + +As per the spec: + + the PARAMETER REGISTER contains the address of a pointer to a + four-field data block. + +So we need to follow arg0 and place the results of SYS_HEAPINFO there. + +Fixes: 3c37cfe0b1 ("semihosting: Change internal common-semi interfaces to use CPUState *") +Signed-off-by: Alex Bennée <email address hidden> +Reviewed-by: Peter Maydell <email address hidden> +Cc: Bug 1915925 <email address hidden> +Cc: Keith Packard <email address hidden> +Bug: https://bugs.launchpad.net/bugs/1915925 +Message-Id: <email address hidden> +Message-Id: <email address hidden> +--- + semihosting/arm-compat-semi.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +diff --git a/semihosting/arm-compat-semi.c b/semihosting/arm-compat-semi.c +index 0f0e129a7c..fe079ca93a 100644 +--- a/semihosting/arm-compat-semi.c ++++ b/semihosting/arm-compat-semi.c +@@ -1214,7 +1214,11 @@ target_ulong do_common_semihosting(CPUState *cs) + for (i = 0; i < ARRAY_SIZE(retvals); i++) { + bool fail; + +- fail = SET_ARG(i, retvals[i]); ++ if (is_64bit_semihosting(env)) { ++ fail = put_user_u64(retvals[i], arg0 + i * 8); ++ } else { ++ fail = put_user_u32(retvals[i], arg0 + i * 4); ++ } + + if (fail) { + /* Couldn't write back to argument block */ +-- +2.20.1 + + + +As per the spec: + + the PARAMETER REGISTER contains the address of a pointer to a + four-field data block. + +So we need to follow arg0 and place the results of SYS_HEAPINFO there. + +Fixes: 3c37cfe0b1 ("semihosting: Change internal common-semi interfaces to use CPUState *") +Signed-off-by: Alex Bennée <email address hidden> +Reviewed-by: Peter Maydell <email address hidden> +Cc: Bug 1915925 <email address hidden> +Cc: Keith Packard <email address hidden> +Bug: https://bugs.launchpad.net/bugs/1915925 +Message-Id: <email address hidden> + +diff --git a/semihosting/arm-compat-semi.c b/semihosting/arm-compat-semi.c +index 0f0e129a7c..fe079ca93a 100644 +--- a/semihosting/arm-compat-semi.c ++++ b/semihosting/arm-compat-semi.c +@@ -1214,7 +1214,11 @@ target_ulong do_common_semihosting(CPUState *cs) + for (i = 0; i < ARRAY_SIZE(retvals); i++) { + bool fail; + +- fail = SET_ARG(i, retvals[i]); ++ if (is_64bit_semihosting(env)) { ++ fail = put_user_u64(retvals[i], arg0 + i * 8); ++ } else { ++ fail = put_user_u32(retvals[i], arg0 + i * 4); ++ } + + if (fail) { + /* Couldn't write back to argument block */ +-- +2.20.1 + + + +This is now merged and while be available in the 6.0 release. + diff --git a/results/classifier/105/mistranslation/1916501 b/results/classifier/105/mistranslation/1916501 new file mode 100644 index 000000000..f11a84596 --- /dev/null +++ b/results/classifier/105/mistranslation/1916501 @@ -0,0 +1,116 @@ +mistranslation: 0.896 +graphic: 0.878 +other: 0.869 +semantic: 0.856 +vnc: 0.832 +assembly: 0.831 +instruction: 0.825 +KVM: 0.823 +socket: 0.820 +network: 0.807 +device: 0.761 +boot: 0.758 + +qemu-img convert segfaults with specific URL + +Using what is currently the latest git: (commit 00d8ba9e0d62ea1c7459c25aeabf9c8bb7659462, Date: Sun Feb 21 19:52:58 2021 +0000) + +$ ./build/qemu-img convert -f qcow2 -O raw https://download.cirros-cloud.net/0.4.0/cirros-0.4.0-x86_64-disk.img out.img +Segmentation fault (core dumped) + + +Backtrace for convenience: +qemu: qemu_mutex_lock_impl: Invalid argument + +Thread 1 "qemu-img" received signal SIGABRT, Aborted. +0x00007ffff77c59d5 in raise () from /lib64/libc.so.6 +(gdb) bt +#0 0x00007ffff77c59d5 in raise () from /lib64/libc.so.6 +#1 0x00007ffff77ae8a4 in abort () from /lib64/libc.so.6 +#2 0x00005555556705b2 in error_exit (err=<optimized out>, msg=msg@entry=0x5555556b69a0 <__func__.31> "qemu_mutex_lock_impl") at ../util/qemu-thread-posix.c:37 +#3 0x0000555555670945 in qemu_mutex_lock_impl (mutex=0x555555ae3758, file=0x5555556827a2 "../block/curl.c", line=406) at ../util/qemu-thread-posix.c:81 +#4 0x000055555559a05b in curl_multi_do (arg=0x555555aad2a0) at ../block/curl.c:406 +#5 0x000055555566193a in aio_dispatch_handler (ctx=ctx@entry=0x555555737790, node=0x555555b14150) at ../util/aio-posix.c:329 +#6 0x0000555555662072 in aio_dispatch_handlers (ctx=0x555555737790) at ../util/aio-posix.c:372 +#7 aio_dispatch (ctx=0x555555737790) at ../util/aio-posix.c:382 +#8 0x000055555564442e in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at ../util/async.c:306 +#9 0x00007ffff7cfda9f in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 +#10 0x000055555566f2c8 in glib_pollfds_poll () at ../util/main-loop.c:232 +#11 os_host_main_loop_wait (timeout=4397000000) at ../util/main-loop.c:255 +#12 main_loop_wait (nonblocking=nonblocking@entry=0) at ../util/main-loop.c:531 +#13 0x0000555555581edd in convert_do_copy (s=0x7fffffffd3a0) at ../qemu-img.c:2139 +#14 img_convert (argc=<optimized out>, argv=<optimized out>) at ../qemu-img.c:2738 +#15 0x00005555555783b1 in main (argc=7, argv=<optimized out>) at ../qemu-img.c:5536 + +I can reproduce this, and I can reproduce it back to 5.0 (haven’t tried any release before that). I couldn’t find a definite reason for why it breaks (curl_clean_state() is called because curl reports CURLMSG_DONE, freeing a socket, but then curl_multi_do() is called again for that socket, resulting in a use-after-free – but I don’t know why curl_multi_do() is invoked after CURLMSG_DONE). + +Because I remembered a similar situation where the curl driver suddenly failed (and then failed for every qemu release until that point), and where it turned out a change in libcurl broke our driver, I tried bisecting libcurl, but it turned out that when I build it myself and use it via LD_PRELOAD, I don’t get a crash. I’ve tried building it with different options and in different versions, but consistently I see that using the system libcurl results in a crash, and using one I built myself does not. (Tested on Fedora and Arch.) + +That isn’t to say the bug isn’t in our curl driver, but to find out where it is exactly, it seems necessary to find out what the difference between the system libcurl and the one I built is... So far, I have no idea. :/ + +Guys, when I run with valgrind, I always get this when segfault occurs: + +==74885== Invalid read of size 8 +==74885== at 0x1DC87D: curl_multi_do (curl.c:410) +==74885== by 0x23B949: aio_dispatch_handler (aio-posix.c:329) +==74885== by 0x23C0A1: aio_dispatch_handlers (aio-posix.c:372) +==74885== by 0x23C0A1: aio_dispatch (aio-posix.c:382) +==74885== by 0x22DEE1: aio_ctx_dispatch (async.c:306) +==74885== by 0x4A854DA: g_main_context_dispatch (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6600.1) +==74885== by 0x236097: glib_pollfds_poll (main-loop.c:232) +==74885== by 0x236097: os_host_main_loop_wait (main-loop.c:255) +==74885== by 0x236097: main_loop_wait (main-loop.c:531) +==74885== by 0x13E30C: convert_do_copy (qemu-img.c:2139) +==74885== by 0x13E30C: img_convert (qemu-img.c:2738) +==74885== by 0x134660: main (qemu-img.c:5536) +==74885== Address 0xf9779b8 is 8 bytes inside a block of size 32 free'd +==74885== at 0x483DA3F: free (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) +==74885== by 0x1DC5BC: curl_clean_state (curl.c:529) +==74885== by 0x1DC5BC: curl_clean_state (curl.c:515) +==74885== by 0x1DC7E4: curl_multi_check_completion (curl.c:385) +==74885== by 0x1DC8D4: curl_multi_do (curl.c:414) +==74885== by 0x23B949: aio_dispatch_handler (aio-posix.c:329) +==74885== by 0x23C0A1: aio_dispatch_handlers (aio-posix.c:372) +==74885== by 0x23C0A1: aio_dispatch (aio-posix.c:382) +==74885== by 0x22DEE1: aio_ctx_dispatch (async.c:306) +==74885== by 0x4A854DA: g_main_context_dispatch (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6600.1) +==74885== by 0x236097: glib_pollfds_poll (main-loop.c:232) +==74885== by 0x236097: os_host_main_loop_wait (main-loop.c:255) +==74885== by 0x236097: main_loop_wait (main-loop.c:531) +==74885== by 0x13E30C: convert_do_copy (qemu-img.c:2139) +==74885== by 0x13E30C: img_convert (qemu-img.c:2738) +==74885== by 0x134660: main (qemu-img.c:5536) +==74885== Block was alloc'd at +==74885== at 0x483ED99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) +==74885== by 0x4A8B5A0: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6600.1) +==74885== by 0x1DBDC9: curl_sock_cb (curl.c:156) +==74885== by 0x55402C1: ??? (in /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.6.0) +==74885== by 0x5543D33: ??? (in /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.6.0) +==74885== by 0x5543E77: curl_multi_socket_action (in /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.6.0) +==74885== by 0x1DC8C7: curl_multi_do_locked (curl.c:403) +==74885== by 0x1DC8C7: curl_multi_do (curl.c:413) +==74885== by 0x23B949: aio_dispatch_handler (aio-posix.c:329) +==74885== by 0x23C0A1: aio_dispatch_handlers (aio-posix.c:372) +==74885== by 0x23C0A1: aio_dispatch (aio-posix.c:382) +==74885== by 0x22DEE1: aio_ctx_dispatch (async.c:306) +==74885== by 0x4A854DA: g_main_context_dispatch (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6600.1) +==74885== by 0x236097: glib_pollfds_poll (main-loop.c:232) +==74885== by 0x236097: os_host_main_loop_wait (main-loop.c:255) +==74885== by 0x236097: main_loop_wait (main-loop.c:531) + +It seems that sockets are being free'd in a non-expecting situation. + +Yes, as I wrote in comment 1, curl reports CURLMSG_DONE, the socket is freed, but then curl_multi_do() is called again for that socket (despite the CURLMSG_DONE). + +I suspect that qemu has interpreted the curl interface differently than curl itself (i.e., qemu has probably understood something wrong), which led to some change in curl breaking qemu’s curl module. (Because I can’t find an old qemu version that doesn’t break, and so can’t find a change in qemu that broke it.) + +So if indeed a change to the curl library is what causes this segfault, or at least made the underlying issue visible, I’d like to know which change that is, so we can try to infer what qemu does wrong. But I can’t find that change, because if I compile libcurl myself, I don’t get a segfault (nor valgrind errors in curl). + +Perhaps there’s something special about the server serving the image (although it just looks like AWS to me), i.e. it was always broken and we’ve just never seen it with other servers. If so, debugging will be more difficult because we’d really need to take a detailed look into all our curl driver does. + +I think I’ve come to kind of understood what might be wrong: qemu frees CURLSocket objects when “their” transfer is done, but libcurl’s documentation actually doesn’t note any long-lasting relationship between a socket and some transfer (i.e., a CURL object), so we probably shouldn’t free CURLSocket objects just because some transfer is done. Instead, we should only do so once libcurl explicitly tells us to remove the socket. + +I’ve sent a two-patch series to that effect: https://lists.nongnu.org/archive/html/qemu-block/2021-03/msg00515.html – it seems to help. + +https://gitlab.com/qemu-project/qemu/-/commit/0f418a207696b37f05d + diff --git a/results/classifier/105/mistranslation/1917565 b/results/classifier/105/mistranslation/1917565 new file mode 100644 index 000000000..63d6cf7d7 --- /dev/null +++ b/results/classifier/105/mistranslation/1917565 @@ -0,0 +1,173 @@ +mistranslation: 0.933 +other: 0.882 +KVM: 0.879 +vnc: 0.864 +instruction: 0.861 +assembly: 0.852 +device: 0.850 +graphic: 0.850 +semantic: 0.848 +boot: 0.848 +network: 0.846 +socket: 0.839 + +Windows 10 fails with "Boot device inaccessible" + +The issue is happening on all versions I tried after the following commit. + +git diff af1b80ae56c9495999e8ccf7b70ef894378de642~ af1b80ae56c9495999e8ccf7b70ef894378de642 +diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c +index b7bcbbbb2a..7a5a8b3521 100644 +--- a/hw/i386/acpi-build.c ++++ b/hw/i386/acpi-build.c +@@ -1497,7 +1497,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker, + dev = aml_device("PCI0"); + aml_append(dev, aml_name_decl("_HID", aml_eisaid("PNP0A03"))); + aml_append(dev, aml_name_decl("_ADR", aml_int(0))); +- aml_append(dev, aml_name_decl("_UID", aml_int(1))); ++ aml_append(dev, aml_name_decl("_UID", aml_int(0))); + aml_append(sb_scope, dev); + aml_append(dsdt, sb_scope); + +@@ -1512,7 +1512,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker, + aml_append(dev, aml_name_decl("_HID", aml_eisaid("PNP0A08"))); + aml_append(dev, aml_name_decl("_CID", aml_eisaid("PNP0A03"))); + aml_append(dev, aml_name_decl("_ADR", aml_int(0))); +- aml_append(dev, aml_name_decl("_UID", aml_int(1))); ++ aml_append(dev, aml_name_decl("_UID", aml_int(0))); + aml_append(dev, build_q35_osc_method()); + aml_append(sb_scope, dev); + aml_append(dsdt, sb_scope); + +The virtual machine start command: +x86_64-softmmu/qemu-system-x86_64 -name guest=win10-dev,debug-threads=on -blockdev '{"driver":"file","filename":"/usr/share/OVMF/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/win10-dev_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-4.2,accel=kvm,usb=off,vmport=off,dump-guest-core=off,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-format -cpu Skylake-Client-IBRS,ss=on,vmx=on,pdcm=on,hypervisor=on,tsc-adjust=on,clflushopt=on,umip=on,md-clear=on,stibp=on,arch-capabilities=on,ssbd=on,xsaves=on,pdpe1gb=on,ibpb=on,amd-ssbd=on,skip-l1dfl-vmentry=on,pschange-mc-no=on,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff -m 6144 -overcommit mem-lock=off -smp 4,sockets=4,cores=1,threads=1 -uuid 5646e540-5022-4ace-8d6a-d7c4b61a6d3d -no-user-config -nodefaults -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -global ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 -boot strict=on -device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2 -device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 -device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 -device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 -device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4 -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 -blockdev '{"driver":"host_device","filename":"/dev/disk/by-id/scsi-1SanDisk_Extreme_SSD_20072F404043","aio":"native","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 ide-hd,bus=ide.0,drive=libvirt-2-format,id=sata0-0-0,bootindex=1,write-cache=on -device ide-cd,bus=ide.1,id=sata0-0-1 -netdev user,id=hostnet0 -device e1000e,netdev=hostnet0,id=net0,mac=52:54:00:10:5b:55,bus=pci.1,addr=0x0 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0,bus=usb.0,port=1 -spice port=5900,addr=127.0.0.1,disable-ticketing=on,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pcie.0,addr=0x1 -device ich9-intel-hda,id=sound0,bus=pcie.0,addr=0x1b -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -device virtio-balloon-pci,id=balloon0,bus=pci.4,addr=0x0 -msg timestamp=on -D ./log.txt -monitor stdio -d + +On Wed, 03 Mar 2021 05:10:51 -0000 +Nick <email address hidden> wrote: + + + +Is it happening to preexisting guest images only or to clean install as well? + + + +> ** Description changed: +> +> The issue is happening on all versions I tried after the following +> - commit. +> + commit. I can also remove this individual from master and it starts to +> + work. +> +> git diff af1b80ae56c9495999e8ccf7b70ef894378de642~ af1b80ae56c9495999e8ccf7b70ef894378de642 +> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c +> index b7bcbbbb2a..7a5a8b3521 100644 +> --- a/hw/i386/acpi-build.c +> +++ b/hw/i386/acpi-build.c +> @@ -1497,7 +1497,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker, +> - dev = aml_device("PCI0"); +> - aml_append(dev, aml_name_decl("_HID", aml_eisaid("PNP0A03"))); +> - aml_append(dev, aml_name_decl("_ADR", aml_int(0))); +> + dev = aml_device("PCI0"); +> + aml_append(dev, aml_name_decl("_HID", aml_eisaid("PNP0A03"))); +> + aml_append(dev, aml_name_decl("_ADR", aml_int(0))); +> - aml_append(dev, aml_name_decl("_UID", aml_int(1))); +> + aml_append(dev, aml_name_decl("_UID", aml_int(0))); +> - aml_append(sb_scope, dev); +> - aml_append(dsdt, sb_scope); +> - +> + aml_append(sb_scope, dev); +> + aml_append(dsdt, sb_scope); +> + +> @@ -1512,7 +1512,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker, +> - aml_append(dev, aml_name_decl("_HID", aml_eisaid("PNP0A08"))); +> - aml_append(dev, aml_name_decl("_CID", aml_eisaid("PNP0A03"))); +> - aml_append(dev, aml_name_decl("_ADR", aml_int(0))); +> + aml_append(dev, aml_name_decl("_HID", aml_eisaid("PNP0A08"))); +> + aml_append(dev, aml_name_decl("_CID", aml_eisaid("PNP0A03"))); +> + aml_append(dev, aml_name_decl("_ADR", aml_int(0))); +> - aml_append(dev, aml_name_decl("_UID", aml_int(1))); +> + aml_append(dev, aml_name_decl("_UID", aml_int(0))); +> - aml_append(dev, build_q35_osc_method()); +> - aml_append(sb_scope, dev); +> - aml_append(dsdt, sb_scope); +> + aml_append(dev, build_q35_osc_method()); +> + aml_append(sb_scope, dev); +> + aml_append(dsdt, sb_scope); +> +> The virtual machine start command: +> x86_64-softmmu/qemu-system-x86_64 -name guest=win10-dev,debug-threads=on -blockdev '{"driver":"file","filename":"/usr/share/OVMF/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/win10-dev_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-4.2,accel=kvm,usb=off,vmport=off,dump-guest-core=off,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-format -cpu Skylake-Client-IBRS,ss=on,vmx=on,pdcm=on,hypervisor=on,tsc-adjust=on,clflushopt=on,umip=on,md-clear=on,stibp=on,arch-capabilities=on,ssbd=on,xsaves=on,pdpe1gb=on,ibpb=on,amd-ssbd=on,skip-l1dfl-vmentry=on,pschange-mc-no=on,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff -m 6144 -overcommit mem-lock=off -smp 4,sockets=4,cores=1,threads=1 -uuid 5646e540-5022-4ace-8d6a-d7c4b61a6d3d -no-user-config -nodefaults -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -global ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 -boot strict=on -device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2 -device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 -device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 -device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 -device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4 -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 -blockdev '{"driver":"host_device","filename":"/dev/disk/by-id/scsi-1SanDisk_Extreme_SSD_20072F404043","aio":"native","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 ide-hd,bus=ide.0,drive=libvirt-2-format,id=sata0-0-0,bootindex=1,write-cache=on -device ide-cd,bus=ide.1,id=sata0-0-1 -netdev user,id=hostnet0 -device e1000e,netdev=hostnet0,id=net0,mac=52:54:00:10:5b:55,bus=pci.1,addr=0x0 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0,bus=usb.0,port=1 -spice port=5900,addr=127.0.0.1,disable-ticketing=on,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pcie.0,addr=0x1 -device ich9-intel-hda,id=sound0,bus=pcie.0,addr=0x1b -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -device virtio-balloon-pci,id=balloon0,bus=pci.4,addr=0x0 -msg timestamp=on -D ./log.txt -monitor stdio -d +> +> ** Description changed: +> +> The issue is happening on all versions I tried after the following +> - commit. I can also remove this individual from master and it starts to +> - work. +> + commit. I can also remove this individual change from master and it +> + starts to work. +> +> git diff af1b80ae56c9495999e8ccf7b70ef894378de642~ af1b80ae56c9495999e8ccf7b70ef894378de642 +> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c +> index b7bcbbbb2a..7a5a8b3521 100644 +> --- a/hw/i386/acpi-build.c +> +++ b/hw/i386/acpi-build.c +> @@ -1497,7 +1497,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker, +> dev = aml_device("PCI0"); +> aml_append(dev, aml_name_decl("_HID", aml_eisaid("PNP0A03"))); +> aml_append(dev, aml_name_decl("_ADR", aml_int(0))); +> - aml_append(dev, aml_name_decl("_UID", aml_int(1))); +> + aml_append(dev, aml_name_decl("_UID", aml_int(0))); +> aml_append(sb_scope, dev); +> aml_append(dsdt, sb_scope); +> +> @@ -1512,7 +1512,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker, +> aml_append(dev, aml_name_decl("_HID", aml_eisaid("PNP0A08"))); +> aml_append(dev, aml_name_decl("_CID", aml_eisaid("PNP0A03"))); +> aml_append(dev, aml_name_decl("_ADR", aml_int(0))); +> - aml_append(dev, aml_name_decl("_UID", aml_int(1))); +> + aml_append(dev, aml_name_decl("_UID", aml_int(0))); +> aml_append(dev, build_q35_osc_method()); +> aml_append(sb_scope, dev); +> aml_append(dsdt, sb_scope); +> +> The virtual machine start command: +> x86_64-softmmu/qemu-system-x86_64 -name guest=win10-dev,debug-threads=on -blockdev '{"driver":"file","filename":"/usr/share/OVMF/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/win10-dev_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-4.2,accel=kvm,usb=off,vmport=off,dump-guest-core=off,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-format -cpu Skylake-Client-IBRS,ss=on,vmx=on,pdcm=on,hypervisor=on,tsc-adjust=on,clflushopt=on,umip=on,md-clear=on,stibp=on,arch-capabilities=on,ssbd=on,xsaves=on,pdpe1gb=on,ibpb=on,amd-ssbd=on,skip-l1dfl-vmentry=on,pschange-mc-no=on,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff -m 6144 -overcommit mem-lock=off -smp 4,sockets=4,cores=1,threads=1 -uuid 5646e540-5022-4ace-8d6a-d7c4b61a6d3d -no-user-config -nodefaults -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -global ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 -boot strict=on -device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2 -device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 -device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 -device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 -device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4 -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 -blockdev '{"driver":"host_device","filename":"/dev/disk/by-id/scsi-1SanDisk_Extreme_SSD_20072F404043","aio":"native","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 ide-hd,bus=ide.0,drive=libvirt-2-format,id=sata0-0-0,bootindex=1,write-cache=on -device ide-cd,bus=ide.1,id=sata0-0-1 -netdev user,id=hostnet0 -device e1000e,netdev=hostnet0,id=net0,mac=52:54:00:10:5b:55,bus=pci.1,addr=0x0 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0,bus=usb.0,port=1 -spice port=5900,addr=127.0.0.1,disable-ticketing=on,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pcie.0,addr=0x1 -device ich9-intel-hda,id=sound0,bus=pcie.0,addr=0x1b -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -device virtio-balloon-pci,id=balloon0,bus=pci.4,addr=0x0 -msg timestamp=on -D ./log.txt -monitor stdio -d +> + + + +I haven't tried a new install. Also, Michael asked to check + git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/for_upstream +The code in question is changed there and it works fine for that existing image. + +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. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1918026 b/results/classifier/105/mistranslation/1918026 new file mode 100644 index 000000000..59faa2ac6 --- /dev/null +++ b/results/classifier/105/mistranslation/1918026 @@ -0,0 +1,53 @@ +mistranslation: 0.963 +semantic: 0.886 +other: 0.830 +graphic: 0.817 +instruction: 0.811 +device: 0.770 +network: 0.646 +vnc: 0.567 +socket: 0.540 +KVM: 0.539 +boot: 0.473 +assembly: 0.440 + +RISCV64 32-bit AMOs incorrectly simulated + +Version: qemu-riscv64 version 4.2.1 (Debian 1:4.2-3ubuntu6.14) + +test: + amomaxu.w a0, a1, (a0) + ret + +int32_t* value = -7; +EXPECT_EQ(-7, test(&value, -11)); +EXPECT_EQ(-7, value); // FAIL, saw -11 +EXPECT_EQ(-7, test(&value, -7)); +EXPECT_EQ(-7, value); // FAIL, raw -11 +EXPECT_EQ(-7, test(&value, -4)); +EXPECT_EQ(-4, value); + +test: + amomax.w a0, a1, (a0) + ret + +int32_t* value = -7; +EXPECT_EQ(-7, test(&value, -11)); +EXPECT_EQ(-7, value); +EXPECT_EQ(-7, test(&value, -7)); +EXPECT_EQ(-7, value); +EXPECT_EQ(-7, test(&value, -4)); +EXPECT_EQ(-4, value); // FAIL, saw -7 + +I suspect that trans_amo<op>_w should be using tcg_gen_atomic_fetch_<op>_i32 instead of tcg_gen_atomic_fetch_<op>_tl. + +Not as simple as _tl vs _i32. That suffix should be taking +care of the sign-extension to _tl that happens after the +operation. The size of the operation should be in the MO_TESL, +which specifies target-endian signed "long" (32-bit). + +Will investigate further. + +Flushing out the report to something that compiles, +the test case works for me using qemu 5.2. + diff --git a/results/classifier/105/mistranslation/1918149 b/results/classifier/105/mistranslation/1918149 new file mode 100644 index 000000000..1138ebfb6 --- /dev/null +++ b/results/classifier/105/mistranslation/1918149 @@ -0,0 +1,56 @@ +mistranslation: 0.940 +other: 0.893 +network: 0.738 +device: 0.734 +instruction: 0.701 +semantic: 0.637 +graphic: 0.622 +vnc: 0.565 +socket: 0.546 +boot: 0.479 +assembly: 0.476 +KVM: 0.401 + +qemu-user reports wrong fault_addr in signal handler + +When a SEGV signal occurs and si_addr of the info struct is nil, qemu still tries to translate the address from host to guest (handle_cpu_signal in accel/tcg/user-exec.c). This means, that the actual signal handler, will receive a fault_addr that is something like 0xffffffffbf709000. + +I was able to get this to happen, by branching to a non canonical address on aarch64. +I used 5.2 (commit: 553032db17). However, building from source, this only seems to happen, if I use the same configure flags as the debian build: + +../configure --static --target-list=aarch64-linux-user --disable-system --enable-trace-backends=simple --disable-linux-io-uring --disable-pie --extra-cflags="-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" --extra-ldflags="-Wl,-z,relro -Wl,--as-needed" + +Let me know, if you need more details. + +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. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1919021 b/results/classifier/105/mistranslation/1919021 new file mode 100644 index 000000000..e14941ef6 --- /dev/null +++ b/results/classifier/105/mistranslation/1919021 @@ -0,0 +1,30 @@ +mistranslation: 0.966 +device: 0.855 +network: 0.724 +graphic: 0.622 +instruction: 0.582 +socket: 0.571 +other: 0.543 +vnc: 0.529 +semantic: 0.463 +boot: 0.394 +KVM: 0.208 +assembly: 0.081 + +Confuse error message in virtio_init_region_cache() + +The error message added in commit e45da653223 to virtio_init_region_cache() +are somehow confuse: + + qemu-system-i386: Cannot map used + +It would be helpful to more explicit string, including "virtio" prefix. + + +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/230 + + diff --git a/results/classifier/105/mistranslation/1920752 b/results/classifier/105/mistranslation/1920752 new file mode 100644 index 000000000..efd1509c4 --- /dev/null +++ b/results/classifier/105/mistranslation/1920752 @@ -0,0 +1,122 @@ +mistranslation: 0.863 +other: 0.817 +device: 0.795 +semantic: 0.769 +vnc: 0.763 +assembly: 0.755 +graphic: 0.748 +KVM: 0.743 +instruction: 0.738 +network: 0.733 +boot: 0.715 +socket: 0.681 + +USB SoundCard Passthrough not working on arm64 + +Hello, + +I am virtualizing a armhf guest on a aarch64 host and was to use my Sound Blaster USB Soundcard as passthrough. + +armhf Guest is: Debian Buster +aarch64 host is a jetson nano. KVM is enabled. + +Latest qemu is built from sources. +The command I use for running is as follows: + +../qemu/build/qemu-system-aarch64 -M virt -m 2048 -smp 2 -cpu host,aarch64=off -enable-kvm \ +-kernel vmlinuz-4.19.0-14-armmp-lpae -initrd initrd.img-4.19.0-14-armmp-lpae -append 'root=/dev/vda2' \ +-device nec-usb-xhci -device usb-kbd -device usb-mouse -device usb-host,hostbus=1,hostport=2.3 -serial stdio \ +-device virtio-gpu-pci,virgl=on,xres=1600,yres=900 -display sdl,gl=on \ +-drive if=none,file=hda2.qcow2,format=qcow2,id=hd -device virtio-blk-device,drive=hd \ +-netdev user,id=mynet -device virtio-net-device,netdev=mynet \ +-bios edk2-arm-code.fd -no-reboot + + +Where are my lsusb -t shows: + +rreddy78@jetson-nano:~/Downloads$ lsusb -t +/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=tegra-xusb/4p, 5000M + |__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/4p, 5000M +/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=tegra-xusb/5p, 480M + |__ Port 2: Dev 6, If 0, Class=Hub, Driver=hub/4p, 480M + |__ Port 1: Dev 7, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M + |__ Port 1: Dev 7, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M + |__ Port 3: Dev 8, If 3, Class=Human Interface Device, Driver=usbhid, 12M + |__ Port 3: Dev 8, If 1, Class=Audio, Driver=snd-usb-audio, 12M + |__ Port 3: Dev 8, If 2, Class=Audio, Driver=snd-usb-audio, 12M + |__ Port 3: Dev 8, If 0, Class=Audio, Driver=snd-usb-audio, 12M + |__ Port 4: Dev 9, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M + +Within the VM I can see the usb as follows + +rreddy78@debian:~$ lsusb -t +/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M +/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M + |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 480M + |__ Port 2: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 480M + + +Its looks like some passthrough as but it seems like only for + + _ Port 3: Dev 8, If 3, Class=Human Interface Device, Driver=usbhid, 12M + +I am not sure if passthrough even works because this post I saw + +https://community.arm.com/developer/ip-products/system/f/embedded-forum/48031/usb-pass-through-in-qemu-command-line-for-arm-machines/168764#168764 + +Hi, do you see errors on stderr when running with "-d guest_errors"? +If so can you attach the log produced by using "-D guest_errors.log -d guest_errors"? + + +Not much. + +Here is the log + +gic_cpu_read: Bad offset fc +gic_cpu_read: Bad offset fc +virtio_mmio_write: attempt to write guest features with guest_features_sel > 0 in legacy mode +virtio_mmio_write: attempt to write guest features with guest_features_sel > 0 in legacy mode + + +This time I used it differently i.e: + +rreddy78@jetson-nano:~/debian-buster-qemu$ lsusb -s 1:8 +Bus 001 Device 008: ID 041e:324d Creative Technology, Ltd + +And + +-device usb-host,vendorid=0x041e,productid=0x324d -D guest_errors.log -d guest_errors + + + +Can you record usb traffic (add pcap=<file> to usb-host)? + +I ran it as follows: + + qemu-system-aarch64 -M virt -m 2048 -smp 2 -cpu host,aarch64=off -enable-kvm -kernel vmlinuz-4.19.0-14-armmp-lpae -initrd initrd.img-4.19.0-14-armmp-lpae -append 'root=/dev/vda2' -device nec-usb-xhci -device usb-kbd -device usb-mouse -device usb-host,pcap=test.pcap,hostbus=1,hostport=2.1 -serial stdio -device virtio-gpu-pci,virgl=on,xres=1600,yres=900 -display sdl,gl=on -drive if=none,file=hda2.qcow2,format=qcow2,id=hd -device virtio-blk-device,drive=hd -netdev user,id=mynet -device virtio-net-device,netdev=mynet -bios edk2-arm-code.fd -no-reboot + +But the pcap file is empty: + +file test.pcap +test.pcap: empty + + + + +Hello, + +You can close this bug as as a simple usb-audio switch is working fine for me: +I just added -device usb-audio and set the -device nec-usb-xhci and sound within the qemu is working fine.. + +qemu-system-aarch64 -M virt -m 2048 -smp 2 -cpu host,aarch64=off -enable-kvm -kernel vmlinuz-4.19.0-14-armmp-lpae -initrd initrd.img-4.19.0-14-armmp-lpae -append 'root=/dev/vda2' -device nec-usb-xhci,id=xhci -device usb-kbd -device usb-mouse -device usb-audio -serial stdio -device virtio-gpu-pci,virgl=on,xres=1600,yres=900 -display sdl,gl=on -drive if=none,file=hda2.qcow2,format=qcow2,id=hd -device virtio-blk-device,drive=hd -netdev user,id=mynet -device virtio-net-device,netdev=mynet -bios edk2-arm-code.fd -no-reboot + + +One more point. The solution above is not usb passthrough. +I just noticed that qemu needs to be configured for usb passthrough. I am trying that out now + +Configure with --enable-libusb + libusb libusb (for usb passthrough) + + +Closing as requested in comment #6 + diff --git a/results/classifier/105/mistranslation/1921444 b/results/classifier/105/mistranslation/1921444 new file mode 100644 index 000000000..451537d39 --- /dev/null +++ b/results/classifier/105/mistranslation/1921444 @@ -0,0 +1,128 @@ +mistranslation: 0.797 +other: 0.759 +semantic: 0.672 +graphic: 0.499 +KVM: 0.488 +vnc: 0.436 +instruction: 0.367 +assembly: 0.366 +network: 0.358 +device: 0.324 +boot: 0.183 +socket: 0.162 + +Q35 doesn't support to hot add the 2nd PCIe device to KVM guest + +KVM: https://git.kernel.org/pub/scm/virt/kvm/kvm.git branch: next, commit: 4a98623d +Qemu: https://git.qemu.org/git/qemu.git branch: master, commit: 9e2e9fe3 + +Created a KVM guest with Q35 chipset, and try to hot add 2 PCIe device to guest with qemu internal command device_add, the 1st device can be added successfully, but the 2nd device failed to hot add. + +If guest chipset is legacy i440fx, the 2 device can be added successfully. + +1. Enable VT-d in BIOS +2. load KVM modules in Linux OS: modprobe kvm; modprobe kvm_intel +3. Bind 2 device to vfio-pci + echo 0000:b1:00.0 > /sys/bus/pci/drivers/i40e/unbind + echo "8086 1572" > /sys/bus/pci/drivers/vfio-pci/new_id + echo 0000:b1:00.1 > /sys/bus/pci/drivers/i40e/unbind + echo "8086 1572" > /sys/bus/pci/drivers/vfio-pci/new_id + +4. create guest with Q35 chipset: +qemu-system-x86_64 --accel kvm -m 4096 -smp 4 -drive file=/home/rhel8.2.qcow2,if=none,id=virtio-disk0 -device virtio-blk-pci,drive=virtio-disk0 -cpu host -machine q35 -device pcie-root-port,id=root1 -daemonize + +5. hot add the 1st device to guest successfully +in guest qemu monitor "device_add vfio-pci,host=b1:00.0,id=nic0,bus=root1" +6. hot add the 2nd device to guest +in guest qemu monitor "device_add vfio-pci,host=b1:00.1,id=nic1,bus=root1" +The 2nd device doesn't be added in guest, and the 1st device is removed from guest. + +Guest partial log: +[ 110.452272] pcieport 0000:00:04.0: pciehp: Slot(0): Attention button pressed +[ 110.453314] pcieport 0000:00:04.0: pciehp: Slot(0) Powering on due to button press +[ 110.454156] pcieport 0000:00:04.0: pciehp: Slot(0): Card present +[ 110.454792] pcieport 0000:00:04.0: pciehp: Slot(0): Link Up +[ 110.580927] pci 0000:01:00.0: [8086:1572] type 00 class 0x020000 +[ 110.582560] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x007fffff 64bit pref] +[ 110.583453] pci 0000:01:00.0: reg 0x1c: [mem 0x00000000-0x00007fff 64bit pref] +[ 110.584278] pci 0000:01:00.0: reg 0x30: [mem 0x00000000-0x0007ffff pref] +[ 110.585051] pci 0000:01:00.0: Max Payload Size set to 128 (was 512, max 2048) +[ 110.586621] pci 0000:01:00.0: PME# supported from D0 D3hot D3cold +[ 110.588140] pci 0000:01:00.0: BAR 0: no space for [mem size 0x00800000 64bit pref] +[ 110.588954] pci 0000:01:00.0: BAR 0: failed to assign [mem size 0x00800000 64bit pref] +[ 110.589797] pci 0000:01:00.0: BAR 6: assigned [mem 0xfe800000-0xfe87ffff pref] +[ 110.590703] pci 0000:01:00.0: BAR 3: assigned [mem 0xfe000000-0xfe007fff 64bit pref] +[ 110.592085] pcieport 0000:00:04.0: PCI bridge to [bus 01] +[ 110.592755] pcieport 0000:00:04.0: bridge window [io 0x1000-0x1fff] +[ 110.594403] pcieport 0000:00:04.0: bridge window [mem 0xfe800000-0xfe9fffff] +[ 110.595847] pcieport 0000:00:04.0: bridge window [mem 0xfe000000-0xfe1fffff 64bit pref] +[ 110.597867] PCI: No. 2 try to assign unassigned res +[ 110.597870] release child resource [mem 0xfe000000-0xfe007fff 64bit pref] +[ 110.597871] pcieport 0000:00:04.0: resource 15 [mem 0xfe000000-0xfe1fffff 64bit pref] released +[ 110.598881] pcieport 0000:00:04.0: PCI bridge to [bus 01] +[ 110.600789] pcieport 0000:00:04.0: BAR 15: assigned [mem 0x180000000-0x180bfffff 64bit pref] +[ 110.601731] pci 0000:01:00.0: BAR 0: assigned [mem 0x180000000-0x1807fffff 64bit pref] +[ 110.602849] pci 0000:01:00.0: BAR 3: assigned [mem 0x180800000-0x180807fff 64bit pref] +[ 110.604069] pcieport 0000:00:04.0: PCI bridge to [bus 01] +[ 110.604941] pcieport 0000:00:04.0: bridge window [io 0x1000-0x1fff] +[ 110.606237] pcieport 0000:00:04.0: bridge window [mem 0xfe800000-0xfe9fffff] +[ 110.607401] pcieport 0000:00:04.0: bridge window [mem 0x180000000-0x180bfffff 64bit pref] +[ 110.653661] i40e: Intel(R) Ethernet Connection XL710 Network Driver +[ 110.654443] i40e: Copyright (c) 2013 - 2019 Intel Corporation. +[ 110.655314] i40e 0000:01:00.0: enabling device (0140 -> 0142) +[ 110.672396] i40e 0000:01:00.0: fw 6.0.48442 api 1.7 nvm 6.01 0x800035b1 1.1747.0 [8086:1572] [8086:0008] +[ 110.750054] i40e 0000:01:00.0: MAC address: 3c:fd:fe:c0:59:98 +[ 110.751792] i40e 0000:01:00.0: FW LLDP is enabled +[ 110.764644] i40e 0000:01:00.0 eth1: NIC Link is Up, 10 Gbps Full Duplex, Flow Control: None +[ 110.779390] i40e 0000:01:00.0: PCI-Express: Speed 8.0GT/s Width x8 +[ 110.789841] i40e 0000:01:00.0: Features: PF-id[0] VFs: 64 VSIs: 66 QP: 4 RSS FD_ATR FD_SB NTUPLE DCB VxLAN Geneve PTP VEPA +[ 111.817553] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready +[ 205.130288] pcieport 0000:00:04.0: pciehp: Slot(0): Attention button pressed +[ 205.131743] pcieport 0000:00:04.0: pciehp: Slot(0): Powering off due to button press +[ 205.133233] pcieport 0000:00:04.0: pciehp: Slot(0): Card not present +[ 205.135728] i40e 0000:01:00.0: i40e_ptp_stop: removed PHC on eth1 + + + +You need a root port per device you want to hotplug, you cannot independently hotplug multiple devices to a PCIe link. + +Alex, thanks for you response. + +I tried to create guest with multiple root ports, but qemu report error: +# qemu-system-x86_64 --accel kvm -m 4096 -smp 4 -drive file=/home/hao/rhel8.2.qcow2,if=none,id=virtio-disk0 -device virtio-blk-pci,drive=virtio-disk0 -device virtio-net-pci,netdev=nic0,mac=00:16:3e:0d:e4:ab -netdev tap,id=nic0,br=virbr0,helper=/usr/local/libexec/qemu-bridge-helper -cpu host -machine q35 -device pcie-root-port,id=root1 -device pcie-root-port,id=root2 -daemonize +qemu-system-x86_64: -device pcie-root-port,id=root2: Can't add chassis slot, error -16 + +Is the command wrong? + +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. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1923689 b/results/classifier/105/mistranslation/1923689 new file mode 100644 index 000000000..2f608ee04 --- /dev/null +++ b/results/classifier/105/mistranslation/1923689 @@ -0,0 +1,101 @@ +mistranslation: 0.845 +other: 0.832 +KVM: 0.794 +instruction: 0.785 +network: 0.774 +device: 0.770 +boot: 0.755 +socket: 0.754 +vnc: 0.751 +graphic: 0.751 +assembly: 0.749 +semantic: 0.705 + +sig-abort / coredump observed from aio_ctx_finalize + +Observing occasional sig-abort based on v5.2.0 (tag) of QEMU. The VMM is configured for Kata use case, launching with a nvdimm/pmem based rootfs, and a set of workloads which are heavily utilizing virtio-fs. + +Sample qemu-cmdline: +/usr/bin/qemu-kata-system-x86_64 +-name sandbox-9dc314445bbb2cd02e6d30126ea8355a4f8acd36c866ea32171486931dc2b99c +-uuid cd58d78d-ad44-4d26-9eab-66efab3fb23b +-machine pc,accel=kvm,kernel_irqchip,nvdimm=on +-cpu host,pmu=off +-qmp unix:/run/vc/vm/9dc314445bbb2cd02e6d30126ea8355a4f8acd36c866ea32171486931dc2b99c/qmp.sock,server,nowait +-m 2048M,slots=10,maxmem=386381M +-device pci-bridge,bus=pci.0,id=pci-bridge-0,chassis_nr=1,shpc=on,addr=2,romfile= +-device virtio-serial-pci,disable-modern=false,id=serial0,romfile=,max_ports=2 +-device virtconsole,chardev=charconsole0,id=console0 +-chardev socket,id=charconsole0,path=/run/vc/vm/9dc314445bbb2cd02e6d30126ea8355a4f8acd36c866ea32171486931dc2b99c/console.sock,server,nowait +-device nvdimm,id=nv0,memdev=mem0 +-object memory-backend-file,id=mem0,mem-path=/usr/share/kata-containers/kata-containers.img,size=536870912 +-object rng-random,id=rng0,filename=/dev/urandom +-device virtio-rng-pci,rng=rng0,romfile= +-device vhost-vsock-pci,disable-modern=false,vhostfd=3,id=vsock-3054067214,guest-cid=3054067214,romfile= +-chardev socket,id=char-770bb156466e8ed5,path=/run/vc/vm/9dc314445bbb2cd02e6d30126ea8355a4f8acd36c866ea32171486931dc2b99c/vhost-fs.sock +-device vhost-user-fs-pci,chardev=char-770bb156466e8ed5,tag=kataShared,romfile= +-netdev tap,id=network-0,vhost=on,vhostfds=4,fds=5 +-device driver=virtio-net-pci,netdev=network-0,mac=9e:ad:0c:d1:58:e0,disable-modern=false,mq=on,vectors=4,romfile= +-rtc base=utc,driftfix=slew,clock=host +-global kvm-pit.lost_tick_policy=discard +-vga none +-no-user-config +-nodefaults +-nographic +--no-reboot +-daemonize +-object memory-backend-file,id=dimm1,size=2048M,mem-path=/dev/shm,share=on +-numa node,memdev=dimm1 +-kernel /usr/share/kata-containers/vmlinuz +-append tsc=reliable no_timer_check rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp reboot=k console=hvc0 console=hvc1 cryptomgr.notests net.ifnames=0 pci=lastbus=0 root=/dev/pmem0p1 rootflags=dax,data=ordered,errors=remount-ro ro rootfstype=ext4 quiet systemd.show_status=false panic=1 nr_cpus=32 systemd.unit=kata-containers.target systemd.mask=systemd-networkd.service systemd.mask=systemd-networkd.socket +-pidfile /run/vc/vm/9dc314445bbb2cd02e6d30126ea8355a4f8acd36c866ea32171486931dc2b99c/pid +-smp 1,cores=1,threads=1,sockets=32,maxcpus=32 + +From the core file I was able to obtain a backtrace: + +``` +(gdb) info thread + Id Target Id Frame + 6 Thread 0x7f92feffd700 (LWP 14678) 0x00007f93b23a0a35 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 + 5 Thread 0x7f92fffff700 (LWP 13860) 0x00007f93b23a0a35 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 + 4 Thread 0x7f930dcff700 (LWP 13572) 0x00007f93b23a0a35 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 + 3 Thread 0x7f92ff7fe700 (LWP 14179) 0x00007f93b23a0a35 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 + 2 Thread 0x7f93aed03700 (LWP 13565) 0x00007f93b20bfd19 in syscall () from /lib64/libc.so.6 +* 1 Thread 0x7f93c718dcc0 (LWP 13564) 0x00007f93b1ffd3d7 in raise () from /lib64/libc.so.6 +(gdb) bt trace +No symbol table is loaded. Use the "file" command. +(gdb) bt +#0 0x00007f93b1ffd3d7 in raise () from /lib64/libc.so.6 +#1 0x00007f93b1ffeac8 in abort () from /lib64/libc.so.6 +#2 0x00007f93b1ff61a6 in __assert_fail_base () from /lib64/libc.so.6 +#3 0x00007f93b1ff6252 in __assert_fail () from /lib64/libc.so.6 +#4 0x00000000007c6955 in aio_ctx_finalize () +#5 0x00007f93c64223d1 in g_source_unref_internal () from /lib64/libglib-2.0.so.0 +#6 0x00007f93c64225f5 in g_source_iter_next () from /lib64/libglib-2.0.so.0 +#7 0x00007f93c642362d in g_main_context_unref () from /lib64/libglib-2.0.so.0 +#8 0x00007f93c6425628 in g_main_loop_unref () from /lib64/libglib-2.0.so.0 +#9 0x00000000006dbaa0 in iothread_instance_finalize () +#10 0x00000000006c01e9 in object_unref () +#11 0x00000000006be647 in object_property_del_child () +#12 0x000000000075ad79 in monitor_cleanup () +#13 0x0000000000630635 in qemu_cleanup () +#14 0x000000000040fed3 in main () +``` + +I *think* we're hitting this assert: https://github.com/qemu/qemu/blob/master/util/async.c#L339 based on +``` +(gdb) up +#4 0x00000000007c6955 in aio_ctx_finalize () +``` + +The error is relatively infrequent, but a catastrophic core dump none the less. + +Please let me know if there's more I can pull from the core, or more info I can share to help facilitate debugging this error. + +Please install debuginfo and run "p *ctx" in GDB from the aio_ctx_finalize frame. That should show ctx->scheduled_coroutines, ctx->bh_slice_list, etc. + +Thanks to Stefan for the help -- IRL we debugged this to the following assert failure: + assert(QSIMPLEQ_EMPTY(&ctx->bh_slice_list)); + +This has been resolved upstream in https://github.com/qemu/qemu/commit/c81219a7dd36a815bd85beed9932fc973d4f5d51 + diff --git a/results/classifier/105/mistranslation/1923693 b/results/classifier/105/mistranslation/1923693 new file mode 100644 index 000000000..81ee347a0 --- /dev/null +++ b/results/classifier/105/mistranslation/1923693 @@ -0,0 +1,37 @@ +mistranslation: 0.946 +graphic: 0.701 +device: 0.607 +semantic: 0.534 +network: 0.509 +socket: 0.447 +instruction: 0.375 +vnc: 0.372 +other: 0.323 +KVM: 0.303 +assembly: 0.289 +boot: 0.276 + +Lack of architecture in gdbstub makes debugging confusing + +I spent some quality time debugging GEF and came to a conclusion here: +https://github.com/hugsy/gef/issues/598#issuecomment-819174169 + +tldr; + +* gdb_arch_name was undefined on riscv +* this bug was fixed recently via https://github.com/qemu/qemu/commit/edf647864bdab84ed4b1a4f47ea05be6bb075c69 + + +* An undefined gdb_arch_name results in qemu's gdbstub omitting the <architecture> xml. +* gdb translates a missing <architecture> as "auto" which breaks a lot of stuff. +* tracking down where "auto" comes from is a bit confusing and time consuming. + + +It might be better to report a missing / blank gdb_arch_name as "<architecture>unknown</architecture>" instead of omitting the block completely. + +Thanks for raising this. I have marked it as fixes as like you say it's fixed in mainline. + +Is there still anything left to do here? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/1925496 b/results/classifier/105/mistranslation/1925496 new file mode 100644 index 000000000..bded95267 --- /dev/null +++ b/results/classifier/105/mistranslation/1925496 @@ -0,0 +1,138 @@ +mistranslation: 0.748 +other: 0.745 +semantic: 0.720 +assembly: 0.699 +KVM: 0.680 +instruction: 0.674 +vnc: 0.668 +device: 0.653 +graphic: 0.652 +socket: 0.630 +network: 0.602 +boot: 0.588 + +nvme disk cannot be hotplugged after removal + +Hello, + +When I try to re-add an nvme disk shortly after removing it, I get an error about duplicate ID. + +See the following commands to reproduce. This happens consistently on all VMs that I tested: + + +attach +========== + +$VAR1 = { + 'arguments' => { + 'command-line' => 'drive_add auto "file=/dev/zvol/rpool/data/vm-20000-disk-1,if=none,id=drive-nvme1,format=raw,cache=none,aio=native,detect-zeroes=on"' + }, + 'execute' => 'human-monitor-command' + }; +$VAR1 = { + 'execute' => 'device_add', + 'arguments' => { + 'serial' => 'nvme1', + 'drive' => 'drive-nvme1', + 'driver' => 'nvme', + 'id' => 'nvme1' + } + }; + + +detach +=========== +$VAR1 = { + 'arguments' => { + 'id' => 'nvme1' + }, + 'execute' => 'device_del' + }; +$VAR1 = { + 'execute' => 'human-monitor-command', + 'arguments' => { + 'command-line' => 'drive_del drive-nvme1' + } + }; + +reattach +=========== +$VAR1 = { + 'arguments' => { + 'command-line' => 'drive_add auto "file=/dev/zvol/rpool/data/vm-20000-disk-1,if=none,id=drive-nvme1,format=raw,cache=none,aio=native,detect-zeroes=on"' + }, + 'execute' => 'human-monitor-command' + }; + + +and I get: +"Duplicate ID 'drive-nvme1' for drive" + +although it does not show up in query-block or query-pci anymore after the first detach. + + +Is this a bug or am I missing something? Please advise. + +Best regards, +Oguz + +Hi, + +What QEMU version is this happening on? Is this the -rc4, is it a regression? + +Hi, + +this is happening on qemu 5.2.0 + +BTW Re: Regression, I think it's not, because this didn't work a year ago either, but I wasn't sure if it's a bug. + +So, I had to investigate this a bit, since it is a part of QEMU that I'm not too familiar with. + +My understanding is that this is the expected behavior. The reason is that the drive cannot be deleted immediately when the device is hot-unplugged, since it might not be safe (other parts of QEMU could be using it, like background block jobs). + +What we *can* do, is make sure we mark the drive for auto deletion when it is safe to do so. I'll add a patch for that. + +On the other hand, the fact that if the drive is removed explicitly through QMP (or in the monitor with drive_del), the drive id is remains "in use". This might be a completely different bug that is unrelated to the nvme device. + +> My understanding is that this is the expected behavior. The reason is that the drive cannot be deleted immediately when the device is hot-unplugged, since it might not be safe (other parts of QEMU could be using it, like background block jobs). + +> On the other hand, the fact that if the drive is removed explicitly through QMP (or in the monitor with drive_del), the drive id is remains "in use". This might be a completely different bug that is unrelated to the nvme device. + +using the same commands I can hot-plug and hot-unplug a scsi disk like this without issue - this behavior only appeared on nvme devices. + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know how to transfer the bug to the new system if +(if still necessary). Thus we're setting the status to "Incomplete" now. + +In the unlikely case that 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 should be +moved to the new system, 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. + + +This issue has been moved to the new bug tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues/423 + +Thus let's close this version in the Launchpad tracker now. + diff --git a/results/classifier/105/mistranslation/1931 b/results/classifier/105/mistranslation/1931 new file mode 100644 index 000000000..ede799e23 --- /dev/null +++ b/results/classifier/105/mistranslation/1931 @@ -0,0 +1,16 @@ +mistranslation: 0.722 +device: 0.625 +semantic: 0.593 +graphic: 0.538 +other: 0.442 +network: 0.257 +vnc: 0.091 +boot: 0.083 +instruction: 0.080 +socket: 0.079 +assembly: 0.041 +KVM: 0.003 + +dbus: Support multiple QEMU instances +Additional information: +cc @marcandre.lureau diff --git a/results/classifier/105/mistranslation/194 b/results/classifier/105/mistranslation/194 new file mode 100644 index 000000000..25886f86b --- /dev/null +++ b/results/classifier/105/mistranslation/194 @@ -0,0 +1,14 @@ +mistranslation: 0.923 +device: 0.605 +graphic: 0.488 +semantic: 0.316 +other: 0.296 +instruction: 0.098 +assembly: 0.062 +vnc: 0.033 +boot: 0.030 +network: 0.028 +socket: 0.012 +KVM: 0.001 + +Qemu fails to start with error " There is no option group 'spice'" diff --git a/results/classifier/105/mistranslation/1956 b/results/classifier/105/mistranslation/1956 new file mode 100644 index 000000000..3135cb17d --- /dev/null +++ b/results/classifier/105/mistranslation/1956 @@ -0,0 +1,14 @@ +mistranslation: 0.891 +device: 0.819 +instruction: 0.595 +semantic: 0.541 +boot: 0.297 +graphic: 0.287 +network: 0.186 +vnc: 0.025 +assembly: 0.013 +socket: 0.011 +other: 0.003 +KVM: 0.001 + +[x86,microvm] Update microvm documentation with ACPI option diff --git a/results/classifier/105/mistranslation/1970 b/results/classifier/105/mistranslation/1970 new file mode 100644 index 000000000..59135bebf --- /dev/null +++ b/results/classifier/105/mistranslation/1970 @@ -0,0 +1,14 @@ +mistranslation: 0.856 +device: 0.778 +instruction: 0.575 +network: 0.574 +boot: 0.337 +graphic: 0.335 +semantic: 0.261 +vnc: 0.208 +socket: 0.171 +other: 0.171 +KVM: 0.058 +assembly: 0.056 + +A64 LDRA decode scales the immediate by wrong amount diff --git a/results/classifier/105/mistranslation/1970563 b/results/classifier/105/mistranslation/1970563 new file mode 100644 index 000000000..b4f26a20c --- /dev/null +++ b/results/classifier/105/mistranslation/1970563 @@ -0,0 +1,132 @@ +mistranslation: 0.877 +other: 0.873 +semantic: 0.870 +vnc: 0.868 +assembly: 0.839 +instruction: 0.839 +socket: 0.824 +graphic: 0.810 +KVM: 0.757 +network: 0.743 +device: 0.741 +boot: 0.613 + +Qemu 1:6.2+dfsg-2ubuntu6 deadlock bug + +There is a known bug that will cause VM deadlock, the patch should be merged and released: + +https://gitlab.com/qemu-project/qemu/-/commit/1dbbe6f172810026c51dc84ed927a3cc23017949#841723aa93098d8ab3b5068795e10ae7cf2a3179 + +That's clearly a fix for a bug, but I couldn't identify an upstream issue which describes the problem. The commit message has: + + Fixes: 0bf41cab + +but that's a reference to another commit, not to an issue. Finding original description of the bug would help identifying a test case for the SRU. + +@xp are you able to point us to the upstream bug report, or to provide steps to reproduce the issue which we can use to verify the fix? + +I'm marking this as Incomplete for now because the description of the problem is too vague, but I think this will become a valid SRU case. + +This should be the upstream bug report: +https://gitlab.com/qemu-project/qemu/-/issues/807 + + +Thanks, that report also has nice steps to reproduce. I updated the bug tags/status accordingly. + +Thanks + +From the description this bug affects Jammy and Kinetic, so I added explicit tasks for each series. + +Thanks this is great pre-work and a patch on a plate. +I was pondering if I should wait until we merge qemu 7.0 for kintic, but that would delay this too much. + +I still need to find some time, but I'll prepare and upload the fix without waiting for 7.0. + +FYI - I have prepared a PPA and merge proposals for the related Ubuntu package changes: + +PPA: https://launchpad.net/~paelzer/+archive/ubuntu/lp-1970563-vnc-deadlock +Jammy: https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/422947 +Kinetic: https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/422946 + +Thanks for the Review Sergio. + +Uploaded the fix for Kinetic. +We can start the SRU to jammy once it is complete there. + +This bug was fixed in the package qemu - 1:6.2+dfsg-2ubuntu7 + +--------------- +qemu (1:6.2+dfsg-2ubuntu7) kinetic; urgency=medium + + * d/p/u/lp-1970563-ui-vnc.c-Fixed-a-deadlock-bug.patch: avoid deadlock + in vnc connections (LP: #1970563) + + -- Christian Ehrhardt <email address hidden> Thu, 19 May 2022 08:25:20 +0200 + +Completed in Kinetic, uploaded to Jammy now - waiting for the SRU team to have a look + +Hello xp, or anyone else affected, + +Accepted qemu into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:6.2+dfsg-2ubuntu6.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-jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-jammy. 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. + +All autopkgtests for the newly accepted qemu (1:6.2+dfsg-2ubuntu6.1) for jammy have finished running. +The following regressions have been reported in tests triggered by the package: + +vagrant-mutate/1.2.0-4.1 (s390x, ppc64el) +livecd-rootfs/2.764 (arm64, ppc64el) +ubuntu-image/2.2+22.04ubuntu3 (arm64, s390x) +sbuild/0.81.2ubuntu6 (s390x, ppc64el) +edk2/2022.02-3 (armhf) +initramfs-tools/0.140ubuntu13 (amd64) +systemd/249.11-0ubuntu3.1 (ppc64el) + + +Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. + +https://people.canonical.com/~ubuntu-archive/proposed-migration/jammy/update_excuses.html#qemu + +[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions + +Thank you! + + +FYI: Autopkgtest issues resolved, but verification of the upload for the presented problem is needed. + +@XP - it is always best to do this in the original reported environment - do you think you could do that verification? + +Sure, This my test steps: +* start a qemu wit qemu vnc + qemu-system-x86_64 -vnc 127.0.0.1:0 ... + +* Connect and disconnect and connect with VNC against it (We use novnc). + +* when qemu-system-x86 1:6.2+dfsg-2ubuntu6 + occur which deadlocks qemu - no interaction is possible anymore + +* upgrade to qemu-system-x86/jammy-proposed 1:6.2+dfsg-2ubuntu6.1 + Connect and disconnect and connect, everything is ok， no more deadlock + +The bug has been fixed, thank you. + +Perfect, thank you Xiongpeng! + +The verification of the Stable Release Update for qemu 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. + +This bug was fixed in the package qemu - 1:6.2+dfsg-2ubuntu6.1 + +--------------- +qemu (1:6.2+dfsg-2ubuntu6.1) jammy; urgency=medium + + * d/p/u/lp-1970563-ui-vnc.c-Fixed-a-deadlock-bug.patch: avoid deadlock + in vnc connections (LP: #1970563) + + -- Christian Ehrhardt <email address hidden> Thu, 19 May 2022 08:25:20 +0200 + diff --git a/results/classifier/105/mistranslation/1975 b/results/classifier/105/mistranslation/1975 new file mode 100644 index 000000000..9e163bcbb --- /dev/null +++ b/results/classifier/105/mistranslation/1975 @@ -0,0 +1,50 @@ +mistranslation: 0.689 +instruction: 0.684 +network: 0.671 +device: 0.666 +semantic: 0.658 +graphic: 0.653 +other: 0.647 +assembly: 0.623 +socket: 0.570 +KVM: 0.550 +vnc: 0.518 +boot: 0.441 + +SEGV on exit: net_cleanup() frees devices it doesn't own. +Description of problem: +On exiting QEMU, the `net_cleanup()` function iterates over all existing `net_clients`, both netdevs and nics, and deletes them all. Freeing the netdevs is fine, and they are correctly detached from their peer nic as appropriate. But the nics belong to an actual device and this can cause a use-after-free or double-free. + +Mostly this doesn't happen because emulated devices *don't* bother to clean up after themselves on exit; none of their state is going to outlast the QEMU process so there's no point. But XenBus devices interact with the external XenStore and do need to perform a cleanup. The `xen_netdev_unrealize()` function calls `qemu_del_nic()` on the nic which `net_cleanup()` already stole from it, and crashes... + +``` +QEMU: Terminated + +Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. +qemu_del_nic (nic=0x55555846ab00) at ../net/net.c:451 +451 int i, queues = MAX(nic->conf->peers.queues, 1); +(gdb) bt +#0 qemu_del_nic (nic=0x55555846ab00) at ../net/net.c:451 +#1 0x0000555555a89ce3 in xen_device_unrealize (dev=<optimized out>) at ../hw/xen/xen-bus.c:973 +#2 0x0000555555e5c847 in notifier_list_notify (list=<optimized out>, data=0x0) at ../util/notify.c:39 +#3 0x00007ffff5fe51e6 in __run_exit_handlers (status=0, listp=<optimized out>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:111 +#4 0x00007ffff5fe532e in __GI_exit (status=<optimized out>) at exit.c:141 +#5 0x00007ffff5fccb91 in __libc_start_call_main (main=main@entry=0x5555558837a0 <main>, argc=argc@entry=23, argv=argv@entry=0x7fffffffd7a8) at ../sysdeps/nptl/libc_start_call_main.h:74 +#6 0x00007ffff5fccc4b in __libc_start_main_impl + (main=0x5555558837a0 <main>, argc=23, argv=0x7fffffffd7a8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffd798) at ../csu/libc-start.c:360 +#7 0x0000555555885345 in _start () +``` +Steps to reproduce: +1. Launch a Xen guest as described at https://qemu-project.gitlab.io/qemu/system/i386/xen.html (which will get a Xen NIC by default). +2. Terminate QEMU. + +It doesn't need to boot, doesn't need to do anything. Just launch a completely non-functional guest and then hit `Ctrl-a x` on the default monitor: +``` +$ ./qemu-system-x86_64 -accel kvm,xen-version=0x40010,kernel-irqchip=split -display none +QEMU: Terminated +Segmentation fault + +``` + +For `net_cleanup()` to clean up the *netdevs* makes sense, because those might have state which persists in the system after QEMU exits, and need to be cleaned up. But deleting the nics doesn't seem to be necessary. +Fix at https://lore.kernel.org/qemu-devel/61ea91785772a8138ad12b305cbd5aac4aa1e86a.camel@infradead.org diff --git a/results/classifier/105/mistranslation/1978 b/results/classifier/105/mistranslation/1978 new file mode 100644 index 000000000..8dc287089 --- /dev/null +++ b/results/classifier/105/mistranslation/1978 @@ -0,0 +1,18 @@ +mistranslation: 0.874 +device: 0.855 +other: 0.837 +vnc: 0.809 +instruction: 0.791 +graphic: 0.778 +network: 0.694 +socket: 0.635 +semantic: 0.524 +boot: 0.385 +KVM: 0.146 +assembly: 0.108 + +sifive_e : erroneous CLINT frequency +Description of problem: +CLINT's `mtime` updates at a clock frequency of [10 MHz](https://gitlab.com/qemu-project/qemu/-/blob/master/hw/riscv/sifive_e.c?ref_type=heads#L228), whereas [SiFive documentation](https://cdn.sparkfun.com/assets/7/f/0/2/7/fe310-g002-manual-v19p05.pdf?_gl=1*w2ieef*_ga*MTcyNDI2MjM0Ny4xNjk2ODcwNTM3*_ga_T369JS7J9N*MTY5Njg3MDUzNy4xLjAuMTY5Njg3MDUzNy42MC4wLjA.) shows that its clock frequency is 32.768 kHz (i.e., the RTC clock). + +This difference leads to unexpected timing behavior. Due to the difference, it can even trigger multiple nested interrupts as the IRQ routine is not able to return before a new timer interrupt is triggered. diff --git a/results/classifier/105/mistranslation/1982 b/results/classifier/105/mistranslation/1982 new file mode 100644 index 000000000..1603de6ae --- /dev/null +++ b/results/classifier/105/mistranslation/1982 @@ -0,0 +1,22 @@ +mistranslation: 0.935 +graphic: 0.891 +boot: 0.840 +device: 0.793 +instruction: 0.685 +socket: 0.680 +semantic: 0.666 +network: 0.538 +vnc: 0.491 +other: 0.356 +assembly: 0.094 +KVM: 0.058 + +PS/2 mouse and keyboard not disabled when adding USB devices +Description of problem: +Documentation (such as https://www.qemu.org/docs/master/system/qemu-manpage.html or https://www.qemu.org/docs/master/system/devices/usb.html) says that enabling a USB keyboard or mouse (or tablet) will disable the PS/2 equivalent, but it seems both are present instead. +Steps to reproduce: +1. Pass a `-usbdevice` or `-device` option to QEMU. +2. Boot Haiku. +3. Find two identical devices in Preferences > Input, both `Extended PS/2 Mouse 1` and `USB Tablet 1`, as well as `AT Keyboard 1` and `USB Keyboard 1`. +Additional information: +The content of /var/log/syslog, which shows discovery of PS/2 devices: [syslog.zst](/uploads/7ed067538c94edfdbaf35ec92a422c68/syslog.zst) diff --git a/results/classifier/105/mistranslation/1995 b/results/classifier/105/mistranslation/1995 new file mode 100644 index 000000000..651ae3cd4 --- /dev/null +++ b/results/classifier/105/mistranslation/1995 @@ -0,0 +1,14 @@ +mistranslation: 0.977 +other: 0.902 +semantic: 0.699 +device: 0.469 +graphic: 0.277 +instruction: 0.215 +boot: 0.183 +assembly: 0.107 +KVM: 0.054 +vnc: 0.036 +socket: 0.017 +network: 0.008 + +No equivalent of `-boot once` for `bootindex` diff --git a/results/classifier/105/mistranslation/1999 b/results/classifier/105/mistranslation/1999 new file mode 100644 index 000000000..747ee2db2 --- /dev/null +++ b/results/classifier/105/mistranslation/1999 @@ -0,0 +1,64 @@ +mistranslation: 0.889 +other: 0.877 +graphic: 0.854 +KVM: 0.848 +assembly: 0.844 +instruction: 0.842 +device: 0.807 +semantic: 0.794 +network: 0.770 +boot: 0.764 +vnc: 0.753 +socket: 0.742 + +qemu got sigabrt when using vpp in guest and dpdk for qemu +Description of problem: +When set the interface up in vpp, the qemu process is crashed with signal sigabrt. + +After some debug, i have identified that the problem lies in the following function. + +```c +static int setup_routing_entry(struct kvm *kvm, + struct kvm_irq_routing_table *rt, + struct kvm_kernel_irq_routing_entry *e, + const struct kvm_irq_routing_entry *ue) +{ + struct kvm_kernel_irq_routing_entry *ei; + int r; + u32 gsi = array_index_nospec(ue->gsi, KVM_MAX_IRQ_ROUTES); + + /* + * Do not allow GSI to be mapped to the same irqchip more than once. + * Allow only one to one mapping between GSI and non-irqchip routing. + */ + hlist_for_each_entry(ei, &rt->map[gsi], link) + if (ei->type != KVM_IRQ_ROUTING_IRQCHIP || + ue->type != KVM_IRQ_ROUTING_IRQCHIP || + ue->u.irqchip.irqchip == ei->irqchip.irqchip) + return -EINVAL; + +``` + +I added some debug printk like following + +```c + hlist_for_each_entry(ei, &rt->map[gsi], link) + if (ei->type != KVM_IRQ_ROUTING_IRQCHIP || + ue->type != KVM_IRQ_ROUTING_IRQCHIP || + ue->u.irqchip.irqchip == ei->irqchip.irqchip){ + printk("ei->type: %u, KVM_IRQ_ROUTING_IRQCHIP: %u, ue->type: %u, ue->u.irqchip.irqchip: %u , ei->irqchip.irqchip: %u", ei->type, KVM_IRQ_ROUTING_IRQCHIP , ue->type, ue->u.irqchip.irqchip , ei->irqchip.irqchip); + return -EINVAL; + } +``` + +Then i got following in dmesg + +``` +[Thu Nov 23 09:29:10 2023] ei->type: 2, KVM_IRQ_ROUTING_IRQCHIP: 1, ue->type: 1, ue->u.irqchip.irqchip: 2 , ei->irqchip.irqchip: 4276097024 +[Thu Nov 23 09:29:10 2023] ei->type: 2, KVM_IRQ_ROUTING_IRQCHIP: 1, ue->type: 1, ue->u.irqchip.irqchip: 2 , ei->irqchip.irqchip: 4276097024 +``` +Steps to reproduce: +This is a kube-ovn + dpdk env, not easy to reproduce now.. +Additional information: +* I also file a bug on kernel.org: https://bugzilla.kernel.org/show_bug.cgi?id=218177 +* the libvirt xml file is also attached [instance.xml](/uploads/05b391046fdc1263fd7e63bcfab6f4fb/instance.xml) diff --git a/results/classifier/105/mistranslation/2005 b/results/classifier/105/mistranslation/2005 new file mode 100644 index 000000000..10665dc4c --- /dev/null +++ b/results/classifier/105/mistranslation/2005 @@ -0,0 +1,42 @@ +mistranslation: 0.736 +other: 0.670 +vnc: 0.658 +KVM: 0.650 +instruction: 0.611 +device: 0.611 +graphic: 0.596 +semantic: 0.570 +socket: 0.540 +assembly: 0.535 +network: 0.512 +boot: 0.500 + +qemu-system-aarch64: ../target/arm/helper.c:6757: sve_vqm1_for_el_sm: Assertion `sm' failed. +Description of problem: +Qemu crashes when sve is completely disabled for CPU model "max" (`-cpu max,sve=off`). Using any CPU model which does not include SVE, or using only e.g. SVE128 (`-cpu max,sve128=on`) works fine.\ +\ +`#0 0x00007f94b8291dec in __pthread_kill_implementation () at /lib64/libc.so.6 `\ +`#1 0x00007f94b823f0c6 in raise () at /lib64/libc.so.6 `\ +`#2 0x00007f94b82268d7 in abort () at /lib64/libc.so.6 `\ +`#3 0x00007f94b82267eb in _nl_load_domain.cold () at /lib64/libc.so.6 `\ +`#4 0x00007f94b8237016 in () at /lib64/libc.so.6 `\ +`#5 0x000055d6794aa698 in sve_vqm1_for_el_sm (env=env@entry=0x55d67c6ff9b0, el=el@entry=1, sm=false) at ../target/arm/helper.c:6757 `\ +`#6 0x000055d6794afc29 in sve_vqm1_for_el (el=1, env=0x55d67c6ff9b0) at ../target/arm/helper.c:6763 `\ +`#7 smcr_write (env=0x55d67c6ff9b0, ri=0x55d67c78f600, value=<optimized out>) at ../target/arm/helper.c:6887 `\ +`#8 0x00007f9469bad101 in code_gen_buffer () `\ +`#9 0x000055d67977dc19 in cpu_tb_exec (cpu=cpu@entry=0x55d67c6fd1f0, itb=<optimized out>, tb_exit=tb_exit@entry=0x7f94acdcc4c4) at ../accel/tcg/cpu-exec.c:457 `\ +`#10 0x000055d67977e59f in cpu_loop_exec_tb (tb_exit=0x7f94acdcc4c4, last_tb=<synthetic pointer>, pc=<optimized out>, tb=<optimized out>, cpu=<optimized out>) at ../accel/tcg/cpu-exec.c:919 `\ +`#11 cpu_exec_loop (cpu=cpu@entry=0x55d67c6fd1f0, sc=sc@entry=0x7f94acdcc570) at ../accel/tcg/cpu-exec.c:1040 `\ +`#12 0x000055d67977ee7d in cpu_exec_setjmp (cpu=0x55d67c6fd1f0, sc=0x7f94acdcc570) at ../accel/tcg/cpu-exec.c:1057 `\ +`#13 0x000055d679787c3d in cpu_exec (cpu=0x55d67c6fd1f0) at ../accel/tcg/cpu-exec.c:1083 `\ +`#14 0x000055d6797a1d52 in tcg_cpus_exec (cpu=0x55d67c6fd1f0) at ../accel/tcg/tcg-accel-ops.c:75 `\ +`#15 mttcg_cpu_thread_fn (arg=arg@entry=0x55d67c6fd1f0) at ../accel/tcg/tcg-accel-ops-mttcg.c:95 `\ +`#16 0x000055d679938698 in qemu_thread_start (args=0x55d67c7a1500) at ../util/qemu-thread-posix.c:541 `\ +`#17 0x00007f94b828ff44 in start_thread () at /lib64/libc.so.6 `\ +`#18 0x00007f94b8318314 in clone () at /lib64/``libc.so``.6`\ + \ +This happens when the system is booting, i.e. grub has just finished, loaded kernel and initrd, and the kernel has just began to run, i.e. early in the kernel startup. +Steps to reproduce: +1. +2. +3. diff --git a/results/classifier/105/mistranslation/2053 b/results/classifier/105/mistranslation/2053 new file mode 100644 index 000000000..ebcbb48ce --- /dev/null +++ b/results/classifier/105/mistranslation/2053 @@ -0,0 +1,14 @@ +mistranslation: 0.899 +device: 0.883 +graphic: 0.741 +network: 0.358 +instruction: 0.349 +semantic: 0.337 +other: 0.273 +vnc: 0.178 +assembly: 0.127 +boot: 0.020 +socket: 0.019 +KVM: 0.019 + +virtio is broken in qemu-system-arm diff --git a/results/classifier/105/mistranslation/2054 b/results/classifier/105/mistranslation/2054 new file mode 100644 index 000000000..a259e818b --- /dev/null +++ b/results/classifier/105/mistranslation/2054 @@ -0,0 +1,55 @@ +mistranslation: 0.726 +graphic: 0.601 +other: 0.587 +semantic: 0.549 +vnc: 0.515 +instruction: 0.492 +KVM: 0.459 +device: 0.436 +boot: 0.422 +socket: 0.406 +assembly: 0.399 +network: 0.395 + +chacha20-s390 broken in 8.2.0 in TCG on s390x +Description of problem: +When running linux guest in qemu-system-s390x in TCG mode, it fails at selftests of crypto algorithms, namely at chacha20: +``` +[ 10.546690] alg: skcipher: chacha20-s390 encryption test failed (wrong result) on test vector 1, cfg="in-place (one sglist)" +[ 10.546914] alg: self-tests for chacha20 using chacha20-s390 failed (rc=-22) +[ 10.546969] ------------[ cut here ]------------ +[ 10.546998] alg: self-tests for chacha20 using chacha20-s390 failed (rc=-22) +[ 10.547182] WARNING: CPU: 1 PID: 109 at crypto/testmgr.c:5936 alg_test+0x55a/0x5b8 +[ 10.547510] Modules linked in: net_failover chacha_s390(+) libchacha virtio_blk(+) failover +[ 10.547854] CPU: 1 PID: 109 Comm: cryptomgr_test Not tainted 6.5.0-5-s390x #1 Debian 6.5.13-1 +[ 10.548002] Hardware name: QEMU 8561 QEMU (KVM/Linux) +[ 10.548101] Krnl PSW : 0704c00180000000 00000000005df8fe (alg_test+0x55e/0x5b8) +[ 10.548207] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3 +[ 10.548291] Krnl GPRS: 0000000000000000 0000000001286408 00000000005df8fa 0000000001286408 +[ 10.548337] 000000000014bf14 00000000001c6ba8 0000000001838b3c 0000000000000005 +[ 10.548475] 00000000025a4880 00000000025a4800 ffffffffffffffea 00000000ffffffea +[ 10.548521] 000000003e649200 00000000ffffffff 00000000005df8fa 000003800016bcf8 +[ 10.549504] Krnl Code: 00000000005df8ee: c020003b5828 larl %r2,0000000000d4a93e +[ 10.549504] 00000000005df8f4: c0e5ffdb62d2 brasl %r14,000000000014be98 +[ 10.549504] #00000000005df8fa: af000000 mc 0,0 +[ 10.549504] >00000000005df8fe: a7f4fee6 brc 15,00000000005df6ca +[ 10.549504] 00000000005df902: b9040042 lgr %r4,%r2 +[ 10.549504] 00000000005df906: b9040039 lgr %r3,%r9 +[ 10.549504] 00000000005df90a: c020003b57df larl %r2,0000000000d4a8c8 +[ 10.549504] 00000000005df910: 18bd lr %r11,%r13 +[ 10.550004] Call Trace: +[ 10.550375] [<00000000005df8fe>] alg_test+0x55e/0x5b8 +[ 10.550467] ([<00000000005df8fa>] alg_test+0x55a/0x5b8) +[ 10.550489] [<00000000005d9fbc>] cryptomgr_test+0x34/0x60 +[ 10.550514] [<000000000017d004>] kthread+0x124/0x130 +[ 10.550539] [<0000000000103124>] __ret_from_fork+0x3c/0x50 +[ 10.550562] [<0000000000b1dfca>] ret_from_fork+0xa/0x30 +[ 10.550611] Last Breaking-Event-Address: +[ 10.550626] [<000000000014bf20>] __warn_printk+0x88/0x110 +[ 10.550723] ---[ end trace 0000000000000000 ]--- +``` +An interesting issue here - it does not happen on, say, amd64 host running qemu-system-s390x, but happens on s390x host. I haven't tried other hosts though. + +Bisection points at v8.1.0-2627-gab84dc398b commit, "tcg/optimize: Optimize env memory operations". + +https://lore.kernel.org/qemu-devel/d5e8f88b-1d19-4e00-8dc2-b20e0cd34931@tls.msk.ru/T/#u is the original report on qemu-devel. diff --git a/results/classifier/105/mistranslation/2062 b/results/classifier/105/mistranslation/2062 new file mode 100644 index 000000000..4f728ac79 --- /dev/null +++ b/results/classifier/105/mistranslation/2062 @@ -0,0 +1,14 @@ +mistranslation: 0.667 +device: 0.632 +graphic: 0.594 +network: 0.506 +other: 0.357 +boot: 0.331 +instruction: 0.235 +socket: 0.209 +semantic: 0.207 +vnc: 0.136 +assembly: 0.037 +KVM: 0.008 + +qemu-img snapshot -l output formatting is broken (field to small / whitespace missing) diff --git a/results/classifier/105/mistranslation/2076 b/results/classifier/105/mistranslation/2076 new file mode 100644 index 000000000..99c863a53 --- /dev/null +++ b/results/classifier/105/mistranslation/2076 @@ -0,0 +1,14 @@ +mistranslation: 0.849 +device: 0.647 +network: 0.516 +instruction: 0.503 +socket: 0.416 +graphic: 0.252 +vnc: 0.144 +boot: 0.140 +semantic: 0.121 +other: 0.061 +KVM: 0.029 +assembly: 0.005 + +stringop-overread warning in tests/tcg/multiarch/sha1.c diff --git a/results/classifier/105/mistranslation/2077 b/results/classifier/105/mistranslation/2077 new file mode 100644 index 000000000..a1b2391f3 --- /dev/null +++ b/results/classifier/105/mistranslation/2077 @@ -0,0 +1,14 @@ +mistranslation: 0.766 +device: 0.645 +graphic: 0.531 +network: 0.468 +other: 0.328 +boot: 0.238 +semantic: 0.196 +instruction: 0.134 +socket: 0.082 +vnc: 0.067 +assembly: 0.024 +KVM: 0.014 + +flaky CI test: acpiBitsTest.test_acpi_smbios_bits diff --git a/results/classifier/105/mistranslation/2084 b/results/classifier/105/mistranslation/2084 new file mode 100644 index 000000000..33721ab85 --- /dev/null +++ b/results/classifier/105/mistranslation/2084 @@ -0,0 +1,14 @@ +mistranslation: 0.861 +device: 0.712 +semantic: 0.586 +graphic: 0.387 +instruction: 0.288 +other: 0.226 +network: 0.177 +assembly: 0.116 +boot: 0.050 +KVM: 0.027 +vnc: 0.022 +socket: 0.006 + +"qemu-system-arm -machine virt -cpu cortex-a9" error message includes a lot of "(null)"s diff --git a/results/classifier/105/mistranslation/209 b/results/classifier/105/mistranslation/209 new file mode 100644 index 000000000..1f3fcff7e --- /dev/null +++ b/results/classifier/105/mistranslation/209 @@ -0,0 +1,14 @@ +mistranslation: 0.545 +graphic: 0.385 +device: 0.304 +instruction: 0.279 +assembly: 0.266 +semantic: 0.169 +vnc: 0.073 +other: 0.044 +network: 0.040 +boot: 0.023 +KVM: 0.011 +socket: 0.007 + +the version number of qemu 6.0.0 is still 5.2.0 diff --git a/results/classifier/105/mistranslation/2120 b/results/classifier/105/mistranslation/2120 new file mode 100644 index 000000000..bdac5f433 --- /dev/null +++ b/results/classifier/105/mistranslation/2120 @@ -0,0 +1,14 @@ +mistranslation: 0.826 +network: 0.532 +semantic: 0.528 +device: 0.466 +vnc: 0.104 +socket: 0.092 +boot: 0.082 +other: 0.070 +instruction: 0.048 +graphic: 0.043 +assembly: 0.025 +KVM: 0.014 + +arm64: Typo in isar_feature_aa64_tidcp1 diff --git a/results/classifier/105/mistranslation/2121 b/results/classifier/105/mistranslation/2121 new file mode 100644 index 000000000..e361558b8 --- /dev/null +++ b/results/classifier/105/mistranslation/2121 @@ -0,0 +1,14 @@ +mistranslation: 0.600 +instruction: 0.489 +device: 0.474 +semantic: 0.359 +graphic: 0.323 +vnc: 0.317 +socket: 0.239 +network: 0.150 +boot: 0.083 +assembly: 0.075 +KVM: 0.019 +other: 0.015 + +tests/qtest/ahci-test.c:89:verify_state: assertion failed (ahci_fingerprint == ahci->fingerprint): (0xe0000000 == 0x29228086) diff --git a/results/classifier/105/mistranslation/2130 b/results/classifier/105/mistranslation/2130 new file mode 100644 index 000000000..e43facefb --- /dev/null +++ b/results/classifier/105/mistranslation/2130 @@ -0,0 +1,14 @@ +mistranslation: 0.980 +other: 0.411 +semantic: 0.396 +graphic: 0.234 +device: 0.188 +KVM: 0.144 +instruction: 0.119 +vnc: 0.118 +network: 0.074 +assembly: 0.070 +boot: 0.064 +socket: 0.052 + +latest code missing "singlestep" diff --git a/results/classifier/105/mistranslation/2184 b/results/classifier/105/mistranslation/2184 new file mode 100644 index 000000000..0e6f69412 --- /dev/null +++ b/results/classifier/105/mistranslation/2184 @@ -0,0 +1,66 @@ +mistranslation: 0.831 +graphic: 0.829 +instruction: 0.779 +other: 0.743 +semantic: 0.735 +KVM: 0.730 +assembly: 0.724 +device: 0.713 +vnc: 0.674 +network: 0.673 +socket: 0.661 +boot: 0.642 + +NVMe differences between QEMU v4.1.0 and v8.2.1 +Description of problem: +We are currently upgrading QEMU from v4.1.0 to v8.2.1. In order to keep compatibility between the two QEMUs, we are adding ``-machine pc-q35-4.1``. One of our test is to ensure a guest that has hibernated on the previous QEMU is able to resume on the new one. + +When resuming, we get the following error: + +``` +[ 7.394709] nvme nvme0: Device not ready; aborting reset, CSTS=0x1 +[ 7.926188] nvme nvme0: Device not ready; aborting reset, CSTS=0x1 +[ 7.938235] Read-error on swap-device (259:0:4874880) +[ 7.938237] Read-error on swap-device (259:0:4620184) +[ 7.938240] Read-error on swap-device (259:0:5536464) +[ 7.938311] Read-error on swap-device (259:0:5006840) +[ 7.938316] Read-error on swap-device (259:0:5791888) +[ 7.938386] Read-error on swap-device (259:0:6579728) +[ 7.938391] Read-error on swap-device (259:0:5536680) +[ 7.938431] Read-error on swap-device (259:0:4877384) +[ 7.938434] Read-error on swap-device (259:0:5005376) +[ 7.938457] Read-error on swap-device (259:0:5269328) +[ 7.939200] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:1: reading directory lblock 0 +[ 7.939267] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:1: reading directory lblock 0 +[ 7.946359] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:1: reading directory lblock 0 +[ 8.063186] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:1: reading directory lblock 0 +[ 8.069556] Aborting journal on device nvme0n1p1-8. +[ 8.069561] Buffer I/O error on dev nvme0n1p1, logical block 262144, lost sync page write +[ 8.069564] JBD2: Error -5 detected when updating journal superblock for nvme0n1p1-8. +[ 8.081218] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:1: reading directory lblock 0 +[ 8.081242] Buffer I/O error on dev nvme0n1p1, logical block 0, lost sync page write +[ 8.081247] EXT4-fs (nvme0n1p1): I/O error while writing superblock +[ 8.147693] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:1: reading directory lblock 0 +[ 8.147753] Buffer I/O error on dev nvme0n1p1, logical block 0, lost sync page write +[ 8.163478] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:1: reading directory lblock 0 +[ 8.174179] EXT4-fs (nvme0n1p1): I/O error while writing superblock +[ 8.198741] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:2: reading directory lblock 0 +[ 8.214483] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:1: reading directory lblock 0 +[ 8.230322] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:2: reading directory lblock 0 +[ 8.246249] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b +[ 8.246269] Core dump to |/usr/share/apport/apport pipe failed +[ 8.246291] Core dump to |/usr/share/apport/apport pipe failed +[ 8.246336] Core dump to |/usr/share/apport/apport pipe failed +[ 8.246826] Core dump to |/usr/share/apport/apport pipe failed +[ 8.249232] Core dump to |/usr/share/apport/apport pipe failed +[ 8.249320] Core dump to |/usr/share/apport/apport pipe failed +[ 8.249880] Core dump to |/usr/share/apport/apport pipe failed +``` + +Digging throw the NVMe code, I have found one [patch](https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg04202.html) changing the BAR layout. It doesn't look like there is a way to select the previous BAR layout. + +When selecting the ``-machine``, I was expecting that the underlying HW (including devices) would not change. Can you clarify if hibernating from QEMU A and resuming to QEMU B is meant to be supported? +Steps to reproduce: +1. Start the guest with qemu v4.1.0 and an NVME disk +2. Hibernate the OS +3. Resume the guest with qemu v8.2.1 diff --git a/results/classifier/105/mistranslation/2197 b/results/classifier/105/mistranslation/2197 new file mode 100644 index 000000000..e3fb407e0 --- /dev/null +++ b/results/classifier/105/mistranslation/2197 @@ -0,0 +1,71 @@ +mistranslation: 0.853 +graphic: 0.815 +socket: 0.794 +instruction: 0.781 +device: 0.681 +other: 0.396 +network: 0.366 +semantic: 0.360 +assembly: 0.330 +boot: 0.302 +vnc: 0.233 +KVM: 0.040 + +qemu user space emulator handles syscall `setsockopt()` with `optlen=0` incorrectly +Description of problem: +Note that despite I have only tested with the parameters/environments above, this problem probably **affects ALL architectures on Linux**. + +When user program calls `setsockopt(fd, SOL_ALG, ALG_SET_KEY, NULL, 0)`, qemu intercepts the syscall and returns `-1` with `errno = ENOMEM`, which should have completed successfully returning zero. +Steps to reproduce: +1. compile this code to binary executable: +```c +#include <unistd.h> +#include <sys/types.h> +#include <sys/socket.h> +#include <stdio.h> +#include <stdlib.h> +#include <string.h> +#include <linux/if_alg.h> + +int create_alg(const char *alg) +{ + struct sockaddr_alg salg; + int sk; + + sk = socket(PF_ALG, SOCK_SEQPACKET | SOCK_CLOEXEC, 0); + if (sk < 0) + return -1; + + memset(&salg, 0, sizeof(salg)); + salg.salg_family = AF_ALG; + strcpy((char *) salg.salg_type, "hash"); + strcpy((char *) salg.salg_name, alg); + + if (bind(sk, (struct sockaddr *) &salg, sizeof(salg)) < 0) { + close(sk); + return -1; + } + + return sk; +} + +int main() { + int fd = create_alg("hmac(sha1)"); + char buf[10]; + int ret = setsockopt(fd, SOL_ALG, ALG_SET_KEY, NULL, 0); + if(ret < 0){ + perror("err"); + } + else{ + puts("SUCCESS!"); + } + return 0; +} +``` +2. run it in any qemu user space emulator + +On real Linux kernel, this program outputs a `SUCCESS!` while in qemu it prints `err: Cannot allocate memory`. + +The error is neither informative nor intuitive and could be misleading for user programs. +Additional information: +I already have a patch which fixes the issue and I'm willing to send it to mailing list as soon as I have done the testing. diff --git a/results/classifier/105/mistranslation/2203 b/results/classifier/105/mistranslation/2203 new file mode 100644 index 000000000..e96d5907a --- /dev/null +++ b/results/classifier/105/mistranslation/2203 @@ -0,0 +1,14 @@ +mistranslation: 0.969 +device: 0.865 +graphic: 0.540 +boot: 0.517 +network: 0.389 +other: 0.353 +semantic: 0.322 +vnc: 0.191 +instruction: 0.139 +socket: 0.090 +assembly: 0.015 +KVM: 0.006 + +RISC-V RVV fractional LMUL check is wrong diff --git a/results/classifier/105/mistranslation/2214 b/results/classifier/105/mistranslation/2214 new file mode 100644 index 000000000..9a0a93bfd --- /dev/null +++ b/results/classifier/105/mistranslation/2214 @@ -0,0 +1,14 @@ +mistranslation: 0.899 +device: 0.886 +other: 0.656 +semantic: 0.611 +network: 0.587 +instruction: 0.215 +graphic: 0.198 +vnc: 0.108 +boot: 0.054 +assembly: 0.048 +socket: 0.046 +KVM: 0.007 + +QEMU gdbstub does not report SIGALRM diff --git a/results/classifier/105/mistranslation/222 b/results/classifier/105/mistranslation/222 new file mode 100644 index 000000000..46219156f --- /dev/null +++ b/results/classifier/105/mistranslation/222 @@ -0,0 +1,14 @@ +mistranslation: 0.958 +device: 0.565 +semantic: 0.510 +graphic: 0.501 +other: 0.441 +network: 0.284 +instruction: 0.234 +KVM: 0.169 +socket: 0.133 +boot: 0.126 +vnc: 0.107 +assembly: 0.101 + +Reading /proc/self/task/<pid>/maps is not remapped to the target diff --git a/results/classifier/105/mistranslation/2227 b/results/classifier/105/mistranslation/2227 new file mode 100644 index 000000000..3816b1d44 --- /dev/null +++ b/results/classifier/105/mistranslation/2227 @@ -0,0 +1,49 @@ +mistranslation: 0.478 +KVM: 0.443 +other: 0.419 +graphic: 0.365 +vnc: 0.363 +instruction: 0.359 +device: 0.347 +assembly: 0.291 +boot: 0.291 +semantic: 0.290 +network: 0.261 +socket: 0.258 + +Crash when using the ast2600-a3 device with the "virt" aarch64 machine +Description of problem: +QEMU crashes with a segmentation fault when trying to use the "ast2600-a3" device with the "virt" machine. +Steps to reproduce: +1. Run ``./qemu-system-aarch64 -display none -machine virt -device ast2600-a3`` +Additional information: +Backtrace indicates that it is crashing in the aspeed_soc_ast2600_realize() function: + +``` +#0 memory_region_update_container_subregions (subregion=0x555558c4b630) at ../../devel/qemu/system/memory.c:2637 +#1 memory_region_add_subregion_common (mr=<optimized out>, offset=<optimized out>, subregion=0x555558c4b630) at ../../devel/qemu/system/memory.c:2661 +#2 0x0000555555d1bd40 in aspeed_soc_ast2600_realize (dev=<optimized out>, errp=0x7fffffffd870) at ../../devel/qemu/hw/arm/aspeed_ast2600.c:301 +#3 0x0000555555ff26ab in device_set_realized (obj=<optimized out>, value=<optimized out>, errp=0x7fffffffda00) at ../../devel/qemu/hw/core/qdev.c:510 +#4 0x0000555555ff6edd in property_set_bool (obj=0x555558c4b360, v=<optimized out>, name=<optimized out>, opaque=0x555557cd5b50, errp=0x7fffffffda00) + at ../../devel/qemu/qom/object.c:2358 +#5 0x0000555555ffa25b in object_property_set (obj=obj@entry=0x555558c4b360, name=name@entry=0x5555563794ed "realized", v=v@entry=0x555558ce0650, errp=errp@entry=0x7fffffffda00) + at ../../devel/qemu/qom/object.c:1472 +#6 0x0000555555ffdb9f in object_property_set_qobject + (obj=obj@entry=0x555558c4b360, name=name@entry=0x5555563794ed "realized", value=value@entry=0x555558cdf270, errp=errp@entry=0x7fffffffda00) + at ../../devel/qemu/qom/qom-qobject.c:28 +#7 0x0000555555ffa8c4 in object_property_set_bool (obj=obj@entry=0x555558c4b360, name=name@entry=0x5555563794ed "realized", value=value@entry=true, errp=errp@entry=0x7fffffffda00) + at ../../devel/qemu/qom/object.c:1541 +#8 0x0000555555ff319c in qdev_realize (dev=dev@entry=0x555558c4b360, bus=bus@entry=0x0, errp=errp@entry=0x7fffffffda00) at ../../devel/qemu/hw/core/qdev.c:292 +#9 0x0000555555c11be3 in qdev_device_add_from_qdict (opts=opts@entry=0x555558c4a2d0, from_json=from_json@entry=false, errp=0x7fffffffda00, errp@entry=0x55555725b478 <error_fatal>) + at ../../devel/qemu/system/qdev-monitor.c:718 +#10 0x0000555555c12051 in qdev_device_add (opts=0x555557cd2a10, errp=errp@entry=0x55555725b478 <error_fatal>) at ../../devel/qemu/system/qdev-monitor.c:737 +#11 0x0000555555c1720f in device_init_func (opaque=<optimized out>, opts=<optimized out>, errp=0x55555725b478 <error_fatal>) at ../../devel/qemu/system/vl.c:1200 +#12 0x00005555561a29c1 in qemu_opts_foreach + (list=<optimized out>, func=func@entry=0x555555c17200 <device_init_func>, opaque=opaque@entry=0x0, errp=errp@entry=0x55555725b478 <error_fatal>) + at ../../devel/qemu/util/qemu-option.c:1135 +#13 0x0000555555c19aea in qemu_create_cli_devices () at ../../devel/qemu/system/vl.c:2637 +#14 qmp_x_exit_preconfig (errp=<optimized out>) at ../../devel/qemu/system/vl.c:2705 +#15 0x0000555555c1d67f in qmp_x_exit_preconfig (errp=<optimized out>) at ../../devel/qemu/system/vl.c:2699 +#16 qemu_init (argc=<optimized out>, argv=<optimized out>) at ../../devel/qemu/system/vl.c:3736 +#17 0x00005555558f6f59 in main (argc=<optimized out>, argv=<optimized out>) at ../../devel/qemu/system/main.c:47 +``` diff --git a/results/classifier/105/mistranslation/2232 b/results/classifier/105/mistranslation/2232 new file mode 100644 index 000000000..3f67b8629 --- /dev/null +++ b/results/classifier/105/mistranslation/2232 @@ -0,0 +1,14 @@ +mistranslation: 0.880 +other: 0.877 +device: 0.574 +semantic: 0.415 +graphic: 0.391 +vnc: 0.388 +network: 0.353 +socket: 0.150 +boot: 0.132 +KVM: 0.124 +instruction: 0.109 +assembly: 0.102 + +ui/qemu.desktop is nonconformant with the desktop entry specification diff --git a/results/classifier/105/mistranslation/2236 b/results/classifier/105/mistranslation/2236 new file mode 100644 index 000000000..7559087d4 --- /dev/null +++ b/results/classifier/105/mistranslation/2236 @@ -0,0 +1,14 @@ +mistranslation: 0.853 +device: 0.695 +instruction: 0.388 +semantic: 0.355 +graphic: 0.313 +boot: 0.250 +vnc: 0.186 +network: 0.154 +other: 0.116 +assembly: 0.097 +socket: 0.063 +KVM: 0.025 + +32-bit PPC CPUs are reported based on 64-bit base CPU diff --git a/results/classifier/105/mistranslation/227 b/results/classifier/105/mistranslation/227 new file mode 100644 index 000000000..f52514a87 --- /dev/null +++ b/results/classifier/105/mistranslation/227 @@ -0,0 +1,14 @@ +mistranslation: 0.993 +semantic: 0.934 +other: 0.729 +graphic: 0.386 +device: 0.329 +vnc: 0.163 +assembly: 0.156 +instruction: 0.152 +socket: 0.136 +boot: 0.060 +KVM: 0.054 +network: 0.040 + +meson: incomplete 'make help' diff --git a/results/classifier/105/mistranslation/228 b/results/classifier/105/mistranslation/228 new file mode 100644 index 000000000..6dd53e4d7 --- /dev/null +++ b/results/classifier/105/mistranslation/228 @@ -0,0 +1,14 @@ +mistranslation: 0.650 +device: 0.564 +semantic: 0.249 +other: 0.241 +graphic: 0.162 +instruction: 0.097 +boot: 0.080 +network: 0.065 +assembly: 0.053 +vnc: 0.048 +socket: 0.030 +KVM: 0.018 + +TCG test targets missing from 'make check-help' diff --git a/results/classifier/105/mistranslation/230 b/results/classifier/105/mistranslation/230 new file mode 100644 index 000000000..57e31e489 --- /dev/null +++ b/results/classifier/105/mistranslation/230 @@ -0,0 +1,14 @@ +mistranslation: 0.948 +device: 0.879 +network: 0.722 +graphic: 0.681 +instruction: 0.573 +semantic: 0.477 +other: 0.458 +vnc: 0.407 +assembly: 0.168 +boot: 0.165 +socket: 0.057 +KVM: 0.031 + +Confuse error message in virtio_init_region_cache() diff --git a/results/classifier/105/mistranslation/23270873 b/results/classifier/105/mistranslation/23270873 new file mode 100644 index 000000000..8f38a9e5c --- /dev/null +++ b/results/classifier/105/mistranslation/23270873 @@ -0,0 +1,700 @@ +mistranslation: 0.881 +other: 0.839 +boot: 0.830 +vnc: 0.820 +device: 0.810 +KVM: 0.803 +assembly: 0.768 +network: 0.768 +graphic: 0.764 +socket: 0.758 +instruction: 0.755 +semantic: 0.752 + +[Qemu-devel] [BUG?] aio_get_linux_aio: Assertion `ctx->linux_aio' failed + +Hi, + +I am seeing some strange QEMU assertion failures for qemu on s390x, +which prevents a guest from starting. + +Git bisecting points to the following commit as the source of the error. + +commit ed6e2161715c527330f936d44af4c547f25f687e +Author: Nishanth Aravamudan <address@hidden> +Date: Fri Jun 22 12:37:00 2018 -0700 + + linux-aio: properly bubble up errors from initialization + + laio_init() can fail for a couple of reasons, which will lead to a NULL + pointer dereference in laio_attach_aio_context(). + + To solve this, add a aio_setup_linux_aio() function which is called + early in raw_open_common. If this fails, propagate the error up. The + signature of aio_get_linux_aio() was not modified, because it seems + preferable to return the actual errno from the possible failing + initialization calls. + + Additionally, when the AioContext changes, we need to associate a + LinuxAioState with the new AioContext. Use the bdrv_attach_aio_context + callback and call the new aio_setup_linux_aio(), which will allocate a +new AioContext if needed, and return errors on failures. If it +fails for +any reason, fallback to threaded AIO with an error message, as the + device is already in-use by the guest. + + Add an assert that aio_get_linux_aio() cannot return NULL. + + Signed-off-by: Nishanth Aravamudan <address@hidden> + Message-id: address@hidden + Signed-off-by: Stefan Hajnoczi <address@hidden> +Not sure what is causing this assertion to fail. Here is the qemu +command line of the guest, from qemu log, which throws this error: +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin +QEMU_AUDIO_DRV=none /usr/local/bin/qemu-system-s390x -name +guest=rt_vm1,debug-threads=on -S -object +secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-21-rt_vm1/master-key.aes +-machine s390-ccw-virtio-2.12,accel=kvm,usb=off,dump-guest-core=off -m +1024 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -object +iothread,id=iothread1 -uuid 0cde16cd-091d-41bd-9ac2-5243df5c9a0d +-display none -no-user-config -nodefaults -chardev +socket,id=charmonitor,fd=28,server,nowait -mon +chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown +-boot strict=on -drive +file=/dev/mapper/360050763998b0883980000002a000031,format=raw,if=none,id=drive-virtio-disk0,cache=none,aio=native +-device +virtio-blk-ccw,iothread=iothread1,scsi=off,devno=fe.0.0001,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on +-netdev tap,fd=30,id=hostnet0,vhost=on,vhostfd=31 -device +virtio-net-ccw,netdev=hostnet0,id=net0,mac=02:3a:c8:67:95:84,devno=fe.0.0000 +-netdev tap,fd=32,id=hostnet1,vhost=on,vhostfd=33 -device +virtio-net-ccw,netdev=hostnet1,id=net1,mac=52:54:00:2a:e5:08,devno=fe.0.0002 +-chardev pty,id=charconsole0 -device +sclpconsole,chardev=charconsole0,id=console0 -device +virtio-balloon-ccw,id=balloon0,devno=fe.3.ffba -sandbox +on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny +-msg timestamp=on +2018-07-17 15:48:42.252+0000: Domain id=21 is tainted: high-privileges +2018-07-17T15:48:42.279380Z qemu-system-s390x: -chardev +pty,id=charconsole0: char device redirected to /dev/pts/3 (label +charconsole0) +qemu-system-s390x: util/async.c:339: aio_get_linux_aio: Assertion +`ctx->linux_aio' failed. +2018-07-17 15:48:43.309+0000: shutting down, reason=failed + + +Any help debugging this would be greatly appreciated. + +Thank you +Farhan + +On 17.07.2018 [13:25:53 -0400], Farhan Ali wrote: +> +Hi, +> +> +I am seeing some strange QEMU assertion failures for qemu on s390x, +> +which prevents a guest from starting. +> +> +Git bisecting points to the following commit as the source of the error. +> +> +commit ed6e2161715c527330f936d44af4c547f25f687e +> +Author: Nishanth Aravamudan <address@hidden> +> +Date: Fri Jun 22 12:37:00 2018 -0700 +> +> +linux-aio: properly bubble up errors from initialization +> +> +laio_init() can fail for a couple of reasons, which will lead to a NULL +> +pointer dereference in laio_attach_aio_context(). +> +> +To solve this, add a aio_setup_linux_aio() function which is called +> +early in raw_open_common. If this fails, propagate the error up. The +> +signature of aio_get_linux_aio() was not modified, because it seems +> +preferable to return the actual errno from the possible failing +> +initialization calls. +> +> +Additionally, when the AioContext changes, we need to associate a +> +LinuxAioState with the new AioContext. Use the bdrv_attach_aio_context +> +callback and call the new aio_setup_linux_aio(), which will allocate a +> +new AioContext if needed, and return errors on failures. If it fails for +> +any reason, fallback to threaded AIO with an error message, as the +> +device is already in-use by the guest. +> +> +Add an assert that aio_get_linux_aio() cannot return NULL. +> +> +Signed-off-by: Nishanth Aravamudan <address@hidden> +> +Message-id: address@hidden +> +Signed-off-by: Stefan Hajnoczi <address@hidden> +> +> +> +Not sure what is causing this assertion to fail. Here is the qemu command +> +line of the guest, from qemu log, which throws this error: +> +> +> +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin +> +QEMU_AUDIO_DRV=none /usr/local/bin/qemu-system-s390x -name +> +guest=rt_vm1,debug-threads=on -S -object +> +secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-21-rt_vm1/master-key.aes +> +-machine s390-ccw-virtio-2.12,accel=kvm,usb=off,dump-guest-core=off -m 1024 +> +-realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -object +> +iothread,id=iothread1 -uuid 0cde16cd-091d-41bd-9ac2-5243df5c9a0d -display +> +none -no-user-config -nodefaults -chardev +> +socket,id=charmonitor,fd=28,server,nowait -mon +> +chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot +> +strict=on -drive +> +file=/dev/mapper/360050763998b0883980000002a000031,format=raw,if=none,id=drive-virtio-disk0,cache=none,aio=native +> +-device +> +virtio-blk-ccw,iothread=iothread1,scsi=off,devno=fe.0.0001,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on +> +-netdev tap,fd=30,id=hostnet0,vhost=on,vhostfd=31 -device +> +virtio-net-ccw,netdev=hostnet0,id=net0,mac=02:3a:c8:67:95:84,devno=fe.0.0000 +> +-netdev tap,fd=32,id=hostnet1,vhost=on,vhostfd=33 -device +> +virtio-net-ccw,netdev=hostnet1,id=net1,mac=52:54:00:2a:e5:08,devno=fe.0.0002 +> +-chardev pty,id=charconsole0 -device +> +sclpconsole,chardev=charconsole0,id=console0 -device +> +virtio-balloon-ccw,id=balloon0,devno=fe.3.ffba -sandbox +> +on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg +> +timestamp=on +> +> +> +> +2018-07-17 15:48:42.252+0000: Domain id=21 is tainted: high-privileges +> +2018-07-17T15:48:42.279380Z qemu-system-s390x: -chardev pty,id=charconsole0: +> +char device redirected to /dev/pts/3 (label charconsole0) +> +qemu-system-s390x: util/async.c:339: aio_get_linux_aio: Assertion +> +`ctx->linux_aio' failed. +> +2018-07-17 15:48:43.309+0000: shutting down, reason=failed +> +> +> +Any help debugging this would be greatly appreciated. +iiuc, this possibly implies AIO was not actually used previously on this +guest (it might have silently been falling back to threaded IO?). I +don't have access to s390x, but would it be possible to run qemu under +gdb and see if aio_setup_linux_aio is being called at all (I think it +might not be, but I'm not sure why), and if so, if it's for the context +in question? + +If it's not being called first, could you see what callpath is calling +aio_get_linux_aio when this assertion trips? + +Thanks! +-Nish + +On 07/17/2018 04:52 PM, Nishanth Aravamudan wrote: +iiuc, this possibly implies AIO was not actually used previously on this +guest (it might have silently been falling back to threaded IO?). I +don't have access to s390x, but would it be possible to run qemu under +gdb and see if aio_setup_linux_aio is being called at all (I think it +might not be, but I'm not sure why), and if so, if it's for the context +in question? + +If it's not being called first, could you see what callpath is calling +aio_get_linux_aio when this assertion trips? + +Thanks! +-Nish +Hi Nishant, +From the coredump of the guest this is the call trace that calls +aio_get_linux_aio: +Stack trace of thread 145158: +#0 0x000003ff94dbe274 raise (libc.so.6) +#1 0x000003ff94da39a8 abort (libc.so.6) +#2 0x000003ff94db62ce __assert_fail_base (libc.so.6) +#3 0x000003ff94db634c __assert_fail (libc.so.6) +#4 0x000002aa20db067a aio_get_linux_aio (qemu-system-s390x) +#5 0x000002aa20d229a8 raw_aio_plug (qemu-system-s390x) +#6 0x000002aa20d309ee bdrv_io_plug (qemu-system-s390x) +#7 0x000002aa20b5a8ea virtio_blk_handle_vq (qemu-system-s390x) +#8 0x000002aa20db2f6e aio_dispatch_handlers (qemu-system-s390x) +#9 0x000002aa20db3c34 aio_poll (qemu-system-s390x) +#10 0x000002aa20be32a2 iothread_run (qemu-system-s390x) +#11 0x000003ff94f879a8 start_thread (libpthread.so.0) +#12 0x000003ff94e797ee thread_start (libc.so.6) + + +Thanks for taking a look and responding. + +Thanks +Farhan + +On 07/18/2018 09:42 AM, Farhan Ali wrote: +On 07/17/2018 04:52 PM, Nishanth Aravamudan wrote: +iiuc, this possibly implies AIO was not actually used previously on this +guest (it might have silently been falling back to threaded IO?). I +don't have access to s390x, but would it be possible to run qemu under +gdb and see if aio_setup_linux_aio is being called at all (I think it +might not be, but I'm not sure why), and if so, if it's for the context +in question? + +If it's not being called first, could you see what callpath is calling +aio_get_linux_aio when this assertion trips? + +Thanks! +-Nish +Hi Nishant, +From the coredump of the guest this is the call trace that calls +aio_get_linux_aio: +Stack trace of thread 145158: +#0 0x000003ff94dbe274 raise (libc.so.6) +#1 0x000003ff94da39a8 abort (libc.so.6) +#2 0x000003ff94db62ce __assert_fail_base (libc.so.6) +#3 0x000003ff94db634c __assert_fail (libc.so.6) +#4 0x000002aa20db067a aio_get_linux_aio (qemu-system-s390x) +#5 0x000002aa20d229a8 raw_aio_plug (qemu-system-s390x) +#6 0x000002aa20d309ee bdrv_io_plug (qemu-system-s390x) +#7 0x000002aa20b5a8ea virtio_blk_handle_vq (qemu-system-s390x) +#8 0x000002aa20db2f6e aio_dispatch_handlers (qemu-system-s390x) +#9 0x000002aa20db3c34 aio_poll (qemu-system-s390x) +#10 0x000002aa20be32a2 iothread_run (qemu-system-s390x) +#11 0x000003ff94f879a8 start_thread (libpthread.so.0) +#12 0x000003ff94e797ee thread_start (libc.so.6) + + +Thanks for taking a look and responding. + +Thanks +Farhan +Trying to debug a little further, the block device in this case is a +"host device". And looking at your commit carefully you use the +bdrv_attach_aio_context callback to setup a Linux AioContext. +For some reason the "host device" struct (BlockDriver bdrv_host_device +in block/file-posix.c) does not have a bdrv_attach_aio_context defined. +So a simple change of adding the callback to the struct solves the issue +and the guest starts fine. +diff --git a/block/file-posix.c b/block/file-posix.c +index 28824aa..b8d59fb 100644 +--- a/block/file-posix.c ++++ b/block/file-posix.c +@@ -3135,6 +3135,7 @@ static BlockDriver bdrv_host_device = { + .bdrv_refresh_limits = raw_refresh_limits, + .bdrv_io_plug = raw_aio_plug, + .bdrv_io_unplug = raw_aio_unplug, ++ .bdrv_attach_aio_context = raw_aio_attach_aio_context, + + .bdrv_co_truncate = raw_co_truncate, + .bdrv_getlength = raw_getlength, +I am not too familiar with block device code in QEMU, so not sure if +this is the right fix or if there are some underlying problems. +Thanks +Farhan + +On 18.07.2018 [11:10:27 -0400], Farhan Ali wrote: +> +> +> +On 07/18/2018 09:42 AM, Farhan Ali wrote: +> +> +> +> +> +> On 07/17/2018 04:52 PM, Nishanth Aravamudan wrote: +> +> > iiuc, this possibly implies AIO was not actually used previously on this +> +> > guest (it might have silently been falling back to threaded IO?). I +> +> > don't have access to s390x, but would it be possible to run qemu under +> +> > gdb and see if aio_setup_linux_aio is being called at all (I think it +> +> > might not be, but I'm not sure why), and if so, if it's for the context +> +> > in question? +> +> > +> +> > If it's not being called first, could you see what callpath is calling +> +> > aio_get_linux_aio when this assertion trips? +> +> > +> +> > Thanks! +> +> > -Nish +> +> +> +> +> +> Hi Nishant, +> +> +> +> From the coredump of the guest this is the call trace that calls +> +> aio_get_linux_aio: +> +> +> +> +> +> Stack trace of thread 145158: +> +> #0 0x000003ff94dbe274 raise (libc.so.6) +> +> #1 0x000003ff94da39a8 abort (libc.so.6) +> +> #2 0x000003ff94db62ce __assert_fail_base (libc.so.6) +> +> #3 0x000003ff94db634c __assert_fail (libc.so.6) +> +> #4 0x000002aa20db067a aio_get_linux_aio (qemu-system-s390x) +> +> #5 0x000002aa20d229a8 raw_aio_plug (qemu-system-s390x) +> +> #6 0x000002aa20d309ee bdrv_io_plug (qemu-system-s390x) +> +> #7 0x000002aa20b5a8ea virtio_blk_handle_vq (qemu-system-s390x) +> +> #8 0x000002aa20db2f6e aio_dispatch_handlers (qemu-system-s390x) +> +> #9 0x000002aa20db3c34 aio_poll (qemu-system-s390x) +> +> #10 0x000002aa20be32a2 iothread_run (qemu-system-s390x) +> +> #11 0x000003ff94f879a8 start_thread (libpthread.so.0) +> +> #12 0x000003ff94e797ee thread_start (libc.so.6) +> +> +> +> +> +> Thanks for taking a look and responding. +> +> +> +> Thanks +> +> Farhan +> +> +> +> +> +> +> +> +Trying to debug a little further, the block device in this case is a "host +> +device". And looking at your commit carefully you use the +> +bdrv_attach_aio_context callback to setup a Linux AioContext. +> +> +For some reason the "host device" struct (BlockDriver bdrv_host_device in +> +block/file-posix.c) does not have a bdrv_attach_aio_context defined. +> +So a simple change of adding the callback to the struct solves the issue and +> +the guest starts fine. +> +> +> +diff --git a/block/file-posix.c b/block/file-posix.c +> +index 28824aa..b8d59fb 100644 +> +--- a/block/file-posix.c +> ++++ b/block/file-posix.c +> +@@ -3135,6 +3135,7 @@ static BlockDriver bdrv_host_device = { +> +.bdrv_refresh_limits = raw_refresh_limits, +> +.bdrv_io_plug = raw_aio_plug, +> +.bdrv_io_unplug = raw_aio_unplug, +> ++ .bdrv_attach_aio_context = raw_aio_attach_aio_context, +> +> +.bdrv_co_truncate = raw_co_truncate, +> +.bdrv_getlength = raw_getlength, +> +> +> +> +I am not too familiar with block device code in QEMU, so not sure if +> +this is the right fix or if there are some underlying problems. +Oh this is quite embarassing! I only added the bdrv_attach_aio_context +callback for the file-backed device. Your fix is definitely corect for +host device. Let me make sure there weren't any others missed and I will +send out a properly formatted patch. Thank you for the quick testing and +turnaround! + +-Nish + +On 07/18/2018 08:52 PM, Nishanth Aravamudan wrote: +> +On 18.07.2018 [11:10:27 -0400], Farhan Ali wrote: +> +> +> +> +> +> On 07/18/2018 09:42 AM, Farhan Ali wrote: +> +>> +> +>> +> +>> On 07/17/2018 04:52 PM, Nishanth Aravamudan wrote: +> +>>> iiuc, this possibly implies AIO was not actually used previously on this +> +>>> guest (it might have silently been falling back to threaded IO?). I +> +>>> don't have access to s390x, but would it be possible to run qemu under +> +>>> gdb and see if aio_setup_linux_aio is being called at all (I think it +> +>>> might not be, but I'm not sure why), and if so, if it's for the context +> +>>> in question? +> +>>> +> +>>> If it's not being called first, could you see what callpath is calling +> +>>> aio_get_linux_aio when this assertion trips? +> +>>> +> +>>> Thanks! +> +>>> -Nish +> +>> +> +>> +> +>> Hi Nishant, +> +>> +> +>> From the coredump of the guest this is the call trace that calls +> +>> aio_get_linux_aio: +> +>> +> +>> +> +>> Stack trace of thread 145158: +> +>> #0 0x000003ff94dbe274 raise (libc.so.6) +> +>> #1 0x000003ff94da39a8 abort (libc.so.6) +> +>> #2 0x000003ff94db62ce __assert_fail_base (libc.so.6) +> +>> #3 0x000003ff94db634c __assert_fail (libc.so.6) +> +>> #4 0x000002aa20db067a aio_get_linux_aio (qemu-system-s390x) +> +>> #5 0x000002aa20d229a8 raw_aio_plug (qemu-system-s390x) +> +>> #6 0x000002aa20d309ee bdrv_io_plug (qemu-system-s390x) +> +>> #7 0x000002aa20b5a8ea virtio_blk_handle_vq (qemu-system-s390x) +> +>> #8 0x000002aa20db2f6e aio_dispatch_handlers (qemu-system-s390x) +> +>> #9 0x000002aa20db3c34 aio_poll (qemu-system-s390x) +> +>> #10 0x000002aa20be32a2 iothread_run (qemu-system-s390x) +> +>> #11 0x000003ff94f879a8 start_thread (libpthread.so.0) +> +>> #12 0x000003ff94e797ee thread_start (libc.so.6) +> +>> +> +>> +> +>> Thanks for taking a look and responding. +> +>> +> +>> Thanks +> +>> Farhan +> +>> +> +>> +> +>> +> +> +> +> Trying to debug a little further, the block device in this case is a "host +> +> device". And looking at your commit carefully you use the +> +> bdrv_attach_aio_context callback to setup a Linux AioContext. +> +> +> +> For some reason the "host device" struct (BlockDriver bdrv_host_device in +> +> block/file-posix.c) does not have a bdrv_attach_aio_context defined. +> +> So a simple change of adding the callback to the struct solves the issue and +> +> the guest starts fine. +> +> +> +> +> +> diff --git a/block/file-posix.c b/block/file-posix.c +> +> index 28824aa..b8d59fb 100644 +> +> --- a/block/file-posix.c +> +> +++ b/block/file-posix.c +> +> @@ -3135,6 +3135,7 @@ static BlockDriver bdrv_host_device = { +> +> .bdrv_refresh_limits = raw_refresh_limits, +> +> .bdrv_io_plug = raw_aio_plug, +> +> .bdrv_io_unplug = raw_aio_unplug, +> +> + .bdrv_attach_aio_context = raw_aio_attach_aio_context, +> +> +> +> .bdrv_co_truncate = raw_co_truncate, +> +> .bdrv_getlength = raw_getlength, +> +> +> +> +> +> +> +> I am not too familiar with block device code in QEMU, so not sure if +> +> this is the right fix or if there are some underlying problems. +> +> +Oh this is quite embarassing! I only added the bdrv_attach_aio_context +> +callback for the file-backed device. Your fix is definitely corect for +> +host device. Let me make sure there weren't any others missed and I will +> +send out a properly formatted patch. Thank you for the quick testing and +> +turnaround! +Farhan, can you respin your patch with proper sign-off and patch description? +Adding qemu-block. + +Hi Christian, + +On 19.07.2018 [08:55:20 +0200], Christian Borntraeger wrote: +> +> +> +On 07/18/2018 08:52 PM, Nishanth Aravamudan wrote: +> +> On 18.07.2018 [11:10:27 -0400], Farhan Ali wrote: +> +>> +> +>> +> +>> On 07/18/2018 09:42 AM, Farhan Ali wrote: +<snip> + +> +>> I am not too familiar with block device code in QEMU, so not sure if +> +>> this is the right fix or if there are some underlying problems. +> +> +> +> Oh this is quite embarassing! I only added the bdrv_attach_aio_context +> +> callback for the file-backed device. Your fix is definitely corect for +> +> host device. Let me make sure there weren't any others missed and I will +> +> send out a properly formatted patch. Thank you for the quick testing and +> +> turnaround! +> +> +Farhan, can you respin your patch with proper sign-off and patch description? +> +Adding qemu-block. +I sent it yesterday, sorry I didn't cc everyone from this e-mail: +http://lists.nongnu.org/archive/html/qemu-block/2018-07/msg00516.html +Thanks, +Nish + diff --git a/results/classifier/105/mistranslation/2352 b/results/classifier/105/mistranslation/2352 new file mode 100644 index 000000000..efff0982c --- /dev/null +++ b/results/classifier/105/mistranslation/2352 @@ -0,0 +1,14 @@ +mistranslation: 0.921 +device: 0.910 +network: 0.821 +vnc: 0.795 +assembly: 0.702 +graphic: 0.671 +semantic: 0.518 +other: 0.500 +socket: 0.479 +instruction: 0.474 +KVM: 0.398 +boot: 0.309 + +spapr-vlan hotplug diff --git a/results/classifier/105/mistranslation/2366 b/results/classifier/105/mistranslation/2366 new file mode 100644 index 000000000..29eba7ea5 --- /dev/null +++ b/results/classifier/105/mistranslation/2366 @@ -0,0 +1,14 @@ +mistranslation: 0.732 +device: 0.558 +graphic: 0.457 +semantic: 0.437 +network: 0.389 +vnc: 0.358 +boot: 0.190 +other: 0.131 +socket: 0.119 +assembly: 0.092 +KVM: 0.083 +instruction: 0.036 + +qemu8.2 check test failed diff --git a/results/classifier/105/mistranslation/2367 b/results/classifier/105/mistranslation/2367 new file mode 100644 index 000000000..ce5f9487c --- /dev/null +++ b/results/classifier/105/mistranslation/2367 @@ -0,0 +1,14 @@ +mistranslation: 0.698 +device: 0.632 +network: 0.496 +semantic: 0.492 +graphic: 0.417 +vnc: 0.381 +boot: 0.217 +socket: 0.169 +assembly: 0.150 +other: 0.116 +KVM: 0.080 +instruction: 0.069 + +qemu8.2 check test failed diff --git a/results/classifier/105/mistranslation/2369 b/results/classifier/105/mistranslation/2369 new file mode 100644 index 000000000..9f1f85e04 --- /dev/null +++ b/results/classifier/105/mistranslation/2369 @@ -0,0 +1,14 @@ +mistranslation: 0.993 +graphic: 0.560 +device: 0.430 +semantic: 0.427 +other: 0.426 +boot: 0.217 +network: 0.181 +instruction: 0.110 +vnc: 0.076 +socket: 0.052 +KVM: 0.019 +assembly: 0.014 + +qemu-img measure is incorrect when using discard-no-unref diff --git a/results/classifier/105/mistranslation/2395 b/results/classifier/105/mistranslation/2395 new file mode 100644 index 000000000..eaa96bbd9 --- /dev/null +++ b/results/classifier/105/mistranslation/2395 @@ -0,0 +1,73 @@ +mistranslation: 0.747 +graphic: 0.744 +other: 0.700 +semantic: 0.674 +socket: 0.665 +instruction: 0.659 +KVM: 0.634 +network: 0.630 +assembly: 0.617 +device: 0.602 +vnc: 0.587 +boot: 0.563 + +qemu-system-x86_64: Assertion `!(bs->open_flags & BDRV_O_INACTIVE)' failed when paused vm migrating (with shared storage) from dest to src host +Description of problem: +We are doing migration tests with share storage (nfs) as follows: +First, we pause the virtual machine using the 'virsh suspend'command, then migrate the virtual machine to the destination host by 'virsh migrate' command, and there is no problem. After the migration is complete, the virtual machine remains paused on the destination host. However, when we migrate the virtual machine back to the original host, an assertion error is triggered on the current host（dest host）: + +``` +705 qemu-system-x86_64: ../block.c:6748: bdrv_inactivate_recurse: Assertion `!(bs->open_flags & BDRV_O_INACTIVE)' failed. +706 2024-06-17 11:15:59.972+0000: shutting down, reason=crashed +``` + +and virsh migrate commant return error: +``` +**virsh migrate test qemu+tcp://host_ip/system tcp://host_ip --live --verbose --unsafe +Migration: [ 98 %]error: operation failed: domain is not running** +``` +Steps to reproduce: +1. We create an vm with shareable storage and then paused vm in source host: + ``` + virsh create test.xml running + virsh suspend test paused + ``` +2. Migrate vm to the destination host: + ``virsh migrate test qemu+tcp://dest_ip/system tcp://dest_ip --live --verbose --unsafe`` +3. In destination host，vm is paused. +4. Migrate vm back to the source host，and then migration failed and assert error in qemu log in destination host: + ``` + virsh migrate test qemu+tcp://host_ip/system tcp://host_ip --live --verbose --unsafe + Migration: [ 98 %]error: operation failed: domain is not running + ``` + ``` + 705 qemu-system-x86_64: ../block.c:6748: bdrv_inactivate_recurse: Assertion `!(bs->open_flags & + BDRV_O_INACTIVE)' failed. + 706 2024-06-17 11:15:59.972+0000: shutting down, reason=crashed + ``` +Additional information: +1) src -----> dest + ``` +migration_thread() + migration_completion + global_state_store() + vm_stop_force_state(RUN_STATE_FINISH_MIGRATE) + qemu_savevm_state_complete_precopy_nop_iterable() + bdrv_inactivate_all () + bdrv_inactivate_recurse() + bs->open_flags |= BDRV_O_INACTIVE; (BDRV_O_INACTIVE=0x0800) +``` + +2) dest -----> src +``` +migration_thread() + qemu_savevm_state_complete_precopy_non_iterable() + bdrv_inactivate_all () + bdrv_inactivate_recurse() + assert(!(bs->open_flags & BDRV_O_INACTIVE)); Assert and Crash +``` + + +I'm not sure how to address this issue. If QEMU does not support such a migration, a gentler way would be to directly report an error and exit, just like what did in migrate_prepare function， instead of crash qemu. + +If you have any ideas, please let me know, thanks. diff --git a/results/classifier/105/mistranslation/2401 b/results/classifier/105/mistranslation/2401 new file mode 100644 index 000000000..da6b2ae8b --- /dev/null +++ b/results/classifier/105/mistranslation/2401 @@ -0,0 +1,14 @@ +mistranslation: 0.943 +other: 0.596 +semantic: 0.460 +device: 0.368 +network: 0.174 +KVM: 0.155 +graphic: 0.154 +instruction: 0.093 +vnc: 0.092 +boot: 0.075 +socket: 0.036 +assembly: 0.030 + +"-nic none" option has no equivalent in config file diff --git a/results/classifier/105/mistranslation/241 b/results/classifier/105/mistranslation/241 new file mode 100644 index 000000000..c241ca40b --- /dev/null +++ b/results/classifier/105/mistranslation/241 @@ -0,0 +1,14 @@ +mistranslation: 0.613 +semantic: 0.465 +graphic: 0.435 +instruction: 0.414 +device: 0.403 +other: 0.063 +boot: 0.039 +vnc: 0.038 +assembly: 0.023 +network: 0.019 +socket: 0.013 +KVM: 0.010 + +Please refactor linux-user/mips/cpu_loop.c diff --git a/results/classifier/105/mistranslation/2415 b/results/classifier/105/mistranslation/2415 new file mode 100644 index 000000000..e7ebcc95f --- /dev/null +++ b/results/classifier/105/mistranslation/2415 @@ -0,0 +1,66 @@ +mistranslation: 0.899 +device: 0.898 +other: 0.891 +graphic: 0.871 +network: 0.867 +instruction: 0.859 +KVM: 0.824 +vnc: 0.822 +assembly: 0.821 +semantic: 0.810 +boot: 0.772 +socket: 0.745 + +Assertion `r->req.aiocb == NULL' in am53c974 device +Description of problem: +The following log reveals it: + +``` +qemu-truman-x86_64-4467afcc: qemu/hw/scsi/scsi-disk.c:558: void scsi_write_data(SCSIRequest *): Assertion `r->req.aiocb == NULL' failed. +==2957464== ERROR: libFuzzer: deadly signal + #0 0x55e76f00e911 in __sanitizer_print_stack_trace llvm/compiler-rt/lib/asan/asan_stack.cpp:87:3 + #1 0x55e76ef88fb8 in fuzzer::PrintStackTrace() llvm/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:5 + #2 0x55e76ef6d1b3 in fuzzer::Fuzzer::CrashCallback() llvm/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:233:3 + #3 0x7f83d604251f (/lib/x86_64-linux-gnu/libc.so.6+0x4251f) + #4 0x7f83d60969fb in __pthread_kill_implementation nptl/./nptl/pthread_kill.c:43:17 + #5 0x7f83d60969fb in __pthread_kill_internal nptl/./nptl/pthread_kill.c:78:10 + #6 0x7f83d60969fb in pthread_kill nptl/./nptl/pthread_kill.c:89:10 + #7 0x7f83d6042475 in gsignal signal/../sysdeps/posix/raise.c:26:13 + #8 0x7f83d60287f2 in abort stdlib/./stdlib/abort.c:79:7 + #9 0x7f83d602871a in __assert_fail_base assert/./assert/assert.c:92:3 + #10 0x7f83d6039e95 in __assert_fail assert/./assert/assert.c:101:3 + #11 0x55e76fbb55a5 in scsi_write_data qemu/hw/scsi/scsi-disk.c:558:5 + #12 0x55e76fb95a1f in scsi_req_continue qemu/hw/scsi/scsi-bus.c + #13 0x55e76fbfe0cc in esp_do_dma qemu/hw/scsi/esp.c + #14 0x55e76fc0be39 in handle_ti qemu/hw/scsi/esp.c:1104:9 + #15 0x55e76fc042f6 in esp_run_cmd qemu/hw/scsi/esp.c:1186:9 + #16 0x55e76fc042f6 in esp_reg_write qemu/hw/scsi/esp.c:1304:9 + #17 0x55e76fc1329b in esp_pci_io_write qemu/hw/scsi/esp-pci.c:248:9 +``` +Steps to reproduce: +``` +cat << EOF | qemu-system-x86_64 -display none\ +-machine accel=qtest, -m 512M -device am53c974,id=scsi -device \ +scsi-hd,drive=disk0 -drive id=disk0,if=none,file=null-co://,format=raw \ +-nodefaults -qtest stdio +outl 0xcf8 0x80001010 +outl 0xcfc 0xc000 +outl 0xcf8 0x80001004 +outw 0xcfc 0x05 +outl 0xc03e 0x030000 +outl 0xc009 0xc1000000 +outl 0xc008 0x8a +outl 0xc00d 0x0 +outl 0xc009 0x00 +outl 0xc00c 0x11 +outl 0xc00d 0x0 +outl 0xc00d 0x00 +outl 0xc00d 0x0 +outw 0xc00f 0x00 +outb 0xc00d 0x0 +outl 0xc00d 0x0 +outl 0xc009 0x41000000 +outb 0xc00c 0x90 +outl 0xc00d 0x0 +EOF +``` diff --git a/results/classifier/105/mistranslation/2425 b/results/classifier/105/mistranslation/2425 new file mode 100644 index 000000000..75d13d132 --- /dev/null +++ b/results/classifier/105/mistranslation/2425 @@ -0,0 +1,20 @@ +mistranslation: 0.796 +other: 0.787 +graphic: 0.772 +device: 0.733 +network: 0.608 +socket: 0.546 +semantic: 0.536 +vnc: 0.476 +instruction: 0.391 +boot: 0.275 +KVM: 0.147 +assembly: 0.083 + +Add support for the 1366x768 resolution to the -vga std output +Additional information: +There is a Debian [issue](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700055) about it back from 2013. The is also a 2024 thread [thread](https://lists.nongnu.org/archive/html/qemu-discuss/2024-07/msg00003.html) about it on the `qemu-user` mailing list. + +I failed to make it a feature reqeust by keeping the template text +`/label ~"kind::Feature Request"` +at the end of the message: *Gitlab* removes it automatically. diff --git a/results/classifier/105/mistranslation/2430 b/results/classifier/105/mistranslation/2430 new file mode 100644 index 000000000..bea2e094c --- /dev/null +++ b/results/classifier/105/mistranslation/2430 @@ -0,0 +1,20 @@ +mistranslation: 0.843 +instruction: 0.817 +graphic: 0.744 +device: 0.711 +network: 0.530 +vnc: 0.507 +other: 0.482 +socket: 0.411 +semantic: 0.364 +boot: 0.339 +KVM: 0.206 +assembly: 0.086 + +allocate / free need use glibs's function. +Description of problem: +https://gitlab.com/qemu-project/qemu/-/blob/master/hw/core/machine.c?ref_type=heads#L982 + +use g_free to free config,because it is allocated by g_malloc0 + +on windows,if use crt's free && glib's(DLL) g_malloc0 ,will crash. diff --git a/results/classifier/105/mistranslation/2431 b/results/classifier/105/mistranslation/2431 new file mode 100644 index 000000000..dfc1d836a --- /dev/null +++ b/results/classifier/105/mistranslation/2431 @@ -0,0 +1,14 @@ +mistranslation: 0.723 +device: 0.703 +semantic: 0.449 +graphic: 0.428 +instruction: 0.394 +other: 0.382 +network: 0.318 +socket: 0.275 +boot: 0.260 +vnc: 0.254 +KVM: 0.077 +assembly: 0.011 + +we ship a single qemu.1 manpage supposedly applicable for all system emulators but it is full of qemu-system-x86_64 specific info/command lines diff --git a/results/classifier/105/mistranslation/244 b/results/classifier/105/mistranslation/244 new file mode 100644 index 000000000..5902bf5e5 --- /dev/null +++ b/results/classifier/105/mistranslation/244 @@ -0,0 +1,14 @@ +mistranslation: 0.961 +other: 0.869 +device: 0.771 +semantic: 0.751 +graphic: 0.460 +instruction: 0.421 +network: 0.376 +assembly: 0.193 +socket: 0.193 +vnc: 0.151 +boot: 0.122 +KVM: 0.016 + +MIPS MT dvpe does not regard VPEConf0.MVP diff --git a/results/classifier/105/mistranslation/2448 b/results/classifier/105/mistranslation/2448 new file mode 100644 index 000000000..89eb37d32 --- /dev/null +++ b/results/classifier/105/mistranslation/2448 @@ -0,0 +1,59 @@ +mistranslation: 0.784 +instruction: 0.779 +graphic: 0.773 +other: 0.763 +device: 0.730 +vnc: 0.728 +semantic: 0.721 +boot: 0.684 +socket: 0.668 +network: 0.648 +assembly: 0.592 +KVM: 0.505 + +linux-user as binfmt_misc fails to recognize AT_EXECFD if it's 0 and leaves it open as stdin +Description of problem: +When a `*-linux-user` is used as binfmt_misc, and... + +- The `O` (i.e. open-binary) flag is set +- File descriptor 0 is closed when running the executable + +FD 0 is opened to point at the executable and passed as `AT_EXECFD`, which QEMU fails to recognize and leaves open before handing control over to the executable, leading to the program to think stdin is opened for reading its own executable. + +Some use cases rely on closed stdin to behave correctly. For example, this problem causes the `tests/tail/follow-stdin.sh` and `tests/tac/tac-2-nonseekable.sh` tests in GNU coreutils to fail. In any case, having the executable itself be stdin is definitely incorrect and quite surprising behavior. +Steps to reproduce: +1. Set up qemu-riscv64 as binfmt_misc with `qemu-binfmt-conf.sh`, with the `--credential` flag (which enables open-binary) +2. Get a coreutils built for riscv64 (Let's say it can be found in `riscv64-coreutils/bin`) +3. Run it with something like `riscv64-coreutils/bin/cat <&- | xxd | head` (`xxd | head` to catch the binary output) + +The correct behavior is (You can see by running the native `cat <&-`): + +``` +cat: -: Bad file descriptor +cat: closing standard input: Bad file descriptor +``` + +Instead, the executable `cat` itself is dumped to stdout. + +Perhaps slightly more clear is `riscv64-coreutils/bin/ls -l /proc/self/fd <&-` which shows fd 0 unexpectedly pointing to the coreutils executable. +Additional information: +I'm interested in writing a patch to fix this issue but I'm uncertain how to proceed. This is what I've found so far: + +In `linux-user/main.c` if (effectively) `getauxval(AT_EXECFD)` is 0 it's treated as nonexistent. (https://gitlab.com/qemu-project/qemu/-/blob/0d9f1016d43302108d33d1268304a06cc3fb2021/linux-user/main.c#L758-765) + +```c + execfd = qemu_getauxval(AT_EXECFD); + if (execfd == 0) { + execfd = open(exec_path, O_RDONLY); + if (execfd < 0) { + printf("Error while loading %s: %s\n", exec_path, strerror(errno)); + _exit(EXIT_FAILURE); + } + } +``` + +However as we've seen `getauxval(AT_EXECFD)` can have 0 as a valid value. + +`qemu_getauxval` in `util/getauxval.c` implements several strategies to get the auxv, but doesn't currently give a way to distinguish not found and 0. FreeBSD `elf_aux_info` has `EINVAL` and `ENOENT` error codes but it's ignored here. On Linux, glibc sets `errno` to `ENOENT` to distinguish the two cases but only on glibc >= 2.19. Musl's `getauxval` has always had setting `errno` to `ENOENT`. + +Once we add a proper "`AT_EXECFD` doesn't exist" check this will no longer be a problem since (IIUC) `execfd` will eventually be closed after loading. How should we add "not found" support to `qemu_getauxval`? Is just simply relying on libc's `getauxval` setting `errno` okay? diff --git a/results/classifier/105/mistranslation/2451 b/results/classifier/105/mistranslation/2451 new file mode 100644 index 000000000..f92b6fcbb --- /dev/null +++ b/results/classifier/105/mistranslation/2451 @@ -0,0 +1,14 @@ +mistranslation: 0.875 +semantic: 0.337 +other: 0.280 +device: 0.222 +boot: 0.212 +instruction: 0.190 +assembly: 0.188 +graphic: 0.164 +socket: 0.156 +KVM: 0.021 +network: 0.018 +vnc: 0.002 + +Italian language (po) not updated diff --git a/results/classifier/105/mistranslation/2467 b/results/classifier/105/mistranslation/2467 new file mode 100644 index 000000000..17f954f7b --- /dev/null +++ b/results/classifier/105/mistranslation/2467 @@ -0,0 +1,44 @@ +mistranslation: 0.310 +graphic: 0.264 +device: 0.255 +instruction: 0.179 +socket: 0.143 +boot: 0.138 +semantic: 0.132 +network: 0.128 +other: 0.111 +vnc: 0.102 +assembly: 0.057 +KVM: 0.022 + +OpenSBI 1.5 packaged in QEMU 9.0.50 fails to support poweroff with 'spike' board +Steps to reproduce: +Build upstream U-Boot: + +- git clone https://source.denx.de/u-boot/u-boot.git +- cd u-boot +- make qemu-riscv64_smode_defconfig +- CROSS_COMPILE=riscv64-linux-gnu- make + +Run U-Boot and execute poweroff command + +- qemu-system-riscv64 -kernel u-boot.bin +- poweroff + +Poweroff fails. + +When building upstream OpenSBI v1.5 with + +- git clone https://github.com/riscv-software-src/opensbi.git +- cd opensbi +- git reset --hard v1.5 +- CROSS_COMPILE=riscv64-linux-gnu- make PLATFORM=generic + +and then running + +- qemu-system-riscv64 -bios fw_dynamic.bin -kernel u-boot.bin +- poweroff + +poweroff succeeds. + +Please, distribute an unpatched OpenSBI v1.5 with QEMU. diff --git a/results/classifier/105/mistranslation/2481 b/results/classifier/105/mistranslation/2481 new file mode 100644 index 000000000..22e629256 --- /dev/null +++ b/results/classifier/105/mistranslation/2481 @@ -0,0 +1,14 @@ +mistranslation: 0.773 +semantic: 0.455 +graphic: 0.446 +KVM: 0.281 +device: 0.281 +vnc: 0.228 +boot: 0.190 +other: 0.173 +assembly: 0.151 +socket: 0.049 +network: 0.044 +instruction: 0.042 + +Possible dereference of NULL diff --git a/results/classifier/105/mistranslation/2484 b/results/classifier/105/mistranslation/2484 new file mode 100644 index 000000000..fd47456b8 --- /dev/null +++ b/results/classifier/105/mistranslation/2484 @@ -0,0 +1,14 @@ +mistranslation: 0.962 +graphic: 0.911 +other: 0.658 +network: 0.543 +device: 0.477 +vnc: 0.269 +boot: 0.239 +instruction: 0.181 +KVM: 0.158 +semantic: 0.142 +socket: 0.123 +assembly: 0.081 + +Confusing query-gic-capabilities output in --without-default-devices config diff --git a/results/classifier/105/mistranslation/255 b/results/classifier/105/mistranslation/255 new file mode 100644 index 000000000..c99c34d73 --- /dev/null +++ b/results/classifier/105/mistranslation/255 @@ -0,0 +1,14 @@ +mistranslation: 0.744 +instruction: 0.716 +device: 0.591 +graphic: 0.552 +semantic: 0.501 +boot: 0.159 +other: 0.077 +assembly: 0.076 +network: 0.035 +socket: 0.012 +vnc: 0.008 +KVM: 0.002 + +Build on sparc64 fails with "undefined reference to `fdt_check_full'" diff --git a/results/classifier/105/mistranslation/25842545 b/results/classifier/105/mistranslation/25842545 new file mode 100644 index 000000000..088ed7a19 --- /dev/null +++ b/results/classifier/105/mistranslation/25842545 @@ -0,0 +1,210 @@ +mistranslation: 0.928 +other: 0.912 +KVM: 0.867 +vnc: 0.862 +device: 0.847 +instruction: 0.835 +semantic: 0.829 +boot: 0.824 +assembly: 0.824 +graphic: 0.822 +socket: 0.808 +network: 0.796 + +[Qemu-devel] [Bug?] Guest pause because VMPTRLD failed in KVM + +Hello, + + We encountered a problem that a guest paused because the KMOD report VMPTRLD +failed. + +The related information is as follows: + +1) Qemu command: + /usr/bin/qemu-kvm -name omu1 -S -machine pc-i440fx-2.3,accel=kvm,usb=off -cpu +host -m 15625 -realtime mlock=off -smp 8,sockets=1,cores=8,threads=1 -uuid +a2aacfff-6583-48b4-b6a4-e6830e519931 -no-user-config -nodefaults -chardev +socket,id=charmonitor,path=/var/lib/libvirt/qemu/omu1.monitor,server,nowait +-mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown +-boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device +virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive +file=/home/env/guest1.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,cache=none,aio=native + -device +virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0 + -drive +file=/home/env/guest_300G.img,if=none,id=drive-virtio-disk1,format=raw,cache=none,aio=native + -device +virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk1,id=virtio-disk1 + -netdev tap,fd=25,id=hostnet0,vhost=on,vhostfd=26 -device +virtio-net-pci,netdev=hostnet0,id=net0,mac=00:00:80:05:00:00,bus=pci.0,addr=0x3 +-netdev tap,fd=27,id=hostnet1,vhost=on,vhostfd=28 -device +virtio-net-pci,netdev=hostnet1,id=net1,mac=00:00:80:05:00:01,bus=pci.0,addr=0x4 +-chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 +-device usb-tablet,id=input0 -vnc 0.0.0.0:0 -device +cirrus-vga,id=video0,vgamem_mb=16,bus=pci.0,addr=0x2 -device +virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -msg timestamp=on + + 2) Qemu log: + KVM: entry failed, hardware error 0x4 + RAX=00000000ffffffed RBX=ffff8803fa2d7fd8 RCX=0100000000000000 +RDX=0000000000000000 + RSI=0000000000000000 RDI=0000000000000046 RBP=ffff8803fa2d7e90 +RSP=ffff8803fa2efe90 + R8 =0000000000000000 R9 =0000000000000000 R10=0000000000000000 +R11=000000000000b69a + R12=0000000000000001 R13=ffffffff81a25b40 R14=0000000000000000 +R15=ffff8803fa2d7fd8 + RIP=ffffffff81053e16 RFL=00000286 [--S--P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 + ES =0000 0000000000000000 ffffffff 00c00000 + CS =0010 0000000000000000 ffffffff 00a09b00 DPL=0 CS64 [-RA] + SS =0018 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] + DS =0000 0000000000000000 ffffffff 00c00000 + FS =0000 0000000000000000 ffffffff 00c00000 + GS =0000 ffff88040f540000 ffffffff 00c00000 + LDT=0000 0000000000000000 ffffffff 00c00000 + TR =0040 ffff88040f550a40 00002087 00008b00 DPL=0 TSS64-busy + GDT= ffff88040f549000 0000007f + IDT= ffffffffff529000 00000fff + CR0=80050033 CR2=00007f81ca0c5000 CR3=00000003f5081000 CR4=000407e0 + DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 +DR3=0000000000000000 + DR6=00000000ffff0ff0 DR7=0000000000000400 + EFER=0000000000000d01 + Code=?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? <??> ?? ?? +?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? + + 3) Demsg + [347315.028339] kvm: vmptrld ffff8817ec5f0000/17ec5f0000 failed + klogd 1.4.1, ---------- state change ---------- + [347315.039506] kvm: vmptrld ffff8817ec5f0000/17ec5f0000 failed + [347315.051728] kvm: vmptrld ffff8817ec5f0000/17ec5f0000 failed + [347315.057472] vmwrite error: reg 6c0a value ffff88307e66e480 (err +2120672384) + [347315.064567] Pid: 69523, comm: qemu-kvm Tainted: GF X +3.0.93-0.8-default #1 + [347315.064569] Call Trace: + [347315.064587] [<ffffffff810049d5>] dump_trace+0x75/0x300 + [347315.064595] [<ffffffff8145e3e3>] dump_stack+0x69/0x6f + [347315.064617] [<ffffffffa03738de>] vmx_vcpu_load+0x11e/0x1d0 [kvm_intel] + [347315.064647] [<ffffffffa029a204>] kvm_arch_vcpu_load+0x44/0x1d0 [kvm] + [347315.064669] [<ffffffff81054ee1>] finish_task_switch+0x81/0xe0 + [347315.064676] [<ffffffff8145f0b4>] thread_return+0x3b/0x2a7 + [347315.064687] [<ffffffffa028d9b5>] kvm_vcpu_block+0x65/0xa0 [kvm] + [347315.064703] [<ffffffffa02a16d1>] __vcpu_run+0xd1/0x260 [kvm] + [347315.064732] [<ffffffffa02a2418>] kvm_arch_vcpu_ioctl_run+0x68/0x1a0 +[kvm] + [347315.064759] [<ffffffffa028ecee>] kvm_vcpu_ioctl+0x38e/0x580 [kvm] + [347315.064771] [<ffffffff8116bdfb>] do_vfs_ioctl+0x8b/0x3b0 + [347315.064776] [<ffffffff8116c1c1>] sys_ioctl+0xa1/0xb0 + [347315.064783] [<ffffffff81469272>] system_call_fastpath+0x16/0x1b + [347315.064797] [<00007fee51969ce7>] 0x7fee51969ce6 + [347315.064799] vmwrite error: reg 6c0c value ffff88307e664000 (err +2120630272) + [347315.064802] Pid: 69523, comm: qemu-kvm Tainted: GF X +3.0.93-0.8-default #1 + [347315.064803] Call Trace: + [347315.064807] [<ffffffff810049d5>] dump_trace+0x75/0x300 + [347315.064811] [<ffffffff8145e3e3>] dump_stack+0x69/0x6f + [347315.064817] [<ffffffffa03738ec>] vmx_vcpu_load+0x12c/0x1d0 [kvm_intel] + [347315.064832] [<ffffffffa029a204>] kvm_arch_vcpu_load+0x44/0x1d0 [kvm] + [347315.064851] [<ffffffff81054ee1>] finish_task_switch+0x81/0xe0 + [347315.064855] [<ffffffff8145f0b4>] thread_return+0x3b/0x2a7 + [347315.064865] [<ffffffffa028d9b5>] kvm_vcpu_block+0x65/0xa0 [kvm] + [347315.064880] [<ffffffffa02a16d1>] __vcpu_run+0xd1/0x260 [kvm] + [347315.064907] [<ffffffffa02a2418>] kvm_arch_vcpu_ioctl_run+0x68/0x1a0 +[kvm] + [347315.064933] [<ffffffffa028ecee>] kvm_vcpu_ioctl+0x38e/0x580 [kvm] + [347315.064943] [<ffffffff8116bdfb>] do_vfs_ioctl+0x8b/0x3b0 + [347315.064947] [<ffffffff8116c1c1>] sys_ioctl+0xa1/0xb0 + [347315.064951] [<ffffffff81469272>] system_call_fastpath+0x16/0x1b + [347315.064957] [<00007fee51969ce7>] 0x7fee51969ce6 + [347315.064959] vmwrite error: reg 6c10 value 0 (err 0) + + 4) The isssue can't be reporduced. I search the Intel VMX sepc about reaseons +of vmptrld failure: + The instruction fails if its operand is not properly aligned, sets +unsupported physical-address bits, or is equal to the VMXON + pointer. In addition, the instruction fails if the 32 bits in memory +referenced by the operand do not match the VMCS + revision identifier supported by this processor. + + But I can't find any cues from the KVM source code. It seems each + error conditions is impossible in theory. :( + +Any suggestions will be appreciated! Paolo? + +-- +Regards, +-Gonglei + +On 10/11/2016 15:10, gong lei wrote: +> +4) The isssue can't be reporduced. I search the Intel VMX sepc about +> +reaseons +> +of vmptrld failure: +> +The instruction fails if its operand is not properly aligned, sets +> +unsupported physical-address bits, or is equal to the VMXON +> +pointer. In addition, the instruction fails if the 32 bits in memory +> +referenced by the operand do not match the VMCS +> +revision identifier supported by this processor. +> +> +But I can't find any cues from the KVM source code. It seems each +> +error conditions is impossible in theory. :( +Yes, it should not happen. :( + +If it's not reproducible, it's really hard to say what it was, except a +random memory corruption elsewhere or even a bit flip (!). + +Paolo + +On 2016/11/17 20:39, Paolo Bonzini wrote: +> +> +On 10/11/2016 15:10, gong lei wrote: +> +> 4) The isssue can't be reporduced. I search the Intel VMX sepc about +> +> reaseons +> +> of vmptrld failure: +> +> The instruction fails if its operand is not properly aligned, sets +> +> unsupported physical-address bits, or is equal to the VMXON +> +> pointer. In addition, the instruction fails if the 32 bits in memory +> +> referenced by the operand do not match the VMCS +> +> revision identifier supported by this processor. +> +> +> +> But I can't find any cues from the KVM source code. It seems each +> +> error conditions is impossible in theory. :( +> +Yes, it should not happen. :( +> +> +If it's not reproducible, it's really hard to say what it was, except a +> +random memory corruption elsewhere or even a bit flip (!). +> +> +Paolo +Thanks for your reply, Paolo :) + +-- +Regards, +-Gonglei + diff --git a/results/classifier/105/mistranslation/2600 b/results/classifier/105/mistranslation/2600 new file mode 100644 index 000000000..1f7280a1c --- /dev/null +++ b/results/classifier/105/mistranslation/2600 @@ -0,0 +1,14 @@ +mistranslation: 0.929 +device: 0.836 +network: 0.647 +semantic: 0.558 +instruction: 0.550 +graphic: 0.459 +boot: 0.270 +vnc: 0.178 +assembly: 0.095 +other: 0.094 +socket: 0.080 +KVM: 0.015 + +qemu-user MAP_SHARED TB invalidation diff --git a/results/classifier/105/mistranslation/2607 b/results/classifier/105/mistranslation/2607 new file mode 100644 index 000000000..d1d8418dc --- /dev/null +++ b/results/classifier/105/mistranslation/2607 @@ -0,0 +1,80 @@ +mistranslation: 0.889 +other: 0.858 +KVM: 0.822 +device: 0.815 +vnc: 0.810 +network: 0.809 +graphic: 0.803 +socket: 0.800 +instruction: 0.799 +semantic: 0.792 +boot: 0.786 +assembly: 0.785 + +msys2 build failed +Description of problem: + +Steps to reproduce: +1. Install MSYS2 and QEMU build dependencies +2. Update (pacman -Syu) +3. Build: +``` +./configure --enable-sdl --enable-fdt=system --disable-docs --target-list=arm-softmmu,aarch64-softmmu --enable-avx2 +make -j16 +``` +Additional information: +See: https://github.com/msys2/MINGW-packages/issues/22104#issuecomment-2393727818 + +output: +``` +FAILED: libcommon.a.p/net_tap-win32.c.obj +"cc" "-m64" "-Ilibcommon.a.p" "-ID:/a/_temp/msys64/mingw64/include/capstone" "-ID:/a/_temp/msys64/mingw64/include/p11-kit-1" "-ID:/a/_temp/msys64/mingw64/include/pixman-1" "-ID:/a/_temp/msys64/mingw64/include/libpng16" "-ID:/a/_temp/msys64/mingw64/include/spice-server" "-ID:/a/_temp/msys64/mingw64/include/spice-1" "-ID:/a/_temp/msys64/mingw64/include/cacard" "-ID:/a/_temp/msys64/mingw64/include/nss3" "-ID:/a/_temp/msys64/mingw64/include/nspr" "-ID:/a/_temp/msys64/mingw64/include/glib-2.0" "-ID:/a/_temp/msys64/mingw64/lib/glib-2.0/include" "-ID:/a/_temp/msys64/mingw64/include/libusb-1.0" "-ID:/a/_temp/msys64/mingw64/include/SDL2" "-ID:/a/_temp/msys64/mingw64/include/slirp" "-ID:/a/_temp/msys64/mingw64/include/ncursesw" "-ID:/a/_temp/msys64/mingw64/include/gtk-3.0" "-ID:/a/_temp/msys64/mingw64/include/pango-1.0" "-ID:/a/_temp/msys64/mingw64/include/harfbuzz" "-ID:/a/_temp/msys64/mingw64/include/cairo" "-ID:/a/_temp/msys64/mingw64/include/freetype2" "-ID:/a/_temp/msys64/mingw64/include/gdk-pixbuf-2.0" "-ID:/a/_temp/msys64/mingw64/include/webp" "-ID:/a/_temp/msys64/mingw64/include/atk-1.0" "-ID:/a/_temp/msys64/mingw64/include/fribidi" "-ID:/a/_temp/msys64/mingw64/include/rav1e" "-ID:/a/_temp/msys64/mingw64/include/svt-av1" "-fdiagnostics-color=auto" "-Wall" "-Winvalid-pch" "-Werror" "-std=gnu11" "-O2" "-g" "-fstack-protector-strong" "-Wempty-body" "-Wendif-labels" "-Wexpansion-to-defined" "-Wformat-security" "-Wformat-y2k" "-Wignored-qualifiers" "-Wimplicit-fallthrough=2" "-Winit-self" "-Wmissing-format-attribute" "-Wmissing-prototypes" "-Wnested-externs" "-Wold-style-declaration" "-Wold-style-definition" "-Wredundant-decls" "-Wshadow=local" "-Wstrict-prototypes" "-Wtype-limits" "-Wundef" "-Wvla" "-Wwrite-strings" "-Wno-missing-include-dirs" "-Wno-psabi" "-Wno-shift-negative-value" "-iquote" "." "-iquote" "D:/a/qemu/qemu" "-iquote" "D:/a/qemu/qemu/include" "-iquote" "D:/a/qemu/qemu/host/include/x86_64" "-iquote" "D:/a/qemu/qemu/host/include/generic" "-iquote" "D:/a/qemu/qemu/tcg/i386" "-msse2" "-mcx16" "-D_GNU_SOURCE" "-D_FILE_OFFSET_BITS=64" "-D_LARGEFILE_SOURCE" "-fno-strict-aliasing" "-fno-common" "-fwrapv" "-fno-pie" "-no-pie" "-ftrivial-auto-var-init=zero" "-fzero-call-used-regs=used-gpr" "-DHWY_SHARED_DEFINE" "-DAVIF_DLL" "-DEB_DLL" "-DLIBDEFLATE_DLL" "-DNCURSES_WIDECHAR" "-DNCURSES_WIDECHAR=1" "-Dmain=SDL_main" "-DSTRUCT_IOVEC_DEFINED" -MD -MQ libcommon.a.p/net_tap-win32.c.obj -MF "libcommon.a.p/net_tap-win32.c.obj.d" -o libcommon.a.p/net_tap-win32.c.obj "-c" ../net/tap-win32.c +../net/tap-win32.c: In function 'tap_win32_open': +../net/tap-win32.c:343:19: error: '%s' directive output may be truncated writing up to 255 bytes into a region of size 176 [-Werror=format-truncation=] + 343 | "%s\\%s\\Connection", + | ^~ + 344 | NETWORK_CONNECTIONS_KEY, enum_name); + | ~~~~~~~~~ +In function 'get_device_guid', + inlined from 'tap_win32_open' at ../net/tap-win32.c:616:10: +../net/tap-win32.c:341:9: note: 'snprintf' output between 92 and 347 bytes into a destination of size 256 + 341 | snprintf(connection_string, + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ + 342 | sizeof(connection_string), + | ~~~~~~~~~~~~~~~~~~~~~~~~~~ + 343 | "%s\\%s\\Connection", + | ~~~~~~~~~~~~~~~~~~~~~ + 344 | NETWORK_CONNECTIONS_KEY, enum_name); + | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +../net/tap-win32.c: In function 'tap_win32_open': +../net/tap-win32.c:242:58: error: '%s' directive output may be truncated writing up to 255 bytes into a region of size 178 [-Werror=format-truncation=] + 242 | snprintf (unit_string, sizeof(unit_string), "%s\\%s", + | ^~ + 243 | ADAPTER_KEY, enum_name); + | ~~~~~~~~~ +In function 'is_tap_win32_dev', + inlined from 'get_device_guid' at ../net/tap-win32.c:368:21, + inlined from 'tap_win32_open' at ../net/tap-win32.c:616:10: +../net/tap-win32.c:242:9: note: 'snprintf' output between 79 and 334 bytes into a destination of size 256 + 242 | snprintf (unit_string, sizeof(unit_string), "%s\\%s", + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + 243 | ADAPTER_KEY, enum_name); + | ~~~~~~~~~~~~~~~~~~~~~~~ +../net/tap-win32.c: In function 'tap_win32_open': +../net/tap-win32.c:620:52: error: '%s' directive output may be truncated writing up to 255 bytes into a region of size 245 [-Werror=format-truncation=] + 620 | snprintf (device_path, sizeof(device_path), "%s%s%s", + | ^~ + 621 | USERMODEDEVICEDIR, + 622 | device_guid, + | ~~~~~~~~~~~ +../net/tap-win32.c:620:5: note: 'snprintf' output between 16 and 271 bytes into a destination of size 256 + 620 | snprintf (device_path, sizeof(device_path), "%s%s%s", + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + 621 | USERMODEDEVICEDIR, + | ~~~~~~~~~~~~~~~~~~ + 622 | device_guid, + | ~~~~~~~~~~~~ + 623 | TAPSUFFIX); + | ~~~~~~~~~~ +cc1.exe: all warnings being treated as errors +``` diff --git a/results/classifier/105/mistranslation/2610 b/results/classifier/105/mistranslation/2610 new file mode 100644 index 000000000..d69e1ec87 --- /dev/null +++ b/results/classifier/105/mistranslation/2610 @@ -0,0 +1,14 @@ +mistranslation: 0.996 +device: 0.780 +graphic: 0.669 +instruction: 0.599 +assembly: 0.571 +network: 0.561 +vnc: 0.518 +semantic: 0.499 +boot: 0.434 +other: 0.399 +socket: 0.346 +KVM: 0.049 + +pl011: incorrect IBRD_MASK and FBRD_MASK diff --git a/results/classifier/105/mistranslation/2614 b/results/classifier/105/mistranslation/2614 new file mode 100644 index 000000000..553bb82e1 --- /dev/null +++ b/results/classifier/105/mistranslation/2614 @@ -0,0 +1,14 @@ +mistranslation: 0.980 +device: 0.602 +semantic: 0.421 +network: 0.407 +other: 0.373 +instruction: 0.272 +graphic: 0.187 +boot: 0.129 +socket: 0.064 +vnc: 0.036 +assembly: 0.028 +KVM: 0.009 + +vhost user documentation for VHOST_USER_ADD_MEM_REG incorrect diff --git a/results/classifier/105/mistranslation/2630 b/results/classifier/105/mistranslation/2630 new file mode 100644 index 000000000..f2e3cfbc6 --- /dev/null +++ b/results/classifier/105/mistranslation/2630 @@ -0,0 +1,14 @@ +mistranslation: 0.839 +other: 0.609 +boot: 0.481 +graphic: 0.401 +device: 0.393 +KVM: 0.321 +semantic: 0.312 +vnc: 0.281 +network: 0.186 +socket: 0.160 +instruction: 0.084 +assembly: 0.043 + +Issue template broken diff --git a/results/classifier/105/mistranslation/2638 b/results/classifier/105/mistranslation/2638 new file mode 100644 index 000000000..2f35f5b5b --- /dev/null +++ b/results/classifier/105/mistranslation/2638 @@ -0,0 +1,30 @@ +mistranslation: 0.992 +device: 0.777 +socket: 0.720 +network: 0.704 +graphic: 0.587 +semantic: 0.586 +KVM: 0.489 +instruction: 0.432 +boot: 0.424 +other: 0.312 +assembly: 0.304 +vnc: 0.210 + +Incorrect SPDX license expression +Description of problem: +In the source code, the syntax of license expressions after the keyword SPDX-License-Identifier is not always correct. + +"GPL-2.0" should be "GPL-2.0-only" + +"GPL-2.0 WITH Linux-syscall-note" should be "GPL-2.0-only WITH Linux-syscall-note" + +"GPL-2.0+" should be "GPL-2.0-or-later" + +"GPL-2.0+ WITH Linux-syscall-note" should be "GPL-2.0-or-later WITH Linux-syscall-note" + +"GPL-v2-only" should be "GPL-2.0-only" + +"LGPL-2.1+" should be "LGPL-2.1-or-later" + +"MIT CC0-1.0" should be "MIT" diff --git a/results/classifier/105/mistranslation/2644 b/results/classifier/105/mistranslation/2644 new file mode 100644 index 000000000..e7e285071 --- /dev/null +++ b/results/classifier/105/mistranslation/2644 @@ -0,0 +1,79 @@ +mistranslation: 0.813 +device: 0.784 +other: 0.783 +KVM: 0.767 +graphic: 0.758 +boot: 0.741 +instruction: 0.729 +semantic: 0.703 +vnc: 0.686 +network: 0.653 +assembly: 0.627 +socket: 0.574 + +openbsd 7.5 crashes with QEMU since "virtio-pci: Add lookup subregion of VirtIOPCIRegion MR" +Description of problem: +Attempt to boot OpenBSD 7.5 in QEMU current git HEAD fdf250e5a37830615e324017cb3a503e84b3712c. + +It immediately aborts with + +``` +Thread 6 (Thread 0x7fe06d2006c0 (LWP 2797401) "CPU 0/KVM"): +#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 +#1 0x00007fe0764476d3 in __pthread_kill_internal (threadid=<optimized out>, signo=6) at pthread_kill.c:78 +#2 0x00007fe0763eec4e in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 +#3 0x00007fe0763d6902 in __GI_abort () at abort.c:79 +#4 0x00007fe0763d681e in __assert_fail_base (fmt=0x7fe076562b98 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x55a00b998b4d "mrs.mr", file=file@entry=0x55a00b998b33 "../hw/virtio/virtio-pci.c", line=line@entry=620, function=function@entry=0x55a00bb596b0 <__PRETTY_FUNCTION__.13> "virtio_address_space_lookup") at assert.c:94 +#5 0x00007fe0763e6d87 in __assert_fail (assertion=assertion@entry=0x55a00b998b4d "mrs.mr", file=file@entry=0x55a00b998b33 "../hw/virtio/virtio-pci.c", line=line@entry=620, function=function@entry=0x55a00bb596b0 <__PRETTY_FUNCTION__.13> "virtio_address_space_lookup") at assert.c:103 +#6 0x000055a00b49d368 in virtio_address_space_lookup (proxy=proxy@entry=0x55a0213a59d0, off=off@entry=0x7fe06d1f3370, len=len@entry=1) at ../hw/virtio/virtio-pci.c:620 +#7 0x000055a00b4a127f in virtio_address_space_write (proxy=0x55a0213a59d0, addr=<optimized out>, buf=0x55a0213b32c8 "", len=1) at ../hw/virtio/virtio-pci.c:654 +#8 virtio_write_config (pci_dev=<optimized out>, address=<optimized out>, val=<optimized out>, len=<optimized out>) at ../hw/virtio/virtio-pci.c:790 +#9 0x000055a00b6edc30 in memory_region_write_accessor (mr=0x55a01fa1b470, addr=4194520, value=<optimized out>, size=1, shift=<optimized out>, mask=<optimized out>, attrs=...) at ../system/memory.c:497 +#10 0x000055a00b6ed4be in access_with_adjusted_size (addr=addr@entry=4194520, value=0x7fe06d1f34c8, size=size@entry=1, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=0x55a00b6edbb0 <memory_region_write_accessor>, mr=<optimized out>, attrs=...) at ../system/memory.c:573 +#11 0x000055a00b6ed7fa in memory_region_dispatch_write (mr=mr@entry=0x55a01fa1b470, addr=addr@entry=4194520, data=<optimized out>, op=<optimized out>, attrs=attrs@entry=...) at ../system/memory.c:1560 +#12 0x000055a00b6f593f in flatview_write_continue_step (attrs=attrs@entry=..., buf=buf@entry=0x7fe07988e028 "", mr_addr=4194520, l=l@entry=0x7fe06d1f3590, mr=0x55a01fa1b470, len=1) at ../system/physmem.c:2786 +#13 0x000055a00b6f6058 in flatview_write_continue (fv=0x7fdf505079f0, addr=2956984536, attrs=..., ptr=0xb04000d8, len=1, mr_addr=<optimized out>, l=<optimized out>, mr=<optimized out>) at .--Type <RET> for more, q to quit, c to continue without paging-- +./system/physmem.c:2816 +#14 flatview_write (fv=0x7fdf505079f0, addr=addr@entry=2956984536, attrs=attrs@entry=..., buf=buf@entry=0x7fe07988e028, len=len@entry=1) at ../system/physmem.c:2847 +#15 0x000055a00b6f97a1 in address_space_write (as=0x55a00ca34600 <address_space_memory>, addr=2956984536, attrs=..., buf=0x7fe07988e028, len=1) at ../system/physmem.c:2967 +#16 address_space_rw (as=0x55a00ca34600 <address_space_memory>, addr=2956984536, attrs=attrs@entry=..., buf=buf@entry=0x7fe07988e028, len=1, is_write=<optimized out>) at ../system/physmem.c:2977 +#17 0x000055a00b75c256 in kvm_cpu_exec (cpu=cpu@entry=0x55a01f9cb690) at ../accel/kvm/kvm-all.c:3184 +#18 0x000055a00b75da25 in kvm_vcpu_thread_fn (arg=arg@entry=0x55a01f9cb690) at ../accel/kvm/kvm-accel-ops.c:50 +#19 0x000055a00b94daa8 in qemu_thread_start (args=0x55a01f9d2140) at ../util/qemu-thread-posix.c:541 +#20 0x00007fe0764456d7 in start_thread (arg=<optimized out>) at pthread_create.c:447 +#21 0x00007fe0764c9414 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:100 + +``` + +Git bisect points to + +``` +commit ffa8a3e3b2e6ff017113b98d500d6a9e05b1560a (HEAD) +Author: Gao Shiyuan <gaoshiyuan@baidu.com> +Date: Tue Sep 3 20:03:04 2024 +0800 + + virtio-pci: Add lookup subregion of VirtIOPCIRegion MR + + Now virtio_address_space_lookup only lookup common/isr/device/notify + MR and exclude their subregions. + + When VHOST_USER_PROTOCOL_F_HOST_NOTIFIER enable, the notify MR has + host-notifier subregions and we need use host-notifier MR to + notify the hardware accelerator directly instead of eventfd notify. + + Further more, maybe common/isr/device MR also has subregions in + the future, so need memory_region_find for each MR incluing + their subregions. + + Add lookup subregion of VirtIOPCIRegion MR instead of only lookup container MR. + + Fixes: a93c8d8 ("virtio-pci: Replace modern_as with direct access to modern_bar") + Co-developed-by: Zuo Boqun <zuoboqun@baidu.com> + Signed-off-by: Gao Shiyuan <gaoshiyuan@baidu.com> + Signed-off-by: Zuo Boqun <zuoboqun@baidu.com> + Message-Id: <20240903120304.97833-1-gaoshiyuan@baidu.com> + Reviewed-by: Michael S. Tsirkin <mst@redhat.com> + Signed-off-by: Michael S. Tsirkin <mst@redhat.com> +``` + +cc @mstredhat diff --git a/results/classifier/105/mistranslation/266 b/results/classifier/105/mistranslation/266 new file mode 100644 index 000000000..4824b4c1d --- /dev/null +++ b/results/classifier/105/mistranslation/266 @@ -0,0 +1,14 @@ +mistranslation: 0.986 +instruction: 0.937 +device: 0.742 +semantic: 0.592 +network: 0.416 +other: 0.357 +graphic: 0.350 +boot: 0.238 +socket: 0.112 +assembly: 0.101 +vnc: 0.084 +KVM: 0.032 + +'mtfsf' instruction can clear FI incorrectly diff --git a/results/classifier/105/mistranslation/267 b/results/classifier/105/mistranslation/267 new file mode 100644 index 000000000..0338e4ff0 --- /dev/null +++ b/results/classifier/105/mistranslation/267 @@ -0,0 +1,14 @@ +mistranslation: 0.988 +device: 0.784 +instruction: 0.611 +network: 0.592 +graphic: 0.488 +semantic: 0.329 +assembly: 0.229 +boot: 0.213 +vnc: 0.176 +other: 0.175 +socket: 0.156 +KVM: 0.024 + +qemu-x86_64 segment prefixes error diff --git a/results/classifier/105/mistranslation/2684 b/results/classifier/105/mistranslation/2684 new file mode 100644 index 000000000..aeb2c5409 --- /dev/null +++ b/results/classifier/105/mistranslation/2684 @@ -0,0 +1,14 @@ +mistranslation: 0.476 +other: 0.405 +device: 0.332 +semantic: 0.302 +graphic: 0.189 +vnc: 0.104 +network: 0.086 +KVM: 0.065 +instruction: 0.048 +socket: 0.044 +boot: 0.035 +assembly: 0.018 + +scripts/archive-source.sh is not documented diff --git a/results/classifier/105/mistranslation/2694 b/results/classifier/105/mistranslation/2694 new file mode 100644 index 000000000..58a651741 --- /dev/null +++ b/results/classifier/105/mistranslation/2694 @@ -0,0 +1,37 @@ +mistranslation: 0.821 +graphic: 0.814 +vnc: 0.782 +semantic: 0.776 +instruction: 0.762 +device: 0.755 +KVM: 0.748 +network: 0.747 +other: 0.691 +boot: 0.683 +socket: 0.655 +assembly: 0.626 + +error: implicit declaration of function 'IOMainPort' is invalid in C99 +Description of problem: +Build in MacOS + Hardware Overview: + + Model Name: MacBook Air + Chip: Apple M1 + Total Number of Cores: 8 (4 performance and 4 efficiency) + Memory: 16 GB +Steps to reproduce: +1. ./configure --cpu=aarch64 --target-list=aarch64-softmmu --enable-slirp +2. make -j +Additional information: +``` +FAILED: libblock.a.p/block_file-posix.c.o +cc -Ilibblock.a.p -I. -I.. -Iqapi -Itrace -Iui -Iui/shader -Iblock -I/opt/homebrew/opt/zstd/include -I/opt/homebrew/Cellar/glib/2.82.2/include/glib-2.0 -I/opt/homebrew/Cellar/glib/2.82.2/lib/glib-2.0/include -I/opt/homebrew/opt/gettext/include -I/opt/homebrew/Cellar/pcre2/10.44/include -I/opt/homebrew/Cellar/glib/2.82.2/include -fdiagnostics-color=auto -Wall -Winvalid-pch -std=gnu11 -O2 -g -fstack-protector-strong -Wempty-body -Wendif-labels -Wexpansion-to-defined -Wformat-security -Wformat-y2k -Wignored-qualifiers -Winit-self -Wmissing-format-attribute -Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wredundant-decls -Wstrict-prototypes -Wtype-limits -Wundef -Wvla -Wwrite-strings -Wno-gnu-variable-sized-type-not-at-end -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-psabi -Wno-shift-negative-value -Wno-string-plus-int -Wno-tautological-type-limit-compare -Wno-typedef-redefinition -iquote . -iquote /Users/august/qemu/src -iquote /Users/august/qemu/src/include -iquote /Users/august/qemu/src/host/include/aarch64 -iquote /Users/august/qemu/src/host/include/generic -iquote /Users/august/qemu/src/tcg/aarch64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-strict-aliasing -fno-common -fwrapv -fno-pie -MD -MQ libblock.a.p/block_file-posix.c.o -MF libblock.a.p/block_file-posix.c.o.d -o libblock.a.p/block_file-posix.c.o -c ../block/file-posix.c +../block/file-posix.c:3940:18: error: implicit declaration of function 'IOMainPort' is invalid in C99 [-Werror,-Wimplicit-function-declaration] + kernResult = IOMainPort(MACH_PORT_NULL, &mainPort); + ^ +1 error generated. +ninja: build stopped: subcommand failed. +make[1]: *** [run-ninja] Error 1 +make: *** [build] Error 2 +``` diff --git a/results/classifier/105/mistranslation/2709 b/results/classifier/105/mistranslation/2709 new file mode 100644 index 000000000..4c70c901a --- /dev/null +++ b/results/classifier/105/mistranslation/2709 @@ -0,0 +1,14 @@ +mistranslation: 0.692 +other: 0.508 +semantic: 0.456 +device: 0.382 +socket: 0.362 +boot: 0.261 +KVM: 0.189 +vnc: 0.157 +network: 0.105 +instruction: 0.103 +graphic: 0.066 +assembly: 0.058 + +Contributing to docs is very confusing diff --git a/results/classifier/105/mistranslation/2740 b/results/classifier/105/mistranslation/2740 new file mode 100644 index 000000000..bbf466dc3 --- /dev/null +++ b/results/classifier/105/mistranslation/2740 @@ -0,0 +1,80 @@ +mistranslation: 0.612 +other: 0.590 +vnc: 0.589 +network: 0.547 +device: 0.542 +KVM: 0.542 +instruction: 0.542 +assembly: 0.520 +graphic: 0.515 +boot: 0.514 +semantic: 0.509 +socket: 0.460 + +Out-of-bounds access and heap-use-after-free in smc91c111_writeb() +Description of problem: +An out-of-bounds access bug was triggered by my fuzzer. + +The error is: + +``` +../hw/net/smc91c111.c:457:17: runtime error: index 48 out of bounds for type 'uint8_t[4][2048]' (aka 'unsigned char[4][2048]') +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/net/smc91c111.c:457:17 in +================================================================= +==60006==ERROR: AddressSanitizer: heap-use-after-free on address 0x6290000385b4 at pc 0x5de3d1ac6add bp 0x7ffc4d4b2b30 sp 0x7ffc4d4b2b28 +WRITE of size 1 at 0x6290000385b4 thread T0 +warning: DWARF unit at offset 0x00417a37 has unsupported address size: 31 (supported are 2, 4, 8) + #0 0x5de3d1ac6adc in smc91c111_writeb smc91c111.c + #1 0x5de3d1abf6e3 in smc91c111_writefn smc91c111.c + #2 0x5de3d2d9e2d3 in memory_region_write_accessor memory.c + #3 0x5de3d2d9da4a in access_with_adjusted_size memory.c + #4 0x5de3d2d9ce78 in memory_region_dispatch_write + #5 0x5de3d2df5e44 in flatview_write_continue_step physmem.c + #6 0x5de3d2de2d40 in flatview_write physmem.c + #7 0x5de3d2de29d7 in address_space_write + ... + +0x6290000385b4 is located 5044 bytes inside of 16176-byte region [0x629000037200,0x62900003b130) +freed by thread T0 here: + #0 0x5de3d1100027 in __interceptor_free.part.0 asan_malloc_linux.cpp + #1 0x5de3d2f35106 in object_unref + #2 0x5de3d24ac45c in qemu_get_nic_models + #3 0x5de3d24acead in qemu_create_nic_bus_devices + #4 0x5de3d2722553 in realview_init realview.c + #5 0x5de3d1468182 in machine_run_board_init + #6 0x5de3d237e40a in qmp_x_exit_preconfig + #7 0x5de3d238505c in qemu_init + ... + +previously allocated by thread T0 here: + #0 0x5de3d1101217 in malloc + #1 0x7ea39d40a738 in g_malloc + #2 0x5de3d24acead in qemu_create_nic_bus_devices + #3 0x5de3d2722553 in realview_init realview.c + #4 0x5de3d1468182 in machine_run_board_init + #5 0x5de3d237e40a in qmp_x_exit_preconfig + #6 0x5de3d238505c in qemu_init + ... +``` +Steps to reproduce: +``` +export QEMU_ARGS="-display none -machine accel=qtest, -m 512M -machine realview-eb" +cat << EOF | ./qemu-system-arm $QEMU_ARGS -qtest /dev/null -qtest stdio +clock_step +readw 0x4e000000 +readw 0x4e000000 +clock_step +writel 0x4e00000c 0x2402e660 +readb 0x4e000008 +readl 0x4e000000 +clock_step +readb 0x4e000000 +writel 0x4e000000 0x66308c81 +writew 0x4e000008 0xe40ba4c +readb 0x4e000000 +readw 0x4e000000 +readl 0x4e000008 +EOF +``` +Additional information: + diff --git a/results/classifier/105/mistranslation/2766 b/results/classifier/105/mistranslation/2766 new file mode 100644 index 000000000..e69063f99 --- /dev/null +++ b/results/classifier/105/mistranslation/2766 @@ -0,0 +1,36 @@ +mistranslation: 0.879 +graphic: 0.869 +instruction: 0.761 +device: 0.732 +semantic: 0.674 +network: 0.537 +socket: 0.462 +other: 0.416 +vnc: 0.352 +boot: 0.233 +assembly: 0.199 +KVM: 0.170 + +Qemu 9.2: stubs: build issue with --enable-user --disable-system --enable-tools +Description of problem: +Since commit "[stubs: avoid duplicate symbols in libqemuutil.a](https://gitlab.com/qemu-project/qemu/-/commit/388b849fb6c33882b481123568995a749a54f648)", Qemu doesn't build with: + + ./configure --enable-user --disable-system --enable-tools + + /usr/bin/ld: libhwcore.a.p/hw_core_qdev.c.o: in function 'device_finalize': \ + /home/autobuild/autobuild/instance-2/output-1/build/host-qemu-9.2.0/build/../hw/core/qdev.c:689:(.text+0x75c): undefined reference to 'qapi_event_send_device_deleted' + collect2: error: ld returned 1 exit status + +See Buildroot automated build results: +http://autobuild.buildroot.org/?reason=host-qemu-9.2.0 + +Indeed, with have_system = false and have_tools = true, Qemu needs the stubs for QAPI events added by stub_ss.add(files('qdev.c')) to provide qapi_event_send_device_deleted. + +Maybe the change in stubs/meson.build should have been: \ + +if not have_system and have_tools \ +stub_ss.add(files('qdev.c')) \ +endif + +Best regards, +Romain diff --git a/results/classifier/105/mistranslation/2770 b/results/classifier/105/mistranslation/2770 new file mode 100644 index 000000000..2d1d4d6f1 --- /dev/null +++ b/results/classifier/105/mistranslation/2770 @@ -0,0 +1,27 @@ +mistranslation: 0.995 +device: 0.853 +network: 0.713 +graphic: 0.708 +semantic: 0.701 +instruction: 0.699 +vnc: 0.670 +KVM: 0.531 +socket: 0.485 +boot: 0.356 +assembly: 0.131 +other: 0.110 + +Build failure due to missing keyctl_pkey_encrypt +Description of problem: + +Steps to reproduce: +1. git checkout v7.2.0 +2. ./configure --target-list=arm-softmmu;make +3. ../backends/cryptodev-lkcf.c: In function ‘cryptodev_lkcf_execute_task’: +../backends/cryptodev-lkcf.c:358:19: error: implicit declaration of function ‘keyctl_pkey_encrypt’; did you mean ‘keyctl_reject’? [-Werror=implicit-function-declaration] + ret = keyctl_pkey_encrypt(key_id, op_desc, + ^~~~~~~~~~~~~~~~~~~ + keyctl_reject +../backends/cryptodev-lkcf.c:358:19: error: nested extern declaration of ‘keyctl_pkey_encrypt’ [-Werror=nested-externs] +Additional information: + diff --git a/results/classifier/105/mistranslation/2776 b/results/classifier/105/mistranslation/2776 new file mode 100644 index 000000000..954ca1587 --- /dev/null +++ b/results/classifier/105/mistranslation/2776 @@ -0,0 +1,14 @@ +mistranslation: 0.814 +device: 0.792 +network: 0.696 +other: 0.522 +vnc: 0.498 +graphic: 0.497 +boot: 0.449 +semantic: 0.336 +KVM: 0.283 +assembly: 0.248 +socket: 0.234 +instruction: 0.130 + +OHCI: Incorrectly reports an overrun error diff --git a/results/classifier/105/mistranslation/2786 b/results/classifier/105/mistranslation/2786 new file mode 100644 index 000000000..4da90a1ed --- /dev/null +++ b/results/classifier/105/mistranslation/2786 @@ -0,0 +1,24 @@ +mistranslation: 0.925 +device: 0.868 +graphic: 0.814 +semantic: 0.628 +instruction: 0.499 +boot: 0.274 +other: 0.261 +assembly: 0.245 +vnc: 0.047 +network: 0.021 +socket: 0.007 +KVM: 0.005 + +deleting files fails on vvfat (was: "error handling renames") +Description of problem: +When working with files, renaming or saving from IDE, QEMU halts with the error message: + +"Error handling renames (-2)" +Steps to reproduce: +1. +2. +3. +Additional information: +a previous del failed, the directories are not synced so the rename on the drive fails when the file with the target file name still exists on the real directory. So the real issue is a failed del. diff --git a/results/classifier/105/mistranslation/2795 b/results/classifier/105/mistranslation/2795 new file mode 100644 index 000000000..b6a0cdf13 --- /dev/null +++ b/results/classifier/105/mistranslation/2795 @@ -0,0 +1,173 @@ +mistranslation: 0.579 +other: 0.564 +graphic: 0.560 +vnc: 0.548 +boot: 0.541 +instruction: 0.531 +device: 0.523 +network: 0.519 +KVM: 0.516 +assembly: 0.505 +socket: 0.499 +semantic: 0.496 + +qemu-system-aarch64 crash when issuing set_link net on in monitor +Description of problem: +Boot the guest. On the host, connect to the qemu monitor and issue the following commmands: +``` +set_link net0 off +ethtool enp0s1 on the guest now shows the link going down +set_link net0 on +``` + +qemu crashes as follows (virtio net): +``` +Thread 1 "qemu-system-aar" received signal SIGSEGV, Segmentation fault. +object_get_class (obj=obj@entry=0x0) at ../qemu/qom/object.c:1049 +1049 return obj->class; +(gdb) bt +#0 object_get_class (obj=obj@entry=0x0) at ../qemu/qom/object.c:1049 +#1 0x000055555602dd0f in QIO_CHANNEL_GET_CLASS (obj=0x0) + at /home/tsailer/src/daedalean/exp-bertcard-emu/qemu/include/io/channel.h:29 +#2 qio_channel_writev_full + (errp=0x0, flags=0, nfds=0, fds=0x0, niov=2, iov=0x7fffffff5190, ioc=0x0) + at ../qemu/io/channel.c:87 +#3 qio_channel_writev + (ioc=0x0, iov=iov@entry=0x7fffffff5190, niov=2, errp=errp@entry=0x0) + at ../qemu/io/channel.c:305 +#4 0x0000555555c42a66 in net_stream_receive + (nc=0x5555578477d0, buf=<optimized out>, size=90) + at ../qemu/net/stream.c:98 +#5 0x0000555555c3d327 in nc_sendv_compat + (flags=<optimized out>, iovcnt=1, iov=0x7fffffff52f0, nc=0x5555578477d0) + at ../qemu/net/net.c:784 +#6 qemu_deliver_packet_iov + (sender=<optimized out>, flags=<optimized out>, iov=0x7fffffff52f0, iovcnt=1, opaque=0x5555578477d0) at ../qemu/net/net.c:830 +#7 0x0000555555c4106c in qemu_net_queue_deliver_iov + (iovcnt=1, iov=0x7fffffff52f0, flags=0, sender=0x5555583049d8, queue=0x55555783c5e0) at ../qemu/net/queue.c:179 +#8 qemu_net_queue_send_iov + (queue=0x55555783c5e0, sender=0x5555583049d8, flags=flags@entry=0, iov=iov@entry=0x7fffffff52f0, iovcnt=iovcnt@entry=1, sent_cb=sent_cb@entry=0x555555f28fa0 <virtio_net_tx_complete>) at ../qemu/net/queue.c:235 +#9 0x0000555555c3ed63 in qemu_sendv_packet_async + (sent_cb=0x555555f28fa0 <virtio_net_tx_complete>, iovcnt=1, iov=0x7fffffff52f0, sender=<optimized out>) at ../qemu/net/net.c:875 +#10 0x0000555555f28c1d in virtio_net_flush_tx (q=q@entry=0x5555582fcb00) + at ../qemu/hw/net/virtio-net.c:2795 +#11 0x0000555555f28f18 in virtio_net_tx_bh (opaque=0x5555582fcb00) + at ../qemu/hw/net/virtio-net.c:2948 +#12 0x00005555561c2f47 in aio_bh_call (bh=bh@entry=0x5555582d0b30) + at ../qemu/util/async.c:172 +#13 0x00005555561c311e in aio_bh_poll (ctx=ctx@entry=0x5555574c3c10) + at ../qemu/util/async.c:219 +#14 0x00005555561ab382 in aio_dispatch (ctx=0x5555574c3c10) + at ../qemu/util/aio-posix.c:424 +#15 0x00005555561c2d82 in aio_ctx_dispatch + (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at ../qemu/util/async.c:361 +#16 0x00007ffff7ad5d3b in g_main_context_dispatch () + at /lib/x86_64-linux-gnu/libglib-2.0.so.0 +#17 0x00005555561c45d8 in glib_pollfds_poll () at ../qemu/util/main-loop.c:287 +#18 os_host_main_loop_wait (timeout=0) at ../qemu/util/main-loop.c:310 +#19 main_loop_wait (nonblocking=nonblocking@entry=0) + at ../qemu/util/main-loop.c:589 +#20 0x0000555555bf2569 in qemu_main_loop () at ../qemu/system/runstate.c:835 +#21 0x00005555561047fa in qemu_default_main () at ../qemu/system/main.c:37 +#22 0x00007ffff7229d90 in __libc_start_call_main + (main=main@entry=0x5555558e5080 <main>, argc=argc@entry=44, argv=argv@entry=0x7fffffffd6c8) + at ../sysdeps/nptl/libc_start_call_main.h:58 +#23 0x00007ffff7229e40 in __libc_start_main_impl + (main=0x5555558e5080 <main>, argc=44, argv=0x7fffffffd6c8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffd6b8) + at ../csu/libc-start.c:392 +#24 0x00005555558e6095 in _start () + +Crash with e1000e: +[ 16.846673] e1000e 0000:00:02.0 enp0s2: NIC Link is Down +[ 18.495388] e1000e 0000:00:02.0 enp0s2: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx + +Thread 5 "qemu-system-aar" received signal SIGSEGV, Segmentation fault. +[Switching to Thread 0x7fffafe00640 (LWP 641377)] +object_get_class (obj=obj@entry=0x0) at ../qemu/qom/object.c:1049 +1049 return obj->class; +(gdb) bt +#0 object_get_class (obj=obj@entry=0x0) at ../qemu/qom/object.c:1049 +#1 0x000055555602dd0f in QIO_CHANNEL_GET_CLASS (obj=0x0) + at /home/tsailer/src/daedalean/exp-bertcard-emu/qemu/include/io/channel.h:29 +#2 qio_channel_writev_full + (errp=0x0, flags=0, nfds=0, fds=0x0, niov=2, iov=0x7fffafdfe9b0, ioc=0x0) + at ../qemu/io/channel.c:87 +#3 qio_channel_writev + (ioc=0x0, iov=iov@entry=0x7fffafdfe9b0, niov=2, errp=errp@entry=0x0) + at ../qemu/io/channel.c:305 +#4 0x0000555555c42a66 in net_stream_receive + (nc=0x5555578589b0, buf=<optimized out>, size=90) + at ../qemu/net/stream.c:98 +#5 0x0000555555c3d327 in nc_sendv_compat + (flags=<optimized out>, iovcnt=3, iov=0x55555850b280, nc=0x5555578589b0) + at ../qemu/net/net.c:784 +#6 qemu_deliver_packet_iov + (sender=<optimized out>, flags=<optimized out>, iov=0x55555850b280, iovcnt=3, opaque=0x5555578589b0) at ../qemu/net/net.c:830 +#7 0x0000555555c4106c in qemu_net_queue_deliver_iov + (iovcnt=3, iov=0x55555850b280, flags=0, sender=0x5555584facf8, queue=0x55555783c6d0) at ../qemu/net/queue.c:179 +#8 qemu_net_queue_send_iov + (queue=0x55555783c6d0, sender=0x5555584facf8, flags=0, iov=0x55555850b280, iovcnt=3, sent_cb=0x0) at ../qemu/net/queue.c:235 +#9 0x0000555555a62737 in net_tx_pkt_send_custom + (pkt=0x5555584fb200, offload=<optimized out>, callback=0x555555a61150 <net_tx_pkt_sendv>, context=0x5555584facf8) at ../qemu/hw/net/net_tx_pkt.c:847 +#10 0x0000555555a62819 in net_tx_pkt_send + (pkt=<optimized out>, nc=<optimized out>) + at ../qemu/hw/net/net_tx_pkt.c:816 +#11 0x0000555555a6dd2a in e1000e_tx_pkt_send + (queue_index=<optimized out>, tx=0x555558480cc8, core=0x555558460a60) + at ../qemu/hw/net/e1000e_core.c:654 +#12 e1000e_process_tx_desc + (queue_index=<optimized out>, dp=0x7fffafdfeb20, tx=0x555558480cc8, core=0x555558460a60) at ../qemu/hw/net/e1000e_core.c:731 +#13 e1000e_start_xmit (core=0x555558460a60, txr=txr@entry=0x7fffafdfeb90) + at ../qemu/hw/net/e1000e_core.c:921 +#14 0x0000555555a6dfcc in e1000e_set_tdt + (core=<optimized out>, index=<optimized out>, val=<optimized out>) + at ../qemu/hw/net/e1000e_core.c:2432 +#15 0x0000555555f72044 in memory_region_write_accessor + (mr=0x555558460610, addr=14360, value=<optimized out>, size=4, shift=<optimized out>, mask=<optimized out>, attrs=...) at ../qemu/system/memory.c:497 +#16 0x0000555555f7320e in access_with_adjusted_size + (addr=addr@entry=14360, value=value@entry=0x7fffafdfece8, size=size@entry=4, + access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=0x555555f71fc0 <memory_region_write_accessor>, mr=<optimized out>, attrs=...) at ../qemu/system/memory.c:573 +#17 0x0000555555f743ad in memory_region_dispatch_write + (mr=mr@entry=0x555558460610, addr=addr@entry=14360, data=<optimized out>, + data@entry=19, op=op@entry=MO_32, attrs=...) + at ../qemu/system/memory.c:1560 +#18 0x0000555555fc6cc9 in int_st_mmio_leN + (cpu=cpu@entry=0x55555789a140, full=full@entry=0x7fffa47eab90, val_le=val_le@entry=19, addr=addr@entry=18446743801007585304, size=size@entry=4, mmu_idx=mmu_idx@entry=2, ra=140736286290890, mr=0x555558460610, mr_offset=14360) + at ../qemu/accel/tcg/cputlb.c:2489 +#19 0x0000555555fc6ec8 in do_st_mmio_leN + (cpu=0x55555789a140, full=0x7fffa47eab90, val_le=19, addr=18446743801007585304, size=4, mmu_idx=2, ra=140736286290890) at ../qemu/accel/tcg/cputlb.c:2524 +#20 0x0000555555fcb55a in do_st_4 + (ra=<optimized out>, memop=<optimized out>, mmu_idx=<optimized out>, val=19, p=<optimized out>, cpu=<optimized out>) at ../qemu/accel/tcg/cputlb.c:2694 +#21 do_st4_mmu + (cpu=0x55555789a140, addr=140736144075184, val=19, oi=2, ra=140736286290890) at ../qemu/accel/tcg/cputlb.c:2770 +#22 0x00007fffb859f416 in code_gen_buffer () +#23 0x0000555555fbb6a6 in cpu_tb_exec + (cpu=cpu@entry=0x55555789a140, itb=itb@entry=0x7fffb859f2c0 <code_gen_buffer+140112531>, tb_exit=tb_exit@entry=0x7fffafdff444) + at ../qemu/accel/tcg/cpu-exec.c:458 +#24 0x0000555555fbbc2f in cpu_loop_exec_tb + (tb_exit=0x7fffafdff444, last_tb=<synthetic pointer>, pc=<optimized out>, tb=0x7fffb859f2c0 <code_gen_buffer+140112531>, cpu=0x55555789a140) + at ../qemu/accel/tcg/cpu-exec.c:908 +#25 cpu_exec_loop (cpu=cpu@entry=0x55555789a140, sc=sc@entry=0x7fffafdff4f0) + at ../qemu/accel/tcg/cpu-exec.c:1022 +#26 0x0000555555fbc3d1 in cpu_exec_setjmp + (cpu=cpu@entry=0x55555789a140, sc=sc@entry=0x7fffafdff4f0) + at ../qemu/accel/tcg/cpu-exec.c:1039 +#27 0x0000555555fbcb9d in cpu_exec (cpu=cpu@entry=0x55555789a140) + at ../qemu/accel/tcg/cpu-exec.c:1065 +#28 0x0000555555fd8123 in tcg_cpu_exec (cpu=cpu@entry=0x55555789a140) + at ../qemu/accel/tcg/tcg-accel-ops.c:78 +#29 0x0000555555fd8280 in mttcg_cpu_thread_fn (arg=arg@entry=0x55555789a140) + at ../qemu/accel/tcg/tcg-accel-ops-mttcg.c:95 +#30 0x00005555561ae740 in qemu_thread_start (args=0x555557883000) + at ../qemu/util/qemu-thread-posix.c:541 +#31 0x00007ffff7294ac3 in start_thread (arg=<optimized out>) + at ./nptl/pthread_create.c:442 +#32 0x00007ffff7326850 in clone3 () + at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 +``` +Steps to reproduce: +1. Boot guest +2. monitor: set_link net0 off +3. monitor: set_link net0 on +Additional information: +Same behaviour with d6430c17d7113d3c38480dc34e59d00b0504e2f7 (master as of 2025-01-19). diff --git a/results/classifier/105/mistranslation/2811 b/results/classifier/105/mistranslation/2811 new file mode 100644 index 000000000..e07683ea6 --- /dev/null +++ b/results/classifier/105/mistranslation/2811 @@ -0,0 +1,107 @@ +mistranslation: 0.745 +KVM: 0.730 +graphic: 0.724 +other: 0.713 +assembly: 0.675 +vnc: 0.658 +device: 0.652 +instruction: 0.642 +socket: 0.642 +semantic: 0.616 +boot: 0.609 +network: 0.539 + +The release artifact for 9.2.1 can not be authenticated with the accompanying OpenPGP signature +Description of problem: +Hi! :wave: + +I package this project for Arch Linux. +This ticket is to inform you that the release artifact for 9.2.1 can not be validated using the accompanying OpenPGP signature. +The signature has been created by the OpenPGP key with the fingerprint `CEACC9E15534EBABB82D3FA03353C9CEF108B584` (held by @mdroth). +However, I am not able to validate the downloaded archive with the provided signature. + +Please make sure that the archive has not been tampered with and ideally do a full re-release and re-sign cycle. +Steps to reproduce: +Download sources and create checksum: + +```bash +curl -O https://download.qemu.org/qemu-9.2.1.tar.xz +curl -O https://download.qemu.org/qemu-9.2.1.tar.xz.sig +b2sum qemu-9.2.1.tar.xz +062b2ef336dbc488bfd9e6c6a21cd95464ab76a98ce8f66bb314101d25a5dc72815ae4eb28028507c85ddade8a28e00cf8897302645ad6ddd2c093bde1cfba9a qemu-9.2.1.tar.xz +``` + +Get latest version of certificate that can be used to verify the signature: + +```bash +gpg --recv-keys CEACC9E15534EBABB82D3FA03353C9CEF108B584 +gpg: key 3353C9CEF108B584: "Michael Roth <michael.roth@amd.com>" not changed +gpg: Total number processed: 1 +gpg: unchanged: 1 +``` + +Export certificate to file: + +```bash +gpg --export CEACC9E15534EBABB82D3FA03353C9CEF108B584 > mdroth.pgp +``` + +Show info about the certificate: + +``` +gpg --list-sigs CEACC9E15534EBABB82D3FA03353C9CEF108B584 +pub rsa2048 2013-10-18 [SC] [expires: 2026-05-11] + CEACC9E15534EBABB82D3FA03353C9CEF108B584 + Keygrip = D85EA26924D8B15B55C659659E2864C375F1547D +uid [ unknown] Michael Roth <michael.roth@amd.com> +sig 3 3353C9CEF108B584 2020-10-27 [self-signature] +sig 3 3353C9CEF108B584 2024-05-11 [self-signature] +uid [ unknown] Michael Roth <flukshun@gmail.com> +sig 3 3353C9CEF108B584 2013-10-18 [self-signature] +uid [ unknown] Michael Roth <mdroth@utexas.edu> +sig 3 3353C9CEF108B584 2013-10-18 [self-signature] +sub rsa2048 2013-10-18 [E] + Keygrip = 9561B09210E2442DEE64237DBA17A9E9D7A58B04 +sig 3353C9CEF108B584 2013-10-18 [self-signature] +``` + +Try verifying the tarball using gpg: + +```bash +gpg --verify qemu-9.2.1.tar.xz.sig +gpg: assuming signed data in 'qemu-9.2.1.tar.xz' +gpg: Signature made 2025-02-12T03:22:55 CET +gpg: using RSA key CEACC9E15534EBABB82D3FA03353C9CEF108B584 +gpg: BAD signature from "Michael Roth <michael.roth@amd.com>" [unknown] +``` + +Try verifying the tarball using the SOP implementation rsop: + +```bash +rsop verify qemu-9.2.1.tar.xz.sig mdroth.pgp < qemu-9.2.1.tar.xz + No acceptable signatures found +``` + +Try verifying the tarball using sq: + +```bash +sq cert import mdroth.pgp + - ┌ CEACC9E15534EBABB82D3FA03353C9CEF108B584 + └ Michael Roth <michael.roth@amd.com> (UNAUTHENTICATED) + - imported + + +Imported 0 new certificates, updated 0 certificates, 1 certificate unchanged, 0 errors. + +sq verify --signature-file qemu-9.2.1.tar.xz.sig qemu-9.2.1.tar.xz +Error verifying signature made by CEACC9E15534EBABB82D3FA03353C9CEF108B584: + + Error: Message has been manipulated +0 authenticated signatures, 1 bad signature. + + Error: Verification failed: could not authenticate any signatures +``` +Additional information: +On Arch Linux we use the provided release tarball and verify it using the detached signature. +For validation we rely on the OpenPGP certificate with the fingerprint `CEACC9E15534EBABB82D3FA03353C9CEF108B584`. +The fingerprint is locked in our [build script](https://gitlab.archlinux.org/archlinux/packaging/packages/qemu/-/blob/7cddf5aa82542d6ba511a22aeaa8eca6d6e7d949/PKGBUILD#L158). diff --git a/results/classifier/105/mistranslation/2823 b/results/classifier/105/mistranslation/2823 new file mode 100644 index 000000000..ff4c52cd8 --- /dev/null +++ b/results/classifier/105/mistranslation/2823 @@ -0,0 +1,56 @@ +mistranslation: 0.723 +other: 0.722 +semantic: 0.676 +instruction: 0.661 +graphic: 0.661 +assembly: 0.642 +boot: 0.639 +vnc: 0.618 +device: 0.616 +KVM: 0.558 +socket: 0.511 +network: 0.472 + +func-aarch64-aarch64_rme_virt function test hangs especially when built with --enable-debug +Description of problem: + +Steps to reproduce: +1. Build with ../../configure --enable-debug +2. ./pyvenv/bin/meson test --setup thorough --suite func-thorough func-aarch64-aarch64_rme_virt +3. repeat until hang +Additional information: +Comparing a normal build to the hang: + +``` +2025-02-20 16:54:15,519: NOTICE: Booting Trusted Firmware | 2025-02-20 16:16:06,740: NOTICE: Booting Trusted Firmware +2025-02-20 16:54:15,519: NOTICE: BL1: v2.11.0(release):f2f94 | 2025-02-20 16:16:06,740: NOTICE: BL1: v2.11.0(release):f2f94 +2025-02-20 16:54:15,519: NOTICE: BL1: Built : 17:54:58, Dec | 2025-02-20 16:16:06,740: NOTICE: BL1: Built : 17:54:58, Dec +2025-02-20 16:54:15,520: NOTICE: BL1: Booting BL2 | 2025-02-20 16:16:06,741: NOTICE: BL1: Booting BL2 +2025-02-20 16:54:15,522: NOTICE: BL2: v2.11.0(release):f2f94 | 2025-02-20 16:16:06,743: NOTICE: BL2: v2.11.0(release):f2f94 +2025-02-20 16:54:15,522: NOTICE: BL2: Built : 17:55:12, Dec | 2025-02-20 16:16:06,743: NOTICE: BL2: Built : 17:55:12, Dec +2025-02-20 16:54:15,545: NOTICE: BL2: Booting BL31 | 2025-02-20 16:16:06,762: NOTICE: BL2: Booting BL31 +2025-02-20 16:54:15,550: NOTICE: BL31: v2.11.0(release):f2f9 | 2025-02-20 16:16:06,768: NOTICE: BL31: v2.11.0(release):f2f9 +2025-02-20 16:54:15,550: NOTICE: BL31: Built : 17:55:22, Dec | 2025-02-20 16:16:06,768: NOTICE: BL31: Built : 17:55:22, Dec +2025-02-20 16:54:15,555: Booting RMM v.0.5.0(release) 1b6bdf8 | 2025-02-20 16:16:06,774: Booting RMM v.0.5.0(release) 1b6bdf8 +2025-02-20 16:54:15,556: RMM-EL3 Interface v.0.4 | 2025-02-20 16:16:06,774: RMM-EL3 Interface v.0.4 +2025-02-20 16:54:15,556: Boot Manifest Interface v.0.3 | 2025-02-20 16:16:06,775: Boot Manifest Interface v.0.3 +2025-02-20 16:54:15,556: RMI/RSI ABI v.1.0/1.0 built: Dec 2 | 2025-02-20 16:16:06,775: RMI/RSI ABI v.1.0/1.0 built: Dec 2 +2025-02-20 16:54:15,587: UEFI firmware (version built at 17: | 2025-02-20 16:16:06,837: UEFI firmware (version built at 17: +2025-02-20 16:54:15,876: ESC[2JESC[01;01HESC[=3hESC[2JESC[01;01HESC[2JESC[01;01HESC[= | 2025-02-20 16:16:07,420: ESC[2JESC[01;01HESC[=3hESC[2JESC[01;01HESC[2JESC[01;01HESC[= +2025-02-20 16:54:15,898: EFI stub: Using DTB from configurati | 2025-02-20 16:16:07,421: +2025-02-20 16:54:15,898: EFI stub: Exiting boot services... | 2025-02-20 16:16:07,421: +2025-02-20 16:54:16,170: [ 0.000000] Booting Linux on phys | 2025-02-20 16:16:07,421: Synchronous Exception at 0x00000000B +2025-02-20 16:54:16,171: [ 0.000000] Linux version 6.12.0- | 2025-02-20 16:16:07,421: +2025-02-20 16:54:16,171: [ 0.000000] KASLR enabled | 2025-02-20 16:16:07,421: +2025-02-20 16:54:16,171: [ 0.000000] random: crng init don | 2025-02-20 16:16:07,421: Synchronous Exception at 0x00000000B +2025-02-20 16:54:16,171: [ 0.000000] Machine model: linux, < +2025-02-20 16:54:16,171: [ 0.000000] efi: EFI v2.7 by EDK < +2025-02-20 16:54:16,171: [ 0.000000] efi: SMBIOS=0xbf3c000 < +2025-02-20 16:54:16,171: [ 0.000000] OF: reserved mem: 0x0 < +2025-02-20 16:54:16,171: [ 0.000000] NUMA: Faking a node a < +2025-02-20 16:54:16,171: [ 0.000000] NODE_DATA(0) allocate < +2025-02-20 16:54:16,171: [ 0.000000] Zone ranges: < +2025-02-20 16:54:16,171: [ 0.000000] DMA [mem 0x000 < +2025-02-20 16:54:16,171: [ 0.000000] DMA32 empty < +2025-02-20 16:54:16,171: [ 0.000000] Normal empty < +``` diff --git a/results/classifier/105/mistranslation/2837 b/results/classifier/105/mistranslation/2837 new file mode 100644 index 000000000..13af9b839 --- /dev/null +++ b/results/classifier/105/mistranslation/2837 @@ -0,0 +1,14 @@ +mistranslation: 0.950 +graphic: 0.824 +device: 0.786 +network: 0.748 +semantic: 0.462 +vnc: 0.137 +other: 0.112 +boot: 0.111 +instruction: 0.034 +socket: 0.033 +assembly: 0.029 +KVM: 0.007 + +qcow2 corruption MinGW64 diff --git a/results/classifier/105/mistranslation/2868 b/results/classifier/105/mistranslation/2868 new file mode 100644 index 000000000..6600aad5d --- /dev/null +++ b/results/classifier/105/mistranslation/2868 @@ -0,0 +1,16 @@ +mistranslation: 0.997 +device: 0.905 +other: 0.902 +instruction: 0.872 +graphic: 0.658 +network: 0.544 +semantic: 0.383 +boot: 0.241 +assembly: 0.230 +socket: 0.220 +vnc: 0.087 +KVM: 0.021 + +amd iommu pte is only 32bits not 64bits. +Additional information: + diff --git a/results/classifier/105/mistranslation/2879 b/results/classifier/105/mistranslation/2879 new file mode 100644 index 000000000..bae7461bc --- /dev/null +++ b/results/classifier/105/mistranslation/2879 @@ -0,0 +1,14 @@ +mistranslation: 0.741 +network: 0.699 +device: 0.687 +instruction: 0.611 +graphic: 0.476 +other: 0.285 +socket: 0.254 +assembly: 0.219 +boot: 0.216 +semantic: 0.178 +KVM: 0.087 +vnc: 0.055 + +-smbios type=11,path=xxx results in buffer overrun due to missing null terminator diff --git a/results/classifier/105/mistranslation/2901 b/results/classifier/105/mistranslation/2901 new file mode 100644 index 000000000..c6e69c100 --- /dev/null +++ b/results/classifier/105/mistranslation/2901 @@ -0,0 +1,14 @@ +mistranslation: 0.945 +device: 0.597 +graphic: 0.420 +network: 0.360 +vnc: 0.282 +socket: 0.253 +boot: 0.227 +other: 0.191 +semantic: 0.175 +instruction: 0.087 +KVM: 0.037 +assembly: 0.031 + +Critical typo in qemu_source_dir/plugins/loader.c diff --git a/results/classifier/105/mistranslation/2932 b/results/classifier/105/mistranslation/2932 new file mode 100644 index 000000000..e839d598c --- /dev/null +++ b/results/classifier/105/mistranslation/2932 @@ -0,0 +1,14 @@ +mistranslation: 0.986 +other: 0.736 +device: 0.613 +graphic: 0.548 +semantic: 0.486 +network: 0.347 +instruction: 0.096 +boot: 0.082 +vnc: 0.076 +assembly: 0.068 +socket: 0.045 +KVM: 0.008 + +QEMU flag fuzz targets not WAI diff --git a/results/classifier/105/mistranslation/2942 b/results/classifier/105/mistranslation/2942 new file mode 100644 index 000000000..442b7937b --- /dev/null +++ b/results/classifier/105/mistranslation/2942 @@ -0,0 +1,78 @@ +mistranslation: 0.875 +other: 0.870 +instruction: 0.869 +assembly: 0.854 +graphic: 0.844 +device: 0.838 +KVM: 0.829 +semantic: 0.825 +boot: 0.811 +socket: 0.809 +network: 0.792 +vnc: 0.788 + +arm: TCG debug assertion failure when handling an ISB or SB insn inside an IT block +Description of problem: +ARM thumb `IT` instruction triggers TCG debug asserts. + +``` +$ ./qemu-system-arm --version +QEMU emulator version 10.0.0 (v10.0.0) + +$ ./qemu-system-arm -M stm32vldiscovery -nographic -device loader,file=raw-it-bug.hex -d in_asm,exec +[...] +Trace 0: 0x72a584000800 [00800400/0000000000000164/00000110/ff020000] +---------------- +IN: +0x00000108: f000 f80a bl #0x120 + +Trace 0: 0x72a584000940 [00800400/0000000000000108/00000110/ff020000] +qemu-system-arm: ../tcg/tcg-op.c:3343: void tcg_gen_goto_tb(unsigned int): Assertion `(tcg_ctx->goto_tb_issue_mask & (1 << idx)) == 0' failed. +``` + +Expected behavior: +``` +$ qemu-system-arm -M stm32vldiscovery -device loader,file=raw-hardfault.hex -d in_asm,exec,int +[...] +Trace 0: 0x7df6dc000800 [00800400/0000000000000164/00000110/ff020000] +---------------- +IN: +0x00000108: f000 f80a bl #0x120 + +Trace 0: 0x7df6dc000940 [00800400/0000000000000108/00000110/ff020000] +---------------- +IN: +0x00000120: 2302 movs r3, #2 +0x00000122: bf00 nop +0x00000124: f04f 25e0 mov.w r5, #-0x1fff2000 +0x00000128: f8d5 1d10 ldr.w r1, [r5, #0xd10] +0x0000012c: f041 0014 orr r0, r1, #0x14 +0x00000130: f8c5 0d10 str.w r0, [r5, #0xd10] +0x00000134: f8d5 0200 ldr.w r0, [r5, #0x200] +0x00000138: f8d5 6100 ldr.w r6, [r5, #0x100] +0x0000013c: 4206 tst r6, r0 +0x0000013e: bf02 ittt eq +0x00000140: f3bf 8f4f dsbeq sy +0x00000144: bf20 wfeeq + +Linking TBs 0x7df6dc000940 index 0 -> 0x7df6dc000a80 +Trace 0: 0x7df6dc000a80 [00800400/0000000000000120/00000110/ff020000] +[...] +Trace 0: 0x7df6dc001fc0 [00800400/0000000000000170/00000110/ff020000] +Taking exception 3 [Prefetch Abort] on CPU 0 +...at fault address 0xdeadbeee +...with CFSR.IACCVIOL +...BusFault with BFSR.STKERR +...taking pending nonsecure exception 3 +...loading from element 3 of non-secure vector table at 0xc +...loaded new PC 0x111 +---------------- +IN: +0x00000110: e7fe b #0x110 +``` +Steps to reproduce: +1. Build QEMU with `CONFIG_DEBUG_TCG` enabled, e.g. with `./configure --enable-debug`. +1. Run Cortex-M firmware with `IT` instruction. (minimal example attached) +Additional information: +- Minimal Reproducer: [raw-it-bug.hex](/uploads/3ae30ab78f49bbc933e48c51f6bf2a2b/raw-it-bug.hex) +- Reproduced on `main`, `v10.0.0` and `v9.1.0`. diff --git a/results/classifier/105/mistranslation/2949 b/results/classifier/105/mistranslation/2949 new file mode 100644 index 000000000..f1fc3458a --- /dev/null +++ b/results/classifier/105/mistranslation/2949 @@ -0,0 +1,30 @@ +mistranslation: 0.850 +device: 0.739 +instruction: 0.701 +graphic: 0.700 +vnc: 0.647 +other: 0.634 +network: 0.598 +semantic: 0.494 +socket: 0.368 +assembly: 0.364 +boot: 0.245 +KVM: 0.124 + +VNC: virtio-gpu outputs not displayed by VNC client +Description of problem: +When combining virtio-gpu multiple outputs with VNC display, only output 0 is enabled. +Additional output are enabled when VNC client sent SetDesktopSize command. + +The following statement assumes that all displays (gtk, sdl) are disabled except VNC: + +# +Steps to reproduce: +1. Start Qemu +2. Start a VNC client on 5900 +3. Start the second VNC client on 5901 +Additional information: +The state of an output is controlled by the [enabled_output_bitmask](https://gitlab.com/qemu-project/qemu/-/blob/master/include/hw/virtio/virtio-gpu.h#L158) which is initialized to `1` at [device realization](https://gitlab.com/qemu-project/qemu/-/blob/master/hw/display/virtio-gpu-base.c#L204), thus VNC0 is always enabled. + +Other devices will set this parameter during inititliazation by calling [dpy_set_ui_info](https://gitlab.com/qemu-project/qemu/-/blob/master/ui/console.c#L754) which schedules a call to [virtio_gpu_ui_info](https://gitlab.com/qemu-project/qemu/-/blob/master/hw/display/virtio-gpu-base.c#L89). However VNC calls this function only when handling [VNC_MSG_CLIENT_SET_DESKTOP_SIZE](https://gitlab.com/qemu-project/qemu/-/blob/master/ui/vnc.c#L2607) client command.\ +If the client does not support this command or never changes the size of the default window, the respective display will remain disabled. diff --git a/results/classifier/105/mistranslation/297 b/results/classifier/105/mistranslation/297 new file mode 100644 index 000000000..4c83b8116 --- /dev/null +++ b/results/classifier/105/mistranslation/297 @@ -0,0 +1,14 @@ +mistranslation: 0.977 +device: 0.840 +other: 0.802 +boot: 0.435 +graphic: 0.282 +semantic: 0.206 +vnc: 0.153 +network: 0.091 +KVM: 0.068 +assembly: 0.031 +instruction: 0.019 +socket: 0.007 + +SD card size constraint conceptually wrong diff --git a/results/classifier/105/mistranslation/2974 b/results/classifier/105/mistranslation/2974 new file mode 100644 index 000000000..1d1fcf90d --- /dev/null +++ b/results/classifier/105/mistranslation/2974 @@ -0,0 +1,14 @@ +mistranslation: 0.772 +device: 0.607 +semantic: 0.429 +instruction: 0.335 +network: 0.253 +graphic: 0.240 +other: 0.174 +boot: 0.142 +socket: 0.050 +assembly: 0.047 +vnc: 0.047 +KVM: 0.006 + +Remove the "51 Franklin Street, Fifth Floor, Boston" from the QEMU code base diff --git a/results/classifier/105/mistranslation/2977 b/results/classifier/105/mistranslation/2977 new file mode 100644 index 000000000..fca35b4b7 --- /dev/null +++ b/results/classifier/105/mistranslation/2977 @@ -0,0 +1,24 @@ +mistranslation: 0.880 +device: 0.805 +instruction: 0.785 +graphic: 0.698 +semantic: 0.643 +vnc: 0.638 +socket: 0.416 +network: 0.399 +boot: 0.377 +other: 0.316 +assembly: 0.188 +KVM: 0.095 + +QEMU SVM VMCB exit_code is uint32_t when AMD spec requires uint64_t +Description of problem: +QEMU's SVM implementation incorrectly uses a 32-bit parameter for the exit code in the `cpu_vmexit` function, despite the AMD SVM specification requiring a 64-bit exit code field in the VMCB (Virtual Machine Control Block). + +I think the issue is in `target/i386/svm.c` in the `cpu_vmexit` function. + +The `exit_code` parameter is declared as `uint32_t` but should be `uint64_t` according to the AMD SVM specification. This causes exit codes to be truncated to 32 bits, resulting in values like 0xffff_ffff instead of the expected 0xffff_ffff_ffff_ffff. +Steps to reproduce: + +Additional information: +[this](https://stackoverflow.com/questions/79632531/qemu-svm-vmcb-exit-code-is-uint32-t-when-amd-spec-requires-uint64-t?noredirect=1#comment140448815_79632531) question I posted on stack overflow diff --git a/results/classifier/105/mistranslation/314 b/results/classifier/105/mistranslation/314 new file mode 100644 index 000000000..876af7699 --- /dev/null +++ b/results/classifier/105/mistranslation/314 @@ -0,0 +1,14 @@ +mistranslation: 0.740 +network: 0.738 +device: 0.718 +semantic: 0.604 +instruction: 0.553 +graphic: 0.458 +assembly: 0.398 +vnc: 0.160 +boot: 0.107 +socket: 0.105 +other: 0.068 +KVM: 0.003 + +qemu-user vm86() segfaults handling interrupt with ss:sp in same page as cs:ip diff --git a/results/classifier/105/mistranslation/342 b/results/classifier/105/mistranslation/342 new file mode 100644 index 000000000..4613d8e73 --- /dev/null +++ b/results/classifier/105/mistranslation/342 @@ -0,0 +1,14 @@ +mistranslation: 0.952 +device: 0.709 +instruction: 0.644 +graphic: 0.596 +network: 0.581 +semantic: 0.483 +assembly: 0.276 +vnc: 0.244 +boot: 0.231 +KVM: 0.168 +socket: 0.163 +other: 0.056 + +Assertion `child->perm & BLK_PERM_WRITE' failed in bdrv_co_write_req_prepare through atapi diff --git a/results/classifier/105/mistranslation/343 b/results/classifier/105/mistranslation/343 new file mode 100644 index 000000000..f437e8619 --- /dev/null +++ b/results/classifier/105/mistranslation/343 @@ -0,0 +1,14 @@ +mistranslation: 0.964 +device: 0.905 +semantic: 0.819 +graphic: 0.464 +network: 0.462 +other: 0.328 +instruction: 0.283 +vnc: 0.141 +boot: 0.139 +assembly: 0.051 +socket: 0.050 +KVM: 0.009 + +madvise reports success, but doesn't implement WIPEONFORK. diff --git a/results/classifier/105/mistranslation/345 b/results/classifier/105/mistranslation/345 new file mode 100644 index 000000000..8f894538f --- /dev/null +++ b/results/classifier/105/mistranslation/345 @@ -0,0 +1,14 @@ +mistranslation: 0.885 +device: 0.828 +graphic: 0.557 +assembly: 0.290 +network: 0.222 +instruction: 0.158 +boot: 0.129 +other: 0.080 +vnc: 0.040 +socket: 0.037 +semantic: 0.015 +KVM: 0.001 + +Sector translation bug in scsi_unmap_complete_noio diff --git a/results/classifier/105/mistranslation/356 b/results/classifier/105/mistranslation/356 new file mode 100644 index 000000000..5a06af2ac --- /dev/null +++ b/results/classifier/105/mistranslation/356 @@ -0,0 +1,14 @@ +mistranslation: 0.984 +network: 0.747 +device: 0.704 +socket: 0.412 +semantic: 0.377 +graphic: 0.365 +other: 0.291 +boot: 0.266 +instruction: 0.249 +vnc: 0.165 +assembly: 0.016 +KVM: 0.005 + +qemu linux-user doesn't translate host/target data for iovec I/O diff --git a/results/classifier/105/mistranslation/359 b/results/classifier/105/mistranslation/359 new file mode 100644 index 000000000..df9eca446 --- /dev/null +++ b/results/classifier/105/mistranslation/359 @@ -0,0 +1,14 @@ +mistranslation: 0.871 +device: 0.795 +socket: 0.746 +network: 0.721 +instruction: 0.641 +other: 0.539 +vnc: 0.474 +semantic: 0.434 +boot: 0.414 +graphic: 0.407 +KVM: 0.229 +assembly: 0.088 + +In the "tests/qtests/meson.build" line 92 need dbus-vmstate1.h and dbus-vmstate1.c files, but in "tests/qtests/" not include this files. diff --git a/results/classifier/105/mistranslation/364 b/results/classifier/105/mistranslation/364 new file mode 100644 index 000000000..6e0b51339 --- /dev/null +++ b/results/classifier/105/mistranslation/364 @@ -0,0 +1,14 @@ +mistranslation: 0.988 +instruction: 0.888 +device: 0.767 +graphic: 0.471 +assembly: 0.259 +semantic: 0.230 +network: 0.202 +boot: 0.097 +vnc: 0.067 +other: 0.021 +socket: 0.018 +KVM: 0.005 + +qemu-aarch64: incorrect signed comparison in ldsmax instructions diff --git a/results/classifier/105/mistranslation/371 b/results/classifier/105/mistranslation/371 new file mode 100644 index 000000000..e5d8d5d9b --- /dev/null +++ b/results/classifier/105/mistranslation/371 @@ -0,0 +1,14 @@ +mistranslation: 0.789 +graphic: 0.454 +device: 0.449 +other: 0.438 +socket: 0.409 +semantic: 0.331 +boot: 0.263 +vnc: 0.258 +KVM: 0.228 +network: 0.213 +instruction: 0.062 +assembly: 0.048 + +Indentation should be done with spaces, not with TABs, in the block subsystem diff --git a/results/classifier/105/mistranslation/372 b/results/classifier/105/mistranslation/372 new file mode 100644 index 000000000..4a8b57fb6 --- /dev/null +++ b/results/classifier/105/mistranslation/372 @@ -0,0 +1,14 @@ +mistranslation: 0.811 +device: 0.662 +graphic: 0.432 +other: 0.417 +vnc: 0.359 +socket: 0.269 +boot: 0.261 +semantic: 0.209 +KVM: 0.183 +instruction: 0.135 +network: 0.014 +assembly: 0.005 + +Indentation should be done with spaces, not with TABs, in the TCG / CPU subsystem diff --git a/results/classifier/105/mistranslation/373 b/results/classifier/105/mistranslation/373 new file mode 100644 index 000000000..ea9d8fc73 --- /dev/null +++ b/results/classifier/105/mistranslation/373 @@ -0,0 +1,14 @@ +mistranslation: 0.807 +device: 0.698 +other: 0.500 +graphic: 0.423 +network: 0.351 +semantic: 0.298 +vnc: 0.275 +socket: 0.264 +boot: 0.263 +instruction: 0.084 +assembly: 0.076 +KVM: 0.012 + +Indentation should be done with spaces, not with TABs, in the ARM subsystem diff --git a/results/classifier/105/mistranslation/374 b/results/classifier/105/mistranslation/374 new file mode 100644 index 000000000..93d084288 --- /dev/null +++ b/results/classifier/105/mistranslation/374 @@ -0,0 +1,14 @@ +mistranslation: 0.809 +device: 0.639 +graphic: 0.424 +other: 0.382 +semantic: 0.317 +boot: 0.295 +vnc: 0.279 +socket: 0.237 +network: 0.103 +instruction: 0.064 +assembly: 0.030 +KVM: 0.021 + +Indentation should be done with spaces, not with TABs, in the PPC subsystem diff --git a/results/classifier/105/mistranslation/376 b/results/classifier/105/mistranslation/376 new file mode 100644 index 000000000..3def9814a --- /dev/null +++ b/results/classifier/105/mistranslation/376 @@ -0,0 +1,14 @@ +mistranslation: 0.817 +device: 0.681 +graphic: 0.473 +other: 0.327 +boot: 0.306 +semantic: 0.296 +socket: 0.248 +vnc: 0.233 +network: 0.191 +instruction: 0.058 +assembly: 0.042 +KVM: 0.007 + +Indentation should be done with spaces, not with TABs, in the SH4 subsystem diff --git a/results/classifier/105/mistranslation/378 b/results/classifier/105/mistranslation/378 new file mode 100644 index 000000000..05c2d0b35 --- /dev/null +++ b/results/classifier/105/mistranslation/378 @@ -0,0 +1,14 @@ +mistranslation: 0.887 +other: 0.716 +graphic: 0.544 +semantic: 0.517 +device: 0.507 +instruction: 0.473 +network: 0.408 +vnc: 0.279 +KVM: 0.234 +boot: 0.185 +socket: 0.118 +assembly: 0.050 + +Indentation should be done with spaces, not with TABs diff --git a/results/classifier/105/mistranslation/379 b/results/classifier/105/mistranslation/379 new file mode 100644 index 000000000..142cd7049 --- /dev/null +++ b/results/classifier/105/mistranslation/379 @@ -0,0 +1,14 @@ +mistranslation: 0.799 +instruction: 0.756 +semantic: 0.690 +device: 0.522 +other: 0.471 +graphic: 0.410 +network: 0.351 +boot: 0.316 +assembly: 0.316 +vnc: 0.181 +socket: 0.137 +KVM: 0.077 + +Update the FSF address to their current location diff --git a/results/classifier/105/mistranslation/382 b/results/classifier/105/mistranslation/382 new file mode 100644 index 000000000..0f616dc49 --- /dev/null +++ b/results/classifier/105/mistranslation/382 @@ -0,0 +1,14 @@ +mistranslation: 0.725 +semantic: 0.527 +graphic: 0.376 +device: 0.331 +instruction: 0.257 +socket: 0.115 +assembly: 0.092 +boot: 0.085 +vnc: 0.075 +network: 0.069 +other: 0.034 +KVM: 0.017 + +target/i386/seg_helper.c: 16-bit TSS struct format wrong? diff --git a/results/classifier/105/mistranslation/388 b/results/classifier/105/mistranslation/388 new file mode 100644 index 000000000..dcb89c01c --- /dev/null +++ b/results/classifier/105/mistranslation/388 @@ -0,0 +1,14 @@ +mistranslation: 0.839 +network: 0.625 +other: 0.534 +device: 0.410 +semantic: 0.406 +graphic: 0.330 +instruction: 0.265 +boot: 0.247 +socket: 0.244 +assembly: 0.242 +KVM: 0.238 +vnc: 0.159 + +Can not pass hw device names as alsa input and output devices diff --git a/results/classifier/105/mistranslation/392 b/results/classifier/105/mistranslation/392 new file mode 100644 index 000000000..cb38ac1ec --- /dev/null +++ b/results/classifier/105/mistranslation/392 @@ -0,0 +1,14 @@ +mistranslation: 0.988 +semantic: 0.877 +instruction: 0.605 +device: 0.520 +graphic: 0.459 +other: 0.406 +network: 0.354 +KVM: 0.141 +assembly: 0.127 +boot: 0.073 +vnc: 0.024 +socket: 0.010 + +`-hda` and `-drive` differ with respect to path handling diff --git a/results/classifier/105/mistranslation/393569 b/results/classifier/105/mistranslation/393569 new file mode 100644 index 000000000..df75572b5 --- /dev/null +++ b/results/classifier/105/mistranslation/393569 @@ -0,0 +1,90 @@ +mistranslation: 0.889 +semantic: 0.878 +other: 0.859 +KVM: 0.851 +boot: 0.835 +vnc: 0.835 +graphic: 0.833 +instruction: 0.831 +assembly: 0.829 +device: 0.819 +socket: 0.787 +network: 0.760 + +qemu cannot load multiple initramfs archives + +According to Documentation/early-userspace/buffer-format.txt, an initramfs can be populated from multiple cpio archives, which seems like it could be a really useful feature when using QEMU to boot Linux kernels directly, without installing them on the disk image. + +Unfortunately, QEMU does not support actually loading multiple files into the initrd space (which is also where initramfs archives go). It would be really nice if it did. + +I'm marking this as wishlist. Technically speaking, our bootload can support multiple initramfs' that are joined together. What we don't do today is generate one of these automagically from multiple -initrd options. This is a completely reasonable thing to do though. + +Linux initrd catting works by appending multiple cpio archives. Usually you pass gzip'ed cpio archives though. +So in order to support multiple -initrd with Linux kernels, we'd need to unpack all initrds, concatenate them and gzip them again so Linux is happy. + +I don't know if that's worth it. + +Multiboot supports multiple "modules" which are represented as -initrd in qemu. I'd rather see multiboot support in Linux than implementing cpio concatenating in qemu. + + Linux initrd catting works by appending multiple cpio +> archives. Usually you pass gzip'ed cpio archives though. So in +> order to support multiple -initrd with Linux kernels, we'd need to +> unpack all initrds, concatenate them and gzip them again so Linux is +> happy. + +That isn't what the Linux documentation says. The relevant portion of +Documentation/early-userspace/buffer-format.txt is: + +,---- +| The full format of the initramfs buffer is defined by the following +| grammar, where: +| * is used to indicate "0 or more occurrences of" +| (|) indicates alternatives +| + indicates concatenation +| GZIP() indicates the gzip(1) of the operand +| ALGN(n) means padding with null bytes to an n-byte boundary +| +| initramfs := ("\0" | cpio_archive | cpio_gzip_archive)* +| +| cpio_gzip_archive := GZIP(cpio_archive) +| +| cpio_archive := cpio_file* + (<nothing> | cpio_trailer) +| +| cpio_file := ALGN(4) + cpio_header + filename + "\0" + ALGN(4) + data +| +| cpio_trailer := ALGN(4) + cpio_header + "TRAILER!!!\0" + ALGN(4) +`---- + +That is, you can concatenate gzipped cpio archives together just fine, +as long as you align each one on a 4-byte boundary by padding the +previous one with NULs. + +> Multiboot supports multiple "modules" which are represented as +> -initrd in qemu. I'd rather see multiboot support in Linux than +> implementing cpio concatenating in qemu. + +QEMU has code for that? Where? I get all of two results from: + + % git log -Smultiboot + +-- both in the binary file named "pc-bios/openbios-sparc32" + +Anyway, even if QEMU does have code for that, why should Linux assume +that multiboot modules are necessarily cpio archives for initramfs? +(If that's not what you meant, what *did* you mean?) + + +Now that looks like a really useful feature. I only knew of cpio concatenating so far, not that Linux can handle multiple gzip'ed cpios. + +My multiboot patchset is on its way upstream. It should be in soon unless something breaks utterly ;-). After that you could write a patch that basically does a split by "," and reads several initrds. + +Or is this bug about a feature request because you won't do it? If so, I could take a look at it next time I'm fiddling with the Linux -kernel code. + +Well, I began an attempt to implement it, but the way I was going about it was touching way too much stuff, and I didn't know if the way I was doing it was even reasonable -- it involved replacing the single initrd name with a list of them, using some stuff from that queue.h reimplementation, and it was getting kind of hairy and touching a lot more code than I liked. + +Your way probably would be a bit easier to do, since it would mean that most of the code that passes around what it believes to be the one and only initrd name could continue to do so without change. + +Looking through old bug tickets... If I've got that right, there is multiboot support in QEMU nowadays, and we also have the possibility to load multiple files with the "loader" device ... is that enough, or is still something to be done here? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/397212 b/results/classifier/105/mistranslation/397212 new file mode 100644 index 000000000..675d5425c --- /dev/null +++ b/results/classifier/105/mistranslation/397212 @@ -0,0 +1,228 @@ +mistranslation: 0.911 +graphic: 0.902 +device: 0.881 +other: 0.878 +assembly: 0.872 +boot: 0.867 +semantic: 0.864 +instruction: 0.855 +socket: 0.851 +network: 0.822 +vnc: 0.814 +KVM: 0.651 + +Scrolling artifacts on some guests + +Screen doesn't refresh properly when scrolling (see the attachment). + +The behavior is seen on RHEL 4.8 and SLES 11, but not on RHEL 5.3. However, on RHEL5.3, scrolling is very sluggish. It seems to be a trade-off between quick movement and frequent / accurate refreshing. + +Command line: + +qemu-system-x86_64 -m 2048 -drive file=/scratch/images/SLES-11-GMC-x86_64.raw -net nic,vlan=0,macaddr=DE:AD:BE:EF:88:95,model=rtl8139 -net tap -vnc :40 -boot cd -monitor stdio -smp 4 + + + +From your command line, I suspect you're testing a copy of KVM. Is this reproducible with the upstream QEMU and if so, with what version (either 0.10.5 or specific git commit)? + +Yes, reproducible upstream. + +commit 9af4aed6c749786edb780e5de1795377f515e8f7 +Author: Andre Przywara <email address hidden> +Date: Thu Jul 2 16:45:43 2009 +0200 + + +Two Fedora 11 (qemu-0.10.x) bugs on this too: + + https://bugzilla.redhat.com/503156 + https://bugzilla.redhat.com/507626 + +Glauber posted a patch here: + + http://lists.gnu.org/archive/html/qemu-devel/2009-07/msg01498.html + + +Description of problem: +after for example catting a large file inside an xterm there are text artifacts remaining inside the xterm window. Scrolling up and down the xterm makes things even worse. + +Not sure if it's related to window scaling, please reassign appropriately if not a virt-manager bug. + +Screenshot attached + +Version-Release number of selected component (if applicable): +virt-manager-0.7.0-5.fc11.i586 + +How reproducible: +always + +Steps to Reproduce: +1. start VM +2. open xterm inside VM +3. cat large file (/var/log/messages) and scroll to make things worse + +Actual results: +text appears garbled + +Expected results: +text appears normal without artifacts + +Additional info: + +Created attachment 345887 +garbled-xterm.png + +Yeah, I can reproduce this, even with vncviewer - doesn't seem reproducible outside of KVM, though + +Moving to qemu + + +This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. +Changing version to '11'. + +More information and reason for this action is here: +http://fedoraproject.org/wiki/BugZappers/HouseKeeping + +bug #507626 is probably a dup of this + +Similar bug report for Ubuntu: + +https://bugs.launchpad.net/qemu/+bug/397212 + +Glauber posted a patch here: + +http://lists.gnu.org/archive/html/qemu-devel/2009-07/msg01498.html + +*** Bug 507626 has been marked as a duplicate of this bug. *** + +Glauber, do you plan to push updated builds with this patch for F-11? I don't see this patch incorporated on any of the recent koji builds..? + +The patched was NACKed upstream by Gerd. He believes there is a better way to solve it. As such, I indent to wait for the real fix, or write it myself it Gerd takes too long + +Gerd has posted an updated patch here: + +http://lists.gnu.org/archive/html/qemu-devel/2009-07/msg02107.html + +my test machine is down presently, so haven't had chance to test it yet. + +Have been playing with this a bit, and unfortunately applying the patch in comment #10 against 0.10.5 requires picking up a fair amount of the recent vnc logic changes (vnc.c and vnc.h) - not sure how you'd recommend proceeding here? One option would be to pull vnc.[c,h] from the current HEAD and add the patch, I suppose.. not sure what else might break. + +So, the upstream commit is: + + http://git.savannah.gnu.org/cgit/qemu.git/commit/?id=3e28c9adf4 + +and it depends on the fix for bug #501131 which we also want back-ported + +(Note the vnc copyrect patch isn't applied to the stable-0.11 branch for F-12 yet, either) + +What I'd really like to see is both of these fixes back-ported to the stable-0.10 branch and sent upstream to qemu-devel + +This should be in the 0.10.7 release shortly: + + http://git.savannah.gnu.org/cgit/qemu.git/commit/?h=stable-0.10&id=74ccfe8b7e + +Will push this to updates-testing soon: + +* Fri Sep 11 2009 Mark McLoughlin <email address hidden> - 2:0.10.6-5 +- Fix vnc segfault on disconnect (#501131) +- Fix vnc screen corruption with e.g. xterm (#503156) +- Rebase vnc sasl patches on top of these two vnc fixes + +qemu-0.10.6-5.fc11 has been submitted as an update for Fedora 11. +http://admin.fedoraproject.org/updates/qemu-0.10.6-5.fc11 + +Created attachment 360920 +Windows XP guest with grabled screen + +As the image attached in Comment #16 shows, this update doesn't fix the problem for me. This is using: + +# rpm -qa | grep qemu +qemu-system-x86-0.10.6-5.fc11.x86_64 +qemu-img-0.10.6-5.fc11.x86_64 +qemu-common-0.10.6-5.fc11.x86_64 + +Thanks for testing Jonathan + +No problem. Alas, if anything, the screen tearing has gotten worse with this version, rather than better - previously resizing the window in the guest triggered a redraw which would clean up the garbage (at least until scrolled again), but now that trick no longer works. + +Why on earth was version 2:qemu-0.10.6-5.fc11.x86_64 released +with this "bugfix" that has made the graphics looks worse? + +Good question in Comment #20. Surely that's a mistake Mark? + +Sorry about that, guys + +This 'fix' will be in 0.10.7, so I'm inclined to leave it in for the moment and try and get it fixed + +If we don't get progress, I'll revert it soon + +Is it worth pushing a build of the 0.10.7 rc to updates-testing? + +Anything new on this bug? + +It's been open for 5 months now. + +It's realllllyyy annoying, it makes Windows even harder to use :-( + +*** Bug 528939 has been marked as a duplicate of this bug. *** + +What would the implications of pushing qemu 0.11 to FC11 be - would that work with libvirt and friends? If so, any chance of doing such a push? + +We don't have any immediate plans to update qemu in Fedora 11 to 0.11. See: + + http://www.redhat.com/archives/fedora-virt/2009-April/msg00008.html + +Honestly, it should be a lot easier to fix this bug than deal with the fallout from the inevitable regressions that would be caused by a re-base. It's just a question of someone finding the time to debug it. + +(In reply to comment #27) +> We don't have any immediate plans to update qemu in Fedora 11 to 0.11. See: +> +> http://www.redhat.com/archives/fedora-virt/2009-April/msg00008.html +> +> Honestly, it should be a lot easier to fix this bug than deal with the fallout +> from the inevitable regressions that would be caused by a re-base. It's just a +> question of someone finding the time to debug it. + +Bah ... + +Is there some way to workaround this bug? + +Is there another way to connect to the output other than VNC? + +I've been using virt-manager. + +Patrick - you could presumably run a VNC server inside your guest and connect to that, rather than the QEMU vnc client. + +The problem with backporting a fix is that there's been a lot of code churn with the vnc related stuff in qemu, so to actually fix it would require some knowledge of the vnc stuff, rather than mechanical adding and removing of commits (I know, as I tried that sometime ago). The people with that knowledge are too busy pushing forward than looking back at old releases (understandably - it's more interesting). + +qemu-0.10.6-9.fc11 has been submitted as an update for Fedora 11. +http://admin.fedoraproject.org/updates/qemu-0.10.6-9.fc11 + +Patrick and Jonathan: okay, let's try and hit this bad boy with our big stick + +I'm pretty sure it's a problem with qemu's implementation of the CopyRect extension, so I've just disabled that extension in qemu-0.10.6-9.fc11 - that should fix the problem + +AFAIK, CopyRect works fine in qemu-0.11.0 in Fedora 12 + +Could you confirm that qemu-0.10.6-9.fc11 fixes the issue? (comment here and bump the karma in bodhi if so) + +Thanks! + +* Fri Oct 23 2009 Mark McLoughlin <email address hidden> - 2:0.10.6-9 +- Disable the vnc CopyRect encoding since it's still broken (#503156) + +Mark: qemu-0.10.6-9.fc11 does indeed fix the issue for me. Thanks very much for taking the time to look at this. + +(In reply to comment #32) +> Mark: qemu-0.10.6-9.fc11 does indeed fix the issue for me. Thanks very much for +> taking the time to look at this. + +Me too, thanks! + +I commented on the web page (showed up as anonymous), but how do I bump bodhi karma? + +qemu-0.10.6-9.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. + If you want to test the update, you can install it with + su -c 'yum --enablerepo=updates-testing update qemu'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-10754 + +qemu-0.10.6-9.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report. + diff --git a/results/classifier/105/mistranslation/400 b/results/classifier/105/mistranslation/400 new file mode 100644 index 000000000..7a6b0fb59 --- /dev/null +++ b/results/classifier/105/mistranslation/400 @@ -0,0 +1,14 @@ +mistranslation: 0.739 +device: 0.482 +instruction: 0.348 +graphic: 0.325 +vnc: 0.193 +semantic: 0.187 +network: 0.160 +socket: 0.065 +other: 0.063 +boot: 0.059 +assembly: 0.044 +KVM: 0.011 + +Build error -Werror=stringop-overflow in util/qemu-thread-posix.c diff --git a/results/classifier/105/mistranslation/421 b/results/classifier/105/mistranslation/421 new file mode 100644 index 000000000..e9b4a9b66 --- /dev/null +++ b/results/classifier/105/mistranslation/421 @@ -0,0 +1,14 @@ +mistranslation: 0.992 +semantic: 0.791 +network: 0.735 +device: 0.646 +instruction: 0.584 +graphic: 0.361 +other: 0.328 +boot: 0.072 +assembly: 0.039 +socket: 0.038 +vnc: 0.026 +KVM: 0.008 + +Please clarify what network card is available with qemu-system-sparc64 diff --git a/results/classifier/105/mistranslation/426 b/results/classifier/105/mistranslation/426 new file mode 100644 index 000000000..5a06af2ac --- /dev/null +++ b/results/classifier/105/mistranslation/426 @@ -0,0 +1,14 @@ +mistranslation: 0.984 +network: 0.747 +device: 0.704 +socket: 0.412 +semantic: 0.377 +graphic: 0.365 +other: 0.291 +boot: 0.266 +instruction: 0.249 +vnc: 0.165 +assembly: 0.016 +KVM: 0.005 + +qemu linux-user doesn't translate host/target data for iovec I/O diff --git a/results/classifier/105/mistranslation/427 b/results/classifier/105/mistranslation/427 new file mode 100644 index 000000000..c11b42a46 --- /dev/null +++ b/results/classifier/105/mistranslation/427 @@ -0,0 +1,14 @@ +mistranslation: 0.924 +instruction: 0.887 +device: 0.849 +network: 0.621 +boot: 0.337 +socket: 0.323 +graphic: 0.321 +semantic: 0.236 +assembly: 0.194 +vnc: 0.187 +other: 0.178 +KVM: 0.003 + +TCG: QEMU incorrectly raises exception on SSE4.2 CRC32 instruction diff --git a/results/classifier/105/mistranslation/435 b/results/classifier/105/mistranslation/435 new file mode 100644 index 000000000..c1e1eafe7 --- /dev/null +++ b/results/classifier/105/mistranslation/435 @@ -0,0 +1,14 @@ +mistranslation: 0.733 +device: 0.634 +semantic: 0.582 +other: 0.406 +instruction: 0.341 +graphic: 0.280 +boot: 0.279 +vnc: 0.228 +network: 0.169 +socket: 0.134 +assembly: 0.077 +KVM: 0.044 + +RISC-V: Support more cores diff --git a/results/classifier/105/mistranslation/450 b/results/classifier/105/mistranslation/450 new file mode 100644 index 000000000..66e7355c5 --- /dev/null +++ b/results/classifier/105/mistranslation/450 @@ -0,0 +1,14 @@ +mistranslation: 0.963 +network: 0.854 +device: 0.847 +instruction: 0.754 +semantic: 0.553 +graphic: 0.440 +boot: 0.283 +assembly: 0.272 +socket: 0.140 +other: 0.106 +vnc: 0.065 +KVM: 0.035 + +sdhci: Assertion wpnum < sd->wpgrps_size failed diff --git a/results/classifier/105/mistranslation/47 b/results/classifier/105/mistranslation/47 new file mode 100644 index 000000000..65b5e48af --- /dev/null +++ b/results/classifier/105/mistranslation/47 @@ -0,0 +1,14 @@ +mistranslation: 0.993 +graphic: 0.415 +semantic: 0.381 +other: 0.320 +device: 0.293 +network: 0.258 +instruction: 0.176 +vnc: 0.095 +boot: 0.079 +socket: 0.070 +assembly: 0.056 +KVM: 0.035 + +A typo in target/riscv/insn32-64.decode diff --git a/results/classifier/105/mistranslation/470 b/results/classifier/105/mistranslation/470 new file mode 100644 index 000000000..0e9b5442f --- /dev/null +++ b/results/classifier/105/mistranslation/470 @@ -0,0 +1,14 @@ +mistranslation: 0.962 +device: 0.771 +instruction: 0.734 +semantic: 0.442 +network: 0.403 +graphic: 0.357 +boot: 0.335 +other: 0.264 +socket: 0.149 +vnc: 0.090 +assembly: 0.016 +KVM: 0.003 + +qemu linux-user requires read permissions on memory passed to syscalls that should only need write access diff --git a/results/classifier/105/mistranslation/491 b/results/classifier/105/mistranslation/491 new file mode 100644 index 000000000..850706095 --- /dev/null +++ b/results/classifier/105/mistranslation/491 @@ -0,0 +1,14 @@ +mistranslation: 0.585 +boot: 0.436 +socket: 0.431 +device: 0.418 +KVM: 0.331 +vnc: 0.295 +network: 0.258 +other: 0.219 +assembly: 0.064 +instruction: 0.054 +graphic: 0.038 +semantic: 0.020 + +There is a code error here diff --git a/results/classifier/105/mistranslation/500 b/results/classifier/105/mistranslation/500 new file mode 100644 index 000000000..aed66ea2b --- /dev/null +++ b/results/classifier/105/mistranslation/500 @@ -0,0 +1,14 @@ +mistranslation: 0.896 +network: 0.534 +semantic: 0.381 +graphic: 0.374 +vnc: 0.340 +KVM: 0.291 +boot: 0.283 +assembly: 0.262 +device: 0.247 +instruction: 0.212 +other: 0.171 +socket: 0.083 + +6.1.0-rc0 Regression: Parameter 'audiodev' is missing diff --git a/results/classifier/105/mistranslation/502107 b/results/classifier/105/mistranslation/502107 new file mode 100644 index 000000000..8800cca87 --- /dev/null +++ b/results/classifier/105/mistranslation/502107 @@ -0,0 +1,134 @@ +mistranslation: 0.851 +semantic: 0.545 +other: 0.483 +graphic: 0.342 +network: 0.326 +assembly: 0.321 +device: 0.312 +instruction: 0.283 +socket: 0.261 +KVM: 0.242 +vnc: 0.234 +boot: 0.229 + +qemu-kvm 0.12.1.2 crashes booting Ubuntu 9.10 with "-vga std" + +I have an Ubuntu VM that works fine without "-vga std" but crashes if I add "-vga std". This is the full command line: + +qemu-system-x86_64 -vga std -drive +cache=writeback,index=0,media=disk,file=ubuntu.img -k en-us -m 2048 -smp 2 -vnc +:3102 -usbdevice tablet -enable-kvm & + +I get this error: + + KVM internal error. Suberror: 1 +rax 00007f789177e000 rbx 0000000000000000 rcx 0000000000000000 rdx +0000000000000000 +rsi 0000000000000000 rdi 00007f789177e000 rsp 00007fff361775e8 rbp +00007fff36177600 +r8 000000000000ff80 r9 0000000000200000 r10 0000000000000000 r11 +00007f789100a3f0 +r12 00000000004017c0 r13 00007fff36178cf0 r14 0000000000000000 r15 +0000000000000000 +rip 00007f789100aa7b rflags 00013206 +cs 0033 (00000000/ffffffff p 1 dpl 3 db 0 s 1 type b l 1 g 1 avl 0) +ds 0000 (00000000/ffffffff p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) +es 0000 (00000000/ffffffff p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) +ss 002b (00000000/ffffffff p 1 dpl 3 db 1 s 1 type 3 l 0 g 1 avl 0) +fs 0000 (7f78917906f0/ffffffff p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) +gs 0000 (00000000/ffffffff p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) +tr 0040 (ffff880001a09440/00002087 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) +ldt 0000 (00000000/ffffffff p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) +gdt ffff8800019fa000/7f +idt ffffffff818fd000/fff +cr0 80050033 cr2 2408000 cr3 379d4000 cr4 6f0 cr8 0 efer d01 +emulation failure, check dmesg for details + +I'm running kernel 2.6.32, and I have the kvm stuff compiled directly into the +kernel. There's nothing in dmesg about kvm at all. + +Note that in the VM grub comes up, but the VM dies when I boot the kernel. + +This command line works: + +qemu-system-x86_64 -drive cache=writeback,index=0,media=disk,file=ubuntu.img -k +en-us -m 2048 -smp 2 -vnc :3102 -usbdevice tablet -enable-kvm & + +That is, removing "-vga std" fixes the problem. + +I recently added this option to both my Ubuntu and Windows XP VMs. The Windows VM still works fine. If Windows can detect that the graphics card has changed, then Ubuntu should also have no problem. That being said, I added the std option when using 0.12.1.1, so there may be a qemu regression. + +I have reported this bug elsewhere: http://bugs.gentoo.org/show_bug.cgi?id=299211 + +Clarification: Qemu doesn't quite crash. The process is still running, and I can attach a VNC client (which gives me a black screen). It's just not DOING anything. I can get into the monitor, so if there's some diagnostic thing you'd like me to enter into the monitor, please let me know. + + +since this morning (probably since i installed kernel 2.6.32-12 in host and guest) the behavior changed. +the guest does not crash any more with 'unaligned pointer error' but gets into an endless loop when loading grub, see attachment + +this happens only with '-vga std' option, standard cirrus emulation works fine. + +sorry for the wrong attachment, here is the correct one + +Confirmed, I'm seeing the same thing. + +Since the last update, the behavior has changed for me and returned to the previous one. +No more boot-loop but instead unaligned pointer error, see screenshot. This happens immediately after Grub takes control (Grub loading). + +Again, this happens only with '-vga std' option. Without vga-switch the virtual machine boots fine. + +This is still the case with version 0.12.3. Crash when booting Ubuntu (after grub), but no crash with Windows. + + +still not resolved: guest=Ubuntu 10.10, host=Fedora14 + +crashes with -vga std or -vga vmware + +works with -vga cirrus + + +PS: qemu-kvm -version = 0.13.0 + +PPS: Ubuntu 10.10 crashes also with qemu-kvm -vga qxl -spice ... + + +Some notes of interest: + +- the unaligned pointer error also seems to happen in real systems with certain ATI cards. +- rebuilding grub with mm-debug makes Ubuntu boot without unaligned/out of range pointer messages with -vga std. +- adding debug messages (with grub_printf()) to grub memalign/free functions in kern/mm.c triggers other reported behaviors including the boot loop, and more worrisomely, KVM_INTERNAL_ERROR_EMULATION. + +These results obtained with stock Ubuntu 10.10 grub2 in guest (1.98+20100804-5ubuntu3) and 3.1.6-1.fc16.x86_64 host. + +see also http://bugs.debian.org/616487 and http://bugs.debian.org/653068 - it appears this prob happens with grub with qxl (spice) and vmware "adaptors" + +and it still happens even in version 1.0 + +It turns out that my previous attempt to reproduce the vga crash using an image generated by grub-mkrescue (which is easier to work with than dealing with a full Ubuntu image) is invalid due to bad instrumentation in the "normal" module init and a stack overflow produced similar results including the boot loop and internal emulation error. It suggests, however, that the vga problem and other grub-related crashes are also caused by memory corruption in guest. + +See also LP#717445: + + https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/717445 + +which is exactly the same issue but reported against grub. And I tend to think more and more it is a grub bug after all, not qemu/kvm/bios bug. + +Yes, memory corruption in guest explains the unaligned/out of range pointer error (issued when grub2 releases a block of memory, and grub uses dynamic allocation quite a lot) and the boot loop. This corruption most likely originates in the vga code fixed in revision 2470 as reported in Bug #717445. So the real issue seems to be the crash in case of memory corruption instead of handling the issue in a more graceful way (for instance, no error is displayed if qemu/virt-manager is not launched from a terminal). Regardless of the circumstances that caused the kvm internal emulation error, I believe qemu should notify and recover instead of simply crash and burn. + +Note: this is already marked as FIXME in kvm-all.c: + + if (run->internal.suberror == KVM_INTERNAL_ERROR_EMULATION) { + fprintf(stderr, "emulation failure\n"); + if (!kvm_arch_stop_on_emulation_error(env)) { + cpu_dump_state(env, stderr, fprintf, CPU_DUMP_CODE); + return EXCP_INTERRUPT; + } + } + /* FIXME: Should trigger a qmp message to let management know + * something went wrong. + */ + + +Triaging old bug tickets ... can you still reproduce this problem with the latest version of QEMU (v2.8)? + +There hasn't been a reply to my question in the last comment within months, so I assume nobody cares about this anymore. So I'm closing this ticket now... + diff --git a/results/classifier/105/mistranslation/508 b/results/classifier/105/mistranslation/508 new file mode 100644 index 000000000..b05d57a9e --- /dev/null +++ b/results/classifier/105/mistranslation/508 @@ -0,0 +1,14 @@ +mistranslation: 0.964 +device: 0.838 +instruction: 0.772 +other: 0.598 +network: 0.591 +graphic: 0.501 +semantic: 0.261 +boot: 0.211 +assembly: 0.091 +vnc: 0.078 +socket: 0.066 +KVM: 0.009 + +x86_64 cmpxchg behavior in qemu tcg does not match the real CPU diff --git a/results/classifier/105/mistranslation/521994 b/results/classifier/105/mistranslation/521994 new file mode 100644 index 000000000..93e5bb615 --- /dev/null +++ b/results/classifier/105/mistranslation/521994 @@ -0,0 +1,207 @@ +mistranslation: 0.888 +other: 0.847 +KVM: 0.787 +vnc: 0.784 +semantic: 0.752 +device: 0.713 +assembly: 0.709 +boot: 0.679 +instruction: 0.668 +socket: 0.649 +graphic: 0.639 +network: 0.628 + +Windows 98 doesn't detect mouse on qemu and SeaBIOS. + +A windows 98 guest doesn't detect mouse on recent qemu. I bisected and the result is + +fd646122418ecefcde228d43821d07da79dd99bb is the first bad commit +commit fd646122418ecefcde228d43821d07da79dd99bb +Author: Anthony Liguori <email address hidden> +Date: Fri Oct 30 09:06:09 2009 -0500 + + Switch pc bios from pc-bios to seabios + + SeaBIOS is a port of pc-bios to GCC. Besides using a more modern tool chain, + SeaBIOS introduces a number of new features including PMM support, better + BEV and BCV support, and better PnP support. + + Signed-off-by: Anthony Liguori <email address hidden> + +I got following messages with DEBUG_BIOS + +Start bios (version 0.5.1-20100111_132716-squirrel.codemonkey.ws) +Ram Size=0x08000000 (0x0000000000000000 high) +CPU Mhz=2271 +Found 1 cpu(s) max supported 1 cpu(s) +PIIX3/PIIX4 init: elcr=00 0c +PCI: bus=0 devfn=0x00: vendor_id=0x8086 device_id=0x1237 +PCI: bus=0 devfn=0x08: vendor_id=0x8086 device_id=0x7000 +PCI: bus=0 devfn=0x09: vendor_id=0x8086 device_id=0x7010 +region 4: 0x0000c000 +PCI: bus=0 devfn=0x0b: vendor_id=0x8086 device_id=0x7113 +PCI: bus=0 devfn=0x10: vendor_id=0x1013 device_id=0x00b8 +region 0: 0xe0000000 +region 1: 0xe2000000 +region 6: 0xe2010000 +MP table addr=0x000f89b0 MPC table addr=0x000f89c0 size=224 +SMBIOS ptr=0x000f8990 table=0x07fffef0 +ACPI tables: RSDP=0x000f8960 RSDT=0x07ffde30 +Scan for VGA option rom +Running option rom at c000:0003 +VGABios $Id$ +Turning on vga console +Starting SeaBIOS (version 0.5.1-20100111_132716-squirrel.codemonkey.ws) + +Found 0 lpt ports +Found 0 serial ports +ATA controller 0 at 1f0/3f4/c000 (irq 14 dev 9) +ATA controller 1 at 170/374/c008 (irq 15 dev 9) +ps2 irq but no data. +ata0-0: PCHS=812/16/63 translation=none LCHS=812/16/63 +ata0-1: PCHS=1152/16/56 translation=none LCHS=1024/16/56 +ps2_recvbyte timeout +keyboard initialized +Scan for option roms +Returned 53248 bytes of ZoneHigh +e820 map has 6 items: + 0: 0000000000000000 - 000000000009f400 = 1 + 1: 000000000009f400 - 00000000000a0000 = 2 + 2: 00000000000f0000 - 0000000000100000 = 2 + 3: 0000000000100000 - 0000000007ffd000 = 1 + 4: 0000000007ffd000 - 0000000008000000 = 2 + 5: 00000000fffc0000 - 0000000100000000 = 2 +enter handle_19: + NULL +Booting from Hard Disk... +Booting from 0000:7c00 +pnp call arg1=5 +pnp call arg1=0 +ps2_recvbyte timeout +ps2_recvbyte timeout +ps2_recvbyte timeout +ps2_recvbyte timeout + +Running 10.04 beta on three different machines and on all the Win95 guest ps2 mouse emulation does not work. + +I also confirm from Lubuntu 10.04 beta2. +Win98 on qemu doesn't detect mouse. +The sound also doesn't works. +I used the same image on Ubuntu 9.04 and it worked. +Bye +Francesco bat + +I confirm that mouse is no more detected from version QEMU-0.12 running a Windows 3.1 on XP-PRO +In fact mouse seems to be "detected" (arrow is present and there is no warning message about lack of mouse) but the arrow doesn't move. (I created a new install with QEMU-0.12.3) +Bye +José + + +I confirm another time on Ubuntu 10.04 stable. +Win98 doesn't detect mouse. +Also the audio doesn't work ! +Bye +Francesco bat + +I confirm this same bug appears in Windows 95, Windows Me and several XFree86 and X.Org versions, as well as DOS based Microsoft Mouse drivers. + +I confirm also that mouse is not detected on Kubuntu 10.04 running qemu and Windows 98. + +I did find a workaround - I removed the BOCH BIOS package and QEMU package from my Lucid Install, and instead used the respective QEMU packages from 8.04 - this worked for me. I don't know if the most recent updates to the BIOS and QEMU packages will fix this or not - I might not try until I get confirmation that the new 10.04 packages are working. + +Apologies if I'm spamming this venue - truly just trying to be of assistance. Just got done installing the new updates to packages + qemu bochsbios qemu-kvm seabios vgabios - still did not fix the failure to recognize the mouse. + +this is fix for other mouse-stuck problem, or maybe the same. + +SeaBIOS 6.0 solved problem for me. + +Yes! Using SeaBIOS 6.0 worked for me as well. Thanks LightBit. I've been waiting for this for quite a while. + +Looks to be fixed by + +commit 14ac15d3ac8e0ef1c91204e2ac772b6412a6b99e +Author: Anthony Liguori <email address hidden> +Date: Tue May 11 07:56:30 2010 -0500 + + Update SeaBIOS + + - 7d09d0e Fix virtio compile errors on various gcc versions. + - 89acfa3 Support for booting from virtio disks + - 6d66316 smbios: avoid counting io hole as ram + - e5cd945 Fix error causing USB HID "boot" protocol to not be enabled. + - 0e88576 Add support for USB mice. + - dd5a8a6 When USB keyboard active, don't send keyboard commands to ps2 port. + - 5718d56 Document usb-hid.c functions. + - e438b0c Further parallelize init when using CONFIG_THREAD_OPTIONROMS. + - f59b5ac Handle unknown function addresses in tools/checkstack.py. + - 9ba1dea Simplify build by manually resolving external symbols in layoutrom.py. + - 698d3f9 USB EHCI should yield() whil waiting for controller to ack reset. + - f9a774c Add __attribute__((__malloc__)) declaration to internal malloc funcs. + - b7045ce Minor - remove redundant check from ata_try_dma. + - 67f6d37 Fix possible unitialized variable issue in usb msc. + - a7eb8fc Some improvements to optionrom preemption support. + - d28b0fe Refactor USB hub code. + - ba28541 Prep version for next release. + - 12bffd5 Update version to 0.6.0. + - 87ab2fb Improve USB EHCI timing. + - d705e5a Disable inlining on old compilers. + - bca0736 Force use of indirect function calls in inline assembler. + - d7eb27e Don't move EBDA while an optionrom is running (CONFIG_THREAD_OPTIONROMS). + - 7415270 Call to int1552 (from int1346) should set regs->dl. + - 9dc243e Adjust debug levels of device discovery. + - d9c9361 Default CONFIG_COREBOOT_FLASH on; make depend on CONFIG_COREBOOT. + - c35e1e5 Restore segment limits in handle_1589 code. + - 11cc662 Extend time for rtc to be ready. + - 4ed378a Backup and restore registers when calling out to user funcs. + - 68c5139 Enable irqs in kbd/clock calls that caller might "spin" on. + - f628244 Process event on ps2 keyboard irq even if event already read. + - a5d8458 Revert "Unify ps2 port data processing." + - b9ed5e2 Handle variable length return of ps2 port GETID command. + - 67a9eec Prevent ps2 irqs from messing up ps2 init. + - 6704cf9 Revert "Rework disabling of ps2 port irqs." + - 808939c Fix smp cpu detect on gcc 4.5. + - a979c1c Improvements to tools/checkstack.py. + - 190cc62 Add USB EHCI controller support. + - 0770d67 Some USB UHCI and OHCI fixes and cleanups. + - bfe7ca7 Minor - USB OHCI interrupt queue should be one larger. + - 09e2f7c Reduce size of USB 'struct uhci_td'. + - 406fad6 Dynamically allocate USB controller structures. + - 4547eb9 Replace USB encoded 'u32 endp' scheme with explicit struct fields. + - 8ebcac0 Further parallelize USB init by launching a thread per usb port. + - e908665 Introduce simple "mutex" locking code. + - 3b79f8b Only compile usb-hub.c and paravirt.c with 32bit code. + - 357bdfa Prefer passing a USB "pipe" structure over a USB endp encoding. + - 7fb8ba8 Add a generic "internal error" warning function. + + Signed-off-by: Anthony Liguori <email address hidden> + +:040000 040000 e1b3c6d95f0d7cbd709b4b6c28bdb91a0ee1a69b 2e871a4a7ac2e8d4c2fdceb585da8295e3f8348e M pc-bios +:040000 040000 4e12b72f4dca9f76592f70e3b9649a634d5894ff 06c34280852bb7a4809b180d7ba897993727caee M roms + +Looks like this is fixed in qemu. + +Im using Mint 19.3 based on Ubuntu 18.04 with QEMU 2.11 from repository, keyboard is working but mouse not in Win98. + + Could someone else to restest it? + + Here is my Qemu starting script: +qemu-system-x86_64 -m 512 \ +-machine type=pc-i440fx-bionic \ +-smp 1,sockets=1,cores=1,threads=1 \ +-vga cirrus \ +-rtc clock=host,base=localtime \ +-parallel none \ +-balloon none \ +-mem-prealloc \ +-serial none \ +-parallel none \ +-L . \ +-soundhw sb16,adlib,pcspk \ +-boot order=cd \ +-no-acpi \ +-hda ./Win98-System.vmdk \ +-cdrom ./Win98SE-ENG.iso \ +-k en-us \ +-net nic,model=rtl8139 -net user + diff --git a/results/classifier/105/mistranslation/53 b/results/classifier/105/mistranslation/53 new file mode 100644 index 000000000..9810aa96c --- /dev/null +++ b/results/classifier/105/mistranslation/53 @@ -0,0 +1,14 @@ +mistranslation: 0.932 +instruction: 0.903 +device: 0.879 +other: 0.692 +vnc: 0.410 +boot: 0.394 +graphic: 0.275 +semantic: 0.271 +socket: 0.146 +KVM: 0.096 +network: 0.082 +assembly: 0.008 + +RISC-V Disassembler/translator instruction decoding disagreement diff --git a/results/classifier/105/mistranslation/541 b/results/classifier/105/mistranslation/541 new file mode 100644 index 000000000..54ae642ba --- /dev/null +++ b/results/classifier/105/mistranslation/541 @@ -0,0 +1,14 @@ +mistranslation: 0.913 +device: 0.702 +semantic: 0.688 +graphic: 0.620 +instruction: 0.609 +vnc: 0.253 +boot: 0.233 +KVM: 0.230 +network: 0.186 +assembly: 0.107 +socket: 0.042 +other: 0.018 + +Heap-use-after-free through ehci_flush_qh diff --git a/results/classifier/105/mistranslation/562107 b/results/classifier/105/mistranslation/562107 new file mode 100644 index 000000000..792319385 --- /dev/null +++ b/results/classifier/105/mistranslation/562107 @@ -0,0 +1,43 @@ +mistranslation: 0.742 +device: 0.733 +semantic: 0.721 +instruction: 0.704 +socket: 0.679 +network: 0.675 +other: 0.588 +graphic: 0.526 +vnc: 0.400 +boot: 0.356 +assembly: 0.243 +KVM: 0.175 + +QEmu GDB stub uses IPv6 instead of v4 (or both) + +This bug has been reported by several people already. + +See http://migeel.sk/blog/2009/04/21/gdb-and-qemu-on-windows/ +and http://qemu-forum.ipi.fi/viewtopic.php?f=5&t=5579&p=16248&hilit=gdb+ipv6#p16248 + + +Seems like a very easy fix. + +Regards, +Matthijs ter Woord + +There is an alternative way to force gdbserver to use ipv4 instead ipv6 without changing the source code. + +Use this command: + +c:\>qemu -S -gdb tcp::1234,ipv4 <...other parameters> + +Works for me until there is a bugfix for this. + +Thanks. + +I have a patch for this... + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/568 b/results/classifier/105/mistranslation/568 new file mode 100644 index 000000000..3c4e44069 --- /dev/null +++ b/results/classifier/105/mistranslation/568 @@ -0,0 +1,39 @@ +mistranslation: 0.905 +graphic: 0.858 +semantic: 0.796 +device: 0.733 +instruction: 0.665 +socket: 0.473 +vnc: 0.364 +assembly: 0.342 +other: 0.158 +boot: 0.154 +network: 0.112 +KVM: 0.072 + +video memory option not working with Mac OS or Windows guest +Description of problem: +The vgamem_mb option tells the guest how much video memory it has access to. When I used this command '-device VGA,vgamem_mb=128', I expect the guest to report there is 128 MB of video memory. What actually happens is the guest does not seem to know how much video memory is actually available. +Steps to reproduce: +**Mac OS guest:** +1. Run a Mac OS guest with this command: -device VGA,vgamem_mb=128 +2. In Mac OS X open the System Information application -> /Applications/Utilities/System Information. +3. Click on "Graphics/Displays". +4. Look at the 'VRAM (Total)' field. +The field only shows 3 MB of video ram. + +**Windows guest:** +1. Run a Windows (Windows XP in my case) guest with this command: -device VGA,vgamem_mb=128 +2. Click on Start->Run. +3. Enter 'dxdiag'. +4. Push the OK button. +5. Click on the Display tap in the DirectX Diagnostic Tool. +6. Look at the Approv. Total Memory field. +The field should say 128 MB but actually says N/A. +Additional information: +**Mac OS 8.5<br>** +<br><br><br> +**Windows XP<br>** +<br><br><br> +**Windows 7<br>** + diff --git a/results/classifier/105/mistranslation/568053 b/results/classifier/105/mistranslation/568053 new file mode 100644 index 000000000..a77bc85b4 --- /dev/null +++ b/results/classifier/105/mistranslation/568053 @@ -0,0 +1,24 @@ +mistranslation: 0.900 +graphic: 0.805 +semantic: 0.767 +device: 0.547 +network: 0.432 +other: 0.425 +instruction: 0.357 +socket: 0.255 +vnc: 0.151 +boot: 0.136 +assembly: 0.051 +KVM: 0.019 + +requires MSYS coreutils ext sub-package to build on Windows + +When I try to build QEMU on Windows without the MSYS coreutils ext sub-package installed, the build fails because it cannot find dd. + + + +pc-bios/optionrom/signrom.sh uses 'dd'. + +signrom.sh has been removed/rewritten by this commit: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=0d6b9cc7420dd2d531b48508f0d4 + diff --git a/results/classifier/105/mistranslation/572 b/results/classifier/105/mistranslation/572 new file mode 100644 index 000000000..28fb0ca12 --- /dev/null +++ b/results/classifier/105/mistranslation/572 @@ -0,0 +1,14 @@ +mistranslation: 0.791 +graphic: 0.762 +device: 0.748 +semantic: 0.607 +instruction: 0.557 +socket: 0.434 +network: 0.421 +vnc: 0.393 +assembly: 0.384 +boot: 0.383 +other: 0.263 +KVM: 0.036 + +s390-pci-bus.h:85: warning: "PAGE_SIZE" redefined diff --git a/results/classifier/105/mistranslation/589827 b/results/classifier/105/mistranslation/589827 new file mode 100644 index 000000000..2902a3b75 --- /dev/null +++ b/results/classifier/105/mistranslation/589827 @@ -0,0 +1,35 @@ +mistranslation: 0.880 +device: 0.490 +other: 0.485 +network: 0.462 +semantic: 0.377 +graphic: 0.360 +vnc: 0.298 +socket: 0.267 +instruction: 0.190 +boot: 0.114 +assembly: 0.033 +KVM: 0.029 + +QEMU netdev tap type id name is not used on linux host + +Tested with 0.12.3, 0.12.4, and latest git as of 4 jun 2010. +The new -netdev type seems to ignore manual specifications of tap ifname. + + qemu-system-x86_64 -hda disk.img -netdev tap,id=ids_e0 -device e1000,netdev=ids_e0 + **creates tap0 instead of ids_e0. tap0 passes traffic, ids_e0 doesn't exist +(I tried -netdev type=tap as well for brevity) + +QEMU creates a tap0 (or appropriate) interface and does not name this "ids_e0" as would be expected. I also tried 'pre' creating the tap interface. + +Previous alterantive was + qemu-system-x86_64 -hda disk.img -net nic,model=e1000,vlan=99 -net tap,ifname=ids_e0,vlan=99 + **creates ids_e0 as expected, and passes traffic as expected. + +Thanks to IRC, the correct syntax is: -netdev tap,id=asa1_eth0_tap,ifname=asa1_eth0_tap -device e1000,netdev=asa1_eth0_tap,mac=00:aa:cd:dd:01:01 + +(noted, fd=h option doesn't work on -netdev) + + +The "id=..." is only the QEMU-internal name of the netdev, not the name of the tap device. So this is not a bug --> closing this ticket. + diff --git a/results/classifier/105/mistranslation/59 b/results/classifier/105/mistranslation/59 new file mode 100644 index 000000000..912eca174 --- /dev/null +++ b/results/classifier/105/mistranslation/59 @@ -0,0 +1,14 @@ +mistranslation: 0.981 +device: 0.676 +network: 0.599 +semantic: 0.533 +vnc: 0.489 +other: 0.391 +graphic: 0.373 +socket: 0.350 +instruction: 0.342 +KVM: 0.335 +boot: 0.319 +assembly: 0.147 + +ide/core.c ATA Major Version reporting incorrect diff --git a/results/classifier/105/mistranslation/596 b/results/classifier/105/mistranslation/596 new file mode 100644 index 000000000..8476ad367 --- /dev/null +++ b/results/classifier/105/mistranslation/596 @@ -0,0 +1,14 @@ +mistranslation: 0.775 +device: 0.545 +semantic: 0.485 +instruction: 0.419 +network: 0.348 +graphic: 0.309 +assembly: 0.175 +boot: 0.163 +other: 0.132 +vnc: 0.132 +socket: 0.041 +KVM: 0.012 + +"./ylwrap: -d: not found" error in tricore-debian-cross-container job diff --git a/results/classifier/105/mistranslation/602 b/results/classifier/105/mistranslation/602 new file mode 100644 index 000000000..cc1ec64e9 --- /dev/null +++ b/results/classifier/105/mistranslation/602 @@ -0,0 +1,26 @@ +mistranslation: 0.915 +device: 0.799 +instruction: 0.769 +graphic: 0.691 +network: 0.643 +vnc: 0.614 +socket: 0.526 +semantic: 0.478 +boot: 0.386 +other: 0.251 +KVM: 0.185 +assembly: 0.180 + +Failure to translate host to target errno in IP_RECVERR, IPV6_RECVERR emulation +Description of problem: +In translated IP_RECVERR (and IPV6_RECVERR) control messages, the `ee_errno` is not translated, so host errnos are observed on guests. E.g., `ECONNREFUSED` is 111 on x86_64 host, but expected to be 146 in MIPS ABI. +Steps to reproduce: +1. https://cirrus-ci.com/task/5914289870471168 +Additional information: +The bugs are on [lines 1970 and 2014 here](https://github.com/qemu/qemu/blob/211364c21e7f757ae1acf4e72b5df39c498fb88b/linux-user/syscall.c#L1970-L2014). + +The fix is something like: + +``` +__put_user(host_to_target_errno(errh->ee.ee_errno), &target_errh->ee.ee_errno); +``` diff --git a/results/classifier/105/mistranslation/602336 b/results/classifier/105/mistranslation/602336 new file mode 100644 index 000000000..9d3cdd9c0 --- /dev/null +++ b/results/classifier/105/mistranslation/602336 @@ -0,0 +1,120 @@ +mistranslation: 0.613 +graphic: 0.569 +semantic: 0.540 +other: 0.528 +instruction: 0.484 +device: 0.476 +assembly: 0.464 +network: 0.447 +vnc: 0.420 +KVM: 0.417 +boot: 0.392 +socket: 0.266 + +bad network performance with 10Gbit + +Hello, +I have trouble with the network performance inside my virtual machines. I don't know if this is realy a bug, but I didn't find a solution for this problem in other forums or maillists. + +My KVM-Host machine is connected to a 10Gbit Network. All interfaces are configured to a mtu of 4132. On this host I have no problems and I can use the full bandwidth: + +CPU_Info: +2x Intel Xeon X5570 +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 rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm ida tpr_shadow vnmi flexpriority ept vpid + +KVM Version: +QEMU PC emulator version 0.12.3 (qemu-kvm-0.12.3), Copyright (c) 2003-2008 Fabrice Bellard +0.12.3+noroms-0ubuntu9 + +KVM Host Kernel: +2.6.32-22-server #36-Ubuntu SMP Thu Jun 3 20:38:33 UTC 2010 x86_64 GNU/Linux + +KVM Host OS: +Ubuntu 10.04 LTS +Codename: lucid + +KVM Guest Kernel: +2.6.32-22-server #36-Ubuntu SMP Thu Jun 3 20:38:33 UTC 2010 x86_64 GNU/Linux + +KVM Guest OS: +Ubuntu 10.04 LTS +Codename: lucid + + +# iperf -c 10.10.80.100 -w 65536 -p 12345 -t 60 -P4 +[ ID] Interval Transfer Bandwidth +[ 4] 0.0-60.0 sec 18.8 GBytes 2.69 Gbits/sec +[ 5] 0.0-60.0 sec 15.0 GBytes 2.14 Gbits/sec +[ 6] 0.0-60.0 sec 19.3 GBytes 2.76 Gbits/sec +[ 3] 0.0-60.0 sec 15.1 GBytes 2.16 Gbits/sec +[SUM] 0.0-60.0 sec 68.1 GBytes 9.75 Gbits/sec + + +Inside a virtual machine don't reach this result: + +# iperf -c 10.10.80.100 -w 65536 -p 12345 -t 60 -P 4 +[ ID] Interval Transfer Bandwidth +[ 3] 0.0-60.0 sec 5.65 GBytes 808 Mbits/sec +[ 4] 0.0-60.0 sec 5.52 GBytes 790 Mbits/sec +[ 5] 0.0-60.0 sec 5.66 GBytes 811 Mbits/sec +[ 6] 0.0-60.0 sec 5.70 GBytes 816 Mbits/sec +[SUM] 0.0-60.0 sec 22.5 GBytes 3.23 Gbits/sec + +I only can use 3,23Gbits of 10Gbits. I use the virtio driver for all of my vms, but I have also tried to use the e1000 nic device instead. + +With starting the iperf performance test on multiple vms simultaneously I can use the full bandwidth of the kvm host's interface. But only one vm can't use the full bandwith. Is this a known limitation, or can I improve this performance? + +Does anyone have an idea how I can improve my network performance? It's very important, because I want to use the network interface to boot all vms via AOE (ATA over Ethernet). + +If I mount a harddisk via AOE inside a vm I get only this results: +Write |CPU |Rewrite |CPU |Read |CPU +102440 |10 |51343 |5 |104249 |3 + +On the KVM Host I get those results on a mouted AOE Device: +Write |CPU |Rewrite |CPU |Read |CPU +205597 |19 |139118 |11 |391316 |11 + +If I mount the AOE Device directly on the kvm-host and put a virtual harddisk-file in it I got the following results inside a vm using this harddisk-file: +Write |CPU |Rewrite |CPU |Read |CPU +175140 |12 |136113 |24 |599989 |29 + +I have just tested vhost_net, but without success. +I have upgraded my kernel to 2.6.35-6 with vhost_net support and have +installed the qemu-kvm version from +git://git.kernel.org/pub/scm/linux/kernel/git/mst/qemu-kvm.git (0.12.50) +But I still have the same results as before. + +I had already posted my problem into a few forums, but still got no +reply. + +I would feel very happy if someone can help me. + +best regards + +Have you tried compiling the latest upstream version to see if this is still an issue? + +At the moment i'm using version qemu 0.12.3+noroms-0ubuntu9.18 of my ubuntu distribution. I'm triing to compile the latest upstream version during the next two weeks to verify if this is still an issue. + +Depending on your networking hardware, you may need to use a virtual function to access the 10G from a guest. On mine, failing to set up the xml file correctly resulted in a NAT connection or a bridge connection instead of the full-speed connection. + +This requires libvirt 1.0x BTW. + +the xml that works for me is: + +<interface type='hostdev'> + <mac address='52:54:00:c7:c3:91'/> + <source> + <address type='pci' domain='0x0000' bus='0x02' slot='0x10' function='0x0'/> + </source> + <target dev='macvtap1'/> + <model type='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> + </interface> + +check your lspci output to get the actual bus numbers. + +You can do some performance optimization , such as isolating cpus, closing selinux, closing nmi_watchdog, disable intel_pstate and so on. You can try such grub cmdline: +nmi_watchdog=0 selinux=0 intel_pstate=disable nosoftlockup isolcpus=4,5,6,7 nohz_full=4,5,6,7 + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/608107 b/results/classifier/105/mistranslation/608107 new file mode 100644 index 000000000..c8d621d09 --- /dev/null +++ b/results/classifier/105/mistranslation/608107 @@ -0,0 +1,51 @@ +mistranslation: 0.851 +other: 0.712 +device: 0.708 +semantic: 0.703 +instruction: 0.676 +socket: 0.659 +network: 0.554 +vnc: 0.546 +assembly: 0.525 +boot: 0.515 +graphic: 0.501 +KVM: 0.395 + +ppc fails to clear MSR_POW when incurring exception + +QEMU VERSION: 0.12.4 + +According to FreeScale's 'Programming Environments Manual for 32-bit Implementations of the PowerPC Architecture' [MPCFPE32B, Rev.3, 9/2005], section 6.5, table 6-7, an interrupt resets MSR_POW to zero but qemu-0.12.4 fails to do so. +Resetting the bit is necessary in order to bring the processor out of power-management since otherwise it goes to sleep right away in the exception handler, i.e., it is impossible to leave PM-mode. + + + +Thomas Monjalon wrote: +> From: till <email address hidden> +> +> According to FreeScale's 'Programming Environments Manual for 32-bit +> Implementations of the PowerPC Architecture' [MPCFPE32B, Rev.3, 9/2005], +> section 6.5, table 6-7, an interrupt resets MSR_POW to zero but qemu-0.12.4 +> fails to do so. +> Resetting the bit is necessary in order to bring the processor out of power +> management since otherwise it goes to sleep right away in the exception +> handler, i.e., it is impossible to leave PM-mode. +> + +This doesn't look right. POW shouldn't even get stored in SRR1. Could +you please redo the patch and make sure that mtmsr masks out MSR_POW? + + +Alex + + +I'm afraid I don't understand. My the problem and fix doesn't address mtmsr at all. +It just makes sure MSR_POW is cleared in MSR when an exception occurs. + +Do you mean MSR_POW should masked from MSR before saving it to SRR1? +That's already taken care of (target-ppc/helper.c:2074 [qemu-0.12.4]). + +As far as I can see, this problem has been fixed by this commit here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=41557447d30eeb944e4 +... so I'm setting the status to "Fix released" now. + diff --git a/results/classifier/105/mistranslation/629791 b/results/classifier/105/mistranslation/629791 new file mode 100644 index 000000000..ed3380c58 --- /dev/null +++ b/results/classifier/105/mistranslation/629791 @@ -0,0 +1,21 @@ +mistranslation: 0.911 +other: 0.862 +instruction: 0.849 +device: 0.848 +semantic: 0.806 +graphic: 0.765 +socket: 0.447 +boot: 0.420 +vnc: 0.417 +network: 0.381 +assembly: 0.244 +KVM: 0.142 + +sysret sets invalid ss + +I'm developing an OS. I use only sysret to enter user space. When an interrupt occurred, it would GPF on iretq'ing from it. On investigating, the cs on the stack is 0x2b (valid and correct). The ss on the stack is 0x20, which has a rpl of 0 which is incorrect. iretq checks that and gpf's. Making the irq handler manually modify it to 0x23 fixes it locally. + +This happens on the non-kvm'ed qemu. I haven't tried the kvm'ed one. Qemu version 0.12.5. I haven't tried with the current development version either. + +Minor update, I found that I made a mistake with the value in STAR. I loaded 0x18 into the top 16 bits, so the bug is not that SS is 0x20 (which I thought to be wrong but was my own mistake). Why does it set CS=0x2b from that value & run? + diff --git a/results/classifier/105/mistranslation/638 b/results/classifier/105/mistranslation/638 new file mode 100644 index 000000000..2f09839d2 --- /dev/null +++ b/results/classifier/105/mistranslation/638 @@ -0,0 +1,26 @@ +mistranslation: 0.840 +graphic: 0.800 +device: 0.796 +network: 0.784 +vnc: 0.760 +instruction: 0.732 +socket: 0.696 +semantic: 0.455 +boot: 0.418 +other: 0.198 +KVM: 0.193 +assembly: 0.152 + +exynos4210_uart.c: SIGSEGV when loadvm +Description of problem: +Line 619 of hw/char/exynos4210_uart.c cast the object incorrectly. + +The function will be called with Exynos4210UartFIFO as opaque because it is set as `vmstate_exynos4210_uart_fifo.post_load` + +# +Steps to reproduce: +1. Create a VM with exynos4210_uart +2. savevm +3. loadvm +Additional information: + diff --git a/results/classifier/105/mistranslation/64322995 b/results/classifier/105/mistranslation/64322995 new file mode 100644 index 000000000..7330769b7 --- /dev/null +++ b/results/classifier/105/mistranslation/64322995 @@ -0,0 +1,62 @@ +mistranslation: 0.936 +device: 0.915 +network: 0.914 +semantic: 0.906 +graphic: 0.904 +other: 0.881 +socket: 0.866 +instruction: 0.864 +vnc: 0.801 +boot: 0.780 +KVM: 0.742 +assembly: 0.653 + +[Qemu-devel] [BUG] trace: QEMU hangs on initialization with the "simple" backend + +While starting the softmmu version of QEMU, the simple backend waits for the +writeout thread to signal a condition variable when initializing the output file +path. But since the writeout thread has not been created, it just waits forever. + +Thanks, + Lluis + +On Tue, Feb 09, 2016 at 09:24:04PM +0100, LluÃs Vilanova wrote: +> +While starting the softmmu version of QEMU, the simple backend waits for the +> +writeout thread to signal a condition variable when initializing the output +> +file +> +path. But since the writeout thread has not been created, it just waits +> +forever. +Denis Lunev posted a fix: +https://patchwork.ozlabs.org/patch/580968/ +Stefan +signature.asc +Description: +PGP signature + +Stefan Hajnoczi writes: + +> +On Tue, Feb 09, 2016 at 09:24:04PM +0100, LluÃs Vilanova wrote: +> +> While starting the softmmu version of QEMU, the simple backend waits for the +> +> writeout thread to signal a condition variable when initializing the output +> +> file +> +> path. But since the writeout thread has not been created, it just waits +> +> forever. +> +Denis Lunev posted a fix: +> +https://patchwork.ozlabs.org/patch/580968/ +Great, thanks. + +Lluis + diff --git a/results/classifier/105/mistranslation/657 b/results/classifier/105/mistranslation/657 new file mode 100644 index 000000000..3d0a33521 --- /dev/null +++ b/results/classifier/105/mistranslation/657 @@ -0,0 +1,14 @@ +mistranslation: 0.856 +semantic: 0.830 +device: 0.713 +instruction: 0.661 +other: 0.470 +network: 0.385 +graphic: 0.340 +boot: 0.206 +vnc: 0.120 +KVM: 0.101 +socket: 0.100 +assembly: 0.063 + +qemu no valid state has been set by load or init-program Mac OS X Tiger diff --git a/results/classifier/105/mistranslation/658 b/results/classifier/105/mistranslation/658 new file mode 100644 index 000000000..4e736d9a4 --- /dev/null +++ b/results/classifier/105/mistranslation/658 @@ -0,0 +1,14 @@ +mistranslation: 0.852 +device: 0.737 +instruction: 0.572 +graphic: 0.196 +semantic: 0.153 +other: 0.141 +network: 0.132 +boot: 0.051 +assembly: 0.038 +socket: 0.025 +vnc: 0.020 +KVM: 0.009 + +Missing documentation for TCG ctpop opcode diff --git a/results/classifier/105/mistranslation/658904 b/results/classifier/105/mistranslation/658904 new file mode 100644 index 000000000..68d082523 --- /dev/null +++ b/results/classifier/105/mistranslation/658904 @@ -0,0 +1,22 @@ +mistranslation: 0.932 +semantic: 0.795 +network: 0.741 +device: 0.540 +socket: 0.483 +graphic: 0.420 +other: 0.359 +instruction: 0.292 +boot: 0.281 +vnc: 0.049 +assembly: 0.035 +KVM: 0.034 + +QEMU refers to VLAN, but doesn't mean 802.1Q + +Throughout the (sparse) documentation and the cmd-line help text, Qemu refers to VLAN ("virtual" LANs), which are unrelated to 802.1Q (tagged ethernet) VLAN, which, IMHO is _very_ confusing. Beyond that, it's also unnecessary, as the network in question isn't "virtual", only the devices used to implement it are. + +To avoid further frustration and confusion, can the term VLAN, _please_ be removed from source and documentation and replaced with something more suitable? Perhaps vNIC (seems like VMware is using that term for a similiar concept)? + +This issue has finally been addressed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=af1a5c3eb41521b4f090ad61 + diff --git a/results/classifier/105/mistranslation/673009 b/results/classifier/105/mistranslation/673009 new file mode 100644 index 000000000..030cad8c4 --- /dev/null +++ b/results/classifier/105/mistranslation/673009 @@ -0,0 +1,153 @@ +mistranslation: 0.884 +graphic: 0.841 +other: 0.813 +KVM: 0.803 +vnc: 0.721 +semantic: 0.712 +instruction: 0.666 +device: 0.656 +boot: 0.622 +assembly: 0.609 +socket: 0.583 +network: 0.546 + +Latest git crashes in if_start with netBSD guest + +The latest version in git (cfd07e7abb1ef39373cd4ce312b015d61b9eea8d) crashes when running a NetBSD guest + +Host OS: Debian Linux/x86_64 5.0 +C Compiler: 4.4.5 +Guest OS:NetBSD/i386 5.0.2 +Command Line: +Build Configure: ./configure --enable-linux-aio --enable-io-thread --enable-kvm +GIT commit: d33ea50a958b2e050d2b28e5f17e3b55e91c6d74 + +*** glibc detected *** /home/njh/src/qemu/i386-softmmu/qemu: free(): invalid pointer: 0x00000000025bd290 *** +======= Backtrace: ========= +/lib/libc.so.6(+0x71ad6)[0x7f15dfe0bad6] +/home/njh/src/qemu/i386-softmmu/qemu[0x492ff3] +/home/njh/src/qemu/i386-softmmu/qemu[0x494082] +/home/njh/src/qemu/i386-softmmu/qemu[0x49b38e] +/home/njh/src/qemu/i386-softmmu/qemu[0x49710a] +/home/njh/src/qemu/i386-softmmu/qemu[0x4947c7] +/home/njh/src/qemu/i386-softmmu/qemu[0x5181cc] +/home/njh/src/qemu/i386-softmmu/qemu[0x518c67] +/lib/libc.so.6(__libc_start_main+0xfd)[0x7f15dfdb8c4d] +/home/njh/src/qemu/i386-softmmu/qemu[0x407699] +======= Memory map: ======== +00400000-006a1000 r-xp 00000000 08:03 406539 /home/njh/src/qemu/i386-softmmu/qemu +008a0000-008c4000 rw-p 002a0000 08:03 406539 /home/njh/src/qemu/i386-softmmu/qemu +008c4000-010ae000 rw-p 00000000 00:00 0 +010ae000-010af000 rwxp 00000000 00:00 0 +010af000-010c7000 rw-p 00000000 00:00 0 +023a8000-024ab000 rw-p 00000000 00:00 0 +024ab000-024bb000 rw-p 00000000 00:00 0 +024bb000-025d5000 rw-p 00000000 00:00 0 +40a6f000-42a6f000 rwxp 00000000 00:00 0 +7f15d292b000-7f15d2941000 r-xp 00000000 08:03 131218 /lib/libgcc_s.so.1 +7f15d2941000-7f15d2b40000 ---p 00016000 08:03 131218 /lib/libgcc_s.so.1 +7f15d2b40000-7f15d2b41000 rw-p 00015000 08:03 131218 /lib/libgcc_s.so.1 +7f15d2b41000-7f15d2b46000 r-xp 00000000 08:03 43471 /usr/lib/libXfixes.so.3.1.0 +7f15d2b46000-7f15d2d45000 ---p 00005000 08:03 43471 /usr/lib/libXfixes.so.3.1.0 +7f15d2d45000-7f15d2d46000 rw-p 00004000 08:03 43471 /usr/lib/libXfixes.so.3.1.0 +7f15d2d46000-7f15d2d4f000 r-xp 00000000 08:03 45831 /usr/lib/libXcursor.so.1.0.2 +7f15d2d4f000-7f15d2f4f000 ---p 00009000 08:03 45831 /usr/lib/libXcursor.so.1.0.2 +7f15d2f4f000-7f15d2f50000 rw-p 00009000 08:03 45831 /usr/lib/libXcursor.so.1.0.2 +7f15d2f50000-7f15d2f9d000 rw-p 00000000 00:00 0 +7f15d3025000-7f15d319a000 r--p 00000000 08:03 298138 /usr/lib/locale/locale-archive +7f15d319a000-7f15d31a2000 r-xp 00000000 08:03 41266 /usr/lib/libXrandr.so.2.2.0 +7f15d31a2000-7f15d33a1000 ---p 00008000 08:03 41266 /usr/lib/libXrandr.so.2.2.0 +7f15d33a1000-7f15d33a2000 rw-p 00007000 08:03 41266 /usr/lib/libXrandr.so.2.2.0 +7f15d33a2000-7f15d33ab000 r-xp 00000000 08:03 74608 /usr/lib/libXrender.so.1.3.0 +7f15d33ab000-7f15d35ab000 ---p 00009000 08:03 74608 /usr/lib/libXrender.so.1.3.0 +7f15d35ab000-7f15d35ac000 rw-p 00009000 08:03 74608 /usr/lib/libXrender.so.1.3.0 +7f15d35ac000-7f15d35bd000 r-xp 00000000 08:03 29479 /usr/lib/libXext.so.6.4.0 +7f15d35bd000-7f15d37bd000 ---p 00011000 08:03 29479 /usr/lib/libXext.so.6.4.0 +7f15d37bd000-7f15d37be000 rw-p 00011000 08:03 29479 /usr/lib/libXext.so.6.4.0 +7f15d37d2000-7f15d37d3000 ---p 00000000 00:00 0 +7f15d37d3000-7f15d3c36000 rw-p 00000000 00:00 0 +7f15d3c49000-7f15d3d63000 rw-s 00000000 00:04 2195492 /SYSV00000000 (deleted) +7f15d3d63000-7f15d3d64000 rw-p 00000000 00:00 0 +7f15d3d64000-7f15d4564000 rw-p 00000000 00:00 0 +7f15d4564000-7f15d4566000 rw-p 00000000 00:00 0 +7f15d4566000-7f15dc566000 rw-p 00000000 00:00 0 +7f15dc566000-7f15dc567000 rw-p 00000000 00:00 0 +7f15dc567000-7f15dc568000 ---p 00000000 00:00 0 +7f15dc568000-7f15de76a000 rw-p 00000000 00:00 0 +7f15de76a000-7f15de76f000 r-xp 00000000 08:03 47085 /usr/lib/libXdmcp.so.6.0.0 +7f15de76f000-7f15de96e000 ---p 00005000 08:03 47085 /usr/lib/libXdmcp.so.6.0.0 +7f15de96e000-7f15de96f000 rw-p 00004000 08:03 47085 /usr/lib/libXdmcp.so.6.0.0 +7f15de96f000-7f15de971000 r-xp 00000000 08:03 68458 /usr/lib/libXau.so.6.0.0 +7f15de971000-7f15deb71000 ---p 00002000 08:03 68458 /usr/lib/libXau.so.6.0.0 +7f15deb71000-7f15deb72000 rw-p 00002000 08:03 68458 /usr/lib/libXau.so.6.0.0 +7f15deb72000-7f15deb91000 r-xp 00000000 08:03 134345 /lib/libx86.so.1 +7f15deb91000-7f15ded91000 ---p 0001f000 08:03 134345 /lib/libx86.so.1 +7f15ded91000-7f15ded93000 rw-p 0001f000 08:03 134345 /lib/libx86.so.1 +7f15ded93000-7f15ded94000 rw-p 00000000 00:00 0 +7f15ded94000-7f15dedb0000 r-xp 00000000 08:03 13392 /usr/lib/libxcb.so.1.1.0 +7f15dedb0000-7f15defaf000 ---p 0001c000 08:03 13392 /usr/lib/libxcb.so.1.1.0 +7f15defaf000-7f15defb0000 rw-p 0001b000 08:03 13392 /usr/lib/libxcb.so.1.1.0 +7f15defb0000-7f15deffd000 r-xp 00000000 08:03 2979 /usr/lib/libvga.so.1.4.3 +7f15deffd000-7f15df1fc000 ---p 0004d000 08:03 2979 /usr/lib/libvga.so.1.4.3 +7f15df1fc000-7f15df205000 rw-p 0004c000 08:03 2979 /usr/lib/libvga.so.1.4.3 +7f15df205000-7f15df20e000 rw-p 00000000 00:00 0 +7f15df20e000-7f15df224000 r-xp 00000000 08:03 12136 /usr/lib/libdirect-1.2.so.9.0.1 +7f15df224000-7f15df423000 ---p 00016000 08:03 12136 /usr/lib/libdirect-1.2.so.9.0.1 +7f15df423000-7f15df425000 rw-p 00015000 08:03 12136 /usr/lib/libdirect-1.2.so.9.0.1 +7f15df425000-7f15df42e000 r-xp 00000000 08:03 11944 /usr/lib/libfusion-1.2.so.9.0.1 +7f15df42e000-7f15df62e000 ---p 00009000 08:03 11944 /usr/lib/libfusion-1.2.so.9.0.1 +7f15df62e000-7f15df62f000 rw-p 00009000 08:03 11944 /usr/lib/libfusion-1.2.so.9.0.1 +7f15df62f000-7f15df6ae000 r-xp 00000000 08:03 11998 /usr/lib/libdirectfb-1.2.so.9.0.1 +7f15df6ae000-7f15df8ad000 ---p 0007f000 08:03 11998 /usr/lib/libdirectfb-1.2.so.9.0.1 +7f15df8ad000-7f15df8b1000 rw-p 0007e000 08:03 11998 /usr/lib/libdirectfb-1.2.so.9.0.1 +7f15df8b1000-7f15df98f000 r-xp 00000000 08:03 92358 /usr/lib/libasound.so.2.0.0 +7f15df98f000-7f15dfb8e000 ---p 000de000 08:03 92358 /usr/lib/libasound.so.2.0.0 +7f15dfb8e000-7f15dfb96000 rw-p 000dd000 08:03 92358 /usr/lib/libasound.so.2.0.0 +7f15dfb96000-7f15dfb98000 r-xp 00000000 08:03 163705 /lib/libdl-2.11.2.so +7f15dfb98000-7f15dfd98000 ---p 00002000 08:03 163705 /lib/libdl-2.11.2.so + +GDB output: + +Thread 3 (Thread 3756): +#0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136 +#1 0x00007f15e182a0e9 in _L_lock_953 () from /lib/libpthread.so.0 +#2 0x00007f15e1829f0b in __pthread_mutex_lock (mutex=0x10690c0) at pthread_mutex_lock.c:61 +#3 0x00000000004914f9 in qemu_mutex_lock (mutex=0x10690c0) at qemu-thread.c:50 +#4 0x0000000000408c4c in qemu_mutex_lock_iothread () at /home/njh/src/qemu/cpus.c:737 +#5 0x000000000041af8e in kvm_cpu_exec (env=0x23e3c40) at /home/njh/src/qemu/kvm-all.c:878 +#6 0x00000000004a7885 in cpu_x86_exec (env1=<value optimized out>) at /home/njh/src/qemu/cpu-exec.c:338 +#7 0x00000000004086e8 in qemu_cpu_exec (env=0x23e3c40) at /home/njh/src/qemu/cpus.c:896 +#8 0x00000000004099e4 in kvm_cpu_thread_fn (arg=<value optimized out>) at /home/njh/src/qemu/cpus.c:613 +#9 0x00007f15e18278ba in start_thread (arg=<value optimized out>) at pthread_create.c:300 +#10 0x00007f15dfe6902d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 +#11 0x0000000000000000 in ?? () + +Thread 2 (Thread 3757): +#0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:211 +#1 0x000000000042ca0b in cond_timedwait (unused=<value optimized out>) at posix-aio-compat.c:104 +#2 aio_thread (unused=<value optimized out>) at posix-aio-compat.c:325 +#3 0x00007f15e18278ba in start_thread (arg=<value optimized out>) at pthread_create.c:300 +#4 0x00007f15dfe6902d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 +#5 0x0000000000000000 in ?? () +Current language: auto +The current source language is "auto; currently asm". + +Thread 1 (Thread 3755): +#0 0x00007f15dfdcc165 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 +#1 0x00007f15dfdcef70 in *__GI_abort () at abort.c:92 +#2 0x00007f15dfe0227b in __libc_message (do_abort=<value optimized out>, fmt=<value optimized out>) at ../sysdeps/unix/sysv/linux/libc_fatal.c:189 +#3 0x00007f15dfe0bad6 in malloc_printerr (action=3, str=0x7f15dfebfb75 "free(): invalid pointer", ptr=<value optimized out>) at malloc.c:6267 +#4 0x0000000000492ff3 in if_start (slirp=0x23aa400) at slirp/if.c:205 +#5 0x0000000000494082 in ip_output (so=<value optimized out>, m0=0x25d3ff0) at slirp/ip_output.c:160 +#6 0x000000000049b38e in udp_output (so=0xeab, m=0xeab, addr=<value optimized out>) at slirp/udp.c:299 +#7 0x000000000049710a in sorecvfrom (so=0x2529380) at slirp/socket.c:527 +#8 0x00000000004947c7 in slirp_select_poll (readfds=0x7fff99a79390, writefds=<value optimized out>, xfds=0x7fff99a79290, select_error=<value optimized out>) + at slirp/slirp.c:542 +#9 0x00000000005181cc in main_loop_wait (nonblocking=<value optimized out>) at /home/njh/src/qemu/vl.c:1266 +#10 0x0000000000518c67 in main_loop (argc=<value optimized out>, argv=<value optimized out>, envp=<value optimized out>) at /home/njh/src/qemu/vl.c:1309 +#11 main (argc=<value optimized out>, argv=<value optimized out>, envp=<value optimized out>) at /home/njh/src/qemu/vl.c:2999 + +I assume this problem has been fixed nowadays ... or can you still somehow reproduce it with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/687 b/results/classifier/105/mistranslation/687 new file mode 100644 index 000000000..e847c143c --- /dev/null +++ b/results/classifier/105/mistranslation/687 @@ -0,0 +1,14 @@ +mistranslation: 0.735 +device: 0.494 +semantic: 0.440 +instruction: 0.297 +graphic: 0.272 +assembly: 0.172 +other: 0.060 +network: 0.023 +boot: 0.007 +vnc: 0.006 +socket: 0.002 +KVM: 0.001 + +what is the DMAR? diff --git a/results/classifier/105/mistranslation/688 b/results/classifier/105/mistranslation/688 new file mode 100644 index 000000000..76542b3b8 --- /dev/null +++ b/results/classifier/105/mistranslation/688 @@ -0,0 +1,60 @@ +mistranslation: 0.881 +graphic: 0.863 +instruction: 0.768 +semantic: 0.755 +other: 0.669 +device: 0.645 +assembly: 0.489 +vnc: 0.413 +boot: 0.398 +network: 0.397 +socket: 0.311 +KVM: 0.230 + +Shrinking an image with qemu-img does not reduce image file size +Description of problem: +I have a macOS 10.9 VM using a qcow2 image that was 151GB. The image was originally converted from a VMware image with: +``` +qemu-img convert macOS-10.9.vmdk -O qcow2 -o preallocation=falloc macOS-10.9.qcow2 +``` +This resulted in `macOS-10.9.qcow2` being 151GB big: +``` +$ du -h macOS-10.9.qcow2 +151G macOS-10.9.qcow2 +``` +After reducing the filesystem size from within macOS to 25GB with DiskUtil, I shut down the VM and resized the image to 30GB with: +``` +qemu-img resize -f qcow2 --shrink macOS-10.9.qcow2 30G +``` +This succeeded. However, the file still consumes 151GB of space: +``` +$ du -h macOS-10.9.qcow2 +151G macOS-10.9.qcow2 +``` +Even though `qemu-img info` shows: +``` +$ qemu-img info macOS-10.9.qcow2 +image: macOS-10.9.qcow2 +file format: qcow2 +virtual size: 30 GiB (32212254720 bytes) +disk size: 30 GiB +cluster_size: 65536 +Format specific information: + compat: 1.1 + compression type: zlib + lazy refcounts: false + refcount bits: 16 + corrupt: false + extended l2: false +``` +The size inside the VM is also reported as being 30GB. + +The whole point of resizing that image was to free up disk space on the host. But this doesn't seem to be happening. + +My filesystem is ext4. +Steps to reproduce: +1. Create a vmdk image with `qemu-img create -f vmdk test.vmdk 5G` +2. Convert the vmdk image to qcow2 with `qemu-img convert test.vmdk -O qcow2 -o preallocation=falloc test.qcow2` +3. Shrink the new image with `qemu-img resize -f qcow2 --shrink test.qcow2 3G` + +The resulting `test.qcow2` file should be 3GB, but it's not. It's 5GB. diff --git a/results/classifier/105/mistranslation/692 b/results/classifier/105/mistranslation/692 new file mode 100644 index 000000000..821fac600 --- /dev/null +++ b/results/classifier/105/mistranslation/692 @@ -0,0 +1,14 @@ +mistranslation: 0.887 +device: 0.724 +instruction: 0.688 +network: 0.636 +other: 0.559 +semantic: 0.441 +KVM: 0.292 +boot: 0.276 +vnc: 0.245 +assembly: 0.234 +graphic: 0.230 +socket: 0.171 + +remove_fd_in_watch does not call g_source_unref diff --git a/results/classifier/105/mistranslation/70294255 b/results/classifier/105/mistranslation/70294255 new file mode 100644 index 000000000..2f154bf28 --- /dev/null +++ b/results/classifier/105/mistranslation/70294255 @@ -0,0 +1,1069 @@ +mistranslation: 0.862 +assembly: 0.861 +semantic: 0.858 +socket: 0.858 +device: 0.857 +graphic: 0.857 +instruction: 0.856 +other: 0.852 +network: 0.846 +vnc: 0.837 +boot: 0.811 +KVM: 0.806 + +[Qemu-devel] 答复: Re: 答复: Re: 答复: Re: 答复: Re: [BUG]COLO failover hang + +hi: + +yes.it is better. + +And should we delete + + + + +#ifdef WIN32 + + QIO_CHANNEL(cioc)-ï¼event = CreateEvent(NULL, FALSE, FALSE, NULL) + +#endif + + + + +in qio_channel_socket_acceptï¼ + +qio_channel_socket_new already have it. + + + + + + + + + + + + +åå§é®ä»¶ + + + +åä»¶äººï¼ address@hidden +æ¶ä»¶äººï¼ç广10165992 +æéäººï¼ address@hidden address@hidden address@hidden address@hidden +æ¥ æ ï¼2017å¹´03æ22æ¥ 15:03 +主 é¢ ï¼Re: [Qemu-devel] çå¤: Re: çå¤: Re: çå¤: Re: [BUG]COLO failover hang + + + + + +Hi, + +On 2017/3/22 9:42, address@hidden wrote: +ï¼ diff --git a/migration/socket.c b/migration/socket.c +ï¼ +ï¼ +ï¼ index 13966f1..d65a0ea 100644 +ï¼ +ï¼ +ï¼ --- a/migration/socket.c +ï¼ +ï¼ +ï¼ +++ b/migration/socket.c +ï¼ +ï¼ +ï¼ @@ -147,8 +147,9 @@ static gboolean +socket_accept_incoming_migration(QIOChannel *ioc, +ï¼ +ï¼ +ï¼ } +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ trace_migration_socket_incoming_accepted() +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ qio_channel_set_name(QIO_CHANNEL(sioc), "migration-socket-incoming") +ï¼ +ï¼ +ï¼ + qio_channel_set_feature(QIO_CHANNEL(sioc), QIO_CHANNEL_FEATURE_SHUTDOWN) +ï¼ +ï¼ +ï¼ migration_channel_process_incoming(migrate_get_current(), +ï¼ +ï¼ +ï¼ QIO_CHANNEL(sioc)) +ï¼ +ï¼ +ï¼ object_unref(OBJECT(sioc)) +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ Is this patch ok? +ï¼ + +Yes, i think this works, but a better way maybe to call +qio_channel_set_feature() +in qio_channel_socket_accept(), we didn't set the SHUTDOWN feature for the +socket accept fd, +Or fix it by this: + +diff --git a/io/channel-socket.c b/io/channel-socket.c +index f546c68..ce6894c 100644 +--- a/io/channel-socket.c ++++ b/io/channel-socket.c +@@ -330,9 +330,8 @@ qio_channel_socket_accept(QIOChannelSocket *ioc, + Error **errp) + { + QIOChannelSocket *cioc +- +- cioc = QIO_CHANNEL_SOCKET(object_new(TYPE_QIO_CHANNEL_SOCKET)) +- cioc-ï¼fd = -1 ++ ++ cioc = qio_channel_socket_new() + cioc-ï¼remoteAddrLen = sizeof(ioc-ï¼remoteAddr) + cioc-ï¼localAddrLen = sizeof(ioc-ï¼localAddr) + + +Thanks, +Hailiang + +ï¼ I have test it . The test could not hang any more. +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ åå§é®ä»¶ +ï¼ +ï¼ +ï¼ +ï¼ åä»¶äººï¼ address@hidden +ï¼ æ¶ä»¶äººï¼ address@hidden address@hidden +ï¼ æéäººï¼ address@hidden address@hidden address@hidden +ï¼ æ¥ æ ï¼2017å¹´03æ22æ¥ 09:11 +ï¼ ä¸» é¢ ï¼Re: [Qemu-devel] çå¤: Re: çå¤: Re: [BUG]COLO failover hang +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ On 2017/3/21 19:56, Dr. David Alan Gilbert wrote: +ï¼ ï¼ * Hailiang Zhang (address@hidden) wrote: +ï¼ ï¼ï¼ Hi, +ï¼ ï¼ï¼ +ï¼ ï¼ï¼ Thanks for reporting this, and i confirmed it in my test, and it is a bug. +ï¼ ï¼ï¼ +ï¼ ï¼ï¼ Though we tried to call qemu_file_shutdown() to shutdown the related fd, in +ï¼ ï¼ï¼ case COLO thread/incoming thread is stuck in read/write() while do +failover, +ï¼ ï¼ï¼ but it didn't take effect, because all the fd used by COLO (also migration) +ï¼ ï¼ï¼ has been wrapped by qio channel, and it will not call the shutdown API if +ï¼ ï¼ï¼ we didn't qio_channel_set_feature(QIO_CHANNEL(sioc), +QIO_CHANNEL_FEATURE_SHUTDOWN). +ï¼ ï¼ï¼ +ï¼ ï¼ï¼ Cc: Dr. David Alan Gilbert address@hidden +ï¼ ï¼ï¼ +ï¼ ï¼ï¼ I doubted migration cancel has the same problem, it may be stuck in write() +ï¼ ï¼ï¼ if we tried to cancel migration. +ï¼ ï¼ï¼ +ï¼ ï¼ï¼ void fd_start_outgoing_migration(MigrationState *s, const char *fdname, +Error **errp) +ï¼ ï¼ï¼ { +ï¼ ï¼ï¼ qio_channel_set_name(QIO_CHANNEL(ioc), "migration-fd-outgoing") +ï¼ ï¼ï¼ migration_channel_connect(s, ioc, NULL) +ï¼ ï¼ï¼ ... ... +ï¼ ï¼ï¼ We didn't call qio_channel_set_feature(QIO_CHANNEL(sioc), +QIO_CHANNEL_FEATURE_SHUTDOWN) above, +ï¼ ï¼ï¼ and the +ï¼ ï¼ï¼ migrate_fd_cancel() +ï¼ ï¼ï¼ { +ï¼ ï¼ï¼ ... ... +ï¼ ï¼ï¼ if (s-ï¼state == MIGRATION_STATUS_CANCELLING && f) { +ï¼ ï¼ï¼ qemu_file_shutdown(f) --ï¼ This will not take effect. No ? +ï¼ ï¼ï¼ } +ï¼ ï¼ï¼ } +ï¼ ï¼ +ï¼ ï¼ (cc'd in Daniel Berrange). +ï¼ ï¼ I see that we call qio_channel_set_feature(ioc, +QIO_CHANNEL_FEATURE_SHUTDOWN) at the +ï¼ ï¼ top of qio_channel_socket_new so I think that's safe isn't it? +ï¼ ï¼ +ï¼ +ï¼ Hmm, you are right, this problem is only exist for the migration incoming fd, +thanks. +ï¼ +ï¼ ï¼ Dave +ï¼ ï¼ +ï¼ ï¼ï¼ Thanks, +ï¼ ï¼ï¼ Hailiang +ï¼ ï¼ï¼ +ï¼ ï¼ï¼ On 2017/3/21 16:10, address@hidden wrote: +ï¼ ï¼ï¼ï¼ Thank youã +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ I have test areadyã +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ When the Primary Node panic,the Secondary Node qemu hang at the same +placeã +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ Incorrding +http://wiki.qemu-project.org/Features/COLO +ï¼kill Primary Node +qemu will not produce the problem,but Primary Node panic canã +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ I think due to the feature of channel does not support +QIO_CHANNEL_FEATURE_SHUTDOWN. +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ when failover,channel_shutdown could not shut down the channel. +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ so the colo_process_incoming_thread will hang at recvmsg. +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ I test a patch: +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ diff --git a/migration/socket.c b/migration/socket.c +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ index 13966f1..d65a0ea 100644 +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ --- a/migration/socket.c +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +++ b/migration/socket.c +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ @@ -147,8 +147,9 @@ static gboolean +socket_accept_incoming_migration(QIOChannel *ioc, +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ } +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ trace_migration_socket_incoming_accepted() +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ qio_channel_set_name(QIO_CHANNEL(sioc), +"migration-socket-incoming") +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ + qio_channel_set_feature(QIO_CHANNEL(sioc), +QIO_CHANNEL_FEATURE_SHUTDOWN) +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ migration_channel_process_incoming(migrate_get_current(), +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ QIO_CHANNEL(sioc)) +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ object_unref(OBJECT(sioc)) +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ My test will not hang any more. +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ åå§é®ä»¶ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ åä»¶äººï¼ address@hidden +ï¼ ï¼ï¼ï¼ æ¶ä»¶äººï¼ç广10165992 address@hidden +ï¼ ï¼ï¼ï¼ æéäººï¼ address@hidden address@hidden +ï¼ ï¼ï¼ï¼ æ¥ æ ï¼2017å¹´03æ21æ¥ 15:58 +ï¼ ï¼ï¼ï¼ 主 é¢ ï¼Re: [Qemu-devel] çå¤: Re: [BUG]COLO failover hang +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ Hi,Wang. +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ You can test this branch: +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +https://github.com/coloft/qemu/tree/colo-v5.1-developing-COLO-frame-v21-with-shared-disk +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ and please follow wiki ensure your own configuration correctly. +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +http://wiki.qemu-project.org/Features/COLO +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ Thanks +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ Zhang Chen +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ On 03/21/2017 03:27 PM, address@hidden wrote: +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ hi. +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ I test the git qemu master have the same problem. +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ (gdb) bt +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #0 qio_channel_socket_readv (ioc=0x7f65911b4e50, iov=0x7f64ef3fd880, +ï¼ ï¼ï¼ï¼ ï¼ niov=1, fds=0x0, nfds=0x0, errp=0x0) at io/channel-socket.c:461 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #1 0x00007f658e4aa0c2 in qio_channel_read +ï¼ ï¼ï¼ï¼ ï¼ (address@hidden, address@hidden "", +ï¼ ï¼ï¼ï¼ ï¼ address@hidden, address@hidden) at io/channel.c:114 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #2 0x00007f658e3ea990 in channel_get_buffer (opaque=ï¼optimized outï¼, +ï¼ ï¼ï¼ï¼ ï¼ buf=0x7f65907cb838 "", pos=ï¼optimized outï¼, size=32768) at +ï¼ ï¼ï¼ï¼ ï¼ migration/qemu-file-channel.c:78 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #3 0x00007f658e3e97fc in qemu_fill_buffer (f=0x7f65907cb800) at +ï¼ ï¼ï¼ï¼ ï¼ migration/qemu-file.c:295 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #4 0x00007f658e3ea2e1 in qemu_peek_byte (address@hidden, +ï¼ ï¼ï¼ï¼ ï¼ address@hidden) at migration/qemu-file.c:555 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #5 0x00007f658e3ea34b in qemu_get_byte (address@hidden) at +ï¼ ï¼ï¼ï¼ ï¼ migration/qemu-file.c:568 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #6 0x00007f658e3ea552 in qemu_get_be32 (address@hidden) at +ï¼ ï¼ï¼ï¼ ï¼ migration/qemu-file.c:648 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #7 0x00007f658e3e66e5 in colo_receive_message (f=0x7f65907cb800, +ï¼ ï¼ï¼ï¼ ï¼ address@hidden) at migration/colo.c:244 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #8 0x00007f658e3e681e in colo_receive_check_message (f=ï¼optimized +ï¼ ï¼ï¼ï¼ ï¼ outï¼, address@hidden, +ï¼ ï¼ï¼ï¼ ï¼ address@hidden) +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ at migration/colo.c:264 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #9 0x00007f658e3e740e in colo_process_incoming_thread +ï¼ ï¼ï¼ï¼ ï¼ (opaque=0x7f658eb30360 ï¼mis_current.31286ï¼) at migration/colo.c:577 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #10 0x00007f658be09df3 in start_thread () from /lib64/libpthread.so.0 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #11 0x00007f65881983ed in clone () from /lib64/libc.so.6 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ (gdb) p ioc-ï¼name +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ $2 = 0x7f658ff7d5c0 "migration-socket-incoming" +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ (gdb) p ioc-ï¼features Do not support QIO_CHANNEL_FEATURE_SHUTDOWN +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ $3 = 0 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ (gdb) bt +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #0 socket_accept_incoming_migration (ioc=0x7fdcceeafa90, +ï¼ ï¼ï¼ï¼ ï¼ condition=G_IO_IN, opaque=0x7fdcceeafa90) at migration/socket.c:137 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #1 0x00007fdcc6966350 in g_main_dispatch (context=ï¼optimized outï¼) at +ï¼ ï¼ï¼ï¼ ï¼ gmain.c:3054 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #2 g_main_context_dispatch (context=ï¼optimized outï¼, +ï¼ ï¼ï¼ï¼ ï¼ address@hidden) at gmain.c:3630 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #3 0x00007fdccb8a6dcc in glib_pollfds_poll () at util/main-loop.c:213 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #4 os_host_main_loop_wait (timeout=ï¼optimized outï¼) at +ï¼ ï¼ï¼ï¼ ï¼ util/main-loop.c:258 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #5 main_loop_wait (address@hidden) at +ï¼ ï¼ï¼ï¼ ï¼ util/main-loop.c:506 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #6 0x00007fdccb526187 in main_loop () at vl.c:1898 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #7 main (argc=ï¼optimized outï¼, argv=ï¼optimized outï¼, envp=ï¼optimized +ï¼ ï¼ï¼ï¼ ï¼ outï¼) at vl.c:4709 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ (gdb) p ioc-ï¼features +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ $1 = 6 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ (gdb) p ioc-ï¼name +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ $2 = 0x7fdcce1b1ab0 "migration-socket-listener" +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ May be socket_accept_incoming_migration should +ï¼ ï¼ï¼ï¼ ï¼ call qio_channel_set_feature(ioc, QIO_CHANNEL_FEATURE_SHUTDOWN)?? +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ thank you. +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ åå§é®ä»¶ +ï¼ ï¼ï¼ï¼ ï¼ address@hidden +ï¼ ï¼ï¼ï¼ ï¼ address@hidden +ï¼ ï¼ï¼ï¼ ï¼ address@hidden@huawei.comï¼ +ï¼ ï¼ï¼ï¼ ï¼ *æ¥ æ ï¼*2017å¹´03æ16æ¥ 14:46 +ï¼ ï¼ï¼ï¼ ï¼ *主 é¢ ï¼**Re: [Qemu-devel] COLO failover hang* +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ On 03/15/2017 05:06 PM, wangguang wrote: +ï¼ ï¼ï¼ï¼ ï¼ ï¼ am testing QEMU COLO feature described here [QEMU +ï¼ ï¼ï¼ï¼ ï¼ ï¼ Wiki]( +http://wiki.qemu-project.org/Features/COLO +). +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ When the Primary Node panic,the Secondary Node qemu hang. +ï¼ ï¼ï¼ï¼ ï¼ ï¼ hang at recvmsg in qio_channel_socket_readv. +ï¼ ï¼ï¼ï¼ ï¼ ï¼ And I run { 'execute': 'nbd-server-stop' } and { "execute": +ï¼ ï¼ï¼ï¼ ï¼ ï¼ "x-colo-lost-heartbeat" } in Secondary VM's +ï¼ ï¼ï¼ï¼ ï¼ ï¼ monitor,the Secondary Node qemu still hang at recvmsg . +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ I found that the colo in qemu is not complete yet. +ï¼ ï¼ï¼ï¼ ï¼ ï¼ Do the colo have any plan for development? +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ Yes, We are developing. You can see some of patch we pushing. +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ Has anyone ever run it successfully? Any help is appreciated! +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ In our internal version can run it successfully, +ï¼ ï¼ï¼ï¼ ï¼ The failover detail you can ask Zhanghailiang for help. +ï¼ ï¼ï¼ï¼ ï¼ Next time if you have some question about COLO, +ï¼ ï¼ï¼ï¼ ï¼ please cc me and zhanghailiang address@hidden +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ Thanks +ï¼ ï¼ï¼ï¼ ï¼ Zhang Chen +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ centos7.2+qemu2.7.50 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ (gdb) bt +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #0 0x00007f3e00cc86ad in recvmsg () from /lib64/libpthread.so.0 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #1 0x00007f3e0332b738 in qio_channel_socket_readv (ioc=ï¼optimized +outï¼, +ï¼ ï¼ï¼ï¼ ï¼ ï¼ iov=ï¼optimized outï¼, niov=ï¼optimized outï¼, fds=0x0, nfds=0x0, +errp=0x0) at +ï¼ ï¼ï¼ï¼ ï¼ ï¼ io/channel-socket.c:497 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #2 0x00007f3e03329472 in qio_channel_read (address@hidden, +ï¼ ï¼ï¼ï¼ ï¼ ï¼ address@hidden "", address@hidden, +ï¼ ï¼ï¼ï¼ ï¼ ï¼ address@hidden) at io/channel.c:97 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #3 0x00007f3e032750e0 in channel_get_buffer (opaque=ï¼optimized outï¼, +ï¼ ï¼ï¼ï¼ ï¼ ï¼ buf=0x7f3e05910f38 "", pos=ï¼optimized outï¼, size=32768) at +ï¼ ï¼ï¼ï¼ ï¼ ï¼ migration/qemu-file-channel.c:78 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #4 0x00007f3e0327412c in qemu_fill_buffer (f=0x7f3e05910f00) at +ï¼ ï¼ï¼ï¼ ï¼ ï¼ migration/qemu-file.c:257 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #5 0x00007f3e03274a41 in qemu_peek_byte (address@hidden, +ï¼ ï¼ï¼ï¼ ï¼ ï¼ address@hidden) at migration/qemu-file.c:510 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #6 0x00007f3e03274aab in qemu_get_byte (address@hidden) at +ï¼ ï¼ï¼ï¼ ï¼ ï¼ migration/qemu-file.c:523 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #7 0x00007f3e03274cb2 in qemu_get_be32 (address@hidden) at +ï¼ ï¼ï¼ï¼ ï¼ ï¼ migration/qemu-file.c:603 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #8 0x00007f3e03271735 in colo_receive_message (f=0x7f3e05910f00, +ï¼ ï¼ï¼ï¼ ï¼ ï¼ address@hidden) at migration/colo.c:215 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #9 0x00007f3e0327250d in colo_wait_handle_message +(errp=0x7f3d62bfaa48, +ï¼ ï¼ï¼ï¼ ï¼ ï¼ checkpoint_request=ï¼synthetic pointerï¼, f=ï¼optimized outï¼) at +ï¼ ï¼ï¼ï¼ ï¼ ï¼ migration/colo.c:546 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #10 colo_process_incoming_thread (opaque=0x7f3e067245e0) at +ï¼ ï¼ï¼ï¼ ï¼ ï¼ migration/colo.c:649 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #11 0x00007f3e00cc1df3 in start_thread () from /lib64/libpthread.so.0 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #12 0x00007f3dfc9c03ed in clone () from /lib64/libc..so.6 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ -- +ï¼ ï¼ï¼ï¼ ï¼ ï¼ View this message in context: +http://qemu.11.n7.nabble.com/COLO-failover-hang-tp473250.html +ï¼ ï¼ï¼ï¼ ï¼ ï¼ Sent from the Developer mailing list archive at Nabble.com. +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ -- +ï¼ ï¼ï¼ï¼ ï¼ Thanks +ï¼ ï¼ï¼ï¼ ï¼ Zhang Chen +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ +ï¼ ï¼ -- +ï¼ ï¼ Dr. David Alan Gilbert / address@hidden / Manchester, UK +ï¼ ï¼ +ï¼ ï¼ . +ï¼ ï¼ +ï¼ + +On 2017/3/22 16:09, address@hidden wrote: +hi: + +yes.it is better. + +And should we delete +Yes, you are right. +#ifdef WIN32 + + QIO_CHANNEL(cioc)-ï¼event = CreateEvent(NULL, FALSE, FALSE, NULL) + +#endif + + + + +in qio_channel_socket_acceptï¼ + +qio_channel_socket_new already have it. + + + + + + + + + + + + +åå§é®ä»¶ + + + +åä»¶äººï¼ address@hidden +æ¶ä»¶äººï¼ç广10165992 +æéäººï¼ address@hidden address@hidden address@hidden address@hidden +æ¥ æ ï¼2017å¹´03æ22æ¥ 15:03 +主 é¢ ï¼Re: [Qemu-devel] çå¤: Re: çå¤: Re: çå¤: Re: [BUG]COLO failover hang + + + + + +Hi, + +On 2017/3/22 9:42, address@hidden wrote: +ï¼ diff --git a/migration/socket.c b/migration/socket.c +ï¼ +ï¼ +ï¼ index 13966f1..d65a0ea 100644 +ï¼ +ï¼ +ï¼ --- a/migration/socket.c +ï¼ +ï¼ +ï¼ +++ b/migration/socket.c +ï¼ +ï¼ +ï¼ @@ -147,8 +147,9 @@ static gboolean +socket_accept_incoming_migration(QIOChannel *ioc, +ï¼ +ï¼ +ï¼ } +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ trace_migration_socket_incoming_accepted() +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ qio_channel_set_name(QIO_CHANNEL(sioc), "migration-socket-incoming") +ï¼ +ï¼ +ï¼ + qio_channel_set_feature(QIO_CHANNEL(sioc), QIO_CHANNEL_FEATURE_SHUTDOWN) +ï¼ +ï¼ +ï¼ migration_channel_process_incoming(migrate_get_current(), +ï¼ +ï¼ +ï¼ QIO_CHANNEL(sioc)) +ï¼ +ï¼ +ï¼ object_unref(OBJECT(sioc)) +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ Is this patch ok? +ï¼ + +Yes, i think this works, but a better way maybe to call +qio_channel_set_feature() +in qio_channel_socket_accept(), we didn't set the SHUTDOWN feature for the +socket accept fd, +Or fix it by this: + +diff --git a/io/channel-socket.c b/io/channel-socket.c +index f546c68..ce6894c 100644 +--- a/io/channel-socket.c ++++ b/io/channel-socket.c +@@ -330,9 +330,8 @@ qio_channel_socket_accept(QIOChannelSocket *ioc, + Error **errp) + { + QIOChannelSocket *cioc +- +- cioc = QIO_CHANNEL_SOCKET(object_new(TYPE_QIO_CHANNEL_SOCKET)) +- cioc-ï¼fd = -1 ++ ++ cioc = qio_channel_socket_new() + cioc-ï¼remoteAddrLen = sizeof(ioc-ï¼remoteAddr) + cioc-ï¼localAddrLen = sizeof(ioc-ï¼localAddr) + + +Thanks, +Hailiang + +ï¼ I have test it . The test could not hang any more. +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ åå§é®ä»¶ +ï¼ +ï¼ +ï¼ +ï¼ åä»¶äººï¼ address@hidden +ï¼ æ¶ä»¶äººï¼ address@hidden address@hidden +ï¼ æéäººï¼ address@hidden address@hidden address@hidden +ï¼ æ¥ æ ï¼2017å¹´03æ22æ¥ 09:11 +ï¼ ä¸» é¢ ï¼Re: [Qemu-devel] çå¤: Re: çå¤: Re: [BUG]COLO failover hang +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ On 2017/3/21 19:56, Dr. David Alan Gilbert wrote: +ï¼ ï¼ * Hailiang Zhang (address@hidden) wrote: +ï¼ ï¼ï¼ Hi, +ï¼ ï¼ï¼ +ï¼ ï¼ï¼ Thanks for reporting this, and i confirmed it in my test, and it is a bug. +ï¼ ï¼ï¼ +ï¼ ï¼ï¼ Though we tried to call qemu_file_shutdown() to shutdown the related fd, in +ï¼ ï¼ï¼ case COLO thread/incoming thread is stuck in read/write() while do +failover, +ï¼ ï¼ï¼ but it didn't take effect, because all the fd used by COLO (also migration) +ï¼ ï¼ï¼ has been wrapped by qio channel, and it will not call the shutdown API if +ï¼ ï¼ï¼ we didn't qio_channel_set_feature(QIO_CHANNEL(sioc), +QIO_CHANNEL_FEATURE_SHUTDOWN). +ï¼ ï¼ï¼ +ï¼ ï¼ï¼ Cc: Dr. David Alan Gilbert address@hidden +ï¼ ï¼ï¼ +ï¼ ï¼ï¼ I doubted migration cancel has the same problem, it may be stuck in write() +ï¼ ï¼ï¼ if we tried to cancel migration. +ï¼ ï¼ï¼ +ï¼ ï¼ï¼ void fd_start_outgoing_migration(MigrationState *s, const char *fdname, +Error **errp) +ï¼ ï¼ï¼ { +ï¼ ï¼ï¼ qio_channel_set_name(QIO_CHANNEL(ioc), "migration-fd-outgoing") +ï¼ ï¼ï¼ migration_channel_connect(s, ioc, NULL) +ï¼ ï¼ï¼ ... ... +ï¼ ï¼ï¼ We didn't call qio_channel_set_feature(QIO_CHANNEL(sioc), +QIO_CHANNEL_FEATURE_SHUTDOWN) above, +ï¼ ï¼ï¼ and the +ï¼ ï¼ï¼ migrate_fd_cancel() +ï¼ ï¼ï¼ { +ï¼ ï¼ï¼ ... ... +ï¼ ï¼ï¼ if (s-ï¼state == MIGRATION_STATUS_CANCELLING && f) { +ï¼ ï¼ï¼ qemu_file_shutdown(f) --ï¼ This will not take effect. No ? +ï¼ ï¼ï¼ } +ï¼ ï¼ï¼ } +ï¼ ï¼ +ï¼ ï¼ (cc'd in Daniel Berrange). +ï¼ ï¼ I see that we call qio_channel_set_feature(ioc, +QIO_CHANNEL_FEATURE_SHUTDOWN) at the +ï¼ ï¼ top of qio_channel_socket_new so I think that's safe isn't it? +ï¼ ï¼ +ï¼ +ï¼ Hmm, you are right, this problem is only exist for the migration incoming fd, +thanks. +ï¼ +ï¼ ï¼ Dave +ï¼ ï¼ +ï¼ ï¼ï¼ Thanks, +ï¼ ï¼ï¼ Hailiang +ï¼ ï¼ï¼ +ï¼ ï¼ï¼ On 2017/3/21 16:10, address@hidden wrote: +ï¼ ï¼ï¼ï¼ Thank youã +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ I have test areadyã +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ When the Primary Node panic,the Secondary Node qemu hang at the same +placeã +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ Incorrding +http://wiki.qemu-project.org/Features/COLO +ï¼kill Primary Node +qemu will not produce the problem,but Primary Node panic canã +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ I think due to the feature of channel does not support +QIO_CHANNEL_FEATURE_SHUTDOWN. +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ when failover,channel_shutdown could not shut down the channel. +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ so the colo_process_incoming_thread will hang at recvmsg. +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ I test a patch: +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ diff --git a/migration/socket.c b/migration/socket.c +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ index 13966f1..d65a0ea 100644 +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ --- a/migration/socket.c +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +++ b/migration/socket.c +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ @@ -147,8 +147,9 @@ static gboolean +socket_accept_incoming_migration(QIOChannel *ioc, +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ } +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ trace_migration_socket_incoming_accepted() +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ qio_channel_set_name(QIO_CHANNEL(sioc), +"migration-socket-incoming") +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ + qio_channel_set_feature(QIO_CHANNEL(sioc), +QIO_CHANNEL_FEATURE_SHUTDOWN) +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ migration_channel_process_incoming(migrate_get_current(), +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ QIO_CHANNEL(sioc)) +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ object_unref(OBJECT(sioc)) +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ My test will not hang any more. +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ åå§é®ä»¶ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ åä»¶äººï¼ address@hidden +ï¼ ï¼ï¼ï¼ æ¶ä»¶äººï¼ç广10165992 address@hidden +ï¼ ï¼ï¼ï¼ æéäººï¼ address@hidden address@hidden +ï¼ ï¼ï¼ï¼ æ¥ æ ï¼2017å¹´03æ21æ¥ 15:58 +ï¼ ï¼ï¼ï¼ 主 é¢ ï¼Re: [Qemu-devel] çå¤: Re: [BUG]COLO failover hang +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ Hi,Wang. +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ You can test this branch: +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +https://github.com/coloft/qemu/tree/colo-v5.1-developing-COLO-frame-v21-with-shared-disk +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ and please follow wiki ensure your own configuration correctly. +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +http://wiki.qemu-project.org/Features/COLO +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ Thanks +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ Zhang Chen +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ On 03/21/2017 03:27 PM, address@hidden wrote: +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ hi. +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ I test the git qemu master have the same problem. +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ (gdb) bt +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #0 qio_channel_socket_readv (ioc=0x7f65911b4e50, iov=0x7f64ef3fd880, +ï¼ ï¼ï¼ï¼ ï¼ niov=1, fds=0x0, nfds=0x0, errp=0x0) at io/channel-socket.c:461 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #1 0x00007f658e4aa0c2 in qio_channel_read +ï¼ ï¼ï¼ï¼ ï¼ (address@hidden, address@hidden "", +ï¼ ï¼ï¼ï¼ ï¼ address@hidden, address@hidden) at io/channel.c:114 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #2 0x00007f658e3ea990 in channel_get_buffer (opaque=ï¼optimized outï¼, +ï¼ ï¼ï¼ï¼ ï¼ buf=0x7f65907cb838 "", pos=ï¼optimized outï¼, size=32768) at +ï¼ ï¼ï¼ï¼ ï¼ migration/qemu-file-channel.c:78 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #3 0x00007f658e3e97fc in qemu_fill_buffer (f=0x7f65907cb800) at +ï¼ ï¼ï¼ï¼ ï¼ migration/qemu-file.c:295 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #4 0x00007f658e3ea2e1 in qemu_peek_byte (address@hidden, +ï¼ ï¼ï¼ï¼ ï¼ address@hidden) at migration/qemu-file.c:555 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #5 0x00007f658e3ea34b in qemu_get_byte (address@hidden) at +ï¼ ï¼ï¼ï¼ ï¼ migration/qemu-file.c:568 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #6 0x00007f658e3ea552 in qemu_get_be32 (address@hidden) at +ï¼ ï¼ï¼ï¼ ï¼ migration/qemu-file.c:648 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #7 0x00007f658e3e66e5 in colo_receive_message (f=0x7f65907cb800, +ï¼ ï¼ï¼ï¼ ï¼ address@hidden) at migration/colo.c:244 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #8 0x00007f658e3e681e in colo_receive_check_message (f=ï¼optimized +ï¼ ï¼ï¼ï¼ ï¼ outï¼, address@hidden, +ï¼ ï¼ï¼ï¼ ï¼ address@hidden) +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ at migration/colo.c:264 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #9 0x00007f658e3e740e in colo_process_incoming_thread +ï¼ ï¼ï¼ï¼ ï¼ (opaque=0x7f658eb30360 ï¼mis_current.31286ï¼) at migration/colo.c:577 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #10 0x00007f658be09df3 in start_thread () from /lib64/libpthread.so.0 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #11 0x00007f65881983ed in clone () from /lib64/libc.so.6 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ (gdb) p ioc-ï¼name +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ $2 = 0x7f658ff7d5c0 "migration-socket-incoming" +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ (gdb) p ioc-ï¼features Do not support QIO_CHANNEL_FEATURE_SHUTDOWN +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ $3 = 0 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ (gdb) bt +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #0 socket_accept_incoming_migration (ioc=0x7fdcceeafa90, +ï¼ ï¼ï¼ï¼ ï¼ condition=G_IO_IN, opaque=0x7fdcceeafa90) at migration/socket.c:137 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #1 0x00007fdcc6966350 in g_main_dispatch (context=ï¼optimized outï¼) at +ï¼ ï¼ï¼ï¼ ï¼ gmain.c:3054 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #2 g_main_context_dispatch (context=ï¼optimized outï¼, +ï¼ ï¼ï¼ï¼ ï¼ address@hidden) at gmain.c:3630 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #3 0x00007fdccb8a6dcc in glib_pollfds_poll () at util/main-loop.c:213 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #4 os_host_main_loop_wait (timeout=ï¼optimized outï¼) at +ï¼ ï¼ï¼ï¼ ï¼ util/main-loop.c:258 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #5 main_loop_wait (address@hidden) at +ï¼ ï¼ï¼ï¼ ï¼ util/main-loop.c:506 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #6 0x00007fdccb526187 in main_loop () at vl.c:1898 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #7 main (argc=ï¼optimized outï¼, argv=ï¼optimized outï¼, envp=ï¼optimized +ï¼ ï¼ï¼ï¼ ï¼ outï¼) at vl.c:4709 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ (gdb) p ioc-ï¼features +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ $1 = 6 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ (gdb) p ioc-ï¼name +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ $2 = 0x7fdcce1b1ab0 "migration-socket-listener" +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ May be socket_accept_incoming_migration should +ï¼ ï¼ï¼ï¼ ï¼ call qio_channel_set_feature(ioc, QIO_CHANNEL_FEATURE_SHUTDOWN)?? +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ thank you. +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ åå§é®ä»¶ +ï¼ ï¼ï¼ï¼ ï¼ address@hidden +ï¼ ï¼ï¼ï¼ ï¼ address@hidden +ï¼ ï¼ï¼ï¼ ï¼ address@hidden@huawei.comï¼ +ï¼ ï¼ï¼ï¼ ï¼ *æ¥ æ ï¼*2017å¹´03æ16æ¥ 14:46 +ï¼ ï¼ï¼ï¼ ï¼ *主 é¢ ï¼**Re: [Qemu-devel] COLO failover hang* +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ On 03/15/2017 05:06 PM, wangguang wrote: +ï¼ ï¼ï¼ï¼ ï¼ ï¼ am testing QEMU COLO feature described here [QEMU +ï¼ ï¼ï¼ï¼ ï¼ ï¼ Wiki]( +http://wiki.qemu-project.org/Features/COLO +). +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ When the Primary Node panic,the Secondary Node qemu hang. +ï¼ ï¼ï¼ï¼ ï¼ ï¼ hang at recvmsg in qio_channel_socket_readv. +ï¼ ï¼ï¼ï¼ ï¼ ï¼ And I run { 'execute': 'nbd-server-stop' } and { "execute": +ï¼ ï¼ï¼ï¼ ï¼ ï¼ "x-colo-lost-heartbeat" } in Secondary VM's +ï¼ ï¼ï¼ï¼ ï¼ ï¼ monitor,the Secondary Node qemu still hang at recvmsg . +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ I found that the colo in qemu is not complete yet. +ï¼ ï¼ï¼ï¼ ï¼ ï¼ Do the colo have any plan for development? +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ Yes, We are developing. You can see some of patch we pushing. +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ Has anyone ever run it successfully? Any help is appreciated! +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ In our internal version can run it successfully, +ï¼ ï¼ï¼ï¼ ï¼ The failover detail you can ask Zhanghailiang for help. +ï¼ ï¼ï¼ï¼ ï¼ Next time if you have some question about COLO, +ï¼ ï¼ï¼ï¼ ï¼ please cc me and zhanghailiang address@hidden +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ Thanks +ï¼ ï¼ï¼ï¼ ï¼ Zhang Chen +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ centos7.2+qemu2.7.50 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ (gdb) bt +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #0 0x00007f3e00cc86ad in recvmsg () from /lib64/libpthread.so.0 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #1 0x00007f3e0332b738 in qio_channel_socket_readv (ioc=ï¼optimized +outï¼, +ï¼ ï¼ï¼ï¼ ï¼ ï¼ iov=ï¼optimized outï¼, niov=ï¼optimized outï¼, fds=0x0, nfds=0x0, +errp=0x0) at +ï¼ ï¼ï¼ï¼ ï¼ ï¼ io/channel-socket.c:497 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #2 0x00007f3e03329472 in qio_channel_read (address@hidden, +ï¼ ï¼ï¼ï¼ ï¼ ï¼ address@hidden "", address@hidden, +ï¼ ï¼ï¼ï¼ ï¼ ï¼ address@hidden) at io/channel.c:97 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #3 0x00007f3e032750e0 in channel_get_buffer (opaque=ï¼optimized outï¼, +ï¼ ï¼ï¼ï¼ ï¼ ï¼ buf=0x7f3e05910f38 "", pos=ï¼optimized outï¼, size=32768) at +ï¼ ï¼ï¼ï¼ ï¼ ï¼ migration/qemu-file-channel.c:78 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #4 0x00007f3e0327412c in qemu_fill_buffer (f=0x7f3e05910f00) at +ï¼ ï¼ï¼ï¼ ï¼ ï¼ migration/qemu-file.c:257 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #5 0x00007f3e03274a41 in qemu_peek_byte (address@hidden, +ï¼ ï¼ï¼ï¼ ï¼ ï¼ address@hidden) at migration/qemu-file.c:510 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #6 0x00007f3e03274aab in qemu_get_byte (address@hidden) at +ï¼ ï¼ï¼ï¼ ï¼ ï¼ migration/qemu-file.c:523 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #7 0x00007f3e03274cb2 in qemu_get_be32 (address@hidden) at +ï¼ ï¼ï¼ï¼ ï¼ ï¼ migration/qemu-file.c:603 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #8 0x00007f3e03271735 in colo_receive_message (f=0x7f3e05910f00, +ï¼ ï¼ï¼ï¼ ï¼ ï¼ address@hidden) at migration/colo.c:215 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #9 0x00007f3e0327250d in colo_wait_handle_message +(errp=0x7f3d62bfaa48, +ï¼ ï¼ï¼ï¼ ï¼ ï¼ checkpoint_request=ï¼synthetic pointerï¼, f=ï¼optimized outï¼) at +ï¼ ï¼ï¼ï¼ ï¼ ï¼ migration/colo.c:546 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #10 colo_process_incoming_thread (opaque=0x7f3e067245e0) at +ï¼ ï¼ï¼ï¼ ï¼ ï¼ migration/colo.c:649 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #11 0x00007f3e00cc1df3 in start_thread () from /lib64/libpthread.so.0 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #12 0x00007f3dfc9c03ed in clone () from /lib64/libc..so.6 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ -- +ï¼ ï¼ï¼ï¼ ï¼ ï¼ View this message in context: +http://qemu.11.n7.nabble.com/COLO-failover-hang-tp473250.html +ï¼ ï¼ï¼ï¼ ï¼ ï¼ Sent from the Developer mailing list archive at Nabble.com. +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ -- +ï¼ ï¼ï¼ï¼ ï¼ Thanks +ï¼ ï¼ï¼ï¼ ï¼ Zhang Chen +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ +ï¼ ï¼ -- +ï¼ ï¼ Dr. David Alan Gilbert / address@hidden / Manchester, UK +ï¼ ï¼ +ï¼ ï¼ . +ï¼ ï¼ +ï¼ + diff --git a/results/classifier/105/mistranslation/704 b/results/classifier/105/mistranslation/704 new file mode 100644 index 000000000..f863da43e --- /dev/null +++ b/results/classifier/105/mistranslation/704 @@ -0,0 +1,14 @@ +mistranslation: 0.995 +instruction: 0.837 +graphic: 0.521 +device: 0.449 +boot: 0.319 +semantic: 0.290 +assembly: 0.078 +network: 0.038 +KVM: 0.023 +vnc: 0.015 +other: 0.013 +socket: 0.005 + +linux-user: misaligned address for type 'struct linux_dirent64' diff --git a/results/classifier/105/mistranslation/713 b/results/classifier/105/mistranslation/713 new file mode 100644 index 000000000..a2acbc1bc --- /dev/null +++ b/results/classifier/105/mistranslation/713 @@ -0,0 +1,14 @@ +mistranslation: 0.984 +semantic: 0.680 +graphic: 0.393 +device: 0.258 +instruction: 0.244 +vnc: 0.104 +socket: 0.093 +network: 0.068 +KVM: 0.038 +boot: 0.038 +assembly: 0.035 +other: 0.033 + +Missing safe-syscall.inc.S for mips diff --git a/results/classifier/105/mistranslation/72 b/results/classifier/105/mistranslation/72 new file mode 100644 index 000000000..c7d234056 --- /dev/null +++ b/results/classifier/105/mistranslation/72 @@ -0,0 +1,14 @@ +mistranslation: 0.857 +graphic: 0.769 +other: 0.717 +semantic: 0.552 +vnc: 0.481 +device: 0.422 +KVM: 0.238 +instruction: 0.219 +assembly: 0.189 +network: 0.064 +boot: 0.062 +socket: 0.009 + +mouse offset or invisible wall 2.11.0-3 diff --git a/results/classifier/105/mistranslation/721 b/results/classifier/105/mistranslation/721 new file mode 100644 index 000000000..237b0ed6a --- /dev/null +++ b/results/classifier/105/mistranslation/721 @@ -0,0 +1,43 @@ +mistranslation: 0.829 +other: 0.819 +vnc: 0.811 +KVM: 0.807 +instruction: 0.804 +network: 0.800 +semantic: 0.778 +assembly: 0.776 +device: 0.766 +graphic: 0.760 +socket: 0.747 +boot: 0.733 + +Build failed at libqemu-aarch64-softmmu.fa.p/accel_tcg_cputlb.c.o +Steps to reproduce: +1. Download and build from source + +``` +wget https://download.qemu.org/qemu-6.1.0.tar.xz +tar xvJf qemu-6.1.0.tar.xz +cd qemu-6.1.0 +./configure +make +``` +Additional information: +``` +[2150/9644] Compiling C object libqemu-alpha-softmmu.fa.p/migration_dirtyrate.c.o +[2151/9644] Compiling C object libqemu-alpha-softmmu.fa.p/migration_ram.c.o +[2152/9644] Compiling C object libqemu-alpha-softmmu.fa.p/target_alpha_fpu_helper.c.o +[2153/9644] Compiling C object libqemu-aarch64-softmmu.fa.p/accel_tcg_translate-all.c.o +[2154/9644] Compiling C object libqemu-alpha-softmmu.fa.p/migration_target.c.o +[2155/9644] Compiling C object libqemu-aarch64-softmmu.fa.p/accel_tcg_cputlb.c.o +FAILED: libqemu-aarch64-softmmu.fa.p/accel_tcg_cputlb.c.o +gcc -Ilibqemu-aarch64-softmmu.fa.p -I. -I.. -Itarget/arm -I../target/arm -I../dtc/libfdt -I../capstone/include/capstone -Iqapi -Itrace -Iui -Iui/shader -I/usr/include/pixman-1 -I/usr/include/libdrm -I/usr/include/valgrind -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -fdiagnostics-color=auto -Wall -Winvalid-pch -std=gnu11 -O2 -g -isystem /home/intel/Sources/qemu-6.1.0/linux-headers -isystem linux-headers -iquote . -iquote /home/intel/Sources/qemu-6.1.0 -iquote /home/intel/Sources/qemu-6.1.0/include -iquote /home/intel/Sources/qemu-6.1.0/disas/libvixl -iquote /home/intel/Sources/qemu-6.1.0/tcg/i386 -pthread -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -m64 -mcx16 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wimplicit-fallthrough=2 -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fstack-protector-strong -g -O3 -feliminate-unused-debug-types -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -Wformat -Wformat-security -m64 -fasynchronous-unwind-tables -Wp,-D_REENTRANT -ftree-loop-distribute-patterns -Wl,-z -Wl,now -Wl,-z -Wl,relro -fno-semantic-interposition -ffat-lto-objects -fno-trapping-math -Wl,-sort-common -Wl,--enable-new-dtags -mtune=skylake -fPIE -isystem../linux-headers -isystemlinux-headers -DNEED_CPU_H '-DCONFIG_TARGET="aarch64-softmmu-config-target.h"' '-DCONFIG_DEVICES="aarch64-softmmu-config-devices.h"' -MD -MQ libqemu-aarch64-softmmu.fa.p/accel_tcg_cputlb.c.o -MF libqemu-aarch64-softmmu.fa.p/accel_tcg_cputlb.c.o.d -o libqemu-aarch64-softmmu.fa.p/accel_tcg_cputlb.c.o -c ../accel/tcg/cputlb.c +during GIMPLE pass: fab +In file included from /home/intel/Sources/qemu-6.1.0/include/qemu/osdep.h:37, + from ../accel/tcg/cputlb.c:20: +../accel/tcg/atomic_common.c.inc: In function ‘helper_atomic_fetch_andb’: +/home/intel/Sources/qemu-6.1.0/include/exec/helper-head.h:21:27: internal compiler error: in optimize_atomic_bit_test_and, at tree-ssa-ccp.c:3245 + 21 | #define HELPER(name) glue(helper_, name) + | ^~~~~~~ +/home/intel/Sources/qemu-6.1.0/include/qemu/compiler.h:35:21: note: in definition of macro ‘xglue’ + 35 | #define xglue(x, y) x diff --git a/results/classifier/105/mistranslation/727134 b/results/classifier/105/mistranslation/727134 new file mode 100644 index 000000000..c36f31703 --- /dev/null +++ b/results/classifier/105/mistranslation/727134 @@ -0,0 +1,21 @@ +mistranslation: 0.781 +device: 0.694 +socket: 0.681 +other: 0.603 +KVM: 0.597 +network: 0.585 +instruction: 0.579 +graphic: 0.521 +vnc: 0.478 +semantic: 0.435 +boot: 0.363 +assembly: 0.194 + +pci-stub.o: In function `do_pci_info':0.14.0 compile problem + +Please see this build log. I didn't compile thq qemu-kvm on Mandriva Cooker and haven't any idea. I'm the qemu maintainer on Mandriva. + + + +QEMU 0.14.0 is quite outdated - and I assume that compilation is working fine again with the latest version, so I'm closing this bug ticket now. If you still have problems with the latest version of QEMU, feel free to open it again (or create a new bug ticket instead). + diff --git a/results/classifier/105/mistranslation/74466963 b/results/classifier/105/mistranslation/74466963 new file mode 100644 index 000000000..ceba02704 --- /dev/null +++ b/results/classifier/105/mistranslation/74466963 @@ -0,0 +1,1886 @@ +mistranslation: 0.927 +assembly: 0.910 +device: 0.909 +instruction: 0.903 +KVM: 0.903 +graphic: 0.895 +boot: 0.894 +semantic: 0.891 +socket: 0.879 +vnc: 0.878 +other: 0.877 +network: 0.871 + +[Qemu-devel] [TCG only][Migration Bug? ] Occasionally, the content of VM's memory is inconsistent between Source and Destination of migration + +Hi all, + +Does anyboday remember the similar issue post by hailiang months ago +http://patchwork.ozlabs.org/patch/454322/ +At least tow bugs about migration had been fixed since that. +And now we found the same issue at the tcg vm(kvm is fine), after +migration, the content VM's memory is inconsistent. +we add a patch to check memory content, you can find it from affix + +steps to reporduce: +1) apply the patch and re-build qemu +2) prepare the ubuntu guest and run memtest in grub. +soruce side: +x86_64-softmmu/qemu-system-x86_64 -netdev tap,id=hn0 -device +e1000,id=net-pci0,netdev=hn0,mac=52:54:00:12:34:65 -boot c -drive +if=none,file=/home/lizj/ubuntu.raw,id=drive-virtio-disk0 -device +virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 +-vnc :7 -m 128 -smp 1 -device piix3-usb-uhci -device usb-tablet -qmp +tcp::4444,server,nowait -monitor stdio -cpu qemu64 -machine +pc-i440fx-2.3,accel=tcg,usb=off +destination side: +x86_64-softmmu/qemu-system-x86_64 -netdev tap,id=hn0 -device +e1000,id=net-pci0,netdev=hn0,mac=52:54:00:12:34:65 -boot c -drive +if=none,file=/home/lizj/ubuntu.raw,id=drive-virtio-disk0 -device +virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 +-vnc :7 -m 128 -smp 1 -device piix3-usb-uhci -device usb-tablet -qmp +tcp::4444,server,nowait -monitor stdio -cpu qemu64 -machine +pc-i440fx-2.3,accel=tcg,usb=off -incoming tcp:0:8881 +3) start migration +with 1000M NIC, migration will finish within 3 min. + +at source: +(qemu) migrate tcp:192.168.2.66:8881 +after saving ram complete +e9e725df678d392b1a83b3a917f332bb +qemu-system-x86_64: end ram md5 +(qemu) + +at destination: +...skip... +Completed load of VM with exit code 0 seq iteration 1264 +Completed load of VM with exit code 0 seq iteration 1265 +Completed load of VM with exit code 0 seq iteration 1266 +qemu-system-x86_64: after loading state section id 2(ram) +49c2dac7bde0e5e22db7280dcb3824f9 +qemu-system-x86_64: end ram md5 +qemu-system-x86_64: qemu_loadvm_state: after cpu_synchronize_all_post_init + +49c2dac7bde0e5e22db7280dcb3824f9 +qemu-system-x86_64: end ram md5 + +This occurs occasionally and only at tcg machine. It seems that +some pages dirtied in source side don't transferred to destination. +This problem can be reproduced even if we disable virtio. +Is it OK for some pages that not transferred to destination when do +migration ? Or is it a bug? +Any idea... + +=================md5 check patch============================= + +diff --git a/Makefile.target b/Makefile.target +index 962d004..e2cb8e9 100644 +--- a/Makefile.target ++++ b/Makefile.target +@@ -139,7 +139,7 @@ obj-y += memory.o cputlb.o + obj-y += memory_mapping.o + obj-y += dump.o + obj-y += migration/ram.o migration/savevm.o +-LIBS := $(libs_softmmu) $(LIBS) ++LIBS := $(libs_softmmu) $(LIBS) -lplumb + + # xen support + obj-$(CONFIG_XEN) += xen-common.o +diff --git a/migration/ram.c b/migration/ram.c +index 1eb155a..3b7a09d 100644 +--- a/migration/ram.c ++++ b/migration/ram.c +@@ -2513,7 +2513,7 @@ static int ram_load(QEMUFile *f, void *opaque, int +version_id) +} + + rcu_read_unlock(); +- DPRINTF("Completed load of VM with exit code %d seq iteration " ++ fprintf(stderr, "Completed load of VM with exit code %d seq iteration " + "%" PRIu64 "\n", ret, seq_iter); + return ret; + } +diff --git a/migration/savevm.c b/migration/savevm.c +index 0ad1b93..3feaa61 100644 +--- a/migration/savevm.c ++++ b/migration/savevm.c +@@ -891,6 +891,29 @@ void qemu_savevm_state_header(QEMUFile *f) + + } + ++#include "exec/ram_addr.h" ++#include "qemu/rcu_queue.h" ++#include <clplumbing/md5.h> ++#ifndef MD5_DIGEST_LENGTH ++#define MD5_DIGEST_LENGTH 16 ++#endif ++ ++static void check_host_md5(void) ++{ ++ int i; ++ unsigned char md[MD5_DIGEST_LENGTH]; ++ rcu_read_lock(); ++ RAMBlock *block = QLIST_FIRST_RCU(&ram_list.blocks);/* Only check +'pc.ram' block */ ++ rcu_read_unlock(); ++ ++ MD5(block->host, block->used_length, md); ++ for(i = 0; i < MD5_DIGEST_LENGTH; i++) { ++ fprintf(stderr, "%02x", md[i]); ++ } ++ fprintf(stderr, "\n"); ++ error_report("end ram md5"); ++} ++ + void qemu_savevm_state_begin(QEMUFile *f, + const MigrationParams *params) + { +@@ -1056,6 +1079,10 @@ void qemu_savevm_state_complete_precopy(QEMUFile +*f, bool iterable_only) +save_section_header(f, se, QEMU_VM_SECTION_END); + + ret = se->ops->save_live_complete_precopy(f, se->opaque); ++ ++ fprintf(stderr, "after saving %s complete\n", se->idstr); ++ check_host_md5(); ++ + trace_savevm_section_end(se->idstr, se->section_id, ret); + save_section_footer(f, se); + if (ret < 0) { +@@ -1791,6 +1818,11 @@ static int qemu_loadvm_state_main(QEMUFile *f, +MigrationIncomingState *mis) +section_id, le->se->idstr); + return ret; + } ++ if (section_type == QEMU_VM_SECTION_END) { ++ error_report("after loading state section id %d(%s)", ++ section_id, le->se->idstr); ++ check_host_md5(); ++ } + if (!check_section_footer(f, le)) { + return -EINVAL; + } +@@ -1901,6 +1933,8 @@ int qemu_loadvm_state(QEMUFile *f) + } + + cpu_synchronize_all_post_init(); ++ error_report("%s: after cpu_synchronize_all_post_init\n", __func__); ++ check_host_md5(); + + return ret; + } + +* Li Zhijian (address@hidden) wrote: +> +Hi all, +> +> +Does anyboday remember the similar issue post by hailiang months ago +> +http://patchwork.ozlabs.org/patch/454322/ +> +At least tow bugs about migration had been fixed since that. +Yes, I wondered what happened to that. + +> +And now we found the same issue at the tcg vm(kvm is fine), after migration, +> +the content VM's memory is inconsistent. +Hmm, TCG only - I don't know much about that; but I guess something must +be accessing memory without using the proper macros/functions so +it doesn't mark it as dirty. + +> +we add a patch to check memory content, you can find it from affix +> +> +steps to reporduce: +> +1) apply the patch and re-build qemu +> +2) prepare the ubuntu guest and run memtest in grub. +> +soruce side: +> +x86_64-softmmu/qemu-system-x86_64 -netdev tap,id=hn0 -device +> +e1000,id=net-pci0,netdev=hn0,mac=52:54:00:12:34:65 -boot c -drive +> +if=none,file=/home/lizj/ubuntu.raw,id=drive-virtio-disk0 -device +> +virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 +> +-vnc :7 -m 128 -smp 1 -device piix3-usb-uhci -device usb-tablet -qmp +> +tcp::4444,server,nowait -monitor stdio -cpu qemu64 -machine +> +pc-i440fx-2.3,accel=tcg,usb=off +> +> +destination side: +> +x86_64-softmmu/qemu-system-x86_64 -netdev tap,id=hn0 -device +> +e1000,id=net-pci0,netdev=hn0,mac=52:54:00:12:34:65 -boot c -drive +> +if=none,file=/home/lizj/ubuntu.raw,id=drive-virtio-disk0 -device +> +virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 +> +-vnc :7 -m 128 -smp 1 -device piix3-usb-uhci -device usb-tablet -qmp +> +tcp::4444,server,nowait -monitor stdio -cpu qemu64 -machine +> +pc-i440fx-2.3,accel=tcg,usb=off -incoming tcp:0:8881 +> +> +3) start migration +> +with 1000M NIC, migration will finish within 3 min. +> +> +at source: +> +(qemu) migrate tcp:192.168.2.66:8881 +> +after saving ram complete +> +e9e725df678d392b1a83b3a917f332bb +> +qemu-system-x86_64: end ram md5 +> +(qemu) +> +> +at destination: +> +...skip... +> +Completed load of VM with exit code 0 seq iteration 1264 +> +Completed load of VM with exit code 0 seq iteration 1265 +> +Completed load of VM with exit code 0 seq iteration 1266 +> +qemu-system-x86_64: after loading state section id 2(ram) +> +49c2dac7bde0e5e22db7280dcb3824f9 +> +qemu-system-x86_64: end ram md5 +> +qemu-system-x86_64: qemu_loadvm_state: after cpu_synchronize_all_post_init +> +> +49c2dac7bde0e5e22db7280dcb3824f9 +> +qemu-system-x86_64: end ram md5 +> +> +This occurs occasionally and only at tcg machine. It seems that +> +some pages dirtied in source side don't transferred to destination. +> +This problem can be reproduced even if we disable virtio. +> +> +Is it OK for some pages that not transferred to destination when do +> +migration ? Or is it a bug? +I'm pretty sure that means it's a bug. Hard to find though, I guess +at least memtest is smaller than a big OS. I think I'd dump the whole +of memory on both sides, hexdump and diff them - I'd guess it would +just be one byte/word different, maybe that would offer some idea what +wrote it. + +Dave + +> +Any idea... +> +> +=================md5 check patch============================= +> +> +diff --git a/Makefile.target b/Makefile.target +> +index 962d004..e2cb8e9 100644 +> +--- a/Makefile.target +> ++++ b/Makefile.target +> +@@ -139,7 +139,7 @@ obj-y += memory.o cputlb.o +> +obj-y += memory_mapping.o +> +obj-y += dump.o +> +obj-y += migration/ram.o migration/savevm.o +> +-LIBS := $(libs_softmmu) $(LIBS) +> ++LIBS := $(libs_softmmu) $(LIBS) -lplumb +> +> +# xen support +> +obj-$(CONFIG_XEN) += xen-common.o +> +diff --git a/migration/ram.c b/migration/ram.c +> +index 1eb155a..3b7a09d 100644 +> +--- a/migration/ram.c +> ++++ b/migration/ram.c +> +@@ -2513,7 +2513,7 @@ static int ram_load(QEMUFile *f, void *opaque, int +> +version_id) +> +} +> +> +rcu_read_unlock(); +> +- DPRINTF("Completed load of VM with exit code %d seq iteration " +> ++ fprintf(stderr, "Completed load of VM with exit code %d seq iteration " +> +"%" PRIu64 "\n", ret, seq_iter); +> +return ret; +> +} +> +diff --git a/migration/savevm.c b/migration/savevm.c +> +index 0ad1b93..3feaa61 100644 +> +--- a/migration/savevm.c +> ++++ b/migration/savevm.c +> +@@ -891,6 +891,29 @@ void qemu_savevm_state_header(QEMUFile *f) +> +> +} +> +> ++#include "exec/ram_addr.h" +> ++#include "qemu/rcu_queue.h" +> ++#include <clplumbing/md5.h> +> ++#ifndef MD5_DIGEST_LENGTH +> ++#define MD5_DIGEST_LENGTH 16 +> ++#endif +> ++ +> ++static void check_host_md5(void) +> ++{ +> ++ int i; +> ++ unsigned char md[MD5_DIGEST_LENGTH]; +> ++ rcu_read_lock(); +> ++ RAMBlock *block = QLIST_FIRST_RCU(&ram_list.blocks);/* Only check +> +'pc.ram' block */ +> ++ rcu_read_unlock(); +> ++ +> ++ MD5(block->host, block->used_length, md); +> ++ for(i = 0; i < MD5_DIGEST_LENGTH; i++) { +> ++ fprintf(stderr, "%02x", md[i]); +> ++ } +> ++ fprintf(stderr, "\n"); +> ++ error_report("end ram md5"); +> ++} +> ++ +> +void qemu_savevm_state_begin(QEMUFile *f, +> +const MigrationParams *params) +> +{ +> +@@ -1056,6 +1079,10 @@ void qemu_savevm_state_complete_precopy(QEMUFile *f, +> +bool iterable_only) +> +save_section_header(f, se, QEMU_VM_SECTION_END); +> +> +ret = se->ops->save_live_complete_precopy(f, se->opaque); +> ++ +> ++ fprintf(stderr, "after saving %s complete\n", se->idstr); +> ++ check_host_md5(); +> ++ +> +trace_savevm_section_end(se->idstr, se->section_id, ret); +> +save_section_footer(f, se); +> +if (ret < 0) { +> +@@ -1791,6 +1818,11 @@ static int qemu_loadvm_state_main(QEMUFile *f, +> +MigrationIncomingState *mis) +> +section_id, le->se->idstr); +> +return ret; +> +} +> ++ if (section_type == QEMU_VM_SECTION_END) { +> ++ error_report("after loading state section id %d(%s)", +> ++ section_id, le->se->idstr); +> ++ check_host_md5(); +> ++ } +> +if (!check_section_footer(f, le)) { +> +return -EINVAL; +> +} +> +@@ -1901,6 +1933,8 @@ int qemu_loadvm_state(QEMUFile *f) +> +} +> +> +cpu_synchronize_all_post_init(); +> ++ error_report("%s: after cpu_synchronize_all_post_init\n", __func__); +> ++ check_host_md5(); +> +> +return ret; +> +} +> +> +> +-- +Dr. David Alan Gilbert / address@hidden / Manchester, UK + +On 2015/12/3 17:24, Dr. David Alan Gilbert wrote: +* Li Zhijian (address@hidden) wrote: +Hi all, + +Does anyboday remember the similar issue post by hailiang months ago +http://patchwork.ozlabs.org/patch/454322/ +At least tow bugs about migration had been fixed since that. +Yes, I wondered what happened to that. +And now we found the same issue at the tcg vm(kvm is fine), after migration, +the content VM's memory is inconsistent. +Hmm, TCG only - I don't know much about that; but I guess something must +be accessing memory without using the proper macros/functions so +it doesn't mark it as dirty. +we add a patch to check memory content, you can find it from affix + +steps to reporduce: +1) apply the patch and re-build qemu +2) prepare the ubuntu guest and run memtest in grub. +soruce side: +x86_64-softmmu/qemu-system-x86_64 -netdev tap,id=hn0 -device +e1000,id=net-pci0,netdev=hn0,mac=52:54:00:12:34:65 -boot c -drive +if=none,file=/home/lizj/ubuntu.raw,id=drive-virtio-disk0 -device +virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 +-vnc :7 -m 128 -smp 1 -device piix3-usb-uhci -device usb-tablet -qmp +tcp::4444,server,nowait -monitor stdio -cpu qemu64 -machine +pc-i440fx-2.3,accel=tcg,usb=off + +destination side: +x86_64-softmmu/qemu-system-x86_64 -netdev tap,id=hn0 -device +e1000,id=net-pci0,netdev=hn0,mac=52:54:00:12:34:65 -boot c -drive +if=none,file=/home/lizj/ubuntu.raw,id=drive-virtio-disk0 -device +virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 +-vnc :7 -m 128 -smp 1 -device piix3-usb-uhci -device usb-tablet -qmp +tcp::4444,server,nowait -monitor stdio -cpu qemu64 -machine +pc-i440fx-2.3,accel=tcg,usb=off -incoming tcp:0:8881 + +3) start migration +with 1000M NIC, migration will finish within 3 min. + +at source: +(qemu) migrate tcp:192.168.2.66:8881 +after saving ram complete +e9e725df678d392b1a83b3a917f332bb +qemu-system-x86_64: end ram md5 +(qemu) + +at destination: +...skip... +Completed load of VM with exit code 0 seq iteration 1264 +Completed load of VM with exit code 0 seq iteration 1265 +Completed load of VM with exit code 0 seq iteration 1266 +qemu-system-x86_64: after loading state section id 2(ram) +49c2dac7bde0e5e22db7280dcb3824f9 +qemu-system-x86_64: end ram md5 +qemu-system-x86_64: qemu_loadvm_state: after cpu_synchronize_all_post_init + +49c2dac7bde0e5e22db7280dcb3824f9 +qemu-system-x86_64: end ram md5 + +This occurs occasionally and only at tcg machine. It seems that +some pages dirtied in source side don't transferred to destination. +This problem can be reproduced even if we disable virtio. + +Is it OK for some pages that not transferred to destination when do +migration ? Or is it a bug? +I'm pretty sure that means it's a bug. Hard to find though, I guess +at least memtest is smaller than a big OS. I think I'd dump the whole +of memory on both sides, hexdump and diff them - I'd guess it would +just be one byte/word different, maybe that would offer some idea what +wrote it. +Maybe one better way to do that is with the help of userfaultfd's write-protect +capability. It is still in the development by Andrea Arcangeli, but there +is a RFC version available, please refer to +http://www.spinics.net/lists/linux-mm/msg97422.html +ï¼I'm developing live memory snapshot which based on it, maybe this is another +scene where we +can use userfaultfd's WP ;) ). +Dave +Any idea... + +=================md5 check patch============================= + +diff --git a/Makefile.target b/Makefile.target +index 962d004..e2cb8e9 100644 +--- a/Makefile.target ++++ b/Makefile.target +@@ -139,7 +139,7 @@ obj-y += memory.o cputlb.o + obj-y += memory_mapping.o + obj-y += dump.o + obj-y += migration/ram.o migration/savevm.o +-LIBS := $(libs_softmmu) $(LIBS) ++LIBS := $(libs_softmmu) $(LIBS) -lplumb + + # xen support + obj-$(CONFIG_XEN) += xen-common.o +diff --git a/migration/ram.c b/migration/ram.c +index 1eb155a..3b7a09d 100644 +--- a/migration/ram.c ++++ b/migration/ram.c +@@ -2513,7 +2513,7 @@ static int ram_load(QEMUFile *f, void *opaque, int +version_id) + } + + rcu_read_unlock(); +- DPRINTF("Completed load of VM with exit code %d seq iteration " ++ fprintf(stderr, "Completed load of VM with exit code %d seq iteration " + "%" PRIu64 "\n", ret, seq_iter); + return ret; + } +diff --git a/migration/savevm.c b/migration/savevm.c +index 0ad1b93..3feaa61 100644 +--- a/migration/savevm.c ++++ b/migration/savevm.c +@@ -891,6 +891,29 @@ void qemu_savevm_state_header(QEMUFile *f) + + } + ++#include "exec/ram_addr.h" ++#include "qemu/rcu_queue.h" ++#include <clplumbing/md5.h> ++#ifndef MD5_DIGEST_LENGTH ++#define MD5_DIGEST_LENGTH 16 ++#endif ++ ++static void check_host_md5(void) ++{ ++ int i; ++ unsigned char md[MD5_DIGEST_LENGTH]; ++ rcu_read_lock(); ++ RAMBlock *block = QLIST_FIRST_RCU(&ram_list.blocks);/* Only check +'pc.ram' block */ ++ rcu_read_unlock(); ++ ++ MD5(block->host, block->used_length, md); ++ for(i = 0; i < MD5_DIGEST_LENGTH; i++) { ++ fprintf(stderr, "%02x", md[i]); ++ } ++ fprintf(stderr, "\n"); ++ error_report("end ram md5"); ++} ++ + void qemu_savevm_state_begin(QEMUFile *f, + const MigrationParams *params) + { +@@ -1056,6 +1079,10 @@ void qemu_savevm_state_complete_precopy(QEMUFile *f, +bool iterable_only) + save_section_header(f, se, QEMU_VM_SECTION_END); + + ret = se->ops->save_live_complete_precopy(f, se->opaque); ++ ++ fprintf(stderr, "after saving %s complete\n", se->idstr); ++ check_host_md5(); ++ + trace_savevm_section_end(se->idstr, se->section_id, ret); + save_section_footer(f, se); + if (ret < 0) { +@@ -1791,6 +1818,11 @@ static int qemu_loadvm_state_main(QEMUFile *f, +MigrationIncomingState *mis) + section_id, le->se->idstr); + return ret; + } ++ if (section_type == QEMU_VM_SECTION_END) { ++ error_report("after loading state section id %d(%s)", ++ section_id, le->se->idstr); ++ check_host_md5(); ++ } + if (!check_section_footer(f, le)) { + return -EINVAL; + } +@@ -1901,6 +1933,8 @@ int qemu_loadvm_state(QEMUFile *f) + } + + cpu_synchronize_all_post_init(); ++ error_report("%s: after cpu_synchronize_all_post_init\n", __func__); ++ check_host_md5(); + + return ret; + } +-- +Dr. David Alan Gilbert / address@hidden / Manchester, UK + +. + +On 12/03/2015 05:37 PM, Hailiang Zhang wrote: +On 2015/12/3 17:24, Dr. David Alan Gilbert wrote: +* Li Zhijian (address@hidden) wrote: +Hi all, + +Does anyboday remember the similar issue post by hailiang months ago +http://patchwork.ozlabs.org/patch/454322/ +At least tow bugs about migration had been fixed since that. +Yes, I wondered what happened to that. +And now we found the same issue at the tcg vm(kvm is fine), after +migration, +the content VM's memory is inconsistent. +Hmm, TCG only - I don't know much about that; but I guess something must +be accessing memory without using the proper macros/functions so +it doesn't mark it as dirty. +we add a patch to check memory content, you can find it from affix + +steps to reporduce: +1) apply the patch and re-build qemu +2) prepare the ubuntu guest and run memtest in grub. +soruce side: +x86_64-softmmu/qemu-system-x86_64 -netdev tap,id=hn0 -device +e1000,id=net-pci0,netdev=hn0,mac=52:54:00:12:34:65 -boot c -drive +if=none,file=/home/lizj/ubuntu.raw,id=drive-virtio-disk0 -device +virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 + +-vnc :7 -m 128 -smp 1 -device piix3-usb-uhci -device usb-tablet -qmp +tcp::4444,server,nowait -monitor stdio -cpu qemu64 -machine +pc-i440fx-2.3,accel=tcg,usb=off + +destination side: +x86_64-softmmu/qemu-system-x86_64 -netdev tap,id=hn0 -device +e1000,id=net-pci0,netdev=hn0,mac=52:54:00:12:34:65 -boot c -drive +if=none,file=/home/lizj/ubuntu.raw,id=drive-virtio-disk0 -device +virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 + +-vnc :7 -m 128 -smp 1 -device piix3-usb-uhci -device usb-tablet -qmp +tcp::4444,server,nowait -monitor stdio -cpu qemu64 -machine +pc-i440fx-2.3,accel=tcg,usb=off -incoming tcp:0:8881 + +3) start migration +with 1000M NIC, migration will finish within 3 min. + +at source: +(qemu) migrate tcp:192.168.2.66:8881 +after saving ram complete +e9e725df678d392b1a83b3a917f332bb +qemu-system-x86_64: end ram md5 +(qemu) + +at destination: +...skip... +Completed load of VM with exit code 0 seq iteration 1264 +Completed load of VM with exit code 0 seq iteration 1265 +Completed load of VM with exit code 0 seq iteration 1266 +qemu-system-x86_64: after loading state section id 2(ram) +49c2dac7bde0e5e22db7280dcb3824f9 +qemu-system-x86_64: end ram md5 +qemu-system-x86_64: qemu_loadvm_state: after +cpu_synchronize_all_post_init + +49c2dac7bde0e5e22db7280dcb3824f9 +qemu-system-x86_64: end ram md5 + +This occurs occasionally and only at tcg machine. It seems that +some pages dirtied in source side don't transferred to destination. +This problem can be reproduced even if we disable virtio. + +Is it OK for some pages that not transferred to destination when do +migration ? Or is it a bug? +I'm pretty sure that means it's a bug. Hard to find though, I guess +at least memtest is smaller than a big OS. I think I'd dump the whole +of memory on both sides, hexdump and diff them - I'd guess it would +just be one byte/word different, maybe that would offer some idea what +wrote it. +Maybe one better way to do that is with the help of userfaultfd's +write-protect +capability. It is still in the development by Andrea Arcangeli, but there +is a RFC version available, please refer to +http://www.spinics.net/lists/linux-mm/msg97422.html +ï¼I'm developing live memory snapshot which based on it, maybe this is +another scene where we +can use userfaultfd's WP ;) ). +sounds good. + +thanks +Li +Dave +Any idea... + +=================md5 check patch============================= + +diff --git a/Makefile.target b/Makefile.target +index 962d004..e2cb8e9 100644 +--- a/Makefile.target ++++ b/Makefile.target +@@ -139,7 +139,7 @@ obj-y += memory.o cputlb.o + obj-y += memory_mapping.o + obj-y += dump.o + obj-y += migration/ram.o migration/savevm.o +-LIBS := $(libs_softmmu) $(LIBS) ++LIBS := $(libs_softmmu) $(LIBS) -lplumb + + # xen support + obj-$(CONFIG_XEN) += xen-common.o +diff --git a/migration/ram.c b/migration/ram.c +index 1eb155a..3b7a09d 100644 +--- a/migration/ram.c ++++ b/migration/ram.c +@@ -2513,7 +2513,7 @@ static int ram_load(QEMUFile *f, void *opaque, int +version_id) + } + + rcu_read_unlock(); +- DPRINTF("Completed load of VM with exit code %d seq iteration " ++ fprintf(stderr, "Completed load of VM with exit code %d seq +iteration " + "%" PRIu64 "\n", ret, seq_iter); + return ret; + } +diff --git a/migration/savevm.c b/migration/savevm.c +index 0ad1b93..3feaa61 100644 +--- a/migration/savevm.c ++++ b/migration/savevm.c +@@ -891,6 +891,29 @@ void qemu_savevm_state_header(QEMUFile *f) + + } + ++#include "exec/ram_addr.h" ++#include "qemu/rcu_queue.h" ++#include <clplumbing/md5.h> ++#ifndef MD5_DIGEST_LENGTH ++#define MD5_DIGEST_LENGTH 16 ++#endif ++ ++static void check_host_md5(void) ++{ ++ int i; ++ unsigned char md[MD5_DIGEST_LENGTH]; ++ rcu_read_lock(); ++ RAMBlock *block = QLIST_FIRST_RCU(&ram_list.blocks);/* Only check +'pc.ram' block */ ++ rcu_read_unlock(); ++ ++ MD5(block->host, block->used_length, md); ++ for(i = 0; i < MD5_DIGEST_LENGTH; i++) { ++ fprintf(stderr, "%02x", md[i]); ++ } ++ fprintf(stderr, "\n"); ++ error_report("end ram md5"); ++} ++ + void qemu_savevm_state_begin(QEMUFile *f, + const MigrationParams *params) + { +@@ -1056,6 +1079,10 @@ void +qemu_savevm_state_complete_precopy(QEMUFile *f, +bool iterable_only) + save_section_header(f, se, QEMU_VM_SECTION_END); + + ret = se->ops->save_live_complete_precopy(f, se->opaque); ++ ++ fprintf(stderr, "after saving %s complete\n", se->idstr); ++ check_host_md5(); ++ + trace_savevm_section_end(se->idstr, se->section_id, ret); + save_section_footer(f, se); + if (ret < 0) { +@@ -1791,6 +1818,11 @@ static int qemu_loadvm_state_main(QEMUFile *f, +MigrationIncomingState *mis) + section_id, le->se->idstr); + return ret; + } ++ if (section_type == QEMU_VM_SECTION_END) { ++ error_report("after loading state section id %d(%s)", ++ section_id, le->se->idstr); ++ check_host_md5(); ++ } + if (!check_section_footer(f, le)) { + return -EINVAL; + } +@@ -1901,6 +1933,8 @@ int qemu_loadvm_state(QEMUFile *f) + } + + cpu_synchronize_all_post_init(); ++ error_report("%s: after cpu_synchronize_all_post_init\n", +__func__); ++ check_host_md5(); + + return ret; + } +-- +Dr. David Alan Gilbert / address@hidden / Manchester, UK + +. +. +-- +Best regards. +Li Zhijian (8555) + +On 12/03/2015 05:24 PM, Dr. David Alan Gilbert wrote: +* Li Zhijian (address@hidden) wrote: +Hi all, + +Does anyboday remember the similar issue post by hailiang months ago +http://patchwork.ozlabs.org/patch/454322/ +At least tow bugs about migration had been fixed since that. +Yes, I wondered what happened to that. +And now we found the same issue at the tcg vm(kvm is fine), after migration, +the content VM's memory is inconsistent. +Hmm, TCG only - I don't know much about that; but I guess something must +be accessing memory without using the proper macros/functions so +it doesn't mark it as dirty. +we add a patch to check memory content, you can find it from affix + +steps to reporduce: +1) apply the patch and re-build qemu +2) prepare the ubuntu guest and run memtest in grub. +soruce side: +x86_64-softmmu/qemu-system-x86_64 -netdev tap,id=hn0 -device +e1000,id=net-pci0,netdev=hn0,mac=52:54:00:12:34:65 -boot c -drive +if=none,file=/home/lizj/ubuntu.raw,id=drive-virtio-disk0 -device +virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 +-vnc :7 -m 128 -smp 1 -device piix3-usb-uhci -device usb-tablet -qmp +tcp::4444,server,nowait -monitor stdio -cpu qemu64 -machine +pc-i440fx-2.3,accel=tcg,usb=off + +destination side: +x86_64-softmmu/qemu-system-x86_64 -netdev tap,id=hn0 -device +e1000,id=net-pci0,netdev=hn0,mac=52:54:00:12:34:65 -boot c -drive +if=none,file=/home/lizj/ubuntu.raw,id=drive-virtio-disk0 -device +virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 +-vnc :7 -m 128 -smp 1 -device piix3-usb-uhci -device usb-tablet -qmp +tcp::4444,server,nowait -monitor stdio -cpu qemu64 -machine +pc-i440fx-2.3,accel=tcg,usb=off -incoming tcp:0:8881 + +3) start migration +with 1000M NIC, migration will finish within 3 min. + +at source: +(qemu) migrate tcp:192.168.2.66:8881 +after saving ram complete +e9e725df678d392b1a83b3a917f332bb +qemu-system-x86_64: end ram md5 +(qemu) + +at destination: +...skip... +Completed load of VM with exit code 0 seq iteration 1264 +Completed load of VM with exit code 0 seq iteration 1265 +Completed load of VM with exit code 0 seq iteration 1266 +qemu-system-x86_64: after loading state section id 2(ram) +49c2dac7bde0e5e22db7280dcb3824f9 +qemu-system-x86_64: end ram md5 +qemu-system-x86_64: qemu_loadvm_state: after cpu_synchronize_all_post_init + +49c2dac7bde0e5e22db7280dcb3824f9 +qemu-system-x86_64: end ram md5 + +This occurs occasionally and only at tcg machine. It seems that +some pages dirtied in source side don't transferred to destination. +This problem can be reproduced even if we disable virtio. + +Is it OK for some pages that not transferred to destination when do +migration ? Or is it a bug? +I'm pretty sure that means it's a bug. Hard to find though, I guess +at least memtest is smaller than a big OS. I think I'd dump the whole +of memory on both sides, hexdump and diff them - I'd guess it would +just be one byte/word different, maybe that would offer some idea what +wrote it. +I try to dump and compare them, more than 10 pages are different. +in source side, they are random value rather than always 'FF' 'FB' 'EF' +'BF'... in destination. +and not all of the different pages are continuous. + +thanks +Li +Dave +Any idea... + +=================md5 check patch============================= + +diff --git a/Makefile.target b/Makefile.target +index 962d004..e2cb8e9 100644 +--- a/Makefile.target ++++ b/Makefile.target +@@ -139,7 +139,7 @@ obj-y += memory.o cputlb.o + obj-y += memory_mapping.o + obj-y += dump.o + obj-y += migration/ram.o migration/savevm.o +-LIBS := $(libs_softmmu) $(LIBS) ++LIBS := $(libs_softmmu) $(LIBS) -lplumb + + # xen support + obj-$(CONFIG_XEN) += xen-common.o +diff --git a/migration/ram.c b/migration/ram.c +index 1eb155a..3b7a09d 100644 +--- a/migration/ram.c ++++ b/migration/ram.c +@@ -2513,7 +2513,7 @@ static int ram_load(QEMUFile *f, void *opaque, int +version_id) + } + + rcu_read_unlock(); +- DPRINTF("Completed load of VM with exit code %d seq iteration " ++ fprintf(stderr, "Completed load of VM with exit code %d seq iteration " + "%" PRIu64 "\n", ret, seq_iter); + return ret; + } +diff --git a/migration/savevm.c b/migration/savevm.c +index 0ad1b93..3feaa61 100644 +--- a/migration/savevm.c ++++ b/migration/savevm.c +@@ -891,6 +891,29 @@ void qemu_savevm_state_header(QEMUFile *f) + + } + ++#include "exec/ram_addr.h" ++#include "qemu/rcu_queue.h" ++#include <clplumbing/md5.h> ++#ifndef MD5_DIGEST_LENGTH ++#define MD5_DIGEST_LENGTH 16 ++#endif ++ ++static void check_host_md5(void) ++{ ++ int i; ++ unsigned char md[MD5_DIGEST_LENGTH]; ++ rcu_read_lock(); ++ RAMBlock *block = QLIST_FIRST_RCU(&ram_list.blocks);/* Only check +'pc.ram' block */ ++ rcu_read_unlock(); ++ ++ MD5(block->host, block->used_length, md); ++ for(i = 0; i < MD5_DIGEST_LENGTH; i++) { ++ fprintf(stderr, "%02x", md[i]); ++ } ++ fprintf(stderr, "\n"); ++ error_report("end ram md5"); ++} ++ + void qemu_savevm_state_begin(QEMUFile *f, + const MigrationParams *params) + { +@@ -1056,6 +1079,10 @@ void qemu_savevm_state_complete_precopy(QEMUFile *f, +bool iterable_only) + save_section_header(f, se, QEMU_VM_SECTION_END); + + ret = se->ops->save_live_complete_precopy(f, se->opaque); ++ ++ fprintf(stderr, "after saving %s complete\n", se->idstr); ++ check_host_md5(); ++ + trace_savevm_section_end(se->idstr, se->section_id, ret); + save_section_footer(f, se); + if (ret < 0) { +@@ -1791,6 +1818,11 @@ static int qemu_loadvm_state_main(QEMUFile *f, +MigrationIncomingState *mis) + section_id, le->se->idstr); + return ret; + } ++ if (section_type == QEMU_VM_SECTION_END) { ++ error_report("after loading state section id %d(%s)", ++ section_id, le->se->idstr); ++ check_host_md5(); ++ } + if (!check_section_footer(f, le)) { + return -EINVAL; + } +@@ -1901,6 +1933,8 @@ int qemu_loadvm_state(QEMUFile *f) + } + + cpu_synchronize_all_post_init(); ++ error_report("%s: after cpu_synchronize_all_post_init\n", __func__); ++ check_host_md5(); + + return ret; + } +-- +Dr. David Alan Gilbert / address@hidden / Manchester, UK + + +. +-- +Best regards. +Li Zhijian (8555) + +* Li Zhijian (address@hidden) wrote: +> +> +> +On 12/03/2015 05:24 PM, Dr. David Alan Gilbert wrote: +> +>* Li Zhijian (address@hidden) wrote: +> +>>Hi all, +> +>> +> +>>Does anyboday remember the similar issue post by hailiang months ago +> +>> +http://patchwork.ozlabs.org/patch/454322/ +> +>>At least tow bugs about migration had been fixed since that. +> +> +> +>Yes, I wondered what happened to that. +> +> +> +>>And now we found the same issue at the tcg vm(kvm is fine), after migration, +> +>>the content VM's memory is inconsistent. +> +> +> +>Hmm, TCG only - I don't know much about that; but I guess something must +> +>be accessing memory without using the proper macros/functions so +> +>it doesn't mark it as dirty. +> +> +> +>>we add a patch to check memory content, you can find it from affix +> +>> +> +>>steps to reporduce: +> +>>1) apply the patch and re-build qemu +> +>>2) prepare the ubuntu guest and run memtest in grub. +> +>>soruce side: +> +>>x86_64-softmmu/qemu-system-x86_64 -netdev tap,id=hn0 -device +> +>>e1000,id=net-pci0,netdev=hn0,mac=52:54:00:12:34:65 -boot c -drive +> +>>if=none,file=/home/lizj/ubuntu.raw,id=drive-virtio-disk0 -device +> +>>virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 +> +>>-vnc :7 -m 128 -smp 1 -device piix3-usb-uhci -device usb-tablet -qmp +> +>>tcp::4444,server,nowait -monitor stdio -cpu qemu64 -machine +> +>>pc-i440fx-2.3,accel=tcg,usb=off +> +>> +> +>>destination side: +> +>>x86_64-softmmu/qemu-system-x86_64 -netdev tap,id=hn0 -device +> +>>e1000,id=net-pci0,netdev=hn0,mac=52:54:00:12:34:65 -boot c -drive +> +>>if=none,file=/home/lizj/ubuntu.raw,id=drive-virtio-disk0 -device +> +>>virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 +> +>>-vnc :7 -m 128 -smp 1 -device piix3-usb-uhci -device usb-tablet -qmp +> +>>tcp::4444,server,nowait -monitor stdio -cpu qemu64 -machine +> +>>pc-i440fx-2.3,accel=tcg,usb=off -incoming tcp:0:8881 +> +>> +> +>>3) start migration +> +>>with 1000M NIC, migration will finish within 3 min. +> +>> +> +>>at source: +> +>>(qemu) migrate tcp:192.168.2.66:8881 +> +>>after saving ram complete +> +>>e9e725df678d392b1a83b3a917f332bb +> +>>qemu-system-x86_64: end ram md5 +> +>>(qemu) +> +>> +> +>>at destination: +> +>>...skip... +> +>>Completed load of VM with exit code 0 seq iteration 1264 +> +>>Completed load of VM with exit code 0 seq iteration 1265 +> +>>Completed load of VM with exit code 0 seq iteration 1266 +> +>>qemu-system-x86_64: after loading state section id 2(ram) +> +>>49c2dac7bde0e5e22db7280dcb3824f9 +> +>>qemu-system-x86_64: end ram md5 +> +>>qemu-system-x86_64: qemu_loadvm_state: after cpu_synchronize_all_post_init +> +>> +> +>>49c2dac7bde0e5e22db7280dcb3824f9 +> +>>qemu-system-x86_64: end ram md5 +> +>> +> +>>This occurs occasionally and only at tcg machine. It seems that +> +>>some pages dirtied in source side don't transferred to destination. +> +>>This problem can be reproduced even if we disable virtio. +> +>> +> +>>Is it OK for some pages that not transferred to destination when do +> +>>migration ? Or is it a bug? +> +> +> +>I'm pretty sure that means it's a bug. Hard to find though, I guess +> +>at least memtest is smaller than a big OS. I think I'd dump the whole +> +>of memory on both sides, hexdump and diff them - I'd guess it would +> +>just be one byte/word different, maybe that would offer some idea what +> +>wrote it. +> +> +I try to dump and compare them, more than 10 pages are different. +> +in source side, they are random value rather than always 'FF' 'FB' 'EF' +> +'BF'... in destination. +> +> +and not all of the different pages are continuous. +I wonder if it happens on all of memtest's different test patterns, +perhaps it might be possible to narrow it down if you tell memtest +to only run one test at a time. + +Dave + +> +> +thanks +> +Li +> +> +> +> +> +>Dave +> +> +> +>>Any idea... +> +>> +> +>>=================md5 check patch============================= +> +>> +> +>>diff --git a/Makefile.target b/Makefile.target +> +>>index 962d004..e2cb8e9 100644 +> +>>--- a/Makefile.target +> +>>+++ b/Makefile.target +> +>>@@ -139,7 +139,7 @@ obj-y += memory.o cputlb.o +> +>> obj-y += memory_mapping.o +> +>> obj-y += dump.o +> +>> obj-y += migration/ram.o migration/savevm.o +> +>>-LIBS := $(libs_softmmu) $(LIBS) +> +>>+LIBS := $(libs_softmmu) $(LIBS) -lplumb +> +>> +> +>> # xen support +> +>> obj-$(CONFIG_XEN) += xen-common.o +> +>>diff --git a/migration/ram.c b/migration/ram.c +> +>>index 1eb155a..3b7a09d 100644 +> +>>--- a/migration/ram.c +> +>>+++ b/migration/ram.c +> +>>@@ -2513,7 +2513,7 @@ static int ram_load(QEMUFile *f, void *opaque, int +> +>>version_id) +> +>> } +> +>> +> +>> rcu_read_unlock(); +> +>>- DPRINTF("Completed load of VM with exit code %d seq iteration " +> +>>+ fprintf(stderr, "Completed load of VM with exit code %d seq iteration " +> +>> "%" PRIu64 "\n", ret, seq_iter); +> +>> return ret; +> +>> } +> +>>diff --git a/migration/savevm.c b/migration/savevm.c +> +>>index 0ad1b93..3feaa61 100644 +> +>>--- a/migration/savevm.c +> +>>+++ b/migration/savevm.c +> +>>@@ -891,6 +891,29 @@ void qemu_savevm_state_header(QEMUFile *f) +> +>> +> +>> } +> +>> +> +>>+#include "exec/ram_addr.h" +> +>>+#include "qemu/rcu_queue.h" +> +>>+#include <clplumbing/md5.h> +> +>>+#ifndef MD5_DIGEST_LENGTH +> +>>+#define MD5_DIGEST_LENGTH 16 +> +>>+#endif +> +>>+ +> +>>+static void check_host_md5(void) +> +>>+{ +> +>>+ int i; +> +>>+ unsigned char md[MD5_DIGEST_LENGTH]; +> +>>+ rcu_read_lock(); +> +>>+ RAMBlock *block = QLIST_FIRST_RCU(&ram_list.blocks);/* Only check +> +>>'pc.ram' block */ +> +>>+ rcu_read_unlock(); +> +>>+ +> +>>+ MD5(block->host, block->used_length, md); +> +>>+ for(i = 0; i < MD5_DIGEST_LENGTH; i++) { +> +>>+ fprintf(stderr, "%02x", md[i]); +> +>>+ } +> +>>+ fprintf(stderr, "\n"); +> +>>+ error_report("end ram md5"); +> +>>+} +> +>>+ +> +>> void qemu_savevm_state_begin(QEMUFile *f, +> +>> const MigrationParams *params) +> +>> { +> +>>@@ -1056,6 +1079,10 @@ void qemu_savevm_state_complete_precopy(QEMUFile *f, +> +>>bool iterable_only) +> +>> save_section_header(f, se, QEMU_VM_SECTION_END); +> +>> +> +>> ret = se->ops->save_live_complete_precopy(f, se->opaque); +> +>>+ +> +>>+ fprintf(stderr, "after saving %s complete\n", se->idstr); +> +>>+ check_host_md5(); +> +>>+ +> +>> trace_savevm_section_end(se->idstr, se->section_id, ret); +> +>> save_section_footer(f, se); +> +>> if (ret < 0) { +> +>>@@ -1791,6 +1818,11 @@ static int qemu_loadvm_state_main(QEMUFile *f, +> +>>MigrationIncomingState *mis) +> +>> section_id, le->se->idstr); +> +>> return ret; +> +>> } +> +>>+ if (section_type == QEMU_VM_SECTION_END) { +> +>>+ error_report("after loading state section id %d(%s)", +> +>>+ section_id, le->se->idstr); +> +>>+ check_host_md5(); +> +>>+ } +> +>> if (!check_section_footer(f, le)) { +> +>> return -EINVAL; +> +>> } +> +>>@@ -1901,6 +1933,8 @@ int qemu_loadvm_state(QEMUFile *f) +> +>> } +> +>> +> +>> cpu_synchronize_all_post_init(); +> +>>+ error_report("%s: after cpu_synchronize_all_post_init\n", __func__); +> +>>+ check_host_md5(); +> +>> +> +>> return ret; +> +>> } +> +>> +> +>> +> +>> +> +>-- +> +>Dr. David Alan Gilbert / address@hidden / Manchester, UK +> +> +> +> +> +>. +> +> +> +> +-- +> +Best regards. +> +Li Zhijian (8555) +> +> +-- +Dr. David Alan Gilbert / address@hidden / Manchester, UK + +Li Zhijian <address@hidden> wrote: +> +Hi all, +> +> +Does anyboday remember the similar issue post by hailiang months ago +> +http://patchwork.ozlabs.org/patch/454322/ +> +At least tow bugs about migration had been fixed since that. +> +> +And now we found the same issue at the tcg vm(kvm is fine), after +> +migration, the content VM's memory is inconsistent. +> +> +we add a patch to check memory content, you can find it from affix +> +> +steps to reporduce: +> +1) apply the patch and re-build qemu +> +2) prepare the ubuntu guest and run memtest in grub. +> +soruce side: +> +x86_64-softmmu/qemu-system-x86_64 -netdev tap,id=hn0 -device +> +e1000,id=net-pci0,netdev=hn0,mac=52:54:00:12:34:65 -boot c -drive +> +if=none,file=/home/lizj/ubuntu.raw,id=drive-virtio-disk0 -device +> +virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 +> +-vnc :7 -m 128 -smp 1 -device piix3-usb-uhci -device usb-tablet -qmp +> +tcp::4444,server,nowait -monitor stdio -cpu qemu64 -machine +> +pc-i440fx-2.3,accel=tcg,usb=off +> +> +destination side: +> +x86_64-softmmu/qemu-system-x86_64 -netdev tap,id=hn0 -device +> +e1000,id=net-pci0,netdev=hn0,mac=52:54:00:12:34:65 -boot c -drive +> +if=none,file=/home/lizj/ubuntu.raw,id=drive-virtio-disk0 -device +> +virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 +> +-vnc :7 -m 128 -smp 1 -device piix3-usb-uhci -device usb-tablet -qmp +> +tcp::4444,server,nowait -monitor stdio -cpu qemu64 -machine +> +pc-i440fx-2.3,accel=tcg,usb=off -incoming tcp:0:8881 +> +> +3) start migration +> +with 1000M NIC, migration will finish within 3 min. +> +> +at source: +> +(qemu) migrate tcp:192.168.2.66:8881 +> +after saving ram complete +> +e9e725df678d392b1a83b3a917f332bb +> +qemu-system-x86_64: end ram md5 +> +(qemu) +> +> +at destination: +> +...skip... +> +Completed load of VM with exit code 0 seq iteration 1264 +> +Completed load of VM with exit code 0 seq iteration 1265 +> +Completed load of VM with exit code 0 seq iteration 1266 +> +qemu-system-x86_64: after loading state section id 2(ram) +> +49c2dac7bde0e5e22db7280dcb3824f9 +> +qemu-system-x86_64: end ram md5 +> +qemu-system-x86_64: qemu_loadvm_state: after cpu_synchronize_all_post_init +> +> +49c2dac7bde0e5e22db7280dcb3824f9 +> +qemu-system-x86_64: end ram md5 +> +> +This occurs occasionally and only at tcg machine. It seems that +> +some pages dirtied in source side don't transferred to destination. +> +This problem can be reproduced even if we disable virtio. +> +> +Is it OK for some pages that not transferred to destination when do +> +migration ? Or is it a bug? +> +> +Any idea... +Thanks for describing how to reproduce the bug. +If some pages are not transferred to destination then it is a bug, so we +need to know what the problem is, notice that the problem can be that +TCG is not marking dirty some page, that Migration code "forgets" about +that page, or anything eles altogether, that is what we need to find. + +There are more posibilities, I am not sure that memtest is on 32bit +mode, and it is inside posibility that we are missing some state when we +are on real mode. + +Will try to take a look at this. + +THanks, again. + + +> +> +=================md5 check patch============================= +> +> +diff --git a/Makefile.target b/Makefile.target +> +index 962d004..e2cb8e9 100644 +> +--- a/Makefile.target +> ++++ b/Makefile.target +> +@@ -139,7 +139,7 @@ obj-y += memory.o cputlb.o +> +obj-y += memory_mapping.o +> +obj-y += dump.o +> +obj-y += migration/ram.o migration/savevm.o +> +-LIBS := $(libs_softmmu) $(LIBS) +> ++LIBS := $(libs_softmmu) $(LIBS) -lplumb +> +> +# xen support +> +obj-$(CONFIG_XEN) += xen-common.o +> +diff --git a/migration/ram.c b/migration/ram.c +> +index 1eb155a..3b7a09d 100644 +> +--- a/migration/ram.c +> ++++ b/migration/ram.c +> +@@ -2513,7 +2513,7 @@ static int ram_load(QEMUFile *f, void *opaque, +> +int version_id) +> +} +> +> +rcu_read_unlock(); +> +- DPRINTF("Completed load of VM with exit code %d seq iteration " +> ++ fprintf(stderr, "Completed load of VM with exit code %d seq iteration " +> +"%" PRIu64 "\n", ret, seq_iter); +> +return ret; +> +} +> +diff --git a/migration/savevm.c b/migration/savevm.c +> +index 0ad1b93..3feaa61 100644 +> +--- a/migration/savevm.c +> ++++ b/migration/savevm.c +> +@@ -891,6 +891,29 @@ void qemu_savevm_state_header(QEMUFile *f) +> +> +} +> +> ++#include "exec/ram_addr.h" +> ++#include "qemu/rcu_queue.h" +> ++#include <clplumbing/md5.h> +> ++#ifndef MD5_DIGEST_LENGTH +> ++#define MD5_DIGEST_LENGTH 16 +> ++#endif +> ++ +> ++static void check_host_md5(void) +> ++{ +> ++ int i; +> ++ unsigned char md[MD5_DIGEST_LENGTH]; +> ++ rcu_read_lock(); +> ++ RAMBlock *block = QLIST_FIRST_RCU(&ram_list.blocks);/* Only check +> +'pc.ram' block */ +> ++ rcu_read_unlock(); +> ++ +> ++ MD5(block->host, block->used_length, md); +> ++ for(i = 0; i < MD5_DIGEST_LENGTH; i++) { +> ++ fprintf(stderr, "%02x", md[i]); +> ++ } +> ++ fprintf(stderr, "\n"); +> ++ error_report("end ram md5"); +> ++} +> ++ +> +void qemu_savevm_state_begin(QEMUFile *f, +> +const MigrationParams *params) +> +{ +> +@@ -1056,6 +1079,10 @@ void +> +qemu_savevm_state_complete_precopy(QEMUFile *f, bool iterable_only) +> +save_section_header(f, se, QEMU_VM_SECTION_END); +> +> +ret = se->ops->save_live_complete_precopy(f, se->opaque); +> ++ +> ++ fprintf(stderr, "after saving %s complete\n", se->idstr); +> ++ check_host_md5(); +> ++ +> +trace_savevm_section_end(se->idstr, se->section_id, ret); +> +save_section_footer(f, se); +> +if (ret < 0) { +> +@@ -1791,6 +1818,11 @@ static int qemu_loadvm_state_main(QEMUFile *f, +> +MigrationIncomingState *mis) +> +section_id, le->se->idstr); +> +return ret; +> +} +> ++ if (section_type == QEMU_VM_SECTION_END) { +> ++ error_report("after loading state section id %d(%s)", +> ++ section_id, le->se->idstr); +> ++ check_host_md5(); +> ++ } +> +if (!check_section_footer(f, le)) { +> +return -EINVAL; +> +} +> +@@ -1901,6 +1933,8 @@ int qemu_loadvm_state(QEMUFile *f) +> +} +> +> +cpu_synchronize_all_post_init(); +> ++ error_report("%s: after cpu_synchronize_all_post_init\n", __func__); +> ++ check_host_md5(); +> +> +return ret; +> +} + +> +> +Thanks for describing how to reproduce the bug. +> +If some pages are not transferred to destination then it is a bug, so we need +> +to know what the problem is, notice that the problem can be that TCG is not +> +marking dirty some page, that Migration code "forgets" about that page, or +> +anything eles altogether, that is what we need to find. +> +> +There are more posibilities, I am not sure that memtest is on 32bit mode, and +> +it is inside posibility that we are missing some state when we are on real +> +mode. +> +> +Will try to take a look at this. +> +> +THanks, again. +> +Hi Juan & Amit + + Do you think we should add a mechanism to check the data integrity during LM +like Zhijian's patch did? it may be very helpful for developers. + Actually, I did the similar thing before in order to make sure that I did the +right thing we I change the code related to LM. + +Liang + +On (Fri) 04 Dec 2015 [01:43:07], Li, Liang Z wrote: +> +> +> +> Thanks for describing how to reproduce the bug. +> +> If some pages are not transferred to destination then it is a bug, so we +> +> need +> +> to know what the problem is, notice that the problem can be that TCG is not +> +> marking dirty some page, that Migration code "forgets" about that page, or +> +> anything eles altogether, that is what we need to find. +> +> +> +> There are more posibilities, I am not sure that memtest is on 32bit mode, +> +> and +> +> it is inside posibility that we are missing some state when we are on real +> +> mode. +> +> +> +> Will try to take a look at this. +> +> +> +> THanks, again. +> +> +> +> +Hi Juan & Amit +> +> +Do you think we should add a mechanism to check the data integrity during LM +> +like Zhijian's patch did? it may be very helpful for developers. +> +Actually, I did the similar thing before in order to make sure that I did +> +the right thing we I change the code related to LM. +If you mean for debugging, something that's not always on, then I'm +fine with it. + +A script that goes along that shows the result of comparison of the +diff will be helpful too, something that shows how many pages are +differnt, how many bytes in a page on average, and so on. + + Amit + diff --git a/results/classifier/105/mistranslation/74545755 b/results/classifier/105/mistranslation/74545755 new file mode 100644 index 000000000..7f5ace505 --- /dev/null +++ b/results/classifier/105/mistranslation/74545755 @@ -0,0 +1,352 @@ +mistranslation: 0.752 +device: 0.720 +instruction: 0.700 +other: 0.683 +semantic: 0.669 +KVM: 0.661 +graphic: 0.660 +vnc: 0.650 +assembly: 0.648 +boot: 0.607 +network: 0.550 +socket: 0.549 + +[Bug Report][RFC PATCH 0/1] block: fix failing assert on paused VM migration + +There's a bug (failing assert) which is reproduced during migration of +a paused VM. I am able to reproduce it on a stand with 2 nodes and a common +NFS share, with VM's disk on that share. + +root@fedora40-1-vm:~# virsh domblklist alma8-vm + Target Source +------------------------------------------ + sda /mnt/shared/images/alma8.qcow2 + +root@fedora40-1-vm:~# df -Th /mnt/shared +Filesystem Type Size Used Avail Use% Mounted on +127.0.0.1:/srv/nfsd nfs4 63G 16G 48G 25% /mnt/shared + +On the 1st node: + +root@fedora40-1-vm:~# virsh start alma8-vm ; virsh suspend alma8-vm +root@fedora40-1-vm:~# virsh migrate --compressed --p2p --persistent +--undefinesource --live alma8-vm qemu+ssh://fedora40-2-vm/system + +Then on the 2nd node: + +root@fedora40-2-vm:~# virsh migrate --compressed --p2p --persistent +--undefinesource --live alma8-vm qemu+ssh://fedora40-1-vm/system +error: operation failed: domain is not running + +root@fedora40-2-vm:~# tail -3 /var/log/libvirt/qemu/alma8-vm.log +2024-09-19 13:53:33.336+0000: initiating migration +qemu-system-x86_64: ../block.c:6976: int +bdrv_inactivate_recurse(BlockDriverState *): Assertion `!(bs->open_flags & +BDRV_O_INACTIVE)' failed. +2024-09-19 13:53:42.991+0000: shutting down, reason=crashed + +Backtrace: + +(gdb) bt +#0 0x00007f7eaa2f1664 in __pthread_kill_implementation () at /lib64/libc.so.6 +#1 0x00007f7eaa298c4e in raise () at /lib64/libc.so.6 +#2 0x00007f7eaa280902 in abort () at /lib64/libc.so.6 +#3 0x00007f7eaa28081e in __assert_fail_base.cold () at /lib64/libc.so.6 +#4 0x00007f7eaa290d87 in __assert_fail () at /lib64/libc.so.6 +#5 0x0000563c38b95eb8 in bdrv_inactivate_recurse (bs=0x563c3b6c60c0) at +../block.c:6976 +#6 0x0000563c38b95aeb in bdrv_inactivate_all () at ../block.c:7038 +#7 0x0000563c3884d354 in qemu_savevm_state_complete_precopy_non_iterable +(f=0x563c3b700c20, in_postcopy=false, inactivate_disks=true) + at ../migration/savevm.c:1571 +#8 0x0000563c3884dc1a in qemu_savevm_state_complete_precopy (f=0x563c3b700c20, +iterable_only=false, inactivate_disks=true) at ../migration/savevm.c:1631 +#9 0x0000563c3883a340 in migration_completion_precopy (s=0x563c3b4d51f0, +current_active_state=<optimized out>) at ../migration/migration.c:2780 +#10 migration_completion (s=0x563c3b4d51f0) at ../migration/migration.c:2844 +#11 migration_iteration_run (s=0x563c3b4d51f0) at ../migration/migration.c:3270 +#12 migration_thread (opaque=0x563c3b4d51f0) at ../migration/migration.c:3536 +#13 0x0000563c38dbcf14 in qemu_thread_start (args=0x563c3c2d5bf0) at +../util/qemu-thread-posix.c:541 +#14 0x00007f7eaa2ef6d7 in start_thread () at /lib64/libc.so.6 +#15 0x00007f7eaa373414 in clone () at /lib64/libc.so.6 + +What happens here is that after 1st migration BDS related to HDD remains +inactive as VM is still paused. Then when we initiate 2nd migration, +bdrv_inactivate_all() leads to the attempt to set BDRV_O_INACTIVE flag +on that node which is already set, thus assert fails. + +Attached patch which simply skips setting flag if it's already set is more +of a kludge than a clean solution. Should we use more sophisticated logic +which allows some of the nodes be in inactive state prior to the migration, +and takes them into account during bdrv_inactivate_all()? Comments would +be appreciated. + +Andrey + +Andrey Drobyshev (1): + block: do not fail when inactivating node which is inactive + + block.c | 10 +++++++++- + 1 file changed, 9 insertions(+), 1 deletion(-) + +-- +2.39.3 + +Instead of throwing an assert let's just ignore that flag is already set +and return. We assume that it's going to be safe to ignore. Otherwise +this assert fails when migrating a paused VM back and forth. + +Ideally we'd like to have a more sophisticated solution, e.g. not even +scan the nodes which should be inactive at this point. + +Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com> +--- + block.c | 10 +++++++++- + 1 file changed, 9 insertions(+), 1 deletion(-) + +diff --git a/block.c b/block.c +index 7d90007cae..c1dcf906d1 100644 +--- a/block.c ++++ b/block.c +@@ -6973,7 +6973,15 @@ static int GRAPH_RDLOCK +bdrv_inactivate_recurse(BlockDriverState *bs) + return 0; + } + +- assert(!(bs->open_flags & BDRV_O_INACTIVE)); ++ if (bs->open_flags & BDRV_O_INACTIVE) { ++ /* ++ * Return here instead of throwing assert as a workaround to ++ * prevent failure on migrating paused VM. ++ * Here we assume that if we're trying to inactivate BDS that's ++ * already inactive, it's safe to just ignore it. ++ */ ++ return 0; ++ } + + /* Inactivate this node */ + if (bs->drv->bdrv_inactivate) { +-- +2.39.3 + +[add migration maintainers] + +On 24.09.24 15:56, Andrey Drobyshev wrote: +Instead of throwing an assert let's just ignore that flag is already set +and return. We assume that it's going to be safe to ignore. Otherwise +this assert fails when migrating a paused VM back and forth. + +Ideally we'd like to have a more sophisticated solution, e.g. not even +scan the nodes which should be inactive at this point. + +Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com> +--- + block.c | 10 +++++++++- + 1 file changed, 9 insertions(+), 1 deletion(-) + +diff --git a/block.c b/block.c +index 7d90007cae..c1dcf906d1 100644 +--- a/block.c ++++ b/block.c +@@ -6973,7 +6973,15 @@ static int GRAPH_RDLOCK +bdrv_inactivate_recurse(BlockDriverState *bs) + return 0; + } +- assert(!(bs->open_flags & BDRV_O_INACTIVE)); ++ if (bs->open_flags & BDRV_O_INACTIVE) { ++ /* ++ * Return here instead of throwing assert as a workaround to ++ * prevent failure on migrating paused VM. ++ * Here we assume that if we're trying to inactivate BDS that's ++ * already inactive, it's safe to just ignore it. ++ */ ++ return 0; ++ } +/* Inactivate this node */ +if (bs->drv->bdrv_inactivate) { +I doubt that this a correct way to go. + +As far as I understand, "inactive" actually means that "storage is not belong to +qemu, but to someone else (another qemu process for example), and may be changed +transparently". In turn this means that Qemu should do nothing with inactive disks. So the +problem is that nobody called bdrv_activate_all on target, and we shouldn't ignore that. + +Hmm, I see in process_incoming_migration_bh() we do call bdrv_activate_all(), +but only in some scenarios. May be, the condition should be less strict here. + +Why we need any condition here at all? Don't we want to activate block-layer on +target after migration anyway? + +-- +Best regards, +Vladimir + +On 9/30/24 12:25 PM, Vladimir Sementsov-Ogievskiy wrote: +> +[add migration maintainers] +> +> +On 24.09.24 15:56, Andrey Drobyshev wrote: +> +> [...] +> +> +I doubt that this a correct way to go. +> +> +As far as I understand, "inactive" actually means that "storage is not +> +belong to qemu, but to someone else (another qemu process for example), +> +and may be changed transparently". In turn this means that Qemu should +> +do nothing with inactive disks. So the problem is that nobody called +> +bdrv_activate_all on target, and we shouldn't ignore that. +> +> +Hmm, I see in process_incoming_migration_bh() we do call +> +bdrv_activate_all(), but only in some scenarios. May be, the condition +> +should be less strict here. +> +> +Why we need any condition here at all? Don't we want to activate +> +block-layer on target after migration anyway? +> +Hmm I'm not sure about the unconditional activation, since we at least +have to honor LATE_BLOCK_ACTIVATE cap if it's set (and probably delay it +in such a case). In current libvirt upstream I see such code: + +> +/* Migration capabilities which should always be enabled as long as they +> +> +* are supported by QEMU. If the capability is supposed to be enabled on both +> +> +* sides of migration, it won't be enabled unless both sides support it. +> +> +*/ +> +> +static const qemuMigrationParamsAlwaysOnItem qemuMigrationParamsAlwaysOn[] = +> +{ +> +> +{QEMU_MIGRATION_CAP_PAUSE_BEFORE_SWITCHOVER, +> +> +QEMU_MIGRATION_SOURCE}, +> +> +> +> +{QEMU_MIGRATION_CAP_LATE_BLOCK_ACTIVATE, +> +> +QEMU_MIGRATION_DESTINATION}, +> +> +}; +which means that libvirt always wants LATE_BLOCK_ACTIVATE to be set. + +The code from process_incoming_migration_bh() you're referring to: + +> +/* If capability late_block_activate is set: +> +> +* Only fire up the block code now if we're going to restart the +> +> +* VM, else 'cont' will do it. +> +> +* This causes file locking to happen; so we don't want it to happen +> +> +* unless we really are starting the VM. +> +> +*/ +> +> +if (!migrate_late_block_activate() || +> +> +(autostart && (!global_state_received() || +> +> +runstate_is_live(global_state_get_runstate())))) { +> +> +/* Make sure all file formats throw away their mutable metadata. +> +> +> +* If we get an error here, just don't restart the VM yet. */ +> +> +bdrv_activate_all(&local_err); +> +> +if (local_err) { +> +> +error_report_err(local_err); +> +> +local_err = NULL; +> +> +autostart = false; +> +> +} +> +> +} +It states explicitly that we're either going to start VM right at this +point if (autostart == true), or we wait till "cont" command happens. +None of this is going to happen if we start another migration while +still being in PAUSED state. So I think it seems reasonable to take +such case into account. For instance, this patch does prevent the crash: + +> +diff --git a/migration/migration.c b/migration/migration.c +> +index ae2be31557..3222f6745b 100644 +> +--- a/migration/migration.c +> ++++ b/migration/migration.c +> +@@ -733,7 +733,8 @@ static void process_incoming_migration_bh(void *opaque) +> +*/ +> +if (!migrate_late_block_activate() || +> +(autostart && (!global_state_received() || +> +- runstate_is_live(global_state_get_runstate())))) { +> ++ runstate_is_live(global_state_get_runstate()))) || +> ++ (!autostart && global_state_get_runstate() == RUN_STATE_PAUSED)) { +> +/* Make sure all file formats throw away their mutable metadata. +> +* If we get an error here, just don't restart the VM yet. */ +> +bdrv_activate_all(&local_err); +What are your thoughts on it? + +Andrey + diff --git a/results/classifier/105/mistranslation/746 b/results/classifier/105/mistranslation/746 new file mode 100644 index 000000000..b27f9ebf1 --- /dev/null +++ b/results/classifier/105/mistranslation/746 @@ -0,0 +1,14 @@ +mistranslation: 0.986 +other: 0.799 +semantic: 0.795 +vnc: 0.765 +device: 0.762 +network: 0.732 +socket: 0.686 +instruction: 0.649 +graphic: 0.622 +boot: 0.551 +KVM: 0.536 +assembly: 0.361 + +Current file VERSION of tag 6.2.0-rc2 contains 6.2.92, not 6.1.92 diff --git a/results/classifier/105/mistranslation/753916 b/results/classifier/105/mistranslation/753916 new file mode 100644 index 000000000..f6659d825 --- /dev/null +++ b/results/classifier/105/mistranslation/753916 @@ -0,0 +1,47 @@ +mistranslation: 0.876 +graphic: 0.863 +boot: 0.836 +other: 0.832 +instruction: 0.814 +semantic: 0.800 +network: 0.795 +device: 0.784 +vnc: 0.741 +socket: 0.688 +assembly: 0.573 +KVM: 0.441 + +performance bug with SeaBios 0.6.x + +in my tests SeaBios 0.5.1 has the best performance (100% faster) +i run qemu port in windows xp (phenom II x4 945, 4 gigas ram DDR3) and windows xp (Pentium 4, 1 giga ram ddr) + +Hi. Thanks for reporting this issue. + +Can you tell us a bit more about the problem? +I'm not sure what the cause could be, but perhaps we can understand it better with some of the following information (plus anything else you can think of that could be related): + - What version of QEMU are you running on each machine? + - Did you build it yourself? If so, can you describe how? If not, can you provide a pointer to where you got it? + - What are you running as the guest environment(s)? + - I'm assuming that Windows XP is the host environment (two different host machines from your description). Which version / service packs do you have installed? + - How did you do the tests? For example, what is the benchmarking tool or load that you are using? How are you using those tools / loads? Can you provide the numbers for each host? + +i use QEMU for test PEs (preinstaled environments) in pendrives with a bat script + +# +SET SDL_VIDEODRIVER=directx +qemu.exe -m 512 -localtime -M pc -hda \\.\physicaldrive1 +# + +my workstation run Windows XP SP3 with all hotfixes, and i use QEMU 0.14.0 (this port http://www.megaupload.com/?d=8LUG85F9) + +i run syslinux loader for Linux PLD rescue .iso file + +i record a test with camstudio http://www.megaupload.com/?d=37LDTOS3 + +OK, from your test.swf file, I assume that the way you're testing is the boot-up of a Linux ISO, and that "100%" is an estimate of boot speed. + +I'm really not sure what the problem is. I can only suggest that you try various SeaBIOS versions and try to isolate which version is the problem. It also might be worth seeing if the problem affects other Linux distro boot-up. + +SeaBios 0.x is pretty outdated nowadays, so I think we should close this bug ... anyway, if you still have problems with SeaBios, you likely should it report on the SeaBios mailing list (https://www.seabios.org/Mailinglist) instead of using the QEMU bugtracker. + diff --git a/results/classifier/105/mistranslation/764252 b/results/classifier/105/mistranslation/764252 new file mode 100644 index 000000000..3ba9aea69 --- /dev/null +++ b/results/classifier/105/mistranslation/764252 @@ -0,0 +1,31 @@ +mistranslation: 0.963 +device: 0.853 +graphic: 0.747 +semantic: 0.707 +network: 0.678 +other: 0.655 +vnc: 0.581 +socket: 0.571 +instruction: 0.475 +boot: 0.464 +KVM: 0.445 +assembly: 0.337 + +wishlist: kirkwood support + +This is a feature request for qemu to emulate the Marvell Kirkwood chipset. It is used by Sheevaplug, Guruplug, and many NAS devices. + +This was added in 2011, is there a plan to integrate support for kirkwood? + +With "this" I mean the bugreport, not the feature requested. + +If somebody wants to write and submit code I will review it. I am not aware of anybody who is working on kirkwood emulation support or with plans to do so. + + +Apparently nobody submitted code for this, and I assume nobody is interested in this kirkwood platform nowadays any more, so I'm closing this ticket now. + +For the record, I still regularly use a Kirkwood device (a QNAP NAS). Being able to compile software for it in qemu would be handy once in a while, though it's not a high priority for me. + +My offer from comment #3 to review code if anybody wants to submit it still stands, but given the amount of work required to implement a model of a new SoC in QEMU I'm not surprised nobody's ever taken me up on it. + + diff --git a/results/classifier/105/mistranslation/77 b/results/classifier/105/mistranslation/77 new file mode 100644 index 000000000..81b85758b --- /dev/null +++ b/results/classifier/105/mistranslation/77 @@ -0,0 +1,14 @@ +mistranslation: 0.980 +other: 0.899 +graphic: 0.499 +semantic: 0.491 +device: 0.380 +boot: 0.296 +network: 0.289 +instruction: 0.079 +KVM: 0.062 +vnc: 0.053 +assembly: 0.052 +socket: 0.013 + +msmouse not recognized in guest diff --git a/results/classifier/105/mistranslation/773 b/results/classifier/105/mistranslation/773 new file mode 100644 index 000000000..09562a010 --- /dev/null +++ b/results/classifier/105/mistranslation/773 @@ -0,0 +1,40 @@ +mistranslation: 0.864 +other: 0.822 +graphic: 0.742 +instruction: 0.737 +device: 0.715 +semantic: 0.707 +network: 0.701 +vnc: 0.691 +assembly: 0.687 +KVM: 0.672 +socket: 0.671 +boot: 0.617 + +TCG profiler build fails +Description of problem: +Attempting to build with --enable-profiler fails +Steps to reproduce: +1. ../../configure --enable-profiler +2. make +Additional information: +[975/3221] Compiling C object libcommon.fa.p/monitor_qmp-cmds.c.o + FAILED: libcommon.fa.p/monitor_qmp-cmds.c.o + cc -m64 -mcx16 -Ilibcommon.fa.p -I../../dtc/libfdt -I/usr/include/capstone -I/usr/include/pixman-1 -I/usr/include/spice-server -I/usr/include/spice-1 -I/usr/include/libpng16 + -I/usr/include/p11-kit-1 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/gio-unix-2.0 -I/us + r/include/slirp -I/usr/include/virgl -I/usr/include/libusb-1.0 -I/usr/include/cacard -I/usr/include/nss -I/usr/include/nspr -I/usr/include/PCSC -I/usr/include/gtk-3.0 -I/usr + /include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/ + include/fribidi -I/usr/include/harfbuzz -I/usr/include/atk-1.0 -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/vte-2.91 -fdiagnosti + cs-color=auto -Wall -Winvalid-pch -Werror -std=gnu11 -O2 -g -isystem /home/alex/lsrc/qemu.git/linux-headers -isystem linux-headers -iquote . -iquote /home/alex/lsrc/qemu.git + -iquote /home/alex/lsrc/qemu.git/include -iquote /home/alex/lsrc/qemu.git/disas/libvixl -iquote /home/alex/lsrc/qemu.git/tcg/i386 -pthread -U_FORTIFY_SOURCE -D_FORTIFY_SOUR + CE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-co + mmon -fwrapv -Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wend + if-labels -Wexpansion-to-defined -Wimplicit-fallthrough=2 -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fstack-protector-strong -fPIE -D_DEFAULT_SOURCE -D_ + XOPEN_SOURCE=600 -DNCURSES_WIDECHAR=1 -D_REENTRANT -DSTRUCT_IOVEC_DEFINED -MD -MQ libcommon.fa.p/monitor_qmp-cmds.c.o -MF libcommon.fa.p/monitor_qmp-cmds.c.o.d -o libcommon. + fa.p/monitor_qmp-cmds.c.o -c ../../monitor/qmp-cmds.c + ../../monitor/qmp-cmds.c: In function ‘qmp_x_query_profile’: + ../../monitor/qmp-cmds.c:369:21: error: implicit declaration of function ‘tcg_cpu_exec_time’ [-Werror=implicit-function-declaration] + 369 | cpu_exec_time = tcg_cpu_exec_time(); + | ^~~~~~~~~~~~~~~~~ + ../../monitor/qmp-cmds.c:369:21: error: nested extern declaration of ‘tcg_cpu_exec_time’ [-Werror=nested-externs] + cc1: all warnings being treated as errors diff --git a/results/classifier/105/mistranslation/793 b/results/classifier/105/mistranslation/793 new file mode 100644 index 000000000..278de5814 --- /dev/null +++ b/results/classifier/105/mistranslation/793 @@ -0,0 +1,14 @@ +mistranslation: 0.997 +graphic: 0.740 +other: 0.610 +device: 0.527 +semantic: 0.319 +assembly: 0.187 +instruction: 0.185 +network: 0.148 +vnc: 0.126 +boot: 0.079 +socket: 0.063 +KVM: 0.032 + +Wrong pci express bus type - qemu 6.1.0-5 diff --git a/results/classifier/105/mistranslation/795866 b/results/classifier/105/mistranslation/795866 new file mode 100644 index 000000000..a390d157e --- /dev/null +++ b/results/classifier/105/mistranslation/795866 @@ -0,0 +1,167 @@ +mistranslation: 0.858 +assembly: 0.802 +semantic: 0.779 +vnc: 0.774 +instruction: 0.762 +graphic: 0.757 +other: 0.747 +device: 0.729 +KVM: 0.721 +boot: 0.681 +socket: 0.680 +network: 0.665 + +pci passthrough doesn´t work + +Hi all, + +I have some problems passing through a pci device to kvm guest. +First I have to say that I´m using the latest kvm-kernel und qemu-kvm from git-tree (Date 11.06.2011). + +I want´t to passthrough this device to guest: + +lspci-output: + +02:00.0 Multimedia video controller: Micronas Semiconductor Holding AG Device 0720 (rev 01) + +So at first I have bind the driver to psi-stub: + +modprobe -r kvm-intel +modprobe -r kvm +echo "18c3 0720" > /sys/bus/pci/drivers/pci-stub/new_id +echo 0000:02:00.0 > /sys/bus/pci/devices/0000:02:00.0/driver/unbind +echo 0000:02:00.0 > /sys/bus/pci/drivers/pci-stub/bind +modprobe kvm +modprobe kvm-intel + +Then I have assigned device to guest: +-device pci-assign,host=02:00.0 + +When I start the guest. The device succesfully get´s an msi-IRQ on host-system: + +cat /proc/interrupt output: + + 32: 0 0 0 0 PCI-MSI-edge kvm_assigned_msi_device + + +On guest device is visibel: + +lspci output: +00:04.0 Multimedia video controller: Micronas Semiconductor Holding AG Device 0720 (rev 01) + + +Sometimes the device (on guest) get´s an IRQ between 10-16: + +00:05.0 Multimedia video controller: Micronas Semiconductor Holding AG Device 0720 (rev 01) + Subsystem: Micronas Semiconductor Holding AG Device dd00 + Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ + Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx+ + Interrupt: pin A routed to IRQ 11 + Region 0: Memory at f2050000 (32-bit, non-prefetchable) [size=64K] + Region 1: Memory at f2060000 (32-bit, non-prefetchable) [size=64K] + Capabilities: [58] Express (v1) Endpoint, MSI 00 + DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us + ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- + DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- + RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ + MaxPayload 128 bytes, MaxReadReq 128 bytes + DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- + LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 unlimited, L1 unlimited + ClockPM- Suprise- LLActRep- BwNot- + LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ + ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- + LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt- + Capabilities: [40] Power Management version 2 + Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) + Status: D0 PME-Enable- DSel=0 DScale=0 PME- + Capabilities: [48] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- + Address: 00000000 Data: 0000 + Kernel modules: ngene + + +In this case the kernel-modul (ngene) can not access the device: + +dmesg | grep ngene + +[ 69.977900] ngene 0000:00:05.0: PCI INT A -> Link[LNKA] -> GSI 11 (level, high) -> IRQ 11 +[ 69.977909] ngene: Found Linux4Media cineS2 DVB-S2 Twin Tuner (v5) +[ 69.978962] ngene 0000:00:05.0: setting latency timer to 64 +[ 69.979118] ngene: Device version 1 +[ 69.979129] ngene 0000:00:05.0: firmware: requesting ngene_18.fw +[ 69.980884] ngene: Loading firmware file ngene_18.fw. +[ 71.981052] ngene: Command timeout cmd=01 prev=00 +[ 71.981205] host_to_ngene (c000): 01 00 00 00 00 00 00 00 +[ 71.981457] ngene_to_host (c100): 00 00 00 00 00 00 00 00 +[ 71.981704] dev->hosttongene (ec902000): 01 00 00 00 00 00 00 00 +[ 71.981963] dev->ngenetohost (ec902100): 00 00 00 00 00 00 00 00 +[ 73.985111] ngene: Command timeout cmd=02 prev=00 +[ 73.985415] host_to_ngene (c000): 02 04 00 d0 00 04 00 00 +[ 73.985684] ngene_to_host (c100): 00 00 00 00 00 00 00 00 +[ 73.985931] dev->hosttongene (ec902000): 02 04 00 d0 00 04 00 00 +[ 73.986191] dev->ngenetohost (ec902100): 00 00 00 00 00 00 00 00 +[ 73.986568] ngene 0000:00:05.0: PCI INT A disabled +[ 73.986584] ngene: probe of 0000:00:05.0 failed with error -1 + + +Sometimes the device (on guest) gets an msi-irq f. e. IRQ 29. +Then kernel-modul (ngene) can succesfully load the driver and all works fine. + + +Short to say: + +HOST GUEST STATUS +MSI-IRQ MSI-IRQ ALL FINE +MSI-IRQ IOAPIC-IRQ DOESN´t WORK + +with modinfo I had a look at the kernel-modul if there is way to force msi, but without success. + +But I think IRQ between (10-16) should also work because when I load the kernel-modul on host with IRQ (10-16) +it works. (Device only get´s an MSI-IRQ If I start the vm to passthrough) + +Do anyone know where can be the problem? + +Here is the dmesg - output of second device which is currently working on guest with MSI-IRQ 29: + +[ 2.137175] ngene 0000:00:04.0: PCI INT A -> Link[LNKD] -> GSI 11 (level, high) -> IRQ 11 +[ 2.137183] ngene: Found Linux4Media cineS2 DVB-S2 Twin Tuner (v5) +[ 2.140506] ngene 0000:00:04.0: setting latency timer to 64 +[ 2.140679] ngene: Device version 1 +[ 2.140693] ngene 0000:00:04.0: firmware: requesting ngene_18.fw +[ 2.214848] ngene: Loading firmware file ngene_18.fw. +[ 2.249797] ngene 0000:00:04.0: irq 29 for MSI/MSI-X + + + + +lspci - output on guest: + +00:04.0 Multimedia video controller: Micronas Semiconductor Holding AG Device 0720 (rev 01) + Subsystem: Micronas Semiconductor Holding AG Device dd00 + Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ + Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx+ + Latency: 0, Cache Line Size: 64 bytes + Interrupt: pin A routed to IRQ 29 + Region 0: Memory at f2030000 (32-bit, non-prefetchable) [size=64K] + Region 1: Memory at f2040000 (32-bit, non-prefetchable) [size=64K] + Capabilities: <access denied> + Kernel driver in use: ngene + Kernel modules: ngene + +00:05.0 Multimedia video controller: Micronas Semiconductor Holding AG Device 0720 (rev 01) + Subsystem: Micronas Semiconductor Holding AG Device dd00 + Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ + Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx+ + Interrupt: pin A routed to IRQ 11 + Region 0: Memory at f2050000 (32-bit, non-prefetchable) [size=64K] + Region 1: Memory at f2060000 (32-bit, non-prefetchable) [size=64K] + Capabilities: <access denied> + Kernel modules: ngene + + +IRQ 11 not working. +IRQ 29 working + +Triaging old bug tickets ... can you still reproduce this problem with the latest version of QEMU? Or can we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/80604314 b/results/classifier/105/mistranslation/80604314 new file mode 100644 index 000000000..cb64e7d6d --- /dev/null +++ b/results/classifier/105/mistranslation/80604314 @@ -0,0 +1,1488 @@ +mistranslation: 0.922 +device: 0.917 +graphic: 0.901 +other: 0.898 +KVM: 0.891 +semantic: 0.890 +assembly: 0.886 +socket: 0.884 +vnc: 0.881 +instruction: 0.877 +network: 0.865 +boot: 0.860 + +[BUG] vhost-vdpa: qemu-system-s390x crashes with second virtio-net-ccw device + +When I start qemu with a second virtio-net-ccw device (i.e. adding +-device virtio-net-ccw in addition to the autogenerated device), I get +a segfault. gdb points to + +#0 0x000055d6ab52681d in virtio_net_get_config (vdev=<optimized out>, + config=0x55d6ad9e3f80 "RT") at /home/cohuck/git/qemu/hw/net/virtio-net.c:146 +146 if (nc->peer->info->type == NET_CLIENT_DRIVER_VHOST_VDPA) { + +(backtrace doesn't go further) + +Starting qemu with no additional "-device virtio-net-ccw" (i.e., only +the autogenerated virtio-net-ccw device is present) works. Specifying +several "-device virtio-net-pci" works as well. + +Things break with 1e0a84ea49b6 ("vhost-vdpa: introduce vhost-vdpa net +client"), 38140cc4d971 ("vhost_net: introduce set_config & get_config") +works (in-between state does not compile). + +This is reproducible with tcg as well. Same problem both with +--enable-vhost-vdpa and --disable-vhost-vdpa. + +Have not yet tried to figure out what might be special with +virtio-ccw... anyone have an idea? + +[This should probably be considered a blocker?] + +On Fri, Jul 24, 2020 at 03:27:18PM +0200, Cornelia Huck wrote: +> +When I start qemu with a second virtio-net-ccw device (i.e. adding +> +-device virtio-net-ccw in addition to the autogenerated device), I get +> +a segfault. gdb points to +> +> +#0 0x000055d6ab52681d in virtio_net_get_config (vdev=<optimized out>, +> +config=0x55d6ad9e3f80 "RT") at +> +/home/cohuck/git/qemu/hw/net/virtio-net.c:146 +> +146 if (nc->peer->info->type == NET_CLIENT_DRIVER_VHOST_VDPA) { +> +> +(backtrace doesn't go further) +> +> +Starting qemu with no additional "-device virtio-net-ccw" (i.e., only +> +the autogenerated virtio-net-ccw device is present) works. Specifying +> +several "-device virtio-net-pci" works as well. +> +> +Things break with 1e0a84ea49b6 ("vhost-vdpa: introduce vhost-vdpa net +> +client"), 38140cc4d971 ("vhost_net: introduce set_config & get_config") +> +works (in-between state does not compile). +Ouch. I didn't test all in-between states :( +But I wish we had a 0-day instrastructure like kernel has, +that catches things like that. + +> +This is reproducible with tcg as well. Same problem both with +> +--enable-vhost-vdpa and --disable-vhost-vdpa. +> +> +Have not yet tried to figure out what might be special with +> +virtio-ccw... anyone have an idea? +> +> +[This should probably be considered a blocker?] + +On Fri, 24 Jul 2020 09:30:58 -0400 +"Michael S. Tsirkin" <mst@redhat.com> wrote: + +> +On Fri, Jul 24, 2020 at 03:27:18PM +0200, Cornelia Huck wrote: +> +> When I start qemu with a second virtio-net-ccw device (i.e. adding +> +> -device virtio-net-ccw in addition to the autogenerated device), I get +> +> a segfault. gdb points to +> +> +> +> #0 0x000055d6ab52681d in virtio_net_get_config (vdev=<optimized out>, +> +> config=0x55d6ad9e3f80 "RT") at +> +> /home/cohuck/git/qemu/hw/net/virtio-net.c:146 +> +> 146 if (nc->peer->info->type == NET_CLIENT_DRIVER_VHOST_VDPA) { +> +> +> +> (backtrace doesn't go further) +The core was incomplete, but running under gdb directly shows that it +is just a bog-standard config space access (first for that device). + +The cause of the crash is that nc->peer is not set... no idea how that +can happen, not that familiar with that part of QEMU. (Should the code +check, or is that really something that should not happen?) + +What I don't understand is why it is set correctly for the first, +autogenerated virtio-net-ccw device, but not for the second one, and +why virtio-net-pci doesn't show these problems. The only difference +between -ccw and -pci that comes to my mind here is that config space +accesses for ccw are done via an asynchronous operation, so timing +might be different. + +> +> +> +> Starting qemu with no additional "-device virtio-net-ccw" (i.e., only +> +> the autogenerated virtio-net-ccw device is present) works. Specifying +> +> several "-device virtio-net-pci" works as well. +> +> +> +> Things break with 1e0a84ea49b6 ("vhost-vdpa: introduce vhost-vdpa net +> +> client"), 38140cc4d971 ("vhost_net: introduce set_config & get_config") +> +> works (in-between state does not compile). +> +> +Ouch. I didn't test all in-between states :( +> +But I wish we had a 0-day instrastructure like kernel has, +> +that catches things like that. +Yep, that would be useful... so patchew only builds the complete series? + +> +> +> This is reproducible with tcg as well. Same problem both with +> +> --enable-vhost-vdpa and --disable-vhost-vdpa. +> +> +> +> Have not yet tried to figure out what might be special with +> +> virtio-ccw... anyone have an idea? +> +> +> +> [This should probably be considered a blocker?] +I think so, as it makes s390x unusable with more that one +virtio-net-ccw device, and I don't even see a workaround. + +On Fri, Jul 24, 2020 at 04:56:27PM +0200, Cornelia Huck wrote: +> +On Fri, 24 Jul 2020 09:30:58 -0400 +> +"Michael S. Tsirkin" <mst@redhat.com> wrote: +> +> +> On Fri, Jul 24, 2020 at 03:27:18PM +0200, Cornelia Huck wrote: +> +> > When I start qemu with a second virtio-net-ccw device (i.e. adding +> +> > -device virtio-net-ccw in addition to the autogenerated device), I get +> +> > a segfault. gdb points to +> +> > +> +> > #0 0x000055d6ab52681d in virtio_net_get_config (vdev=<optimized out>, +> +> > config=0x55d6ad9e3f80 "RT") at +> +> > /home/cohuck/git/qemu/hw/net/virtio-net.c:146 +> +> > 146 if (nc->peer->info->type == NET_CLIENT_DRIVER_VHOST_VDPA) { +> +> > +> +> > (backtrace doesn't go further) +> +> +The core was incomplete, but running under gdb directly shows that it +> +is just a bog-standard config space access (first for that device). +> +> +The cause of the crash is that nc->peer is not set... no idea how that +> +can happen, not that familiar with that part of QEMU. (Should the code +> +check, or is that really something that should not happen?) +> +> +What I don't understand is why it is set correctly for the first, +> +autogenerated virtio-net-ccw device, but not for the second one, and +> +why virtio-net-pci doesn't show these problems. The only difference +> +between -ccw and -pci that comes to my mind here is that config space +> +accesses for ccw are done via an asynchronous operation, so timing +> +might be different. +Hopefully Jason has an idea. Could you post a full command line +please? Do you need a working guest to trigger this? Does this trigger +on an x86 host? + +> +> > +> +> > Starting qemu with no additional "-device virtio-net-ccw" (i.e., only +> +> > the autogenerated virtio-net-ccw device is present) works. Specifying +> +> > several "-device virtio-net-pci" works as well. +> +> > +> +> > Things break with 1e0a84ea49b6 ("vhost-vdpa: introduce vhost-vdpa net +> +> > client"), 38140cc4d971 ("vhost_net: introduce set_config & get_config") +> +> > works (in-between state does not compile). +> +> +> +> Ouch. I didn't test all in-between states :( +> +> But I wish we had a 0-day instrastructure like kernel has, +> +> that catches things like that. +> +> +Yep, that would be useful... so patchew only builds the complete series? +> +> +> +> +> > This is reproducible with tcg as well. Same problem both with +> +> > --enable-vhost-vdpa and --disable-vhost-vdpa. +> +> > +> +> > Have not yet tried to figure out what might be special with +> +> > virtio-ccw... anyone have an idea? +> +> > +> +> > [This should probably be considered a blocker?] +> +> +I think so, as it makes s390x unusable with more that one +> +virtio-net-ccw device, and I don't even see a workaround. + +On Fri, 24 Jul 2020 11:17:57 -0400 +"Michael S. Tsirkin" <mst@redhat.com> wrote: + +> +On Fri, Jul 24, 2020 at 04:56:27PM +0200, Cornelia Huck wrote: +> +> On Fri, 24 Jul 2020 09:30:58 -0400 +> +> "Michael S. Tsirkin" <mst@redhat.com> wrote: +> +> +> +> > On Fri, Jul 24, 2020 at 03:27:18PM +0200, Cornelia Huck wrote: +> +> > > When I start qemu with a second virtio-net-ccw device (i.e. adding +> +> > > -device virtio-net-ccw in addition to the autogenerated device), I get +> +> > > a segfault. gdb points to +> +> > > +> +> > > #0 0x000055d6ab52681d in virtio_net_get_config (vdev=<optimized out>, +> +> > > config=0x55d6ad9e3f80 "RT") at +> +> > > /home/cohuck/git/qemu/hw/net/virtio-net.c:146 +> +> > > 146 if (nc->peer->info->type == NET_CLIENT_DRIVER_VHOST_VDPA) { +> +> > > +> +> > > (backtrace doesn't go further) +> +> +> +> The core was incomplete, but running under gdb directly shows that it +> +> is just a bog-standard config space access (first for that device). +> +> +> +> The cause of the crash is that nc->peer is not set... no idea how that +> +> can happen, not that familiar with that part of QEMU. (Should the code +> +> check, or is that really something that should not happen?) +> +> +> +> What I don't understand is why it is set correctly for the first, +> +> autogenerated virtio-net-ccw device, but not for the second one, and +> +> why virtio-net-pci doesn't show these problems. The only difference +> +> between -ccw and -pci that comes to my mind here is that config space +> +> accesses for ccw are done via an asynchronous operation, so timing +> +> might be different. +> +> +Hopefully Jason has an idea. Could you post a full command line +> +please? Do you need a working guest to trigger this? Does this trigger +> +on an x86 host? +Yes, it does trigger with tcg-on-x86 as well. I've been using + +s390x-softmmu/qemu-system-s390x -M s390-ccw-virtio,accel=tcg -cpu qemu,zpci=on +-m 1024 -nographic -device virtio-scsi-ccw,id=scsi0,devno=fe.0.0001 +-drive file=/path/to/image,format=qcow2,if=none,id=drive-scsi0-0-0-0 +-device +scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 + +-device virtio-net-ccw + +It seems it needs the guest actually doing something with the nics; I +cannot reproduce the crash if I use the old advent calendar moon buggy +image and just add a virtio-net-ccw device. + +(I don't think it's a problem with my local build, as I see the problem +both on my laptop and on an LPAR.) + +> +> +> > > +> +> > > Starting qemu with no additional "-device virtio-net-ccw" (i.e., only +> +> > > the autogenerated virtio-net-ccw device is present) works. Specifying +> +> > > several "-device virtio-net-pci" works as well. +> +> > > +> +> > > Things break with 1e0a84ea49b6 ("vhost-vdpa: introduce vhost-vdpa net +> +> > > client"), 38140cc4d971 ("vhost_net: introduce set_config & get_config") +> +> > > works (in-between state does not compile). +> +> > +> +> > Ouch. I didn't test all in-between states :( +> +> > But I wish we had a 0-day instrastructure like kernel has, +> +> > that catches things like that. +> +> +> +> Yep, that would be useful... so patchew only builds the complete series? +> +> +> +> > +> +> > > This is reproducible with tcg as well. Same problem both with +> +> > > --enable-vhost-vdpa and --disable-vhost-vdpa. +> +> > > +> +> > > Have not yet tried to figure out what might be special with +> +> > > virtio-ccw... anyone have an idea? +> +> > > +> +> > > [This should probably be considered a blocker?] +> +> +> +> I think so, as it makes s390x unusable with more that one +> +> virtio-net-ccw device, and I don't even see a workaround. +> + +On 2020/7/24 ä¸å11:34, Cornelia Huck wrote: +On Fri, 24 Jul 2020 11:17:57 -0400 +"Michael S. Tsirkin"<mst@redhat.com> wrote: +On Fri, Jul 24, 2020 at 04:56:27PM +0200, Cornelia Huck wrote: +On Fri, 24 Jul 2020 09:30:58 -0400 +"Michael S. Tsirkin"<mst@redhat.com> wrote: +On Fri, Jul 24, 2020 at 03:27:18PM +0200, Cornelia Huck wrote: +When I start qemu with a second virtio-net-ccw device (i.e. adding +-device virtio-net-ccw in addition to the autogenerated device), I get +a segfault. gdb points to + +#0 0x000055d6ab52681d in virtio_net_get_config (vdev=<optimized out>, + config=0x55d6ad9e3f80 "RT") at +/home/cohuck/git/qemu/hw/net/virtio-net.c:146 +146 if (nc->peer->info->type == NET_CLIENT_DRIVER_VHOST_VDPA) { + +(backtrace doesn't go further) +The core was incomplete, but running under gdb directly shows that it +is just a bog-standard config space access (first for that device). + +The cause of the crash is that nc->peer is not set... no idea how that +can happen, not that familiar with that part of QEMU. (Should the code +check, or is that really something that should not happen?) + +What I don't understand is why it is set correctly for the first, +autogenerated virtio-net-ccw device, but not for the second one, and +why virtio-net-pci doesn't show these problems. The only difference +between -ccw and -pci that comes to my mind here is that config space +accesses for ccw are done via an asynchronous operation, so timing +might be different. +Hopefully Jason has an idea. Could you post a full command line +please? Do you need a working guest to trigger this? Does this trigger +on an x86 host? +Yes, it does trigger with tcg-on-x86 as well. I've been using + +s390x-softmmu/qemu-system-s390x -M s390-ccw-virtio,accel=tcg -cpu qemu,zpci=on +-m 1024 -nographic -device virtio-scsi-ccw,id=scsi0,devno=fe.0.0001 +-drive file=/path/to/image,format=qcow2,if=none,id=drive-scsi0-0-0-0 +-device +scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 +-device virtio-net-ccw + +It seems it needs the guest actually doing something with the nics; I +cannot reproduce the crash if I use the old advent calendar moon buggy +image and just add a virtio-net-ccw device. + +(I don't think it's a problem with my local build, as I see the problem +both on my laptop and on an LPAR.) +It looks to me we forget the check the existence of peer. + +Please try the attached patch to see if it works. + +Thanks +0001-virtio-net-check-the-existence-of-peer-before-accesi.patch +Description: +Text Data + +On Sat, 25 Jul 2020 08:40:07 +0800 +Jason Wang <jasowang@redhat.com> wrote: + +> +On 2020/7/24 ä¸å11:34, Cornelia Huck wrote: +> +> On Fri, 24 Jul 2020 11:17:57 -0400 +> +> "Michael S. Tsirkin"<mst@redhat.com> wrote: +> +> +> +>> On Fri, Jul 24, 2020 at 04:56:27PM +0200, Cornelia Huck wrote: +> +>>> On Fri, 24 Jul 2020 09:30:58 -0400 +> +>>> "Michael S. Tsirkin"<mst@redhat.com> wrote: +> +>>> +> +>>>> On Fri, Jul 24, 2020 at 03:27:18PM +0200, Cornelia Huck wrote: +> +>>>>> When I start qemu with a second virtio-net-ccw device (i.e. adding +> +>>>>> -device virtio-net-ccw in addition to the autogenerated device), I get +> +>>>>> a segfault. gdb points to +> +>>>>> +> +>>>>> #0 0x000055d6ab52681d in virtio_net_get_config (vdev=<optimized out>, +> +>>>>> config=0x55d6ad9e3f80 "RT") at +> +>>>>> /home/cohuck/git/qemu/hw/net/virtio-net.c:146 +> +>>>>> 146 if (nc->peer->info->type == NET_CLIENT_DRIVER_VHOST_VDPA) { +> +>>>>> +> +>>>>> (backtrace doesn't go further) +> +>>> The core was incomplete, but running under gdb directly shows that it +> +>>> is just a bog-standard config space access (first for that device). +> +>>> +> +>>> The cause of the crash is that nc->peer is not set... no idea how that +> +>>> can happen, not that familiar with that part of QEMU. (Should the code +> +>>> check, or is that really something that should not happen?) +> +>>> +> +>>> What I don't understand is why it is set correctly for the first, +> +>>> autogenerated virtio-net-ccw device, but not for the second one, and +> +>>> why virtio-net-pci doesn't show these problems. The only difference +> +>>> between -ccw and -pci that comes to my mind here is that config space +> +>>> accesses for ccw are done via an asynchronous operation, so timing +> +>>> might be different. +> +>> Hopefully Jason has an idea. Could you post a full command line +> +>> please? Do you need a working guest to trigger this? Does this trigger +> +>> on an x86 host? +> +> Yes, it does trigger with tcg-on-x86 as well. I've been using +> +> +> +> s390x-softmmu/qemu-system-s390x -M s390-ccw-virtio,accel=tcg -cpu +> +> qemu,zpci=on +> +> -m 1024 -nographic -device virtio-scsi-ccw,id=scsi0,devno=fe.0.0001 +> +> -drive file=/path/to/image,format=qcow2,if=none,id=drive-scsi0-0-0-0 +> +> -device +> +> scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 +> +> -device virtio-net-ccw +> +> +> +> It seems it needs the guest actually doing something with the nics; I +> +> cannot reproduce the crash if I use the old advent calendar moon buggy +> +> image and just add a virtio-net-ccw device. +> +> +> +> (I don't think it's a problem with my local build, as I see the problem +> +> both on my laptop and on an LPAR.) +> +> +> +It looks to me we forget the check the existence of peer. +> +> +Please try the attached patch to see if it works. +Thanks, that patch gets my guest up and running again. So, FWIW, + +Tested-by: Cornelia Huck <cohuck@redhat.com> + +Any idea why this did not hit with virtio-net-pci (or the autogenerated +virtio-net-ccw device)? + +On 2020/7/27 ä¸å2:43, Cornelia Huck wrote: +On Sat, 25 Jul 2020 08:40:07 +0800 +Jason Wang <jasowang@redhat.com> wrote: +On 2020/7/24 ä¸å11:34, Cornelia Huck wrote: +On Fri, 24 Jul 2020 11:17:57 -0400 +"Michael S. Tsirkin"<mst@redhat.com> wrote: +On Fri, Jul 24, 2020 at 04:56:27PM +0200, Cornelia Huck wrote: +On Fri, 24 Jul 2020 09:30:58 -0400 +"Michael S. Tsirkin"<mst@redhat.com> wrote: +On Fri, Jul 24, 2020 at 03:27:18PM +0200, Cornelia Huck wrote: +When I start qemu with a second virtio-net-ccw device (i.e. adding +-device virtio-net-ccw in addition to the autogenerated device), I get +a segfault. gdb points to + +#0 0x000055d6ab52681d in virtio_net_get_config (vdev=<optimized out>, + config=0x55d6ad9e3f80 "RT") at +/home/cohuck/git/qemu/hw/net/virtio-net.c:146 +146 if (nc->peer->info->type == NET_CLIENT_DRIVER_VHOST_VDPA) { + +(backtrace doesn't go further) +The core was incomplete, but running under gdb directly shows that it +is just a bog-standard config space access (first for that device). + +The cause of the crash is that nc->peer is not set... no idea how that +can happen, not that familiar with that part of QEMU. (Should the code +check, or is that really something that should not happen?) + +What I don't understand is why it is set correctly for the first, +autogenerated virtio-net-ccw device, but not for the second one, and +why virtio-net-pci doesn't show these problems. The only difference +between -ccw and -pci that comes to my mind here is that config space +accesses for ccw are done via an asynchronous operation, so timing +might be different. +Hopefully Jason has an idea. Could you post a full command line +please? Do you need a working guest to trigger this? Does this trigger +on an x86 host? +Yes, it does trigger with tcg-on-x86 as well. I've been using + +s390x-softmmu/qemu-system-s390x -M s390-ccw-virtio,accel=tcg -cpu qemu,zpci=on +-m 1024 -nographic -device virtio-scsi-ccw,id=scsi0,devno=fe.0.0001 +-drive file=/path/to/image,format=qcow2,if=none,id=drive-scsi0-0-0-0 +-device +scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 +-device virtio-net-ccw + +It seems it needs the guest actually doing something with the nics; I +cannot reproduce the crash if I use the old advent calendar moon buggy +image and just add a virtio-net-ccw device. + +(I don't think it's a problem with my local build, as I see the problem +both on my laptop and on an LPAR.) +It looks to me we forget the check the existence of peer. + +Please try the attached patch to see if it works. +Thanks, that patch gets my guest up and running again. So, FWIW, + +Tested-by: Cornelia Huck <cohuck@redhat.com> + +Any idea why this did not hit with virtio-net-pci (or the autogenerated +virtio-net-ccw device)? +It can be hit with virtio-net-pci as well (just start without peer). +For autogenerated virtio-net-cww, I think the reason is that it has +already had a peer set. +Thanks + +On Mon, 27 Jul 2020 15:38:12 +0800 +Jason Wang <jasowang@redhat.com> wrote: + +> +On 2020/7/27 ä¸å2:43, Cornelia Huck wrote: +> +> On Sat, 25 Jul 2020 08:40:07 +0800 +> +> Jason Wang <jasowang@redhat.com> wrote: +> +> +> +>> On 2020/7/24 ä¸å11:34, Cornelia Huck wrote: +> +>>> On Fri, 24 Jul 2020 11:17:57 -0400 +> +>>> "Michael S. Tsirkin"<mst@redhat.com> wrote: +> +>>> +> +>>>> On Fri, Jul 24, 2020 at 04:56:27PM +0200, Cornelia Huck wrote: +> +>>>>> On Fri, 24 Jul 2020 09:30:58 -0400 +> +>>>>> "Michael S. Tsirkin"<mst@redhat.com> wrote: +> +>>>>> +> +>>>>>> On Fri, Jul 24, 2020 at 03:27:18PM +0200, Cornelia Huck wrote: +> +>>>>>>> When I start qemu with a second virtio-net-ccw device (i.e. adding +> +>>>>>>> -device virtio-net-ccw in addition to the autogenerated device), I get +> +>>>>>>> a segfault. gdb points to +> +>>>>>>> +> +>>>>>>> #0 0x000055d6ab52681d in virtio_net_get_config (vdev=<optimized out>, +> +>>>>>>> config=0x55d6ad9e3f80 "RT") at +> +>>>>>>> /home/cohuck/git/qemu/hw/net/virtio-net.c:146 +> +>>>>>>> 146 if (nc->peer->info->type == NET_CLIENT_DRIVER_VHOST_VDPA) { +> +>>>>>>> +> +>>>>>>> (backtrace doesn't go further) +> +>>>>> The core was incomplete, but running under gdb directly shows that it +> +>>>>> is just a bog-standard config space access (first for that device). +> +>>>>> +> +>>>>> The cause of the crash is that nc->peer is not set... no idea how that +> +>>>>> can happen, not that familiar with that part of QEMU. (Should the code +> +>>>>> check, or is that really something that should not happen?) +> +>>>>> +> +>>>>> What I don't understand is why it is set correctly for the first, +> +>>>>> autogenerated virtio-net-ccw device, but not for the second one, and +> +>>>>> why virtio-net-pci doesn't show these problems. The only difference +> +>>>>> between -ccw and -pci that comes to my mind here is that config space +> +>>>>> accesses for ccw are done via an asynchronous operation, so timing +> +>>>>> might be different. +> +>>>> Hopefully Jason has an idea. Could you post a full command line +> +>>>> please? Do you need a working guest to trigger this? Does this trigger +> +>>>> on an x86 host? +> +>>> Yes, it does trigger with tcg-on-x86 as well. I've been using +> +>>> +> +>>> s390x-softmmu/qemu-system-s390x -M s390-ccw-virtio,accel=tcg -cpu +> +>>> qemu,zpci=on +> +>>> -m 1024 -nographic -device virtio-scsi-ccw,id=scsi0,devno=fe.0.0001 +> +>>> -drive file=/path/to/image,format=qcow2,if=none,id=drive-scsi0-0-0-0 +> +>>> -device +> +>>> scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 +> +>>> -device virtio-net-ccw +> +>>> +> +>>> It seems it needs the guest actually doing something with the nics; I +> +>>> cannot reproduce the crash if I use the old advent calendar moon buggy +> +>>> image and just add a virtio-net-ccw device. +> +>>> +> +>>> (I don't think it's a problem with my local build, as I see the problem +> +>>> both on my laptop and on an LPAR.) +> +>> +> +>> It looks to me we forget the check the existence of peer. +> +>> +> +>> Please try the attached patch to see if it works. +> +> Thanks, that patch gets my guest up and running again. So, FWIW, +> +> +> +> Tested-by: Cornelia Huck <cohuck@redhat.com> +> +> +> +> Any idea why this did not hit with virtio-net-pci (or the autogenerated +> +> virtio-net-ccw device)? +> +> +> +It can be hit with virtio-net-pci as well (just start without peer). +Hm, I had not been able to reproduce the crash with a 'naked' -device +virtio-net-pci. But checking seems to be the right idea anyway. + +> +> +For autogenerated virtio-net-cww, I think the reason is that it has +> +already had a peer set. +Ok, that might well be. + +On 2020/7/27 ä¸å4:41, Cornelia Huck wrote: +On Mon, 27 Jul 2020 15:38:12 +0800 +Jason Wang <jasowang@redhat.com> wrote: +On 2020/7/27 ä¸å2:43, Cornelia Huck wrote: +On Sat, 25 Jul 2020 08:40:07 +0800 +Jason Wang <jasowang@redhat.com> wrote: +On 2020/7/24 ä¸å11:34, Cornelia Huck wrote: +On Fri, 24 Jul 2020 11:17:57 -0400 +"Michael S. Tsirkin"<mst@redhat.com> wrote: +On Fri, Jul 24, 2020 at 04:56:27PM +0200, Cornelia Huck wrote: +On Fri, 24 Jul 2020 09:30:58 -0400 +"Michael S. Tsirkin"<mst@redhat.com> wrote: +On Fri, Jul 24, 2020 at 03:27:18PM +0200, Cornelia Huck wrote: +When I start qemu with a second virtio-net-ccw device (i.e. adding +-device virtio-net-ccw in addition to the autogenerated device), I get +a segfault. gdb points to + +#0 0x000055d6ab52681d in virtio_net_get_config (vdev=<optimized out>, + config=0x55d6ad9e3f80 "RT") at +/home/cohuck/git/qemu/hw/net/virtio-net.c:146 +146 if (nc->peer->info->type == NET_CLIENT_DRIVER_VHOST_VDPA) { + +(backtrace doesn't go further) +The core was incomplete, but running under gdb directly shows that it +is just a bog-standard config space access (first for that device). + +The cause of the crash is that nc->peer is not set... no idea how that +can happen, not that familiar with that part of QEMU. (Should the code +check, or is that really something that should not happen?) + +What I don't understand is why it is set correctly for the first, +autogenerated virtio-net-ccw device, but not for the second one, and +why virtio-net-pci doesn't show these problems. The only difference +between -ccw and -pci that comes to my mind here is that config space +accesses for ccw are done via an asynchronous operation, so timing +might be different. +Hopefully Jason has an idea. Could you post a full command line +please? Do you need a working guest to trigger this? Does this trigger +on an x86 host? +Yes, it does trigger with tcg-on-x86 as well. I've been using + +s390x-softmmu/qemu-system-s390x -M s390-ccw-virtio,accel=tcg -cpu qemu,zpci=on +-m 1024 -nographic -device virtio-scsi-ccw,id=scsi0,devno=fe.0.0001 +-drive file=/path/to/image,format=qcow2,if=none,id=drive-scsi0-0-0-0 +-device +scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 +-device virtio-net-ccw + +It seems it needs the guest actually doing something with the nics; I +cannot reproduce the crash if I use the old advent calendar moon buggy +image and just add a virtio-net-ccw device. + +(I don't think it's a problem with my local build, as I see the problem +both on my laptop and on an LPAR.) +It looks to me we forget the check the existence of peer. + +Please try the attached patch to see if it works. +Thanks, that patch gets my guest up and running again. So, FWIW, + +Tested-by: Cornelia Huck <cohuck@redhat.com> + +Any idea why this did not hit with virtio-net-pci (or the autogenerated +virtio-net-ccw device)? +It can be hit with virtio-net-pci as well (just start without peer). +Hm, I had not been able to reproduce the crash with a 'naked' -device +virtio-net-pci. But checking seems to be the right idea anyway. +Sorry for being unclear, I meant for networking part, you just need +start without peer, and you need a real guest (any Linux) that is trying +to access the config space of virtio-net. +Thanks +For autogenerated virtio-net-cww, I think the reason is that it has +already had a peer set. +Ok, that might well be. + +On Mon, Jul 27, 2020 at 04:51:23PM +0800, Jason Wang wrote: +> +> +On 2020/7/27 ä¸å4:41, Cornelia Huck wrote: +> +> On Mon, 27 Jul 2020 15:38:12 +0800 +> +> Jason Wang <jasowang@redhat.com> wrote: +> +> +> +> > On 2020/7/27 ä¸å2:43, Cornelia Huck wrote: +> +> > > On Sat, 25 Jul 2020 08:40:07 +0800 +> +> > > Jason Wang <jasowang@redhat.com> wrote: +> +> > > > On 2020/7/24 ä¸å11:34, Cornelia Huck wrote: +> +> > > > > On Fri, 24 Jul 2020 11:17:57 -0400 +> +> > > > > "Michael S. Tsirkin"<mst@redhat.com> wrote: +> +> > > > > > On Fri, Jul 24, 2020 at 04:56:27PM +0200, Cornelia Huck wrote: +> +> > > > > > > On Fri, 24 Jul 2020 09:30:58 -0400 +> +> > > > > > > "Michael S. Tsirkin"<mst@redhat.com> wrote: +> +> > > > > > > > On Fri, Jul 24, 2020 at 03:27:18PM +0200, Cornelia Huck wrote: +> +> > > > > > > > > When I start qemu with a second virtio-net-ccw device (i.e. +> +> > > > > > > > > adding +> +> > > > > > > > > -device virtio-net-ccw in addition to the autogenerated +> +> > > > > > > > > device), I get +> +> > > > > > > > > a segfault. gdb points to +> +> > > > > > > > > +> +> > > > > > > > > #0 0x000055d6ab52681d in virtio_net_get_config +> +> > > > > > > > > (vdev=<optimized out>, +> +> > > > > > > > > config=0x55d6ad9e3f80 "RT") at +> +> > > > > > > > > /home/cohuck/git/qemu/hw/net/virtio-net.c:146 +> +> > > > > > > > > 146 if (nc->peer->info->type == +> +> > > > > > > > > NET_CLIENT_DRIVER_VHOST_VDPA) { +> +> > > > > > > > > +> +> > > > > > > > > (backtrace doesn't go further) +> +> > > > > > > The core was incomplete, but running under gdb directly shows +> +> > > > > > > that it +> +> > > > > > > is just a bog-standard config space access (first for that +> +> > > > > > > device). +> +> > > > > > > +> +> > > > > > > The cause of the crash is that nc->peer is not set... no idea +> +> > > > > > > how that +> +> > > > > > > can happen, not that familiar with that part of QEMU. (Should +> +> > > > > > > the code +> +> > > > > > > check, or is that really something that should not happen?) +> +> > > > > > > +> +> > > > > > > What I don't understand is why it is set correctly for the +> +> > > > > > > first, +> +> > > > > > > autogenerated virtio-net-ccw device, but not for the second +> +> > > > > > > one, and +> +> > > > > > > why virtio-net-pci doesn't show these problems. The only +> +> > > > > > > difference +> +> > > > > > > between -ccw and -pci that comes to my mind here is that config +> +> > > > > > > space +> +> > > > > > > accesses for ccw are done via an asynchronous operation, so +> +> > > > > > > timing +> +> > > > > > > might be different. +> +> > > > > > Hopefully Jason has an idea. Could you post a full command line +> +> > > > > > please? Do you need a working guest to trigger this? Does this +> +> > > > > > trigger +> +> > > > > > on an x86 host? +> +> > > > > Yes, it does trigger with tcg-on-x86 as well. I've been using +> +> > > > > +> +> > > > > s390x-softmmu/qemu-system-s390x -M s390-ccw-virtio,accel=tcg -cpu +> +> > > > > qemu,zpci=on +> +> > > > > -m 1024 -nographic -device virtio-scsi-ccw,id=scsi0,devno=fe.0.0001 +> +> > > > > -drive file=/path/to/image,format=qcow2,if=none,id=drive-scsi0-0-0-0 +> +> > > > > -device +> +> > > > > scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 +> +> > > > > -device virtio-net-ccw +> +> > > > > +> +> > > > > It seems it needs the guest actually doing something with the nics; +> +> > > > > I +> +> > > > > cannot reproduce the crash if I use the old advent calendar moon +> +> > > > > buggy +> +> > > > > image and just add a virtio-net-ccw device. +> +> > > > > +> +> > > > > (I don't think it's a problem with my local build, as I see the +> +> > > > > problem +> +> > > > > both on my laptop and on an LPAR.) +> +> > > > It looks to me we forget the check the existence of peer. +> +> > > > +> +> > > > Please try the attached patch to see if it works. +> +> > > Thanks, that patch gets my guest up and running again. So, FWIW, +> +> > > +> +> > > Tested-by: Cornelia Huck <cohuck@redhat.com> +> +> > > +> +> > > Any idea why this did not hit with virtio-net-pci (or the autogenerated +> +> > > virtio-net-ccw device)? +> +> > +> +> > It can be hit with virtio-net-pci as well (just start without peer). +> +> Hm, I had not been able to reproduce the crash with a 'naked' -device +> +> virtio-net-pci. But checking seems to be the right idea anyway. +> +> +> +Sorry for being unclear, I meant for networking part, you just need start +> +without peer, and you need a real guest (any Linux) that is trying to access +> +the config space of virtio-net. +> +> +Thanks +A pxe guest will do it, but that doesn't support ccw, right? + +I'm still unclear why this triggers with ccw but not pci - +any idea? + +> +> +> +> +> > For autogenerated virtio-net-cww, I think the reason is that it has +> +> > already had a peer set. +> +> Ok, that might well be. +> +> +> +> + +On 2020/7/27 ä¸å7:43, Michael S. Tsirkin wrote: +On Mon, Jul 27, 2020 at 04:51:23PM +0800, Jason Wang wrote: +On 2020/7/27 ä¸å4:41, Cornelia Huck wrote: +On Mon, 27 Jul 2020 15:38:12 +0800 +Jason Wang<jasowang@redhat.com> wrote: +On 2020/7/27 ä¸å2:43, Cornelia Huck wrote: +On Sat, 25 Jul 2020 08:40:07 +0800 +Jason Wang<jasowang@redhat.com> wrote: +On 2020/7/24 ä¸å11:34, Cornelia Huck wrote: +On Fri, 24 Jul 2020 11:17:57 -0400 +"Michael S. Tsirkin"<mst@redhat.com> wrote: +On Fri, Jul 24, 2020 at 04:56:27PM +0200, Cornelia Huck wrote: +On Fri, 24 Jul 2020 09:30:58 -0400 +"Michael S. Tsirkin"<mst@redhat.com> wrote: +On Fri, Jul 24, 2020 at 03:27:18PM +0200, Cornelia Huck wrote: +When I start qemu with a second virtio-net-ccw device (i.e. adding +-device virtio-net-ccw in addition to the autogenerated device), I get +a segfault. gdb points to + +#0 0x000055d6ab52681d in virtio_net_get_config (vdev=<optimized out>, + config=0x55d6ad9e3f80 "RT") at +/home/cohuck/git/qemu/hw/net/virtio-net.c:146 +146 if (nc->peer->info->type == NET_CLIENT_DRIVER_VHOST_VDPA) { + +(backtrace doesn't go further) +The core was incomplete, but running under gdb directly shows that it +is just a bog-standard config space access (first for that device). + +The cause of the crash is that nc->peer is not set... no idea how that +can happen, not that familiar with that part of QEMU. (Should the code +check, or is that really something that should not happen?) + +What I don't understand is why it is set correctly for the first, +autogenerated virtio-net-ccw device, but not for the second one, and +why virtio-net-pci doesn't show these problems. The only difference +between -ccw and -pci that comes to my mind here is that config space +accesses for ccw are done via an asynchronous operation, so timing +might be different. +Hopefully Jason has an idea. Could you post a full command line +please? Do you need a working guest to trigger this? Does this trigger +on an x86 host? +Yes, it does trigger with tcg-on-x86 as well. I've been using + +s390x-softmmu/qemu-system-s390x -M s390-ccw-virtio,accel=tcg -cpu qemu,zpci=on +-m 1024 -nographic -device virtio-scsi-ccw,id=scsi0,devno=fe.0.0001 +-drive file=/path/to/image,format=qcow2,if=none,id=drive-scsi0-0-0-0 +-device +scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 +-device virtio-net-ccw + +It seems it needs the guest actually doing something with the nics; I +cannot reproduce the crash if I use the old advent calendar moon buggy +image and just add a virtio-net-ccw device. + +(I don't think it's a problem with my local build, as I see the problem +both on my laptop and on an LPAR.) +It looks to me we forget the check the existence of peer. + +Please try the attached patch to see if it works. +Thanks, that patch gets my guest up and running again. So, FWIW, + +Tested-by: Cornelia Huck<cohuck@redhat.com> + +Any idea why this did not hit with virtio-net-pci (or the autogenerated +virtio-net-ccw device)? +It can be hit with virtio-net-pci as well (just start without peer). +Hm, I had not been able to reproduce the crash with a 'naked' -device +virtio-net-pci. But checking seems to be the right idea anyway. +Sorry for being unclear, I meant for networking part, you just need start +without peer, and you need a real guest (any Linux) that is trying to access +the config space of virtio-net. + +Thanks +A pxe guest will do it, but that doesn't support ccw, right? +Yes, it depends on the cli actually. +I'm still unclear why this triggers with ccw but not pci - +any idea? +I don't test pxe but I can reproduce this with pci (just start a linux +guest without a peer). +Thanks + +On Mon, Jul 27, 2020 at 08:44:09PM +0800, Jason Wang wrote: +> +> +On 2020/7/27 ä¸å7:43, Michael S. Tsirkin wrote: +> +> On Mon, Jul 27, 2020 at 04:51:23PM +0800, Jason Wang wrote: +> +> > On 2020/7/27 ä¸å4:41, Cornelia Huck wrote: +> +> > > On Mon, 27 Jul 2020 15:38:12 +0800 +> +> > > Jason Wang<jasowang@redhat.com> wrote: +> +> > > +> +> > > > On 2020/7/27 ä¸å2:43, Cornelia Huck wrote: +> +> > > > > On Sat, 25 Jul 2020 08:40:07 +0800 +> +> > > > > Jason Wang<jasowang@redhat.com> wrote: +> +> > > > > > On 2020/7/24 ä¸å11:34, Cornelia Huck wrote: +> +> > > > > > > On Fri, 24 Jul 2020 11:17:57 -0400 +> +> > > > > > > "Michael S. Tsirkin"<mst@redhat.com> wrote: +> +> > > > > > > > On Fri, Jul 24, 2020 at 04:56:27PM +0200, Cornelia Huck wrote: +> +> > > > > > > > > On Fri, 24 Jul 2020 09:30:58 -0400 +> +> > > > > > > > > "Michael S. Tsirkin"<mst@redhat.com> wrote: +> +> > > > > > > > > > On Fri, Jul 24, 2020 at 03:27:18PM +0200, Cornelia Huck +> +> > > > > > > > > > wrote: +> +> > > > > > > > > > > When I start qemu with a second virtio-net-ccw device +> +> > > > > > > > > > > (i.e. adding +> +> > > > > > > > > > > -device virtio-net-ccw in addition to the autogenerated +> +> > > > > > > > > > > device), I get +> +> > > > > > > > > > > a segfault. gdb points to +> +> > > > > > > > > > > +> +> > > > > > > > > > > #0 0x000055d6ab52681d in virtio_net_get_config +> +> > > > > > > > > > > (vdev=<optimized out>, +> +> > > > > > > > > > > config=0x55d6ad9e3f80 "RT") at +> +> > > > > > > > > > > /home/cohuck/git/qemu/hw/net/virtio-net.c:146 +> +> > > > > > > > > > > 146 if (nc->peer->info->type == +> +> > > > > > > > > > > NET_CLIENT_DRIVER_VHOST_VDPA) { +> +> > > > > > > > > > > +> +> > > > > > > > > > > (backtrace doesn't go further) +> +> > > > > > > > > The core was incomplete, but running under gdb directly +> +> > > > > > > > > shows that it +> +> > > > > > > > > is just a bog-standard config space access (first for that +> +> > > > > > > > > device). +> +> > > > > > > > > +> +> > > > > > > > > The cause of the crash is that nc->peer is not set... no +> +> > > > > > > > > idea how that +> +> > > > > > > > > can happen, not that familiar with that part of QEMU. +> +> > > > > > > > > (Should the code +> +> > > > > > > > > check, or is that really something that should not happen?) +> +> > > > > > > > > +> +> > > > > > > > > What I don't understand is why it is set correctly for the +> +> > > > > > > > > first, +> +> > > > > > > > > autogenerated virtio-net-ccw device, but not for the second +> +> > > > > > > > > one, and +> +> > > > > > > > > why virtio-net-pci doesn't show these problems. The only +> +> > > > > > > > > difference +> +> > > > > > > > > between -ccw and -pci that comes to my mind here is that +> +> > > > > > > > > config space +> +> > > > > > > > > accesses for ccw are done via an asynchronous operation, so +> +> > > > > > > > > timing +> +> > > > > > > > > might be different. +> +> > > > > > > > Hopefully Jason has an idea. Could you post a full command +> +> > > > > > > > line +> +> > > > > > > > please? Do you need a working guest to trigger this? Does +> +> > > > > > > > this trigger +> +> > > > > > > > on an x86 host? +> +> > > > > > > Yes, it does trigger with tcg-on-x86 as well. I've been using +> +> > > > > > > +> +> > > > > > > s390x-softmmu/qemu-system-s390x -M s390-ccw-virtio,accel=tcg +> +> > > > > > > -cpu qemu,zpci=on +> +> > > > > > > -m 1024 -nographic -device +> +> > > > > > > virtio-scsi-ccw,id=scsi0,devno=fe.0.0001 +> +> > > > > > > -drive +> +> > > > > > > file=/path/to/image,format=qcow2,if=none,id=drive-scsi0-0-0-0 +> +> > > > > > > -device +> +> > > > > > > scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 +> +> > > > > > > -device virtio-net-ccw +> +> > > > > > > +> +> > > > > > > It seems it needs the guest actually doing something with the +> +> > > > > > > nics; I +> +> > > > > > > cannot reproduce the crash if I use the old advent calendar +> +> > > > > > > moon buggy +> +> > > > > > > image and just add a virtio-net-ccw device. +> +> > > > > > > +> +> > > > > > > (I don't think it's a problem with my local build, as I see the +> +> > > > > > > problem +> +> > > > > > > both on my laptop and on an LPAR.) +> +> > > > > > It looks to me we forget the check the existence of peer. +> +> > > > > > +> +> > > > > > Please try the attached patch to see if it works. +> +> > > > > Thanks, that patch gets my guest up and running again. So, FWIW, +> +> > > > > +> +> > > > > Tested-by: Cornelia Huck<cohuck@redhat.com> +> +> > > > > +> +> > > > > Any idea why this did not hit with virtio-net-pci (or the +> +> > > > > autogenerated +> +> > > > > virtio-net-ccw device)? +> +> > > > It can be hit with virtio-net-pci as well (just start without peer). +> +> > > Hm, I had not been able to reproduce the crash with a 'naked' -device +> +> > > virtio-net-pci. But checking seems to be the right idea anyway. +> +> > Sorry for being unclear, I meant for networking part, you just need start +> +> > without peer, and you need a real guest (any Linux) that is trying to +> +> > access +> +> > the config space of virtio-net. +> +> > +> +> > Thanks +> +> A pxe guest will do it, but that doesn't support ccw, right? +> +> +> +Yes, it depends on the cli actually. +> +> +> +> +> +> I'm still unclear why this triggers with ccw but not pci - +> +> any idea? +> +> +> +I don't test pxe but I can reproduce this with pci (just start a linux guest +> +without a peer). +> +> +Thanks +> +Might be a good addition to a unit test. Not sure what would the +test do exactly: just make sure guest runs? Looks like a lot of work +for an empty test ... maybe we can poke at the guest config with +qtest commands at least. + +-- +MST + +On 2020/7/27 ä¸å9:16, Michael S. Tsirkin wrote: +On Mon, Jul 27, 2020 at 08:44:09PM +0800, Jason Wang wrote: +On 2020/7/27 ä¸å7:43, Michael S. Tsirkin wrote: +On Mon, Jul 27, 2020 at 04:51:23PM +0800, Jason Wang wrote: +On 2020/7/27 ä¸å4:41, Cornelia Huck wrote: +On Mon, 27 Jul 2020 15:38:12 +0800 +Jason Wang<jasowang@redhat.com> wrote: +On 2020/7/27 ä¸å2:43, Cornelia Huck wrote: +On Sat, 25 Jul 2020 08:40:07 +0800 +Jason Wang<jasowang@redhat.com> wrote: +On 2020/7/24 ä¸å11:34, Cornelia Huck wrote: +On Fri, 24 Jul 2020 11:17:57 -0400 +"Michael S. Tsirkin"<mst@redhat.com> wrote: +On Fri, Jul 24, 2020 at 04:56:27PM +0200, Cornelia Huck wrote: +On Fri, 24 Jul 2020 09:30:58 -0400 +"Michael S. Tsirkin"<mst@redhat.com> wrote: +On Fri, Jul 24, 2020 at 03:27:18PM +0200, Cornelia Huck wrote: +When I start qemu with a second virtio-net-ccw device (i.e. adding +-device virtio-net-ccw in addition to the autogenerated device), I get +a segfault. gdb points to + +#0 0x000055d6ab52681d in virtio_net_get_config (vdev=<optimized out>, + config=0x55d6ad9e3f80 "RT") at +/home/cohuck/git/qemu/hw/net/virtio-net.c:146 +146 if (nc->peer->info->type == NET_CLIENT_DRIVER_VHOST_VDPA) { + +(backtrace doesn't go further) +The core was incomplete, but running under gdb directly shows that it +is just a bog-standard config space access (first for that device). + +The cause of the crash is that nc->peer is not set... no idea how that +can happen, not that familiar with that part of QEMU. (Should the code +check, or is that really something that should not happen?) + +What I don't understand is why it is set correctly for the first, +autogenerated virtio-net-ccw device, but not for the second one, and +why virtio-net-pci doesn't show these problems. The only difference +between -ccw and -pci that comes to my mind here is that config space +accesses for ccw are done via an asynchronous operation, so timing +might be different. +Hopefully Jason has an idea. Could you post a full command line +please? Do you need a working guest to trigger this? Does this trigger +on an x86 host? +Yes, it does trigger with tcg-on-x86 as well. I've been using + +s390x-softmmu/qemu-system-s390x -M s390-ccw-virtio,accel=tcg -cpu qemu,zpci=on +-m 1024 -nographic -device virtio-scsi-ccw,id=scsi0,devno=fe.0.0001 +-drive file=/path/to/image,format=qcow2,if=none,id=drive-scsi0-0-0-0 +-device +scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 +-device virtio-net-ccw + +It seems it needs the guest actually doing something with the nics; I +cannot reproduce the crash if I use the old advent calendar moon buggy +image and just add a virtio-net-ccw device. + +(I don't think it's a problem with my local build, as I see the problem +both on my laptop and on an LPAR.) +It looks to me we forget the check the existence of peer. + +Please try the attached patch to see if it works. +Thanks, that patch gets my guest up and running again. So, FWIW, + +Tested-by: Cornelia Huck<cohuck@redhat.com> + +Any idea why this did not hit with virtio-net-pci (or the autogenerated +virtio-net-ccw device)? +It can be hit with virtio-net-pci as well (just start without peer). +Hm, I had not been able to reproduce the crash with a 'naked' -device +virtio-net-pci. But checking seems to be the right idea anyway. +Sorry for being unclear, I meant for networking part, you just need start +without peer, and you need a real guest (any Linux) that is trying to access +the config space of virtio-net. + +Thanks +A pxe guest will do it, but that doesn't support ccw, right? +Yes, it depends on the cli actually. +I'm still unclear why this triggers with ccw but not pci - +any idea? +I don't test pxe but I can reproduce this with pci (just start a linux guest +without a peer). + +Thanks +Might be a good addition to a unit test. Not sure what would the +test do exactly: just make sure guest runs? Looks like a lot of work +for an empty test ... maybe we can poke at the guest config with +qtest commands at least. +That should work or we can simply extend the exist virtio-net qtest to +do that. +Thanks + diff --git a/results/classifier/105/mistranslation/814 b/results/classifier/105/mistranslation/814 new file mode 100644 index 000000000..43d4aed65 --- /dev/null +++ b/results/classifier/105/mistranslation/814 @@ -0,0 +1,50 @@ +mistranslation: 0.857 +instruction: 0.826 +graphic: 0.824 +other: 0.814 +assembly: 0.800 +device: 0.787 +semantic: 0.785 +network: 0.773 +socket: 0.772 +KVM: 0.746 +boot: 0.745 +vnc: 0.743 + +On Windows, qcow2 is corrupted on expansion +Description of problem: +On Windows, the qcow2 loses blocks on account of which the filesystem withing is corrupted as data is copied to it, just the same way as in #727 VHDX is corrupted on expansion on both Linux/Windows. + +After filing a bug for WNBD https://github.com/cloudbase/wnbd/issues/63 , I was suggested to try raw and qcow2. In the process I found that qcow2 is also affected. But it is also true that the kernel-5.15.4 ... 5.15.13 series have also been buggy https://bugzilla.kernel.org/show_bug.cgi?id=215460 . +On Linux, qcow2 never showed any signs of corruption. +On Windows, however, qcow2 does corrupt. + +It is possible that, as Linux is so much more efficient at files and disk-IO, the kernel-block-code, qemu-block-code and qemu-qcow2-code do not hit the bug, and so the corruption does not show up as easily in Linux. Windows, being a little slower at this, might be causing the bug to show up in this qcow2 test. Possibly, the issue more likely to show up on slower machines. I am using an 2013-era intel-4rth gen i7-4700mq Haswell machine. + +It is possible that, the resolution for this issue and that for #727 could be the same or very closely related. The bug may not be in qcow2.c or vhdx.c but maybe in the qemu/block subsystem. If the data-block that arrives from the VM-interface/nbd-interface which has to be written to file, but never gets to the virtual-disk code, not allocated and written to, then the data-block is lost. +Steps to reproduce: +1. Prepare virtual-disk1 as empty qcow2. In my-setup, the qcow2 file resides on an 150 GiB ExFAT partition on 512 GiB SSD. I use ExFAT as the ExFAT-filesystem does not have a concept of sparse files, eliminating that factor from troubleshooting. + ```qemu-img.exe create -f qcow2 H:\gkpics01.qcow2 99723771904``` +2. Prepare virtual-disk2 VHDX with synthetic generated data (sgdata). Scriptlets to recreate sgdata are described in https://gitlab.com/qemu-project/qemu/-/issues/727#note_739930694 . In my-setup, the vhdx file resides on an 1 TiB NTFS partition on a 2 TiB HDD. +3. Start qemu with arguments as given above. +4. Inside VM, boot and bringup livecd desktop, close the installer and open a terminal +5. Use gdisk to put an ext4 partition on /dev/sda +6. Put ext4 partition on sda1 ```mkfs.ext4 -L fs_gkpics01 /dev/sda1``` +7. Create mount directories ```mkdir /mnt/a /mnt/b``` +8. Mount the empty partition from virtual-disk-1 ```mount -t ext4 /dev/sda1 /mnt/a``` +9. Mount the sgdata partition from virtual-disk-2 ```mount.ntfs-3g /dev/sdb2 /mnt/b``` or ```mount -t ntfs3 /dev/sdb2 /mnt/b``` +10. Keep a terminal tab open with ```dmesg -w``` running +11. Rsync sgdata ```( sdate=`date` ; cd /mnt/b ; rsync -avH ./photos001 /mnt/a | tee /tmp/rst.txt ; echo $sdate ; date )``` +12. Check sha256sum ```( sdate=`date` ; cd /mnt/a/photos001 ; shas256sum -c ./find.CHECKSUM --quiet ; echo $sdate ; date )``` + corruption will show even without needing to unmount-remount or reboot-remount. + +- About 1.4 GiB free-space left on the ext4 partition. +- Compared to #727, The number of files corrupted are less ``` sha256sum: WARNING: 31 computed checksums did not match ``` +- After, VM guest OS warm reboot, a recheck of the sha256sum shows the same 31 files as corrupted +- After, qemu poweroff, restart qemu, VM guest OS cold boot, a recheck of the sha256sum shows the same 31 files as corrupted +- df shows: sda1 has 95271336 1k-blocks, of which 88840860 are used, 1544820 available, 99% used. The numbers don't add up. Either file-blocks are lost in lost-clusters or the ext4-filesystem has a large journal or the file-system-metadata is too large, or the ext4-filesystem has large cluster-size which results in inefficient space usage. +- An ```unmount /dev/sda1 ; fsck -y /dev/sda1 ; mount -t ext4 /dev/sda1 /mnt/a``` did not find any lost clusters. + +The reason I don't think this is a kernel bug, is because the raw-file as virtual-disk-1 doesn't show this issue. Also, it happens regardless of whether sgdata is on ntfs-3g or ntfs3-paragon. +Additional information: + diff --git a/results/classifier/105/mistranslation/814222 b/results/classifier/105/mistranslation/814222 new file mode 100644 index 000000000..0e24fb6a6 --- /dev/null +++ b/results/classifier/105/mistranslation/814222 @@ -0,0 +1,258 @@ +mistranslation: 0.743 +semantic: 0.641 +assembly: 0.574 +other: 0.555 +graphic: 0.500 +KVM: 0.499 +instruction: 0.462 +vnc: 0.413 +socket: 0.410 +device: 0.408 +boot: 0.391 +network: 0.382 + +kvm cannot use vhd files over 127GB + +The primary use case for using vhds with KVM is to perform a conversion to a raw image file so that one could move from Hyper-V to Linux-KVM. See more on this http://blog.allanglesit.com/2011/03/linux-kvm-migrating-hyper-v-vhd-images-to-kvm/ + +# kvm-img convert -f raw -O vpc /root/file.vhd /root/file.img + +The above works great if you have VHDs smaller than 127GB, however if it is larger, then no error is generated during the conversion process, but it appears to just process up to that 127GB barrier and no more. Also of note. VHDs can also be run directly using KVM if they are smaller than 127GB. VHDs can be read and function well using virtualbox as well as hyper-v, so I suspect the problem lies not with the VHD format (since that has a 2TB limitation). But instead with how qemu-kvm is interpreting them. + +BORING VERSION INFO: +# cat /etc/issue +Ubuntu 11.04 \n \l +# uname -rmiv +2.6.38-8-server #42-Ubuntu SMP Mon Apr 11 03:49:04 UTC 2011 x86_64 x86_64 +# apt-cache policy kvm +kvm: + Installed: 1:84+dfsg-0ubuntu16+0.14.0+noroms+0ubuntu4.1 + Candidate: 1:84+dfsg-0ubuntu16+0.14.0+noroms+0ubuntu4.1 + Version table: + *** 1:84+dfsg-0ubuntu16+0.14.0+noroms+0ubuntu4.1 0 + 500 http://apt.sonosite.com/ubuntu/ natty-updates/main amd64 Packages + 500 http://apt.sonosite.com/ubuntu/ natty-security/main amd64 Packages + 100 /var/lib/dpkg/status + 1:84+dfsg-0ubuntu16+0.14.0+noroms+0ubuntu4 0 + 500 http://apt.sonosite.com/ubuntu/ natty/main amd64 Packages +# apt-cache policy libvirt-bin +libvirt-bin: + Installed: 0.8.8-1ubuntu6.2 + Candidate: 0.8.8-1ubuntu6.2 + Version table: + *** 0.8.8-1ubuntu6.2 0 + 500 http://apt.sonosite.com/ubuntu/ natty-updates/main amd64 Packages + 500 http://apt.sonosite.com/ubuntu/ natty-security/main amd64 Packages + 100 /var/lib/dpkg/status + 0.8.8-1ubuntu6 0 + 500 http://apt.sonosite.com/ubuntu/ natty/main amd64 Packages + +qemu-img version 0.14.0 + +# vboxmanage -v +4.0.12r72916 + + +REPRODUCTION STEPS (requires Windows 7 or Windows 2008 R2 with < 1GB of free space) + +## WINDOWS MACHINE ## + +Use Computer Management > Disk Management +-Create 2 VHD files, both dynamically expanding 120GB and 140GB respectively. +-Do not initialize or format. + +These files will need to be transferred to an Ubuntu KVM machine (pscp is what I used but usb would work as well). + +## UBUNTU KVM MACHINE ## + +# ls *.vhd +120g-dyn.vhd 140g-dyn.vhd +# kvm-img info 120g-dyn.vhd +image: 120g-dyn.vhd +file format: vpc +virtual size: 120G (128847052800 bytes) +disk size: 244K +# kvm-img info 140g-dyn.vhd +image: 140g-dyn.vhd +file format: vpc +virtual size: 127G (136899993600 bytes) +disk size: 284K +# kvm-img info 120g-dyn.vhd | grep "virtual size" +virtual size: 120G (128847052800 bytes) +# kvm-img info 140g-dyn.vhd | grep "virtual size" +virtual size: 127G (136899993600 bytes) + +Regardless of how big the second vhd is I always get a virtual size of 127G + +Now if we use virtualbox to view the vhds we see markedly different results. + +# VBoxManage showhdinfo 120g-dyn.vhd +UUID: e63681e0-ff12-4114-85de-7d13562b36db +Accessible: yes +Logical size: 122880 MBytes +Current size on disk: 0 MBytes +Type: normal (base) +Storage format: VHD +Format variant: dynamic default +Location: /root/120g-dyn.vhd +# VBoxManage showhdinfo 140g-dyn.vhd +UUID: 94531905-46b4-469f-bb44-7a7d388fb38f +Accessible: yes +Logical size: 143360 MBytes +Current size on disk: 0 MBytes +Type: normal (base) +Storage format: VHD +Format variant: dynamic default +Location: /root/140g-dyn.vhd + +# kvm-img convert -f vpc -O raw 120g-dyn.vhd 120g-dyn.img +# +# kvm-img convert -f vpc -O raw 140g-dyn.vhd 140g-dyn.img +# + +# kvm-img info 120g-dyn.img +image: 120g-dyn.img +file format: raw +virtual size: 120G (128847052800 bytes) +disk size: 0 +# kvm-img info 120g-dyn.img | grep "virtual size" +virtual size: 120G (128847052800 bytes) +# kvm-img info 140g-dyn.img +image: 140g-dyn.img +file format: raw +virtual size: 127G (136899993600 bytes) +disk size: 0 +# kvm-img info 140g-dyn.img | grep "virtual size" +virtual size: 127G (136899993600 bytes) + +Notice after the conversion the raw image will the taken on the partial geometry of the vhd, thus rendering that image invalid. + +vboxmanage has a clonehd option which allows you to successfully convert vhd to a raw image, which kvm then sees properly. + +For giggles I also tested with a 140GB fixed VHD (in the same manner as above) and it displayed the virtual size as correct, so a good work around is to convert your VHDs to fixed, then use kvm-img to convert them. + +Keep in mind that these reproduction steps will not have a file systems therefore no valid data, if there were for example NTFS with a text file the problem would still occur but more importantly the guest trying to use it would not be able to open the disk because of it being unable to find the final sector. + +So long story short I think we are dealing with 2 issues here. + +1) kvm not being able to deal with dynamic VHD files larger than 127GB +2) kvm-img not generating an error when it "fails" at converting or displaying information on dynamic VHDs larger than 127GB. The error should be something like "qemu-kvm does not support dynamic VHD files larger that 127GB..." + +Thanks for taking the time to submit this bug. + +It looks like the 127G limit is known. A recent patch went in to help with the symptom you are seeing, but unfortunately it only makes the failure detectable :) It's a start at least. + +The following commit should be pulled in: + +commit 6e9ea0c0629fe25723494a19498bedf4b781cbfa +Author: aurel32 <aurel32@c046a42c-6fe2-441c-8c8c-71466251a162> +Date: Wed Apr 15 14:42:46 2009 +0000 + + block-vpc: Don't silently create smaller image than requested + + The algorithm from the VHD specification for CHS calculation silently limits + images to 127 GB which may confuse a user who requested a larger image. Better + output an error message and abort. + + Signed-off-by: Kevin Wolf <email address hidden> + Signed-off-by: Aurelien Jarno <email address hidden> + + git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7109 c046a42c-6fe2-441c-8c8c-71466251a162 + + +Hm, no - that patch is already in natty and oneiric's qemu-kvm. + +I'm afraid I'll need time to find a place where I can reproduce this. + +As converting to fixed is listed as a workaround, I'm changing the priority to low per priority definitions. + +Are the priority definitions documented somewhere? + +I personally think you were right on when you had the priority at medium. + +Primarily because of the fact that no error is generated. It can't just silently fail. If it generated an error (so that people knew they needed to look for a work around) then I would agree that fixing the bug itself would be a low priority, as the work around is simple for anyone to implement. + +@Matthew, + +yes, the definitions are at https://wiki.ubuntu.com/Bugs/Importance. + +Your reasoning makes sense. I'll bump it back up, thanks. + +This could be tough to reproduce, as I don't seem to have a way to +create a vpc image > 127G in the first place: + +root@ip-10-36-186-165:/mnt# qemu-img create -f vpc vpc2.img 130G +Formatting 'vpc2.img', fmt=vpc size=139586437120 +qemu-img: The image size is too large for file format 'vpc' + +root@ip-10-36-186-165:/mnt# qemu-img create -f raw raw1.img 130G +Formatting 'raw1.img', fmt=raw size=139586437120 +root@ip-10-36-186-165:/mnt# qemu-img convert -f raw -O vpc raw1.img vpc1.img +qemu-img: The image size is too large for file format 'vpc' + +root@ip-10-36-186-165:/mnt# qemu-img create -f vpc vpc1.img 127G +Formatting 'vpc1.img', fmt=vpc size=136365211648 +root@ip-10-36-186-165:/mnt# qemu-img convert -f vpc -O raw vpc1.img raw2.img +root@ip-10-36-186-165:/mnt# qemu-img info raw2.img +image: raw2.img +file format: raw +virtual size: 127G (136365219840 bytes) +disk size: 0 + + + + +This is a dynamically expanding VHD file created using the reproduction steps above on Windows 7. This one is 120GB and converts correctly. + +This has not been formatted or even initialized. + +"kvm-img info 120g-dynamic.vhd" shows the proper geometry. + + +This is a dynamically expanding VHD file created using the reproduction steps above on Windows 7. This one is 140GB and silently errors on conversion. + +This has not been formatted or even initialized. + +"kvm-img info 140g-dynamic.vhd" does not show the proper geometry. + +I have attached a couple of VHDs that I created with Windows 7. These should be helpful in your reproduction. + +Also looking at your notes it looks like that previous patch which was committed only affected the creation. So perhaps the same sort of check can be incorporated into the conversion process as well, so that you don't have the silent error. + +@Matthew + +thanks for the attachments. + + + +This bug was fixed in the package qemu-kvm - 0.14.1+noroms-0ubuntu5 + +--------------- +qemu-kvm (0.14.1+noroms-0ubuntu5) oneiric; urgency=low + + * debian/patches/vpc.patch: detect vpc files which are too big + (LP: #814222) + -- Serge Hallyn <email address hidden> Mon, 12 Sep 2011 11:28:36 -0500 + +I came here from : http://lists.gnu.org/archive/html/qemu-devel/2011-07/msg02806.html + +Actually, I experience an issue which may be useful to you. + +I have a corrupted VHD file (as explained in that thread : https://forums.virtualbox.org/viewtopic.php?f=7&t=20614 ). I wanted to follow that procedure to solve my issue : + + qemu-img convert -O raw miimagen.vhd miimagen.bin + VBoxManage convertdd miimagen.bin miimagen.vdi + + +but qemu-img convert -O raw miimagen.vhd miimagen.bin triggers the qemu-img: Could not open 'img.VHD': File too large error message. + +Since, my file is 52,6 Go and the output is raw format. I guess it should not trigger that exception? or is that the normal behavior? Is there a way to bypass this limit? I use qemu-img 1.0 version. + +Hope it can help your development (and it can help me back) +Thanks, +simon + +Looks like Serge's fix has been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=efc8243d00ab4cf4fa05a9b +... so let's close this bug now. + diff --git a/results/classifier/105/mistranslation/828 b/results/classifier/105/mistranslation/828 new file mode 100644 index 000000000..bbfab69d4 --- /dev/null +++ b/results/classifier/105/mistranslation/828 @@ -0,0 +1,24 @@ +mistranslation: 0.944 +network: 0.879 +instruction: 0.812 +graphic: 0.792 +device: 0.736 +semantic: 0.564 +vnc: 0.424 +socket: 0.329 +boot: 0.324 +other: 0.257 +KVM: 0.147 +assembly: 0.104 + +using qemu-system-x86_64 to start multiple windows 10 guests concurrently , the mac address of the guests is incorrect +Description of problem: +I plan to run multiple windows 10 guests concurrently, I choose NAT network and specify a unique MAC addr for each guest. and I choose dnsmasq as a dhcp server. but I found that all guests MAC addresses are the same as the guest started first. +This situation also occurs in windows 8. But the strange thing is that this never happened to windows7 guests. +I'm Chinese and my English is pool, please forgive my bad expressions. +Steps to reproduce: +1.make a windows 10 image +2.qemu-system-x86_64 command assign unique MAC addr +3. python multiprocess lib running command above +Additional information: + diff --git a/results/classifier/105/mistranslation/83 b/results/classifier/105/mistranslation/83 new file mode 100644 index 000000000..ca61d874d --- /dev/null +++ b/results/classifier/105/mistranslation/83 @@ -0,0 +1,14 @@ +mistranslation: 0.859 +instruction: 0.857 +device: 0.813 +other: 0.511 +graphic: 0.374 +boot: 0.370 +socket: 0.204 +semantic: 0.165 +vnc: 0.149 +network: 0.095 +assembly: 0.028 +KVM: 0.001 + +QEMU x87 emulation of trig and other complex ops is only at 64-bit precision, not 80-bit diff --git a/results/classifier/105/mistranslation/838 b/results/classifier/105/mistranslation/838 new file mode 100644 index 000000000..89adfb204 --- /dev/null +++ b/results/classifier/105/mistranslation/838 @@ -0,0 +1,14 @@ +mistranslation: 0.966 +device: 0.721 +network: 0.611 +other: 0.586 +semantic: 0.579 +graphic: 0.496 +instruction: 0.457 +vnc: 0.259 +socket: 0.195 +boot: 0.171 +assembly: 0.090 +KVM: 0.034 + +qemu-system-arm, ast2600-evb, the address mapping of ASPEED_DEV_SPI2 is different from datasheet diff --git a/results/classifier/105/mistranslation/853 b/results/classifier/105/mistranslation/853 new file mode 100644 index 000000000..d20676a92 --- /dev/null +++ b/results/classifier/105/mistranslation/853 @@ -0,0 +1,23 @@ +mistranslation: 0.925 +device: 0.740 +semantic: 0.733 +other: 0.721 +graphic: 0.511 +network: 0.507 +vnc: 0.374 +socket: 0.321 +instruction: 0.241 +boot: 0.230 +KVM: 0.136 +assembly: 0.052 + +Quaint English in qemu-options.hx +Description of problem: +qemu-options.hx contains grammar that a native English-speaking person would never use. I had to read a sentence in that file very slowly and more than once to understand it. +Steps to reproduce: +1. Install QEMU +2. Run a command to display documentation that includes qemu-options.hx for instance "man qemu-system-x86_64" +3. Observe "This option defines where is connected the drive ..." +4. Scratch head, figure out that "This option defines where the drive is connected ..." is the meaning. +Additional information: +It is very difficult to report QEMU documentation bugs. diff --git a/results/classifier/105/mistranslation/862 b/results/classifier/105/mistranslation/862 new file mode 100644 index 000000000..b5ee28d13 --- /dev/null +++ b/results/classifier/105/mistranslation/862 @@ -0,0 +1,62 @@ +mistranslation: 0.726 +instruction: 0.717 +semantic: 0.672 +graphic: 0.661 +other: 0.661 +boot: 0.649 +device: 0.632 +KVM: 0.621 +vnc: 0.576 +network: 0.562 +socket: 0.536 +assembly: 0.515 + +Using qemu+kvm is slower than using qemu in rv6(xv6 rust porting) +Description of problem: +Using qemu+kvm is slower than using qemu in rv6(xv6 rust porting) +Steps to reproduce: +``` +git clone https://github.com/kaist-cp/rv6 +cd rv6 +make clean +TARGET=arm GIC_VERSION=3 KVM=yes make qemu +``` +Additional information: +We are currently working on the [rv6 project](https://github.com/kaist-cp/rv6) which is porting MIT's educational operating system [xv6](https://github.com/mit-pdos/xv6-public) to Rust.<br> Our code is located [here](https://github.com/kaist-cp/rv6/tree/main/kernel-rs). +We use qemu and [qemu's virt platform](https://qemu.readthedocs.io/en/latest/system/arm/virt.html) to execute rv6, and it works well with using qemu. +Executing command on arm machine is this: +``` +RUST_MODE=release TARGET=arm KVM=yes GIC_VERSION=3 +qemu-system-aarch64 -machine virt -kernel kernel/kernel -m 128M -smp 80 -nographic -drive file=fs.img,if=none,format=raw,id=x0,copy-on-read=off -device virtio-blk-device,drive=x0,bus=virtio-mmio-bus.0 -cpu cortex-a53 -machine gic-version=3 -net none +``` +To make some speed boost experiment with KVM, we made rv6 support the arm architecture on arm machine. The arm architecture's driver code locates in [here](https://github.com/kaist-cp/rv6/tree/main/kernel-rs/src/arch/arm). +The problem is, when we use qemu with kvm, the performance is significantly reduced. +Executing command on arm machine with KVM is this: +``` +qemu-system-aarch64 -machine virt -kernel kernel/kernel -m 128M -smp 80 -nographic -drive file=fs.img,if=none,format=raw,id=x0,copy-on-read=off -device virtio-blk-device,drive=x0,bus=virtio-mmio-bus.0 -cpu host -enable-kvm -machine gic-version=3 -net none +``` +We repeated +1. Write 500 bytes syscall 10,000 times and the result was: kvm disable: 4,500,000 us, kvm enable: 29,000,000 us. (> 5 times) +2. Open/Close syscall 10,000 times result: kvm disable: 12,000,000 us, kvm enable: 29,000,000 us. (> 5 times) +3. Getppid syscall 10,000 times result: kvm disable: 735,000 us, kvm enable: 825,000 us. (almost same) +4. Simple calculation(a = a * 1664525 + 1013904223) 100 million times result: kvm disable: 2,800,000 us, kvm enable: 65,000,000 us. (> 20 times) + +And the elapsed time was estimated by [uptime_as_micro](https://github.com/kaist-cp/rv6/blob/90b84b60931327ae8635875b788b10280e47b99c/kernel-rs/src/arch/arm/timer.rs#L17) syscall in rv6. +These results were so hard to understand. <br>So first we tried to find the bottleneck on rv6's booting process, because finding bottleneck during processing user program was so difficult. +We found that the first noticeable bottleneck on rv6 booting process was [here](https://github.com/kaist-cp/rv6/blob/main/kernel-rs/src/kalloc.rs#L107-L108): +``` +run.as_mut().init(); +self.runs().push_front(run.as_ref()); +``` +As far as we know, this part is just kind of "list initialization and push element" part. So we thought that by some reason, the KVM is not actually working and it makes worse result. And also this part is even before turn on some interrupts, so we thought [arm's GIC](https://developer.arm.com/documentation/dai0492/b/) or interrupt related thing is not related with problem. + +So, how can I get better performance when using kvm with qemu? + +To solve this problem, we tried these already: +1. change qemu(4.2, 6.2), virt version, change [some command for qemu-kvm](https://linux.die.net/man/1/qemu-kvm) like cpu, drive cache, copy-on-read something, kernel_irqchip.., cpu core.. etc +2. find some kvm hypercall to use - but not exists on arm64 +3. Run [lmbench](http://lmbench.sourceforge.net/) by ubuntu on qemu with kvm to check KVM itself is okay. - We found KVM with ubuntu is super faster than only using qemu. +4. Check [16550a UART print code](https://github.com/kaist-cp/rv6/blob/main/kernel-rs/src/arch/arm/uart.rs) is really slow on enabling KVM which makes incorrect result on benchmark - Without bottleneck code, we found the progress time of rv6 booting were almost same with KVM enabled or not. +5. Check other people who suffer same situation like us - but [this superuser page](https://superuser.com/questions/1317948/qemu-enable-kvm-slower-than-pure-emulation-for-x86-64) not works. Our clocksource is arch_sys_counter. + +Thank you for your help. diff --git a/results/classifier/105/mistranslation/864490 b/results/classifier/105/mistranslation/864490 new file mode 100644 index 000000000..6418c47a6 --- /dev/null +++ b/results/classifier/105/mistranslation/864490 @@ -0,0 +1,32 @@ +mistranslation: 0.855 +device: 0.802 +other: 0.786 +graphic: 0.755 +instruction: 0.639 +semantic: 0.614 +socket: 0.557 +assembly: 0.547 +boot: 0.531 +vnc: 0.510 +network: 0.472 +KVM: 0.277 + +Windows 2008 x64 (SBS Server) freezes randomly when using more than 1 CPU core + +This issue has been giving headache to us since a long time. +Difficult to reproduce as it happens randomly. +We had this issue when we ran Windows 2008 x64 or Windows SBS Server guests in either XEN 3.3 or Proxmox environments. +When only one CPU core is assigned to the guest, everything is fine. If 2 or more cores are assigned, the guest stops responding after several hours - and in the host machine one of the cores is using 100%. The only thing that helps is resetting the guest. + +I am ready to provide logs/crashdumps if needed, because we want to help resolve this issue. I saw some posts on the web of people having the same problems - for some of the workaround was to fix some BIOS settings, but we did not have success with those (e.g. disabling C1E Support and Intel C-State ) + +Server is running on Intel® Core™ i7-920 Quad-Core, 24 Gig RAM. + +Hi, + +Is this bug tracker active or I posted to the wrong place? + +thx + +Since nobody replied here within the last years: I think you should rather report problems with XEN / Proxmox to the XEN or Proxmox bugtracker instead. + diff --git a/results/classifier/105/mistranslation/870 b/results/classifier/105/mistranslation/870 new file mode 100644 index 000000000..266ca312e --- /dev/null +++ b/results/classifier/105/mistranslation/870 @@ -0,0 +1,25 @@ +mistranslation: 0.970 +device: 0.785 +graphic: 0.726 +instruction: 0.717 +semantic: 0.424 +network: 0.321 +other: 0.309 +vnc: 0.298 +socket: 0.207 +KVM: 0.199 +boot: 0.154 +assembly: 0.048 + +Throws a #GP when it should throw a #SS +Description of problem: +When stacks are switched as part of a 64-bit mode privilege-level change (resulting from an interrupt), IA-32e mode loads only an inner-level RSP from the TSS. If the value of rsp from tss is a non-canonical form. It will trigger #SS. But when I test it in qemu it throws #GP instead of #SS +Steps to reproduce: +In order to confirm that it is the #SS triggered by the non-canonical address, We can verify on a real machine. +1. Set the value of the current core's `TSS.IST7` to the the non-canonical address. +2. Set the `ist` field of the interrupt 4 (Overflow Exception) descriptor to 7. +3. Execute the `INT 4` instruction in Ring 3 and it will be taken over by the #SS handler. + +Repeat the above steps in qemu this exception will be taken over by #GP +Additional information: + diff --git a/results/classifier/105/mistranslation/886255 b/results/classifier/105/mistranslation/886255 new file mode 100644 index 000000000..5b96d7402 --- /dev/null +++ b/results/classifier/105/mistranslation/886255 @@ -0,0 +1,126 @@ +mistranslation: 0.856 +other: 0.807 +KVM: 0.786 +network: 0.782 +boot: 0.776 +graphic: 0.762 +device: 0.761 +vnc: 0.746 +instruction: 0.721 +semantic: 0.653 +assembly: 0.652 +socket: 0.649 + +Qemu master branch - RHEL 6.1 guest fails to boot + +Guest: RHEL 6.1 64 bit DVD + +Kernel: Latest Fedora, also reproduces with Avi's kvm.git kernel based on 3.1: 2.6.40.6-0.fc15.x86_64 + +qemu version: + +11/04 00:25:30 DEBUG|virt_utils:2587| Git repo qemu uri: git://git.qemu.org/qemu.git +11/04 00:25:30 DEBUG|virt_utils:2590| Git repo qemu branch: master +11/04 00:25:30 DEBUG|virt_utils:3189| Configure options for git_repo_qemu: ['--target-list=x86_64-softmmu'] +11/04 00:25:30 DEBUG|virt_utils:2496| Initializing new git repo at /usr/local/autotest/tests/kvm/src/qemu for receiving git repo 11/04 00:25:30 INFO |virt_utils:2505| Fetching git [REP 'git://git.qemu.org/qemu.git' BRANCH 'master'] -> /usr/local/autotest/tests/kvm/src/qemu +11/04 00:25:30 DEBUG|base_utils:0074| Running 'git fetch -q -f -u -t git://git.qemu.org/qemu.git master:master' +11/04 00:34:41 INFO |virt_utils:2531| Commit hash for qemu is 932eacc158c064935c7bab920c88a93a629e1ca4 (no tag found) + +On guest boot screenshots (one of them attached), you can see the message + +"Bringing up interface eth0: Device eth0 does not seem to be present, delaying initialization" + +Network card info +11/04 00:44:55 DEBUG| virt_test:0041| bridge = virbr0 +11/04 00:44:55 DEBUG| virt_test:0041| nic_mode = tap +11/04 00:44:55 DEBUG| virt_test:0041| nic_model = virtio + +Commented excerpt of the test log: + +11/04 00:44:57 INFO | kvm_vm:0790| Running qemu command: +/usr/local/autotest/tests/kvm/qemu -name 'vm1' -nodefaults -vga std -monitor unix:'/tmp/monitor-humanmonitor1-20111104-003602-LPJY',server,nowait -qmp unix:'/tmp/monitor-qmpmonitor1-20111104-003602-LPJY',server,nowait -serial unix:'/tmp/serial-20111104-003602-LPJY',server,nowait -drive file='/tmp/kvm_autotest_root/images/rhel6.1-64.qcow2',index=0,if=virtio,cache=none -device virtio-net-pci,netdev=id3HQgQx,mac='9a:16:a5:3c:05:25',id='id0AfUVE' -netdev tap,id=id3HQgQx,fd=23 -m 2048 -smp 2 -vnc :0 -enable-kvm +11/04 00:44:59 DEBUG|kvm_monito:0624| (monitor qmpmonitor1) Sending command 'qmp_capabilities' +11/04 00:44:59 DEBUG| kvm_vm:0851| VM appears to be alive with PID 9827 +11/04 00:44:59 DEBUG|virt_env_p:0318| Starting screendump thread +11/04 00:44:59 DEBUG| virt_vm:0654| Attempting to log into 'vm1' (timeout 720s) + +... here it starts booting ... + +11/04 00:44:59 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:01 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:03 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:05 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:07 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:09 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:11 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:13 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:15 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:17 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:19 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:21 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:23 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 + +... here it gets an IP from the DHCP server ... + +11/04 00:45:24 DEBUG|virt_env_p:0438| (address cache) Adding cache entry: 9a:16:a5:3c:05:25 ---> 192.168.122.195 + +... ok, let's try to login ... + +11/04 00:45:25 DEBUG|virt_utils:0710| Trying to login with command 'ssh -o UserKnownHostsFile=/dev/null -o PreferredAuthentications=password -p 22 root@192.168.122.195' + +... ouch, not possible to login ... + +11/04 00:45:25 DEBUG| virt_vm:0660| Client said 'connection refused' (output: 'ssh: connect to host 192.168.122.195 port 22: Connection refused\n') + +... message above repeats until ... + +11/04 00:56:59 ERROR| virt_test:0095| Test failed: LoginError: Client said 'connection refused' (output: 'ssh: connect to host 192.168.122.195 port 22: Connection refused\n') +11/04 00:56:59 DEBUG|virt_env_p:0147| Postprocessing VM 'vm1' +11/04 00:56:59 DEBUG|virt_env_p:0166| Param 'kill_vm' specified, killing VM +11/04 00:56:59 DEBUG| kvm_vm:0885| Destroying VM with PID 9827 +11/04 00:56:59 DEBUG| kvm_vm:0889| Trying to shutdown VM with shell command +11/04 00:56:59 DEBUG|virt_utils:0710| Trying to login with command 'ssh -o UserKnownHostsFile=/dev/null -o PreferredAuthentications=password -p 22 root@192.168.122.195' +11/04 00:56:59 DEBUG| kvm_vm:0893| Client said 'connection refused' (output: 'ssh: connect to host 192.168.122.195 port 22: Connection refused\n') +11/04 00:56:59 DEBUG| kvm_vm:0908| Trying to kill VM with monitor command +11/04 00:56:59 INFO | aexpect:0783| [qemu output] (Process terminated with status 0) +11/04 00:57:00 DEBUG| kvm_vm:0916| VM is down +11/04 00:57:00 DEBUG| virt_vm:0318| Checking image file /tmp/kvm_autotest_root/images/rhel6.1-64.qcow2 +11/04 00:57:00 DEBUG|base_utils:0074| Running '/usr/local/autotest/tests/kvm/qemu-img' +11/04 00:57:00 DEBUG|base_utils:0074| Running '/usr/local/autotest/tests/kvm/qemu-img info /tmp/kvm_autotest_root/images/rhel6.1-64.qcow2' +11/04 00:57:00 DEBUG|base_utils:0106| [stdout] image: /tmp/kvm_autotest_root/images/rhel6.1-64.qcow2 +11/04 00:57:00 DEBUG|base_utils:0106| [stdout] file format: qcow2 +11/04 00:57:00 DEBUG|base_utils:0106| [stdout] virtual size: 10G (10737418240 bytes) +11/04 00:57:00 DEBUG|base_utils:0106| [stdout] disk size: 2.1G +11/04 00:57:00 DEBUG|base_utils:0106| [stdout] cluster_size: 65536 +11/04 00:57:00 DEBUG|base_utils:0074| Running '/usr/local/autotest/tests/kvm/qemu-img check /tmp/kvm_autotest_root/images/rhel6.1-64.qcow2' + + + +We are currently investigating the failure. One of our suspects is that on kvm autotest, each new qemu process instance might have a new NIC mac address, and that might be triggering some condition in qemu in conjunction to the guest init scripts. + +It is important to note that this problem does not affect qemu-kvm.git, or RHEL based branches for that matter. + +I can't reproduce this with an Ubuntu guest. I suspect it has something to do with how you're configuring networking. + +A little more investigation shows that empty ssh keys are being generated on the first boot, so now it doesn't look like a network problem anymore. now we are trying to figure out just on qemu this phenomenon is happening. + +We've identified that the following commit resolved the issue + + commit 47113ab6b8c5659ad94c69aacca572f731ebb0ac + Author: Wen Congyang <email address hidden> + Date: Fri Nov 4 10:45:58 2011 +0800 + reenable vm_clock when resuming all vcpus + + We disable vm_clock when pausing all vcpus, but we forget to + reenable it when resuming all vcpus. It will cause that the + guest can not be rebooted. + + Tested-by: Zhi Yong Wu <email address hidden> + Reviewed-by: Paolo Bonzini <email address hidden> + Signed-off-by: Wen Congyang <email address hidden> + Signed-off-by: Anthony Liguori <email address hidden> + +That's good, you can close the issue. + +Marking as fixed, according to comment #5 + diff --git a/results/classifier/105/mistranslation/889053 b/results/classifier/105/mistranslation/889053 new file mode 100644 index 000000000..7e96b31ef --- /dev/null +++ b/results/classifier/105/mistranslation/889053 @@ -0,0 +1,63 @@ +mistranslation: 0.767 +instruction: 0.661 +device: 0.640 +graphic: 0.544 +socket: 0.539 +vnc: 0.495 +semantic: 0.495 +other: 0.417 +network: 0.411 +boot: 0.317 +KVM: 0.296 +assembly: 0.277 + +x86: FPU_MAX, FPU_MIN incorrect + +Dear All, + +Bug was found in qemu.git. +Now (0.15, 1.0) all fpu is softfpu. +See target-i386/ops_sse.h: +#define FPU_MIN(size, a, b) (a) < (b) ? (a) : (b) +#define FPU_MAX(size, a, b) (a) > (b) ? (a) : (b) +It is incorrect now, becouse float64 (or 32) is (typedef) uint64_t (or 32). +And if we have signed operands we get error... + +There is a test with this error (spec shinx3 test data, results diffs on machine and qemu (linux)) and fixed patch. See attach. + +Daniil. + + + + + +misprint: +spec sphinx3 test data + +482.sphinx3: http://www.spec.org/cpu2006/CFP2006/ + +The attached patch is incorrect (using the softfloat _min/_max functions will give wrong answers for some special cases). The correct macros are +#define FPU_MIN(size, a, b) float ## size ## _lt(a, b, &env->sse_status) ? (a) : (b) +#define FPU_MAX(size, a, b) float ## size ## _lt(b, a, &env->sse_status) ? (a) : (b) + +(see recent discussion on the qemu-devel list). + + +Hello! +Can I commit this patch (in development branch), and close this bug... +Or you must do it? + +Your patch is broken, as I said before. + + +Yes, but you patch is correct... + +May be commit you patch + +I say about +#define FPU_MIN(size, a, b) float ## size ## _lt(a, b, &env->sse_status) ? (a) : (b) +#define FPU_MAX(size, a, b) float ## size ## _lt(b, a, &env->sse_status) ? (b) : (a) + +The patch mentioned in comment #5 has been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=a4d1f142542935b90d2e + diff --git a/results/classifier/105/mistranslation/890 b/results/classifier/105/mistranslation/890 new file mode 100644 index 000000000..35c44221d --- /dev/null +++ b/results/classifier/105/mistranslation/890 @@ -0,0 +1,14 @@ +mistranslation: 0.996 +other: 0.859 +graphic: 0.767 +semantic: 0.720 +vnc: 0.256 +device: 0.190 +boot: 0.157 +KVM: 0.111 +network: 0.027 +assembly: 0.023 +socket: 0.013 +instruction: 0.006 + +Misinterpretation of arm neon invalid insn diff --git a/results/classifier/105/mistranslation/891625 b/results/classifier/105/mistranslation/891625 new file mode 100644 index 000000000..3f8f8cb33 --- /dev/null +++ b/results/classifier/105/mistranslation/891625 @@ -0,0 +1,52 @@ +mistranslation: 0.659 +device: 0.644 +other: 0.590 +graphic: 0.570 +semantic: 0.567 +network: 0.438 +instruction: 0.421 +KVM: 0.392 +socket: 0.375 +vnc: 0.312 +boot: 0.306 +assembly: 0.289 + +[qemu-kvm] add vhost-net to kvm group udev rules 65-kvm.rules + +Please consider authorizing the kvm group to access vhost-net device, similar to the kvm device. +Thanks! + + + +I wonder if it really belongs to kvm group, -- maybe a separate "vhost_net" group should be used instead. Yes it can only be used with qemu/kvm currently, but maybe some other tool will use it in the future, and looking at how many security issues /dev/kvm access had, maybe vhost_net shold be restricted more... + +How other distributions are doing this? I'm not sure we want to introduce our own naming here... + +Well, at Gentoo we have kvm group, and I think that this comes from +upstream rule. +Doing vhost_net is good, anything that may be assigned to regular users. +Thanks! + + +Since there is no udev file in upstream QEMU, I guess this bug was meant for the qemu Ubuntu package instead? + +The attachment "udef.diff" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team. + +[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.] + +Thank you for taking the time to report this bug and helping to make Ubuntu better. + +I'm not sure if it would be appropriate to make this change, but it is clear what you're requesting so I'm setting the bug status to Triaged. + +Hi, +I'm currently parsing through bug that are dormant way too long. + +These days the content still exists, but is in debian/qemu-system-common.udev + +But vhost-net is working fine without that change, so I wonder what it was back then that failed without that - so that we can verify if that actually is an issue today. + +Until then setting incomplete. + + +[Expired for qemu (Ubuntu) because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/893367 b/results/classifier/105/mistranslation/893367 new file mode 100644 index 000000000..b4bb485da --- /dev/null +++ b/results/classifier/105/mistranslation/893367 @@ -0,0 +1,37 @@ +mistranslation: 0.965 +graphic: 0.795 +device: 0.728 +instruction: 0.655 +network: 0.619 +semantic: 0.591 +socket: 0.590 +vnc: 0.442 +other: 0.372 +boot: 0.307 +assembly: 0.269 +KVM: 0.216 + +HPET supports only one IRQ + +The emulated HPET only supports triggering IRQ 2. Since MSIs are by default disabled, this severely limits the usefulness of the HPET as only one timer block can effectively be used (otherwise they would share IRQ 2). Ideally, the HPET should support as much timer blocks as CPUs and each timer block can be driven by a different IRQ. + +TIMER: HPET at fed00000 -> 0xbf500000. +TIMER: HPET vendor 8086 revision 01: LEGACY 64BIT +TIMER: HPET: cap 8086a201 config 0 period 10000000 +TIMER: HPET Timer[0]: config 30 int 4 +TIMER: HPET Timer[1]: config 30 int 4 +TIMER: HPET Timer[2]: config 30 int 4 + +The offending code seems to be: + + /* advertise availability of ioapic inti2 */ + timer->config |= 0x00000004ULL << 32; + +in hw/hpet.c hpet_reset(). + +I assume this has been fixed by this commit here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=7a10ef51c2397ac4323b +Or is there still something left to do here? + +No. Looks good to me. + diff --git a/results/classifier/105/mistranslation/895 b/results/classifier/105/mistranslation/895 new file mode 100644 index 000000000..ed21bd467 --- /dev/null +++ b/results/classifier/105/mistranslation/895 @@ -0,0 +1,51 @@ +mistranslation: 0.936 +vnc: 0.861 +graphic: 0.733 +device: 0.723 +semantic: 0.587 +instruction: 0.412 +KVM: 0.391 +other: 0.374 +network: 0.364 +boot: 0.309 +socket: 0.255 +assembly: 0.149 + +can't find table device while call qemu_input_is_absolute function +Description of problem: +vnc service can‘t run with mouse absolute mode +Steps to reproduce: +1.create a virtual machine with vnc service via virt-manager. + +2.delete mouse and table device if exists. + +3.add table devices first,next add mouse device. + +4.gdb attach corresponding qemu thread, run command +print "%d",qemu_input_is_absolute() +display function return false ,so I can't use mouse with absolute mode. +Additional information: +code in qemu_input_is_absolute() is +``` +bool qemu_input_is_absolute(void) +{ + QemuInputHandlerState *s; + + s = qemu_input_find_handler(INPUT_EVENT_MASK_REL | INPUT_EVENT_MASK_ABS, + NULL); + return (s != NULL) && (s->handler->mask & INPUT_EVENT_MASK_ABS); +} +``` +qemu_input_find_handler function find a handler INPUT_EVENT_MASK_REL or INPUT_EVENT_MASK_ABS,but just compare with INPUT_EVENT_MASK_ABS, +I think it should be +``` +bool qemu_input_is_absolute(void) +{ + QemuInputHandlerState *s; + + s = qemu_input_find_handler(INPUT_EVENT_MASK_ABS, + NULL); + return (s != NULL) && (s->handler->mask & INPUT_EVENT_MASK_ABS); +} +``` +thanks for your help. diff --git a/results/classifier/105/mistranslation/906 b/results/classifier/105/mistranslation/906 new file mode 100644 index 000000000..e1b238e07 --- /dev/null +++ b/results/classifier/105/mistranslation/906 @@ -0,0 +1,14 @@ +mistranslation: 0.829 +other: 0.675 +device: 0.511 +graphic: 0.483 +semantic: 0.382 +instruction: 0.290 +network: 0.258 +assembly: 0.144 +vnc: 0.140 +socket: 0.125 +boot: 0.090 +KVM: 0.041 + +Cannot IPL this ISO image diff --git a/results/classifier/105/mistranslation/917 b/results/classifier/105/mistranslation/917 new file mode 100644 index 000000000..0947e94e0 --- /dev/null +++ b/results/classifier/105/mistranslation/917 @@ -0,0 +1,14 @@ +mistranslation: 0.964 +device: 0.900 +semantic: 0.792 +network: 0.662 +other: 0.606 +assembly: 0.442 +graphic: 0.376 +boot: 0.275 +instruction: 0.264 +vnc: 0.173 +socket: 0.104 +KVM: 0.079 + +FireWire Device Passthrough? diff --git a/results/classifier/105/mistranslation/939437 b/results/classifier/105/mistranslation/939437 new file mode 100644 index 000000000..69f46e4f5 --- /dev/null +++ b/results/classifier/105/mistranslation/939437 @@ -0,0 +1,26 @@ +mistranslation: 0.882 +device: 0.812 +instruction: 0.789 +network: 0.763 +KVM: 0.723 +semantic: 0.667 +socket: 0.586 +graphic: 0.494 +other: 0.480 +boot: 0.414 +vnc: 0.387 +assembly: 0.128 + +spice is not supported by this qemu build.(ubuntu 12.04) + +$ kvm -spice port=5900,addr=127.0.0.1,disable-ticketing +kvm: -spice port=5900,addr=127.0.0.1,disable-ticketing: there is no option group "spice" +spice is not supported by this qemu build. + +$ kvm -version +QEMU emulator version 1.0 (qemu-kvm-1.0), Copyright (c) 2003-2008 Fabrice Bellard + +Status changed to 'Confirmed' because the bug affects multiple users. + +On precise, use the qemu-kvm-spice package. + diff --git a/results/classifier/105/mistranslation/939443 b/results/classifier/105/mistranslation/939443 new file mode 100644 index 000000000..23fd199e7 --- /dev/null +++ b/results/classifier/105/mistranslation/939443 @@ -0,0 +1,20 @@ +mistranslation: 0.918 +device: 0.888 +KVM: 0.863 +graphic: 0.764 +semantic: 0.690 +instruction: 0.688 +network: 0.621 +other: 0.421 +boot: 0.409 +socket: 0.392 +vnc: 0.233 +assembly: 0.079 + +qemu-system-x86_64 can no support 1366x768 + +My laptop resolution is 1366x768, but can not support at -vga vmware the -vga std. + +$ kvm -version +QEMU emulator version 1.0 (qemu-kvm-1.0), Copyright (c) 2003-2008 Fabrice Bellard + diff --git a/results/classifier/105/mistranslation/940 b/results/classifier/105/mistranslation/940 new file mode 100644 index 000000000..3c4c11b27 --- /dev/null +++ b/results/classifier/105/mistranslation/940 @@ -0,0 +1,14 @@ +mistranslation: 0.716 +device: 0.667 +graphic: 0.483 +semantic: 0.456 +socket: 0.342 +other: 0.332 +instruction: 0.286 +network: 0.270 +vnc: 0.254 +KVM: 0.168 +boot: 0.078 +assembly: 0.045 + +"analyze-migration.py -m" does not appear to account for the pci-hole diff --git a/results/classifier/105/mistranslation/942659 b/results/classifier/105/mistranslation/942659 new file mode 100644 index 000000000..3a1d3cfd1 --- /dev/null +++ b/results/classifier/105/mistranslation/942659 @@ -0,0 +1,61 @@ +mistranslation: 0.713 +semantic: 0.575 +other: 0.443 +device: 0.294 +assembly: 0.255 +instruction: 0.235 +socket: 0.171 +graphic: 0.124 +vnc: 0.080 +network: 0.065 +boot: 0.058 +KVM: 0.024 + +ARM: CORTEX M, PRIMASK does not disable interrupts + +qemu version 0.15.1 +but the same code is in qemu 1.0 + +"CPSID I" does not disable interrupts for CORTEX M3 + + +if (interrupt_request & CPU_INTERRUPT_HARD + && ((IS_M(env) && env->regs[15] < 0xfffffff0) + || !(env->uncached_cpsr & CPSR_I))) { + env->exception_index = EXCP_IRQ; + do_interrupt(env); + next_tb = 0; + } + + +do_interrupt() will be executed even if (env->uncached_cpsr & CPSR_I) == 1 , disable interrupt bit set. + + +then changed to: + +if (interrupt_request & CPU_INTERRUPT_HARD + && !(env->uncached_cpsr & CPSR_I) + && (IS_M(env) ? env->regs[15] < 0xfffffff0: 1) ) { + env->exception_index = EXCP_IRQ; + do_interrupt(env); + next_tb = 0; + } + +works + +This change changes the behaviour for non-M-profile cores, which looks wrong. + +See discussion in this mailing list thread where a similar patch was suggested: + http://lists.gnu.org/archive/html/qemu-devel/2011-06/msg00500.html + +M profile interrupt handling is known-broken. I'm not accepting any patches in this area unless they come attached to a decent explanation of why they are the correct change to make and show some evidence of the whole problem having been considered. + + +> This change changes the behaviour for non-M-profile cores + +...or maybe not: I was confused by the resemblance to that other patch. I still think one-line fixes are unlikely to be the right approach here, though. + + +This long-standing bug has been fixed by the rewrite of the M-profile exception handling for QEMU 2.9. + + diff --git a/results/classifier/105/mistranslation/947273 b/results/classifier/105/mistranslation/947273 new file mode 100644 index 000000000..4c38f51ef --- /dev/null +++ b/results/classifier/105/mistranslation/947273 @@ -0,0 +1,21 @@ +mistranslation: 0.624 +graphic: 0.427 +semantic: 0.236 +device: 0.154 +other: 0.129 +vnc: 0.074 +network: 0.056 +assembly: 0.043 +boot: 0.031 +instruction: 0.025 +socket: 0.013 +KVM: 0.002 + +launchpad homepage url is out of date + +The launchpad "homepage" link to QEMU's homepage is http://www.nongnu.org/qemu/, this link immediately redirects one to http://qemu.org (then wiki.qemu.org). + +The link should probably be updated to http://qemu.org + +As far as I can see, the "home page" link is now set to http://wiki.qemu-project.org/ - so it seems this has been fixed. + diff --git a/results/classifier/105/mistranslation/950 b/results/classifier/105/mistranslation/950 new file mode 100644 index 000000000..5b0c2b01d --- /dev/null +++ b/results/classifier/105/mistranslation/950 @@ -0,0 +1,36 @@ +mistranslation: 0.587 +vnc: 0.474 +KVM: 0.417 +device: 0.269 +graphic: 0.263 +network: 0.250 +instruction: 0.218 +assembly: 0.201 +other: 0.184 +boot: 0.160 +socket: 0.156 +semantic: 0.126 + +7.0.0-rc2 hw/9pfs/9p.h cannot find XATTR_SIZE_MAX +Description of problem: +``` +[844/2583] Compiling C object tests/qtest/qos-test.p/virtio-rng-test.c.o +ninja: job failed: clang -m64 -mcx16 -Itests/qtest/qos-test.p -Itests/qtest -I../tests/qtest -I. -Iqapi -Itrace -Iui -Iui/shader -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -flto -fcolor-diagnostics -Wall -Winvalid-pch -std=gnu11 -O2 -g -isystem /home/dummy/qemu-7.0.0-rc2/linux-headers -isystem linux-headers -iquote . -iquote /home/dummy/qemu-7.0.0-rc2 -iquote /home/dummy/qemu-7.0.0-rc2/include -iquote /home/dummy/qemu-7.0.0-rc2/disas/libvixl -iquote /home/dummy/qemu-7.0.0-rc2/tcg/i386 -pthread -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int -Wno-typedef-redefinition -Wno-tautological-type-limit-compare -Wno-psabi -fstack-protector-strong -fsanitize=cfi-icall -fsanitize-cfi-icall-generalize-pointers -fPIE -MD -MQ tests/qtest/qos-test.p/virtio-9p-test.c.o -MF tests/qtest/qos-test.p/virtio-9p-test.c.o.d -o tests/qtest/qos-test.p/virtio-9p-test.c.o -c ../tests/qtest/virtio-9p-test.c +In file included from ../tests/qtest/virtio-9p-test.c:18: +/home/dummy/qemu-7.0.0-rc2/hw/9pfs/9p.h:497:2: error: Missing definition for P9_XATTR_SIZE_MAX for this host system +#error Missing definition for P9_XATTR_SIZE_MAX for this host system + ^ +1 error generated. +ninja: subcommand failed +make[1]: *** [Makefile:163: run-ninja] Error 1 +make[1]: Leaving directory '/home/dummy/qemu-7.0.0-rc2/build' +make: *** [GNUmakefile:11: all] Error 2 +The command '/bin/sh -c make -j"`grep -c '^processor' /proc/cpuinfo`"' returned a non-zero code: 2 + +``` +Steps to reproduce: +1. build with attached Dockerfile +Additional information: +This problem is introduced by lore.kernel.org/all/20220227223522.91937-7-wwcohen@gmail.com/ + +`XATTR_SIZE_MAX` is in `<linux/limits.h>` which is included by `9p.c` but not `9p.h`. However the `9p.h` checks existence of XATTR_SIZE_MAX, so any other file including `9p.h` would be illegal. This is clearly misplacement of header including. diff --git a/results/classifier/105/mistranslation/961757 b/results/classifier/105/mistranslation/961757 new file mode 100644 index 000000000..887512028 --- /dev/null +++ b/results/classifier/105/mistranslation/961757 @@ -0,0 +1,39 @@ +mistranslation: 0.921 +instruction: 0.811 +semantic: 0.777 +graphic: 0.752 +other: 0.735 +device: 0.591 +socket: 0.378 +assembly: 0.309 +vnc: 0.274 +network: 0.265 +boot: 0.190 +KVM: 0.064 + +wrong error for blockdev-snapshot-sync + +From Laszlo Ersek: + +>> + proto_drv = bdrv_find_protocol(snapshot_file); +>> if (!proto_drv) { +>> - qerror_report(QERR_INVALID_BLOCK_FORMAT, format); +>> - ret = -1; +>> - goto out; +>> + error_set(errp, QERR_INVALID_BLOCK_FORMAT, format); +>> + return; +>> } +> +> I don't understand the logic here (based on the error message). We +> specified "format" for the case when a completely new snapshot file has +> to be created. If the file exists already, then bdrv_find_protocol() +> tries to find the driver for it. If that fails, then we must report an +> error indeed, but instead of referring to "format", we'd have to report +> the "scheme" from the beginning of "snapshot_file". + +Which version of QEMU was this? Is this still a problem with the latest version of QEMU? + +I can't find anything in the blockdev-snapshot-sync path that has this code in it still. Think it's a non-issue in 2017. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/963 b/results/classifier/105/mistranslation/963 new file mode 100644 index 000000000..5a29b4c72 --- /dev/null +++ b/results/classifier/105/mistranslation/963 @@ -0,0 +1,14 @@ +mistranslation: 0.857 +instruction: 0.822 +network: 0.652 +device: 0.642 +vnc: 0.528 +socket: 0.453 +graphic: 0.448 +assembly: 0.331 +other: 0.228 +boot: 0.226 +semantic: 0.215 +KVM: 0.120 + +qemu-7.0.0-rc2/migration/ram.c:1292: possible wrong operator ? diff --git a/results/classifier/105/mistranslation/988128 b/results/classifier/105/mistranslation/988128 new file mode 100644 index 000000000..33982ee05 --- /dev/null +++ b/results/classifier/105/mistranslation/988128 @@ -0,0 +1,52 @@ +mistranslation: 0.752 +graphic: 0.719 +device: 0.695 +semantic: 0.692 +other: 0.689 +socket: 0.689 +instruction: 0.600 +network: 0.580 +KVM: 0.529 +vnc: 0.509 +assembly: 0.461 +boot: 0.242 + +smbd crashes when called with "smb ports = 0" + +The smb.conf generated by qemu-kvm contains a "smb ports = 0" directive. This +causes at least version 3.6.4 of Samba to crash with + +[0] vostro:/tmp/qemu-smb.6836-0# smbd -i -s smb.conf +Unable to setup corepath for smbd: Operation not permitted +smbd version 3.6.4 started. +Copyright Andrew Tridgell and the Samba Team 1992-2011 +open_sockets_smbd: No sockets available to bind to. +=============================================================== +Abnormal server exit: open_sockets_smbd() failed +=============================================================== +BACKTRACE: 6 stack frames: + #0 smbd(log_stack_trace+0x1a) [0x7fe50c14f8ba] + #1 smbd(+0x6a0743) [0x7fe50c3bd743] + #2 smbd(+0x6a0a41) [0x7fe50c3bda41] + #3 smbd(main+0xa52) [0x7fe50be26d42] + #4 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd) [0x7fe508ac0ead] + #5 smbd(+0x10a6b9) [0x7fe50be276b9] + +Changing "smb ports" to a non-privilileged port works around the issue. + +I'd like to help fix this, but I am not sure what qemu-kvm's intention is here. +Zero is not a valid port, and the smb.conf manpage does not describe any +special meaning of zero here. I found that previous versions of samba apparently +did not bind to any port if zero was specified - but in that case, how is +qemu communicating with samba? + +It communicates via standard input (just like inetd). Obviously newer versions do not need this anymore, and smbd will detect in which mode it is supposed to run. + +That switch was once introduce in 157777ef3e to add "Samba 3 support". Maybe you can check with the samba guys if that switch was actually ever required or since when it became redundant. + +Sent a patch to qemu-devel, http://article.gmane.org/gmane.comp.emulators.qemu/148378 + +The link from comment #2 does not work anymore ... does anybody know whether the fix has been included in the QEMU repository? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/mistranslation/995758 b/results/classifier/105/mistranslation/995758 new file mode 100644 index 000000000..097a57cca --- /dev/null +++ b/results/classifier/105/mistranslation/995758 @@ -0,0 +1,30 @@ +mistranslation: 0.969 +instruction: 0.850 +graphic: 0.838 +device: 0.835 +semantic: 0.817 +other: 0.789 +socket: 0.651 +boot: 0.648 +network: 0.632 +vnc: 0.619 +assembly: 0.503 +KVM: 0.448 + +Possibly inaccurate statement in PC Platform Docs + +The documentation at: + +http://wiki.qemu.org/Documentation/Platforms/PC + +Contains the statement that the processor, after reset, executes code starting from address 0xFFFFF, corresponding to the last byte of the single megabyte of memory in the old 8086 address range. + +From my recollection of working in the microcomputer industry in the late 1980's, execution actually starts in real mode at the start of the last 16 bytes of addressable memory, at 0xFFFF0. Think about it - if it's the last byte there's no room for an address operand to accompany a 1-byte opcode. + +Oh, and if I recall correctly, on the 80286 and 80386 and 80486, on reset the amount of addressable memory was 16MiB, 4GiB and 4GiB respectively, and IBM made the choice to map the BIOS ROMs to both the top of addressable memory and at the top of the first MiB. The CPU's themselves always reset to near the top of their address range, and the BIOS writers promptly jumped back down to somewhere near the top of the first MiB. + + +As far as I can see, the wording on the page only says that the BIOS ends at address 0xFFFFF, not that it starts execution at exactly that address. So I think that page is ok. + +OK, I just read the text again, and the sentences before the one with the 0xfffff indeed sounded like the the start address was at the last byte. I've reworded the text now a little bit so that it should be more accurate. + diff --git a/results/classifier/105/mistranslation/996798 b/results/classifier/105/mistranslation/996798 new file mode 100644 index 000000000..9d72a0f30 --- /dev/null +++ b/results/classifier/105/mistranslation/996798 @@ -0,0 +1,31 @@ +mistranslation: 0.863 +device: 0.842 +instruction: 0.815 +vnc: 0.726 +graphic: 0.663 +socket: 0.583 +semantic: 0.582 +network: 0.552 +boot: 0.402 +other: 0.294 +assembly: 0.119 +KVM: 0.039 + +Incorrect order of task switching + +In Intel specifications (http://download.intel.com/design/processor/manuals/253668.pdf 7.3), we can see: + + 8. Saves the state of the current (old) task in the current task’s TSS. + +… + + 11. Loads the task register with the segment selector and descriptor for the new task's TSS. + +But, in QEMU code (https://raw.github.com/qemu/QEMU/v1.0/target-i386/op_helper.c :375), the order is reversed: TSS registers & segments loads BEFORE save old task state. + +Some bug in VirtualBox: https://www.virtualbox.org/ticket/10532 + +Is problem still reproducable with the latest version of QEMU, or has it been fixed nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + |